agile, scrum и житие мое

05 Jan 2008


Хочу поделиться своими впечатлениями о работе в моем текущем проекте глазами разработчика, так сказать изнутри.

А если точнее то своим впечатлением от управления проектом по методологии agile. На сегодня слово agile уже набило оскому, не смотря на то, что точного перевода этого английского слова (в отношении к разработке) я еще не встречал. Поэтому все так и пишут — в оригинале. Как же эта красивая теория приживается на практике, в злободневной рутине?..

Лично мне до сих пор не понятно, почему именно разработчики в таком восторге от очередной новой теории управления проектами или методологии разработки. Ведь если разобраться, то любая из них направлена на то, чтобы выжать из команды максимум возможного результата (читай «заставить работать на полную катушку»). Что в принципе вполне оправдано со стороны начальства и заказчика, но в итоге не всегда легко решается самими разработчиками. Я не пишу, что agile — это зло или просто очередной «гемор» для разработчика, но он им может стать...

Итак, главная фишка agile методологии разработки — это непосредственное общение внутри команды, с минимумом спецификаций и других технических документов и с максимумом реального общения. Т.е. когда заказчик (или бизнес-представитель) сидит рядом с разработчиками и рассказывает что, как и где должно работать (очень упрощенное объяснение). Наиболее распространенный вариант agile-разработки — scrum еще подразумевает ежедневные встречи команды для кратких отчетов кто над чем работает и что собирается делать в ближайшие рабочие часы. Плюс процесс самой разработки делится на итерации (иногда так называемые «спринты») — временные отрезки с набором задач. В конце каждой итерации, понятное дело, подбивается итог и по общей успеваемости разработчиков можно рисовать картину успеваемости самого проекта.

Про преимущества agile, scrum и остального зоопарка по управлению проектами вы найдете кучу статей, а вот про недостатки я расскажу далее. На самом деле в самих теориях управления проектами как правило все гладко, но мы то знаем, что теория не стопроцентно ложится на рабочую действительность. Итак, типичные проблемы, которые появляются в работе agile-команд:

  • команда распределена регионально (в смысле люди сидят в разных зданиях); сильно ухудшает коммуникацию; на самом деле при таком раскладе нормальный agile почти невозможен;
  • бизнес/заказчик все таки пишет подробные спеки; в этом случае пролеты гарантированы, т.к. скорее всего спеки нормально писать в agile темпе никто не сможет;
  • командой управляет не технический менеджер или менеджер который не может прочитать/подправить код; это просто беда, такой менеджер скорее всего будет стопорить работу лишними вопросами и пустыми разговорами;

Могу сказать еще, что работать по правилам agile действительно интересно и приятно в небольшой команде матерых профи. Но в проектах с большим количеством разработчиков, agile надо как-то адаптировать. Как вариант — делить команду на более мелкие группы по более узким направлениям. Еще могу привести пример, что agile вполне успешно приживается даже в распределенных командах, но с учетом того, что команда маленькая. Тот-же джаббер чат и скайп достаточно эффективно решает вопрос командной коммуникации.

Итак простой вывод для читателей-разработчиков: если на собеседовании на новую работу/проект вы услышали волшебное слово agile, не спешите радоваться :-) позадавайте побольше общих вопросов о команде, менеджерах и заказчиках.

coding monkey