Скажем прямо, русскому человеку планировать тяжело. Люди в России сильны импровизацией и умением собираться в критический момент, выдавая поразительные результаты. Но жизнь показывает, что команда программистов на подобной идеологии далеко не уедет. Героические усилия в одно время не смогут компенсировать пофигизм в другое.
Что общего у зомби-апокалипсиса и разработки ПО? Простые правила помогают пережить и то, и другое
Этап планирования предполагает осознанную и целенаправленную деятельность команды на пути к достижению результата. Определить задачи, разбить на вехи, предвидеть сроки – необходимый шаг на пути воплощения задуманного. Особенно, если дело касается гибкой методологии Agile, которую считаем наилучшей.
Команды разработчиков допускают такие ошибки при планировании создания ПО.
1. Планировать сроки должны программисты, а не менеджеры.
Частая ошибка, когда руководитель проекта, не понимающий должным образом объем и специфику задач, устанавливает сроки проекта не в соответствии с опытом, возможностями и компетенциями команды, а опираясь на собственные представления, желания или запросы клиента. Программистам в подобных группах не позавидуешь. Расхождения запланированных и реальных сроков составляет 40-80%. Атмосфера в коллективе создается гнетущая и отбивающая желание работать. Проблемы следуют одна за другой, а виноватыми выставляются непосредственные разработчики.
2. Необходимо заранее определять примерные сроки сдачи всего проекта и реальное время решения задачи.
Отпускать процессы на самотек ни в коем случае нельзя. Игнорирование процедуры планирования приводит к расхлябанности, низкой мотивации разработчиков в предшествующие дедлайну периоды, к непониманию командой, что делать, куда двигаться и что нужно получить в итоге. В объединениях, где примерные сроки сдачи проекта не определяются, желательно задуматься о том, что подобный хаос до добра не доведет.
3. Проект разбивайте на мелкие этапы с четкими целями и обязательным обсуждением результатов.
Применение принципа необходимо для противодействия закону Паркинсона, определяющему, что общий объём работы всегда будет увеличиваться, чтобы заполнить всё выделенное на работу время. Следуя совету, можно избежать желания усердно трудиться лишь незадолго до срока сдачи проекта. Разбивка процесса достижения глобальной цели на контрольные периоды с необходимостью выполнения конкретных задач в течение недели – двух позволит использовать рабочий потенциал команды по максимуму. При указанном подходе поддерживается высокий уровень мотивации и работоспособности разработчиков на протяжении всего периода создания ПО и увеличивается вероятность достижения желаемых целей.
4. Члены команды должны максимально плотно взаимодействовать друг с другом.
Прежде всего повышается сплоченность коллектива и стимулируется оказание взаимопомощи. При недостаточном общении между членами объединения отсутствует «командный дух», обеспечивающий слаженную работу. Совместная продуктивная деятельность удовлетворяет социальные потребности человека в ощущении значимости выполняемого труда. Соблюдение принципа позволяет безболезненно заменить любого члена команды, потому что участники в курсе кто, что и как делает.
5. Включайте резерв времени для покрытия форс-мажора, новых требований заказчика, отпусков и праздников, на интеграцию и тестирование
На первоначальном этапе планирования нельзя предусмотреть все ситуации. Поэтому нужно зарезервировать время про запас, чтобы команде не пришлось торопиться и, как следствие, совершать ошибки. Не стоит игнорировать необходимость отладки и доведения ПО до уровня стабильной работы и приемлемого количества багов. Выпуск сырого продукта из-за жесткой экономии времени не разумен. Методология Agile предполагает изменчивость внешних условий и необходимость быстрой и безболезненной адаптации к ним.
6. Нельзя торопиться, нарушать план и уменьшать время разработки ПО.
Частая ошибка менеджеров, думающих, что программисты смогут потянуть любые сроки. Во-первых, команда демотивируется, саботирует процесс труда или пишет заявления по собственному желанию. Во-вторых, резкое ускорение рабочих операций истощает ресурсы организма и психики человека, ведет к профессиональному выгоранию. В-третьих, завышенный темп приводит к увеличению количества ошибок в коде. На отладку и исправление в будущем потребуется значительно больше времени, чем получится сэкономить подобным образом.
7. Документируйте планирование с помощью подходящей программы багтреккинга.
Выбор конкретной программы является вопрос вкуса. Планы следует фиксировать. Требуется наглядность как для разработчиков, так и для клиентов, сохраняя возможность для внесения изменений. Это позволяет улучшить взаимопонимание команды разработчиков, менеджмента и клиента. Снижается количество споров относительно трактовки рабочих действий. Четкость формулировки плана поможет избежать двоякого толкования.
8. Расставляйте приоритеты задачам и концентрируйтесь на главном.
Старайтесь в первую очередь реализовывать наиболее важный функционал. Имейте ввиду, что какими-то фичами в процессе разработки придется пожертвовать, равно как и реализацией части идей. А расставить приоритеты возможно исключительно через общение и обмен мнениями.
А что вы думаете по поводу планирования в разработке ПО? Оставляйте свои комментарии к статье. Мы будем рады услышать ваше мнение.
ссылка на оригинал статьи http://habrahabr.ru/post/272085/
Добавить комментарий