Д. А. Градусов а. В. Шутов теоретические вопросы разработки программного обеспечения учебное пособие
жүктеу/скачать 2,75 Mb. Pdf көрінісі
|
| 4.
Собрание стоя Каждое утро проводится собрание для обсуждения проблем, их решений и для усиления концентрации команды. Собрание проводится стоя во избежание длительных дискуссий неинтересных всем членам команды. Большое количество времени людей тратится чтобы получить небольшое количество коммуникации. Поэтому участие всех людей в собраниях уводит ресурсы из проекта и создает хаос в планировании. Для такого рода коммуникаций и нужно собрание стоя. Намного лучше иметь одно короткое обязательное собрание, чем множество длинных на которых большинство разработчиков должно все равно присутствовать. Ежедневное утреннее собрание позволит избежать многих других собраний и сэкономит больше времени, чем на него затрачено. 5. Простота Простой дизайн всегда занимает меньше времени, чем сложный. Поэтому всегда делайте самые простые вещи, которые только смогут работать. Всегда быстрее и дешевле заменить сложный код сразу, прежде чем вы потратите много времени на работу с ним. Сохраняйте вещи такими простыми, как только возможно, не добавляя 54 функциональность до того, как это запланировано. Имейте в виду: сохранять дизайн простым — это тяжелая работа. 6. Система метафор Выбор системы метафор нужен для удержания команды в одних и тех же рамках при именовании классов и методов. Название объектов важно для понимания общего дизайна системы и повторного использования кодов. Если разработчик в состоянии правильно предугадать, как может быть назван существующий объект, это ведет к экономии времени. 7. Заказчик на рабочей площадке Основная проблема разработки программного обеспечения - недостаток знаний программистов в разрабатываемой предметной области. Для решения этой проблемы используется участие заказчика в процессе разработки. Экстремальное программирование учит нас находить самые простые решения — будет задан заказчику прямой вопрос. Более строгие подходы требуют всеобъемлющего предварительного анализа разрабатываемой области. Реальный опыт ведения приземленных проектов показывает, что невозможно собрать все требования заранее. Для этого фиксируется User Story — это описание того как система должна работать. Каждая User Story написана на карточке и представляет какой-то кусок функциональности системы, имеющий логический смысл с точки зрения Заказчика. жүктеу/скачать 2,75 Mb. Достарыңызбен бөлісу:
|