agile, scrum и житие мое 10
Хочу поделиться своими впечатлениями о работе в моем текущем проекте глазами разработчика, так сказать изнутри.
А если точнее то своим впечатлением от управления проектом по методологии agile. На сегодня слово agile уже набило оскому, не смотря на то, что точного перевода этого английского слова (в отношении к разработке) я еще не встречал. Поэтому все так и пишут — в оригинале. Как же эта красивая теория приживается на практике, в злободневной рутине?..
Лично мне до сих пор не понятно, почему именно разработчики в таком восторге от очередной новой теории управления проектами или методологии разработки. Ведь если разобраться, то любая из них направлена на то, чтобы выжать из команды максимум возможного результата (читай «заставить работать на полную катушку»). Что в принципе вполне оправдано со стороны начальства и заказчика, но в итоге не всегда легко решается самими разработчиками. Я не пишу, что agile — это зло или просто очередной «гемор» для разработчика, но он им может стать…
Итак, главная фишка agile методологии разработки — это непосредственное общение внутри команды, с минимумом спецификаций и других технических документов и с максимумом реального общения. Т.е. когда заказчик (или бизнес-представитель) сидит рядом с разработчиками и рассказывает что, как и где должно работать (очень упрощенное объяснение). Наиболее распространенный вариант agile-разработки — scrum еще подразумевает ежедневные встречи команды для кратких отчетов кто над чем работает и что собирается делать в ближайшие рабочие часы. Плюс процесс самой разработки делится на итерации (иногда так называемые «спринты») — временные отрезки с набором задач. В конце каждой итерации, понятное дело, подбивается итог и по общей успеваемости разработчиков можно рисовать картину успеваемости самого проекта.
Про преимущества agile, scrum и остального зоопарка по управлению проектами вы найдете кучу статей, а вот про недостатки я расскажу далее. На самом деле в самих теориях управления проектами как правило все гладко, но мы то знаем, что теория не стопроцентно ложится на рабочую действительность. Итак, типичные проблемы, которые появляются в работе agile-команд:
- команда распределена регионально (в смысле люди сидят в разных зданиях); сильно ухудшает коммуникацию; на самом деле при таком раскладе нормальный agile почти невозможен;
- бизнес/заказчик все таки пишет подробные спеки; в этом случае пролеты гарантированы, т.к. скорее всего спеки нормально писать в agile темпе никто не сможет;
- командой управляет не технический менеджер или менеджер который не может прочитать/подправить код; это просто беда, такой менеджер скорее всего будет стопорить работу лишними вопросами и пустыми разговорами;
Могу сказать еще, что работать по правилам agile действительно интересно и приятно в небольшой команде матерых профи. Но в проектах с большим количеством разработчиков, agile надо как-то адаптировать. Как вариант — делить команду на более мелкие группы по более узким направлениям. Еще могу привести пример, что agile вполне успешно приживается даже в распределенных командах, но с учетом того, что команда маленькая. Тот-же джаббер чат и скайп достаточно эффективно решает вопрос командной коммуникации.
Итак простой вывод для читателей-разработчиков: если на собеседовании на новую работу/проект вы услышали волшебное слово agile, не спешите радоваться :-) позадавайте побольше общих вопросов о команде, менеджерах и заказчиках.
Trackbacks
Use the following link to trackback from your own site:
http://livedev.org/trackbacks?article_id=agile-scrum-zhitie-moe&day=05&month=01&year=2008
Вот это явно показывает, что под "agile" каждый понимает свое :-). На большом количестве общения, если мне не изменяет память, настаивает только одна agile-методология -- XP. Но даже на, кажется, не настаивает на минимуме спецификаций.
И поэтому я как-то совсем не понимаю перечисленных дальше минусов, потому что в нашей agile-разработке их просто не появляется :-).
P.S. Напишу-ка я пост...
Спасибо за твою статью Иван. Буду комментировать ее, а не здесь :-)
Разный Agile
Не "аскомину", а "оскомину". :)
А где фид-бэк форма для баг-репортинга?
мм, если не видели раньше, достаточно интересное мнение об agile http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html
Неправильный подход изначально в статье: работодателю совсем нужно не то, чтобы работники много работали, а нужно, чтобы они делали именно то, за что будут платить деньги заказчики. Тут очень большая разница, поэтому остальные буквы в статье тоже не могут не быть пшиком.
Странно что вы называете это статьей. Это просто личная заметка о наболевшем. Не больше :-)
А за ссылку спасибо — прочту!
Илья,
Присоединяясь (почти) ко всем комментам Сагалаева, хочу сказать, что то, что ты описываешь - это не agile, а "чёрте-что и сбоку бантик", называемое в PR-целях agile. И действительно, самый характерный абзац в твоих "путевых заметках" - это призыв быть бдительным и не "вестись" на слово agile.
Это я всё к тому, что нет оснований по одной разработке, на которую лишь одета одёжка с лейблом, содержащим слово agile, судить как о собственно agile концепции/методе, так и о разработках, в которых делаются реальные (но, естественно, в разумных пределах :) ) усилия по воплощению этой концепции и метода "в реальную" жисть/житие ;)
По этому пункту я не согласен. Менеджер не должен править код. Я видел отличных менеджеров которые в код не смотрели. Поверьте мне, менеджеру есть чем заняться и без кода :)
" командой управляет не технический менеджер или менеджер который не может прочитать/подправить код; это просто беда, такой менеджер скорее всего будет стопорить работу лишними вопросами и пустыми разговорами "
Сергей, я не писал что менеджер должен править код. Но он должен уметь!
Потому что, софтварный менеджер должен знать особенности языка и платформы на которой пишется продукт.
Вот PR менеджеру не обязательно знать технические детали, согласен. Но тот кто работает с тех. персоналом должен уметь говорить на их языке :-)
Это опять же мое личное мнение...
Павел, это действительно не полноценный agile. Но оно пытается им быть :-)
Дело в том, что я сделал главный вывод для себя. Agile ложиться с наименьшими запарками на небольшие локальные команды. Остальные случаи могут быть не менее удачные, но с бОльшими затратами.