Почему ценности гибкой методологии не подходят для крупных проектов?
Еще один тренд недавно ушедшего 2018 года (который успешно перекочевал в 2019) – это распространение гибких методик (Agile) в управлении проектами. Те, кто внедряет их, выделяют целый ряд преимуществ, как то: снижение проектных рисков, увеличение предсказуемости хода работ, готовность к изменениям требований и приоритетов, возможность для заказчика увидеть в работе отдельные части проекта еще до окончания всех работ и многое другое.
Многие компании в IT-сфере и за ее пределами устремились к внедрению у себя Agile, боясь остаться за бортом прогресса. Но нюанс в том, что сфера информационных технологий, которая и подарила миру Agile, лучше всего на своем примере доказывает, что на деле это методология не улучшает работу на проекте, а помогает «правильно» оправдываться в том случае, когда что-то пошло не так.
Чтобы это доказать, давайте сначала вспомним ценности гибких методологий, которые задекларированы в Agile-манифесте. Их всего четыре, вот они:
- Люди и взаимодействие важнее процессов и инструментов.
- Работающий продукт важнее исчерпывающей документации.
- Сотрудничество с заказчиком важнее согласования условий контракта.
- Готовность к изменениям важнее следования первоначальному плану.
Любая методология разработки программного обеспечения, которая удовлетворяет этим четырем ценностям, может называться гибкой.
Что же с ними не так?
Еще в 60-х годах 20 века Наус и Фарр замерили, как количество программного кода влияет на продолжительность работы над проектом. Спойлер: плохо. Проще всего суть этого исследование пояснить на примере с каменщиками и кирпичами.
Предположим, у нас есть некий каменщик, который первый кирпич в своей жизни кладет за условные 10 минут, второй – за 9 минут и 30 секунд, десятый – за две минуты, а тысячный – уже за 3 секунды, не глядя, залипая в телефоне, другой рукой поедая свой обед. Что ему помогает? Приобретенный опыт, все логично.
Теперь представим программиста. Первую строчку своего кода он написал за 3 секунды (залипая в телефоне и так далее…), вторую – за условную минуту и уже без телефона, десятую – за 10 минут, а тысячную – за полдня. Как это вышло?! С учетом того, что программист получает фиксированную ежемесячную зарплату, выходит, что стоимость каждой его строчки растет по мере роста проекта.
Реальность в данном случае безжалостна: для программирования свойственно падение производительности труда по мере роста проекта. А следовательно — увеличение сроков разработки.
Не то чтобы программисты совсем ни в чем не виноваты в данном случае, но свою роль тут играют проблемы сложности, о которых можно почитать по ссылке.
Говоря кратко, писать ПО — дело сложное, все равно, что пожар тушить решетом. Отсюда и все проблемы.
Никогда не задумывались, почему компании, выпуская новую версию своего продукта, с гордостью заявляют, что она написана с нуля, без использования старого кода? Это противоречит здравому смыслу: старый код стоил много денег, зачем его выбрасывать, если в новой версии содержится в том числе функциональность старой?! Увы, это лишь попытка сохранить хорошую мину при плохой игре: потому что «на помойку» может отправиться проект стоимостью в десятки миллиардов долларов просто из-за того, что его дешевле выкинуть и переписать с нуля, чем изменить.
Итак, вокруг царит хаос, темпы разработки падают, потребность в квалифицированных программистах лавинообразно растет (а их количество что-то не очень). И вот, возможно, с традиционным боевым кличем «Это не баг, это фича!» существующие у них проблемы компании начинают подавать клиенту как плюшки. Более того, к этим плюшкам еще и придумывают красивое название – Agile.
Давайте рассмотрим несколько проблем, которые «покрывает» Agile. Каждую из проблем опишем с двух точек зрения: как её решают программисты и как решение подается клиенту.
Проблема №1. Нарушение сроков разработки
Программисты плохо сдерживают обещанные сроки. Проект оценивают, предполагая, что скорость разработки останется постоянной, без учета падения производительности труда. При этом, даже если все остальное сделано правильно, ошибка со сроками может достигать сотне процентов — в зависимости от объема работ.
Предлагаемое решение: итеративные процессы разработки. Предполагается, что при небольших объемах скорость разработки будет падать незначительно. А значит, можно дать более точную оценку.
Отказываемся от оценки всего проекта в целом. Разбиваем его на небольшие куски — фазы. И «едим слона» по чуть-чуть, перед каждой итерацией оценивая сроки только для нее.
Что мы говорим клиенту: Нам нужна обратная связь! После каждой итерации необходимо получать отзывы от заказчика, чтобы быть уверенным, что проект на верном пути. Обратная связь, безусловно, очень важна, но современные практики, например, Continuous Delivery, позволяют получить её в любой момент, не дожидаясь конца итерации.
Но итеративная разработка прижилась.
Что мы получаем на самом деле: производительность все равно падает. Итерации или нет, а производительность команды со временем снижается. Даже при итеративной работе вероятность ошибки будет только нарастать.
Какое решение мы бы предложили: Velocity. В Agile есть практика Velocity, которая заключается в определении коэффициента — разницы между фактическим объемом работы и планируемым, поделенная на планируемый объем работ. На этот коэффициент будет умножаться оценка следующей итерации.
То есть просто описываем нелинейную кривую производительности с помощью набора небольших линейных участков, уменьшая погрешность в собственной оценке. В математике такой прием называется кусочно-линейной аппроксимацией.
На самом деле это просто временной буфер, который каждый грамотный менеджер должен иметь при работе над проектом.
Проблема №2. Стоимость реализации требований увеличивается со временем
Увы, чем дольше мы откладываем некое изменение в проекте, тем дороже становится его вносить. В условиях падения производительности очень важно расставлять приоритеты, чтобы успеть реализовать те функции, за которые пользователь будет платить заказчику (или вам) деньги, пока весь бюджет не вылетел в трубу.
Как это подается клиенту: готовность к изменениям важнее следования первоначальному плану (четвёртая ценность Agile). Что мы имеем на деле? Заказчику приходится мириться с тем фактом, что будет реализован не весь функционал, который он хочет, а только тот, на который у него хватит денег. При этом заранее никто не знает, на что именно их хватит.
Что делать: расставлять приоритеты. Последовательность реализации действительно важна, да, нужно в первую очередь делать то, что приносит наибольшую выгоду — так что вопрос в том, как правильно оценить эту выгоду. Увы, как правило, оценка очень субъективная и меняется от итерации к итерации.
Проблема №3. Нет времени на документацию
Разработка кода — она как газ — пытается заполнить собой весь бюджет, выделенный на проект. И когда дело доходит до документации, от финансов остается полное ничего. При этом, как мы уже поняли, лихое падение производительности связано с необходимостью вносить правки в текст программы. При этом, документацию тоже должен кто-то править, а раз это тоже текст, то и правки в нем будут иметь такой же нелинейный характер. Так, может, лучше и не начинать вовсе?...
Как это подается клиенту: работающий продукт важнее исчерпывающей документации (третья ценность Agile). А на самом деле мы просто решаем отказаться от документирования.
Конечно, хороший код должен быть самодокументируемым — то есть, понятным настолько, чтобы не нуждаться в сопровождении документацией. Но и тут суровая к программистам реальность подкачала: мало кто может похвастаться, что в реальности встречал проект, где с документацией было бы все в порядке. Чаще всего её начинают писать, но потом бросают из-за того, что не хватает времени на разработку.
Проблема №4. Невозможно выполнить проект при соблюдении сразу всех трёх ограничений: функциональность, сроки, бюджет
Классический треугольник управления проектами описывает три ограничения: сроки, стоимость и содержание проекта. Проще говоря: «быстро», «дешево» или «качественно» - думаем, этот треугольник уж точно всем знаком. Изменение одного из параметров в данном случае влияет на два остальных. Чего хочет клиент? Качественно и за оговоренные деньги? Или в указанные сроки?
Сроки сложно выдержать, а значит, и управлять ими тоже. Тогда для сохранения функциональность необходимо увеличивать бюджет, а для сохранения бюджета урезать функциональность.
Как это подается клиенту: сотрудничество с заказчиком важнее согласования условий контракта (вторая ценность Agile). А на самом деле, мы должны признать, что для завершения проекта придется либо увеличивать бюджет, либо урезать функциональность. Заказчик, понятное дело, от обоих вариантов развития событий в восторг не придет. Проще говоря, на изменение бюджета или сокращение функциональности он согласится только если очень сильно доверяет исполнителю.
Проблема №5. В условиях, когда сроки сложно прогнозировать, результат проекта зависит от усилий и способностей конкретных исполнителей
Сроки сложно прогнозировать всегда, поэтому наилучший выход, придуманный в Agile – дать людям сполна прочувствовать коллективную ответственность за результат. На этой почве в здесь используется очень много психологических приемов, цель которых — сделать так, чтобы каждый человек эту ответственность на себя принял — и не юлил потом. Например, довольно часто программист может отказаться от ответственности за соблюдение сроков по отдельной задаче, если оценку давал не он сам. Так, конечно, дело не пойдет - «виноватых» потом не сыщешь.
Чтобы исключить подобную ситуацию, используется прием Planning Poker — задачи для очередной итерации проекта оцениваются коллективно и согласуются персонально с каждым членом команды.
Как это подается клиенту: люди и взаимодействие важнее процессов и инструментов (первая ценность Agile). Тут, пожалуй, и комментарии излишни - без взаимодействия ответственных за проект не найдешь и спустя годы.
*
Евгений Тюменцев, CEO «Hello World! Technologies»:
«Хочу заметить, что я ни в коем случае не нахожу ценности неверными или вредными. Каждая из них сама по себе приносит пользу. Дело в другом: Agile не решает проблему, которая существует в IT-отрасли с самого её появления, а вместо этого адаптирует к ней и заказчиков, и исполнителей. В этом плане Agile-манифест — отличное пособие о том, как недостатки превратить в преимущества. Но этого недостаточно для больших проектов».