«Всё — яд, всё — лекарство; то и другое определяет доза.»
Парацельс
Принято отсчитывать историю Agile от февраля 2001 года, когда появился на свет довольно странный документ — Agile Manifesto. По большому счёту текст документа скомпонован из философских очевидностей (например, «простота — искусство не делать лишней работы») и спорных утверждений (например, «лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды»). Но этот документ странен не столько своим содержанием (мало ли что может прийти в голову на лыжном курорте), сколько эпичностью последовавших изменений в отрасли разработки программного обеспечения. В кратчайшее время появилось множество методик, реализующих методологию «гибкой» разработки, которые торжественным маршем пошли по миру, захватывая умы Исполнителей и кошельки Заказчиков. Адептами этот движ преподносится как некая волшебная пилюля, решающая всё. Дошло до того, что благородному дону честному программисту уже стало неприличным признаться в причастности к разработке ПО по традиционной ориентации методологии. Попробуем же разобраться в причинах и следствиях явления, на примере Scrum-а, как наиболее распространённого проявления Agile.
Для начала попытаемся понять, что же действительно нового мы получили в обёртке Agile вообще и Scrum-а в частности.
Scrum в древнем Египте
Возьму на себя смелость утверждать, что гибкая методология вообще, и методика Scrum в частности, существовали всегда, хотя так и не назывались. Они вообще никак не назывались, а были просто наиболее естественным и эффективным способом вести свои внутренние проекты (ключевое слово тут — «внутренние»).
Вот, например, задумал древнеегипетский фараон построить пирамиду и… понеслось. Обсудил идею со жрецами (stakeholders) и назначил своего виночерпия ответственным за проект (product owner). Виночерпий подыскал грамотного каменщика (scrum master). Каменщик нанял помошников (scrum team), а те пошли на невольничий рынок и набрали рабов (рабочие инструменты: ПК, сервера, софт для разработки и т.д.).
Так как фараон приказал ежемесячно докладывать ему о ходе строительства, то каменщик (с помощниками) стал ежемесячно проводить показ стройки (demo) для виночерпия. Во время показа обсуждалось не только уже сделанное (retrospective), но и составлялся план на следующий месяц (sprint). Для того, чтобы ничего не упустить, виночерпий весь месяц обсуждал со жрецами их хотелки (user stories) и записывал в специальный пергамент (backlog), из которого хотелки попадали в план следующего месяца. Ну и так далее. Я не знаю, как тогда выглядели стикеры, scrum board и burndown-диаграммы. Любой грамотный руководитель подбирает себе наиболее удобные инструменты для управления и контроля проекта. Детали тут не важны, главное, что методика работает.
Т.е. думаю, что все руководители во все времена использовали гибкую методику для создания своего внутреннего (на свой страх и риск) продукта потому, что:
- достаточно компетентны для проектирования конечного результата;
- достаточно компетентны для контроля за ходом процесса;
- имеют достаточно власти над подчинёнными участниками процесса;
- соотношение срока, стоимости и качества работ не являются для них догмой и могут при необходимости пересматриваться (так как «сам себе хозяин»);
- а самое главное — и конечный результат и процесс его достижения находится в одних руках, и преследуют один коммерческий интерес.
Но для внешнего Заказчика неприменим ни один из пунктов данного списка, поэтому для внешних (заказных) проектов гибкая методика не использовалась практически никогда (исключения только подтверждают правило). Ведь народ был простой и нетолерантный, за вопиющее превышение сроков и смет могли и на голову укоротить.
Scrum в наше время
Единственная новизна современного Scrum-а состоит в факте его использования для реализации внешних (заказных) проектов. Эту сторону вопроса стараются не выпячивать, ведь потянув за ниточку можно вытянуть на свет реальную мотивацию участников рынка. По сути дела, манифест Agile и вся аргументация Scrum являются чистой пропагандой интересов Исполнителя, для приличия завуалированной под борьбу за всё хорошее против всего плохого. В том и состоит гениальность решения, что позволяет убедить Заказчика пожертвовать результатом ради процесса!
Итак, что же меняется, если product owner является сотрудником другой, а не своей, компании? Главное отличие в том, что конечный результат и процесс его достижения теперь находится по разные стороны «баррикады» и каждая из сторон преследует только свой коммерческий интерес. Заказчику важен результат, а Исполнителю — процесс. По-другому и быть не может — ведь «ничего личного, это только бизнес».
Agile выгоден игрокам IT-рынка, так как им предоставляет возможность:
- зарабатывать на процессе и не нести ответственность за результат;
- сократить расходы на грамотные руководящие кадры (стоят они дорого, но ведь проектировать теперь ничего не нужно и ТЗ писать не нужно, а процесс теперь контролирует product owner Заказчика).
А раз это выгодно, то прямо на наших глазах программистские коллективы с костяком из высококвалифицированных и системно-мыслящих профессионалов могут превратиться в фермы сдаваемых внаём кодеров средней руки.
Попробуйте поставить себя на место человека, который нанимает бригаду строителей для ремонта своей квартиры и пытается добиться от бригадира сроков и стоимости ремонта, а в ответ слышит:
- мы люди творческие, поэтому работать будем «как пойдёт», но Вы оплачиваете каждый час работы бригады и материалы;
- общего проекта и плана мы делать не будем, разберёмся по ходу дела (если и сделаем что-то неправильно, потом переделаем за дополнительно оплаченное Вами время и дополнительные материалы);
- будем показывать результаты своей работы каждые две недели и рассказывать о своих проблемах, а затем вместе будем планировать следующие две недели.
Вряд ли кто-то согласится с таким предложением, а Заказчики IT-шников соглашаются! Вот что делает пропаганда животворящая!
Мало того, что Заказчика убеждают согласиться на непредсказуемые сроки и стоимость, так ещё и перекладывают на него всю ответственность за неудачи. Как правило, квалификация Заказчика не позволяет формализовать требования к конечному результату и профессионально контролировать ход процесса. Поэтому, всегда можно его запутать и отвлечь (при отсутствии общего ТЗ) на решение множества второстепенных вопросов (которые и возникают чаще всего из-за отсутствия долгосрочного планирования).
Последствия Agile-поклонства
Вам не кажется, что качество программных продуктов падает пропорционально широте распространения Agile в отрасли? Откуда взяться качеству, если весь процесс заточен на решении задач самым простым и быстрым способом из всех возможных? А думать вперёд официально запрещено методологией!
Вам не кажется, что программные продукты всё чаще превращаются в «лоскутные одеяла», когда с удивлением замечаешь, что разные разделы одного и того же ПО как будто сделаны совершенно разными людьми? И даже на одном экране программы могут смешаться разные стили оформления, разные подходы эргономики и разные алгоритмы функционирования аналогичных элементов управления. Но ведь ТЗ и Style Guide на продукт отсутствуют, значит кому как привычнее, тот так и сделает! А QA-персонал, как и все, зажат рамками сроков спринта.
О чём это всё?
Из всего вышеизложенного может показаться, что я являюсь ярым Agile-ненавистником. Но это вовсе не так! И я вовсе не старался кого-либо обидеть! Всего лишь старался нагляднее проиллюстрировать вынесенные в эпиграф слова великого Парацельса.
Гибкая методология вполне пригодна для внутренних малых и даже средних проектов. Размер проекта ограничивается только способностями конкретного руководителя «не потерять лес за деревьями», т.е. умением держать в уме, как все подробности, так и желаемый результат, не систематизируя это «на бумаге».
Гибкая методология ограничено пригодна и для внешних проектов. В этом случае, к product owner-у Заказчика применимы те же требования, что и к руководителю внутреннего проекта, т. е. этот человек должен быть настоящим IT-профессионалом, а не секретарём тянущим временную обузу по-совместительству. Он должен быть в состоянии проверить квалификацию нанятой команды и постоянно контролировать качество разрабатываемого продукта. Кроме того, сам разрабатываемый продукт должен позволять (в случае форс-мажора) замену команды разработчиков. Только в этом случае можно рассчитывать, что не будет «обидно и больно за бесцельно прожитые годы».
Как видите, у Agile есть своё место под солнцем, но оно сильно ограничено в сфере контрактных IT-разработок. Что же делать, если Ваш проект не попадает в категорию Agile-пригодных?
Вам не кажется подозрительным тот факт, что гибкая методология не прижилась нигде, кроме контрактных разработок программного обеспечения? Ну не делают по Scrum-у ни подводные лодки, ни самолёты, ни автомобили. Мудрость предков учит нас, что даже нормальную собачью будку нельзя сколотить без этапа проектирования (карандашный набросок с размерами) и подготовки ТЗ (перечень материалов и инструментов). Всё что вы видите вокруг (от табуретки до космического корабля) создано по старому доброму «водопаду» (waterfall). Почему бы и Вам не поступить так же? И помните — всё будет хорошо!
P.S.
Всё сказанное основано на моём личном немалом (19 лет) опыте контрактных веб-разработок с использованием как традиционного (Waterfall) так и прогрессивного (Scrum) подходов. Побудительным мотивом для написания статьи явились моральные муки от созерцания очередного «чуда враждебных технологий», слепленного по заветам великого Франкенштейна для одной уважаемой западной компании.
Автор: Pran
