Agile Methodology: 10 заповедей. 1-3.

J.D.Meier в своём блоге как-то давал описание agile-методологи, как её применяют в Microsoft’е. Там же он привёл 10 заповедей Agile, которые мне показались весьма интересными и, как мне кажется, незаслуженно неприменяемыми у нас.

Начну с первых трёх.

1. 40-часовая рабочая неделя. Хотя казалось бы, ведь чем больше работаешь, тем лучше? В нашей среде, по моим наблюдениям, слишком многие к рабочим часам относятся легкомысленно. С одной стороны я согласен с тем, что программирование дело творческое, а творчество по расписанию не бывает. Но всё же и другое верно: порядок и организация важны во всём. А умение себя организовать, а не ждать возможного визита музы — залог успеха. Работая по 40 часов в неделю, все члены команды соблюдают баланс между личной жизнью и работой, что уже хорошо. Это также способствует выработке размеренного режима работы вместо постоянного аврала.

Но вот интересная и свежая мысль: 40-часовая рабочая неделя всегда оставляет буфер для реагирования на действительно непредвиденные обстоятельства!

2. Исследования и испытания. Выделение отдельной фазы на исследования — тоже хорошая идея. Это то время, когда можно изучить и проверить новые технологии и возможности, оценить технологические риски, понять нужды пользователей. Прикидывая основные элементы архитектуры, можно довольно быстро понять потенциальные узкие места, которые могут повлиять на разработку проекта, причём ещё задолго до того, как он в действительности начнётся.

Обычно в Microsoft эта фаза длится от 4 до 8 недель. А за счёт того, что время и бюджет этой фазы ограничены, во-первых снижаются риски для бизнеса, а во-вторых, появляется возможность поймать и не упустить новые возможности.

3. Демонстрации. Демонстрации — это ключ к успеху продукта, если их делать достаточно рано. Они служат двум основным вещам. Прежде всего, готовясь к демонстрации, вы собираете всё то, что успели сделать, в пригодную для показа форму. И может оказаться, что то, что прекрасно выглядит на бумаге или в вашем воображении, не так хорошо в момент собственно показа. Так что демонстрация это отличное средство для определения того, что действительно имеет значение, а что лишнее.

Второе значение демонстрации — это получение обратной связи. На закрытых демо каждый член команды получает обратную связь от коллег, а на открытых есть шанс получить актуальные отзывы от реальных пользователей.

Демо хорошо проводить регулярно, привязав к итерациям. Например, в команде J.D.Meier’а в Microsoft демонстрации проходят каждую неделю по четвергам. А чем быстрее поймёшь, в чём ты прогадал, а в чём преуспел — тем лучше. Ошибки выявляются быстрее, и тут же есть возможность узнать, почему это не нравится пользователям, и как сделать лучше.