Письмо в редакцию: Забудьте об Agile и вспомните о людях03.06.2016 13:09

Если вы сильно увлечены Agile — скорее всего, вы дилетант. И дело не в том, что Agile или Scrum не работают, а в том, что никаких особых методологий де-факто не существует. Даже каноническое сравнение «водопада» и итерационного подхода — это, по сути, лишь спор о размере итерации.

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

Почему фанаты Agile цепляются за идею недельных или двухнедельных спринтов? Им кажется, что стоит только применить модный подход — и задачи начнут решаться не за месяцы, а за недели. Только вот с задачами, которые можно выполнить за неделю-две или декомпозировать на такие подзадачи, проблем нет. Трудности возникают, когда задача либо не дробится на более мелкие, либо так или иначе связана со всем продуктом, и ее нельзя решить наскоком.

Самое страшное, что все методологии опускают одну фундаментальную переменную — производительность специалиста.

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

Но это полная ерунда. Даже токарь или забойщик выдают очень разный результат в зависимости от своей мотивации: вспомните стахановское движение. А у работника умственного труда производительность запросто может отличаться в сотни раз. Один и тот же программист с одной и той же задачей при одних и тех же условиях может расправиться за час, а может провозиться полмесяца. Думаете, я преувеличиваю?

Знаете эти веселые тесты на IQ, где сначала кажется, что задача нерешаема, но стоит посмотреть на нее под другим углом — и все получается? А теперь представьте, что уверенности в наличии решения нет. Вы легко потратите сотню часов, доказывая невыполнимость задачи, вместо того чтобы все-таки поискать. Попытайтесь поставить дедлайн или назначить премию за найденное решение — и все станет только хуже. Это отлично доказал в 1935 году тест Карла Данкера.

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

Люди удивительно цикличны в своей мотивации. Фазы усталости сменяются фазами гиперактивности и сообразительности, причем усталость наступает обычно после достижения цели, а гиперактивность — во время приближения к ней.

Цель и радость достижения цели мотивируют. Стабильная и равномерная нагрузка убивает.

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

Хотите вывести команду на пик ее возможностей? Дайте ей цель, победу и, самое главное, возможность отдохнуть. Рывок, победа, отдых; рывок, победа, отдых — вот цикл, при котором мы максимально эффективны.

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

Методологии, призывающие нас превратить разработку в вечный поток мелких задач, слишком много внимания уделяют отношениям с заказчиком, работе с требованиями, но абсолютно пренебрегают разработчиком. Люди не машины, на них нельзя равномерно подавать задачи на обработку.

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

Не стоит забывать, что мы работаем не с проектом, а с людьми.