Разный Agile

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

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

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

В качестве свежего личного примера хочу привести наш готовящийся скоро к выпуску проект в Яндексе. Мы не пытались построить процесс по какой-то конкретной описанной методологии (и уж тем более не по XP, которую я просто не люблю). Я даже думаю, что многие участники проекта и не знают, что мы работаем по "agile-методологии" :-). Вместо этого мы просто применяем принципы, которые кажутся разумными, и в итоге проблемы, которые Илья упоминает в статье, у нас просто не случились:

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

Наша команда распределена по Екатеринбургу, Москве и Питеру, причем разделение идет прямо "по-живому": например питоновый код и HTML'ные шаблоны пишут люди в разных городах. Оперативная коммуникация идет через Jabber, но основа общения между участниками проекта — баг-тракинг. Мы пользуемся им очень активно, и это одна из составляющих нашей гибкости: мы всегда знаем, что нам нужно делать, от чего можно безболезненно отказаться, и во что нам встанет очередное изменение направления развития.

бизнес/заказчик все таки пишет подробные спеки; в этом случае пролеты гарантированы, т.к. скорее всего спеки нормально писать в agile темпе никто не сможет;

Вот с этим я не согласен максимально. Без спецификаций работать по agile-методологии вообще невозможно, потому что в спецификации написано текущее согласованное видение всех участников проекта о том, буквально, куда все идут! Если не знать этого, то совершенно невозможно куда-то гибко поворачивать.

Кто их будет писать — вопрос второстепенный, на самом деле. У нас их пишет тот, у кого получатся полно и читаемо формулировать (я :-) ). Но что именно туда писать, определяется в общении с заказчиками, менеджерами и разработчиками. Большой ошибкой Ильи мне тут кажется то, что он воспринимает подробные спецификации от заказчика помехой темпу разработки, который устанавливается целью agile-методологии. На мой взгляд, темп — это вторично, он появляется сам по себе, если все остальное делается правильно. И отказ от написания читаемых и всем понятных спецификаций здесь точно не помогает.

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

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

Другими словами, нетехнический менеджер может быть очень полезен. Его только не надо грузить несвойственными ему полномочиями.

Есть, кстати, место в статье, где я на 100% с Ильей согласен:

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

+1

Ускользающие методологии

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

1. Сделать предварительные наблюдения и оценки
2. Произвести магию
3. Обработать результаты и сделать выводы

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