Хабрахабр

[Из песочницы] Мифы и легенды Agile — oт фараонов до наших дней

«Всё — яд, всё — лекарство; то и другое определяет доза.»
Парацельс

По большому счёту текст документа скомпонован из философских очевидностей (например, «простота — искусство не делать лишней работы») и спорных утверждений (например, «лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды»). Принято отсчитывать историю Agile от февраля 2001 года, когда появился на свет довольно странный документ — Agile Manifesto. В кратчайшее время появилось множество методик, реализующих методологию «гибкой» разработки, которые торжественным маршем пошли по миру, захватывая умы Исполнителей и кошельки Заказчиков. Но этот документ странен не столько своим содержанием (мало ли что может прийти в голову на лыжном курорте), сколько эпичностью последовавших изменений в отрасли разработки программного обеспечения. Дошло до того, что благородному дону честному программисту уже стало неприличным признаться в причастности к разработке ПО по традиционной ориентации методологии. Адептами этот движ преподносится как некая волшебная пилюля, решающая всё. Попробуем же разобраться в причинах и следствиях явления, на примере Scrum-а, как наиболее распространённого проявления Agile.
Для начала попытаемся понять, что же действительно нового мы получили в обёртке Agile вообще и Scrum-а в частности.

Scrum в древнем Египте

Они вообще никак не назывались, а были просто наиболее естественным и эффективным способом вести свои внутренние проекты (ключевое слово тут — «внутренние»). Возьму на себя смелость утверждать, что гибкая методология вообще, и методика Scrum в частности, существовали всегда, хотя так и не назывались.

Обсудил идею со жрецами (stakeholders) и назначил своего виночерпия ответственным за проект (product owner). Вот, например, задумал древнеегипетский фараон построить пирамиду и… понеслось. Каменщик нанял помошников (scrum team), а те пошли на невольничий рынок и набрали рабов (рабочие инструменты: ПК, сервера, софт для разработки и т.д.). Виночерпий подыскал грамотного каменщика (scrum master).

Во время показа обсуждалось не только уже сделанное (retrospective), но и составлялся план на следующий месяц (sprint). Так как фараон приказал ежемесячно докладывать ему о ходе строительства, то каменщик (с помощниками) стал ежемесячно проводить показ стройки (demo) для виночерпия. Ну и так далее. Для того, чтобы ничего не упустить, виночерпий весь месяц обсуждал со жрецами их хотелки (user stories) и записывал в специальный пергамент (backlog), из которого хотелки попадали в план следующего месяца. Любой грамотный руководитель подбирает себе наиболее удобные инструменты для управления и контроля проекта. Я не знаю, как тогда выглядели стикеры, scrum board и burndown-диаграммы. Детали тут не важны, главное, что методика работает.

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

  • достаточно компетентны для проектирования конечного результата;
  • достаточно компетентны для контроля за ходом процесса;
  • имеют достаточно власти над подчинёнными участниками процесса;
  • соотношение срока, стоимости и качества работ не являются для них догмой и могут при необходимости пересматриваться (так как «сам себе хозяин»);
  • а самое главное — и конечный результат и процесс его достижения находится в одних руках, и преследуют один коммерческий интерес.

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

Scrum в наше время

Эту сторону вопроса стараются не выпячивать, ведь потянув за ниточку можно вытянуть на свет реальную мотивацию участников рынка. Единственная новизна современного Scrum-а состоит в факте его использования для реализации внешних (заказных) проектов. В том и состоит гениальность решения, что позволяет убедить Заказчика пожертвовать результатом ради процесса! По сути дела, манифест Agile и вся аргументация Scrum являются чистой пропагандой интересов Исполнителя, для приличия завуалированной под борьбу за всё хорошее против всего плохого.

Главное отличие в том, что конечный результат и процесс его достижения теперь находится по разные стороны «баррикады» и каждая из сторон преследует только свой коммерческий интерес. Итак, что же меняется, если product owner является сотрудником другой, а не своей, компании? По-другому и быть не может — ведь «ничего личного, это только бизнес». Заказчику важен результат, а Исполнителю — процесс.

Agile выгоден игрокам IT-рынка, так как им предоставляет возможность:

  • зарабатывать на процессе и не нести ответственность за результат;
  • сократить расходы на грамотные руководящие кадры (стоят они дорого, но ведь проектировать теперь ничего не нужно и ТЗ писать не нужно, а процесс теперь контролирует product owner Заказчика).

