На прошлой неделе вышла заметка Михаила Токовинина «Забудьте об Agile, вспомните о людях». Несколько человек очень сильно просили её прокомментировать.

Сложно догадаться, зачем Михаил решил опубликовать статью. Возможно, нравится слава пророка «Все плохо. Web умер. Agile не работает». А, может быть, нравятся провокации. Разберем ошибки:

Начнем сначала. Заголовок. Михаил призывает забыть об Agile и вспомнить о людях. Однако один из КЛЮЧЕВЫХ принципов Agile — люди и взаимодействие важнее процессов и инструментов. Принципы были сформулированы еще в 2001 году очень умными и опытными людьми, и оформлены в Agile Manifest. Катахреза в заголовке — это либо неосведомленность автора в вопросе, либо очень толстый троллинг. В прочем, вряд ли неосведомленность — обычно создается впечатление что Михаил хорошо знает что делает :)

«Даже каноническое сравнение «водопада» и итерационного подхода — это, по сути, лишь спор о размере итерации«, вторая ошибка. Автор делает вид, что в гибких методологиях нет никаких значимых артефактов, кроме итераций. А ведь там много чего есть хорошего: от четких проектных ролей, принципов приоритизации backlog, до грамотных командных активностей, типа ретроспектив. Все это либо по «канонически» отсутствует в водопаде, либо начинает придумываться на ходу. Импровизационно. Не то, что бы импровизация — это всегда плохо (хороший менеджер должен уметь создавать необходимые ему инструменты). Плохо, что при этом не изучены или не приняты во внимание базовые вещи из Agile. Их кстати, лучше учить не по выступлениям Германа Грефа :), а прочитать хотя бы википедию или Agile-чеклист от ScrumTrek. А еще лучше — книги Хенрика Книберга (это чтение не на пятнадцать минут, а на пару вечеров).

"Самое страшное, что все методологии опускают одну фундаментальную переменную — производительность специалиста", — пишет Михаил. Ошибка № 3. Дело в том, что именно в Agile очень четко осознают, что производительность зависит от огромного числа факторов. От сработанности команды. От опыта. От интереса к задаче. От больного зуба. Да мало ли. Именно поэтому в Agile существуют такие понятия как оценки в Story Point, Velocity и диаграмма сгорания спринта Sprint Burndown chart. Эти артефакты появились не на пустом месте, а как результат осмысления тех проблем, с которыми сталкивались команды разработки софта. Очень ярко рассказана история Scrum и предпосылки его возникновения в книге Джеффа Сазерленда (бывший военный летчик, стоявший у истоков создания scrum). Например, наглядно показано, что люди очень плохо умеют оценивать объем работы в абсолютных величинах, но намного лучше делают это в относительных. По сути, именно в гибких методиках делается хорошая попытка визуализировать прогресс команды относительно её предыдущих успехов. Ни в каких водопадах в принципе нет ничего подобного. Тюнинг в виде Planning Poker — это тоже работа в первую очередь с людьми, цель которой — сделать сложный процесс оценок более простым и независящим от авторитетов.

"Рывок, победа, отдых; рывок, победа, отдых — вот цикл, при котором мы максимально эффективны", — единственная здравая мысль во всей статье. Ирония в том, что для достижения именно такого ритма и были придуманы гибкие методологии, подготовка в виде планирования, спринты, демонстрации, ретроспективы. И они прекрасно работают, если их знать и уметь применять.

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

1. фанатизм и пыл уже утих;

2. разочарование, что Scrum — не серебряная пуля — стихло;

3. адепты культа карго угомонились;

4. наступает понимание, что Scrum имеет самый существенный недостаток, свойственный всем инструментам: ИМИ РАБОТАТЬ НУЖНО.

Нужно знать не только то, что методология МОЖЕТ, но и то, чего она НЕ МОЖЕТ. Причем второе — существеннее. Зона применимости инструмента. Точно так же, как мы не применяем молоток для микросхем или фотошоп для набора текстовых документов.