А раз это выгодно, то прямо на наших глазах программистские коллективы с костяком из высококвалифицированных и системно-мыслящих профессионалов могут превратиться в фермы сдаваемых внаём кодеров средней руки.

Попробуйте поставить себя на место человека, который нанимает бригаду строителей для ремонта своей квартиры и пытается добиться от бригадира сроков и стоимости ремонта, а в ответ слышит:

  • мы люди творческие, поэтому работать будем «как пойдёт», но Вы оплачиваете каждый час работы бригады и материалы;
  • общего проекта и плана мы делать не будем, разберёмся по ходу дела (если и сделаем что-то неправильно, потом переделаем за дополнительно оплаченное Вами время и дополнительные материалы);
  • будем показывать результаты своей работы каждые две недели и рассказывать о своих проблемах, а затем вместе будем планировать следующие две недели.

Вряд ли кто-то согласится с таким предложением, а Заказчики IT-шников соглашаются! Вот что делает пропаганда животворящая!

Как правило, квалификация Заказчика не позволяет формализовать требования к конечному результату и профессионально контролировать ход процесса. Мало того, что Заказчика убеждают согласиться на непредсказуемые сроки и стоимость, так ещё и перекладывают на него всю ответственность за неудачи. Поэтому, всегда можно его запутать и отвлечь (при отсутствии общего ТЗ) на решение множества второстепенных вопросов (которые и возникают чаще всего из-за отсутствия долгосрочного планирования).

Последствия Agile-поклонства

Откуда взяться качеству, если весь процесс заточен на решении задач самым простым и быстрым способом из всех возможных? Вам не кажется, что качество программных продуктов падает пропорционально широте распространения Agile в отрасли? А думать вперёд официально запрещено методологией!

И даже на одном экране программы могут смешаться разные стили оформления, разные подходы эргономики и разные алгоритмы функционирования аналогичных элементов управления. Вам не кажется, что программные продукты всё чаще превращаются в «лоскутные одеяла», когда с удивлением замечаешь, что разные разделы одного и того же ПО как будто сделаны совершенно разными людьми? А QA-персонал, как и все, зажат рамками сроков спринта. Но ведь ТЗ и Style Guide на продукт отсутствуют, значит кому как привычнее, тот так и сделает!

О чём это всё?

Из всего вышеизложенного может показаться, что я являюсь ярым Agile-ненавистником. Но это вовсе не так! И я вовсе не старался кого-либо обидеть! Всего лишь старался нагляднее проиллюстрировать вынесенные в эпиграф слова великого Парацельса.

Размер проекта ограничивается только способностями конкретного руководителя «не потерять лес за деревьями», т.е. Гибкая методология вполне пригодна для внутренних малых и даже средних проектов. умением держать в уме, как все подробности, так и желаемый результат, не систематизируя это «на бумаге».

В этом случае, к product owner-у Заказчика применимы те же требования, что и к руководителю внутреннего проекта, т. е. Гибкая методология ограничено пригодна и для внешних проектов. Он должен быть в состоянии проверить квалификацию нанятой команды и постоянно контролировать качество разрабатываемого продукта. этот человек должен быть настоящим IT-профессионалом, а не секретарём тянущим временную обузу по-совместительству. Только в этом случае можно рассчитывать, что не будет «обидно и больно за бесцельно прожитые годы». Кроме того, сам разрабатываемый продукт должен позволять (в случае форс-мажора) замену команды разработчиков.

Что же делать, если Ваш проект не попадает в категорию Agile-пригодных? Как видите, у Agile есть своё место под солнцем, но оно сильно ограничено в сфере контрактных IT-разработок.

Ну не делают по Scrum-у ни подводные лодки, ни самолёты, ни автомобили. Вам не кажется подозрительным тот факт, что гибкая методология не прижилась нигде, кроме контрактных разработок программного обеспечения? Всё что вы видите вокруг (от табуретки до космического корабля) создано по старому доброму «водопаду» (waterfall). Мудрость предков учит нас, что даже нормальную собачью будку нельзя сколотить без этапа проектирования (карандашный набросок с размерами) и подготовки ТЗ (перечень материалов и инструментов). И помните — всё будет хорошо! Почему бы и Вам не поступить так же?

P.S.

Всё сказанное основано на моём личном немалом (19 лет) опыте контрактных веб-разработок с использованием как традиционного (Waterfall) так и прогрессивного (Scrum) подходов. Побудительным мотивом для написания статьи явились моральные муки от созерцания очередного «чуда враждебных технологий», слепленного по заветам великого Франкенштейна для одной уважаемой западной компании.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть