Мифы и рифы “Гибких технологий”

Александр Мирзахмедов, руководитель проекта

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

Герои и антигерои

На эту заметку меня сподобили обсуждения, статьи, высказывания, которые я читаю/слышу от коллег по компании или коллег по “цеху”. И как же часто мне приходится удивляться, что уважаемые коллеги, к гибким технологиям относятся как к чему-то мифологическому. А вот недавно и от заказчика услышал интересную фразу, что работа по “гибким технологиям” - это всегда долго и дорого. Мнений просто уйма, кто-то их восхваляет и превозносит, а кто-то наоборот, считает что они неэффективны и лишь вредят.

Конечно же, я не беру в расчёт мнения людей, которые только начинают свой путь в IT, напротив, все мои маркёры как раз таки очень даже серьёзные. Один - заместитель генерального директора одной крупной компании, вполне себе развитый и современный мужчина-управленец, с грамотной речью, и хорошей деловой хваткой. Другой - руководитель подразделения крупной компании-интегратора с большим опытом. Третья - автор статьи на популярном ресурсе для 1Сников, где можно публиковать свои статьи-заметки. А также многие другие коллеги и просто знакомые, которые высказывались о своём опыте с гибкими технологиями.

Про себя могу сказать, что и моё мнение, конечно же, не претендует на истину в последней инстанции с ценностью энциклопедического уровня. Моё знакомство с предметом заметки началось сравнительно недавно - в 2015 году. Я работал в компании, где “современный эффективный менеджер”, в должности коммерческого директора, с горящими глазами и пылающим сердцем только и говорил всем нам, кто у него работал, какое чудо этот аджайл/скрам/канбан. На каждом совещании, которые проводились по проблемным проектам, а таких было много, он, вооружившись стикерами и маркером, устраивал разнос менеджерам, и тут же брался составлять доску пользовательских историй и фиксировать на ней текущие проблемы. Несмотря на все потуги, проекты у нас проваливались. Причём под провалом, я понимаю и те, где заказчик формально принимал результаты работы, но радости это ему не приносило. Я же тогда трудился обычным техническим писателем, который привлекался к проектам, на которых заказчик требовал ТЗ. И вот весь этот период работы в этой компании у меня было устойчивое чувство неприятия к “этому вашему аджайлу”. Благо, меня он не сильно касался, т.к. по мнению нашего руководителя, ТЗ - это для “водопада”, который “фу” и “кака”, а всё нормальные ребята уже работают по аджайлу.

Такое длинное вступление я написал, чтобы вы понимали, какой ненавистью я воспылал к всему “гибкому”, что так энергично пытался нам привить наш руководитель. Решив однажды, что так больше нельзя, я начал искать информацию о том, что же такое аджайл и как с ним работать. Видео с Ютюба, где долго и неинтересно что-то рассказывали, я игнорировал. Я искал того, кто простым языком, доходчиво, мог бы погрузить меня в тему. И я нашёл такого человека, отдам ему должок и назову его имя - Михаил Софонов(1). В своих видео(2), которые длились от 10 до 20 минут, он довольно ярко рассказывал о своём опыте и наблюдениях о чужом опыте в работе “по аджайлу”. Сказать, что они произвели на меня впечатления - ничего не сказать - я стал приверженцем “гибкости”. Вскоре компания “пошла ко дну”(3), что было совершенно закономерно, и я сменил работу. На новой работе, уже будучи руководителем проектов, я успешно внедрил “скрамбан” (о нём я расскажу в следующий раз), который по сей день там и используется.

Что ж, пришло время наконец перейти к сути и объяснить, что же не так в том, что я вижу и слышу от коллег. Давайте начнём с базиса.

Антагонистом и протагонистом всех этих сравнительных статей и речей всегда почему-то выступают “водопад”(4) и “аджайл”. Я вот, считаю, что настоящим антагонистом во всех проблемных ситуациях, является непрофессионализм и отсутствие знаний в предметной области при наличии власти и возможности влияния на проект. Но к этому, я надеюсь привести вас в выводах, в конце моей заметки, а сейчас давайте сядем в машину времени и сделаем короткое путешествие.

До 1970-х

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

Википедия не даёт ответ, когда человек начал использовать этот подход, но как мне кажется, он появился вместе с первыми мастерами, возможно в “бронзовом веке”, ведь всё, к чему прикасались руки мастера в то время было физическим или материальным. Действительно, вытесав из дерева что-либо, уже нельзя было “откатить” результат в связи с ошибкой или появившимися новыми “требованиями заказчика”. Придётся брать новую заготовку/брусок и начинать свой труд заново. Без стабильных целей и чётких требований тут никак. В 1970-х, когда информационные технологии уже бурно развивались, в отношении производства IT-продукта уже появилась ясность, что то, над чем вы работаете - это код, который можно в любой момент изменить, а если что-то идёт не так, то вернуться к предыдущей версии. И появляется “итеративная разработка”(5). Однако, по моему наблюдению, для моих ситуативных визави, разница в подходах не наступает, ведь стадии меняются не значительно:

Было в “водопаде”:

1. Определение требований
2. Проектирование
3. Конструирование или моделирование
4. Воплощение
5. Тестирование и отладка
6. Инсталляция
7. Поддержка

Стало в “итеративной разработке”:

1. (Первичное) планирование на основании собранных требований
2. Анализ, проектирование и моделирование
3. Воплощение
4. Тестирование и отладка
5. Инсталляция
6. Оценка результата, сбор новых требований, переосмысление
7. см. п. 1. Где-то фоном после первого “деплоя” начинается “поддержка”

Что же дал этот новый подход? Очевидно - возможность изменений под меняющиеся требования бизнеса и более быструю реакцию на допущенные ошибки. К тому же, появилась возможность делать MVP а затем приращивать его функционал. Неочевидным следствием, стало то, что этот подход снизил порог требований к технической документации. Нет, дело не в том, что стало можно делать её плохо или не делать вообще. Просто появилась возможность делать её детально проработанной только для того, чтобы осуществить очередную итерацию.

Как говорит мой шеф, “Водопад умер в 70-х”. Ну а как тут не умереть?! Информационные технологии становятся всё более доступными. Процесс приобретает циклический характер: снижение порога привлекает в IT новичков, новички приносят с собой “непрофессионализм” и “бунтарство”, порогу некуда деваться - он снова снижается. В середине 70-х из таких новичков появляются компании, которым уготована участь стать гигантами и “законодателями IT моды” в наше время: Майкрософт, Эппл, Оракл и многие другие. Появляется ясность, что важно менять не только процесс разработки, но и сами методы управления этим процессом. Институт управления проектами в 1975 году объявляет новые цели для своей работы(6), которые позже выльются в стандарты управления проектами.

После 1970-х

Мир IT растёт, состав его участников совершенно неоднородный. Процессы в нём также разные и разнонаправленные. В 80-х появляются новые стандарты управления проектами (в частности PRINCE2), которые требуют изучения и строгого следования. Позже, появится и PMBoK - свод лучших практик по ведению управления проектами, который, на мой взгляд, должен быть настольной книгой любого уважающего себя РП.

Увеличение числа успешных самоучек сделало естественным отсутствие необходимости в профильном обучении в ВУЗах, которые были слишком “медленными” и неповоротливыми для бурлящего рынка идей и стартапов. Ну действительно, не будете же вы ждать, когда специалисты, которых вы можете себе позволить для своей идеи отучатся в ВУЗах, чтобы потом начать работать на вас. Развитие языков программирования шло в том же русле - упрощение и снижение порога вхождения. Быть одиночкой в разработке ПО? Легко! В 90-х годах 20 века рынок стал очень насыщенным компаниями-участниками разного размера и специалистами (некоторые уже в статусе звёзд и “рок-звёзд”(7)), и IT-компании начинают скупать их или брать к себе на работу для того, чтобы обеспечить им финансирование и извлечь прибыль из всего того, что они творили. Появляются совершенно новые формы работы над кодом и над проектом в целом, знания об успешных из них требуется передавать и формулируются методологии(8), такие как: парное программирование, экстремальное программирование и другое.

Ближе к миллениуму - начинается бум “доткомов”. “Классические” - выверенные и хорошо регламентированные методологии разработки начинают считаться избыточно зарегулированными(8) и их замещают “гибкие технологии” разработки. Да и доводы вполне понятные:

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

История не терпит сослагательного наклонения, и мы не можем знать, могло ли быть иначе, но все эти изменения приводят к следующему:

• Качество конечного продукта стало снижаться. Всё чаще можно встретить “готовую” к использованию программу, которая работает нестабильно. Проблемы решаются в течение срока поддержки от версии к версии. Этот процесс стал проще с развитием Интернета. Мы ведь уже и забыли, что когда-то ПО покупалось на компакт-дисках, а до них - на дискетах. Сейчас даже большие компании не стесняются выпускать “сырой” продукт на рынок(9), и все надежды на “патч первого дня”. А ведь когда-то, из-за невозможности исправить свой продукт и во избежании провала, на носителях распространялись достаточно стабильные версии ПО.
• Появляется существенный разрыв между компаниями/командами/проектами “старой школы” и теми, кто начал адаптироваться и перестраивать свои процессы достигая результата (как правило, большего дохода). В рамках одной компании возникает “разница дифференциалов”: тех, кто достигает результата всячески награждают и возвышают, тех кто просто “что-то делает” лишают финансирования и отправляют в небытие. Возникает конфликт между “бюрократами и традиционалистами” и теми, кто даёт результат(10). Все, кто не смог перестроиться вынуждены были уходить или были смещены вышестоящим руководством.
• Размер “среднего по больнице” продукта уменьшается за счёт увеличения числа “простых” продуктов. Для компаний становится нормой иметь свой сайт-визитку, а затем, с ростом “продающей” составляющей интернета и “продуктового” сайта, в последствии интернет-магазина. С распространением ПК у пользователей появляется спрос на всевозможные утилиты - прикладные программы, нацеленные на решение относительно узкого спектра задач. Утилиты из хобби автора перерастают в коммерческие продукты. Появляется множество программных продуктов нацеленных на решение задач у компаний определенного сегмента или помогающие компаниям в решении определенных задач, например, бухгалтерии (привет, 1С!).

Так получилось, что Вселенной было угодно в 2001 году свести в одном месте 17 человек, которые в ходе дискуссии о делах насущных и проблемах отрасли выработали Agile manifest(11) - манифест гибкого подхода к разработке ПО, который определил основы новой идеологии. Манифест сопровождался 12 принципами(12), которые раскрывали саму идеологию. Себя же эти люди назвали The Agile Alliance.

Ключевая разница

Давайте посмотрим, что же характерно в “аджайле” и чем он отличается от всего прочего. Ответ содержится в самом манифесте и его 12 принципах. Там не говорится о том, как построить процесс управления проектом. И уж тем более не говорится как выполнять проектные работы в какой либо роли участника. Там говорится о том, как перестроить своё мышление, принципы и приоритеты, которые вы должны использовать. Иными словами, “Аджайл” - это идеология. Он появился в формализованном виде существенно позднее таких методологий как Скрам(14) или Канбан(15) или какой-либо другой из тех, что на слуху. Но тем не менее, для всех методологий, которые называются “гибкими” он стал знаменем под которым они продвигаются. Теперь, их “гибкость” всегда логически связывается с “аджайлом”. Это вызывает путаницу у тех, кто не в курсе хронологии событий. Но главное, конечно, то, какую путаницу сами методологии вызывают в головах и сколько ошибок совершается в связи с этим.

Прежде чем перейти к следующей части, в которой следует поговорить о том, когда всё-таки применять “гибкие методологии”, давайте всё таки расставим все точки над i. Что же изменилось в связи с тем, что над всеми “гибкими методологиями” поднят флаг “аджайла”? Разве мы отказались от тех стадий, которые были заложены ещё в “водопаде”? Мы перестали собирать требования? Нет. Отказались от тестирования? Нет. Тогда что же изменилось? Почему “аджайл” противопоставляют давно не используемому “водопаду”?

Компания Атлассиан, которая развивает и продвигает продвигает линейку различных программных продуктов для проектной деятельности и деятельности по разработке ПО, вообще-то определяет “аджайл” лишь как один из подходов к итеративной разработке(16). На этой же странице, она показывает, что позволяет использовать фреймворки Скрам и Канбан в рамках ведения проектов с использованием инструментов Атлассиан. При этом, если посмотреть на набор стадий проекта - они всё те же. Всё та же классика со времен “водопада”.

То есть, если стадии не поменялись, а вся суть сводится к длительности итераций в итеративной разработке и различных артефактах сопровождающих процесс, то получается, что специалисты лишь понасоздавали разные подходы к осуществлению старой, доброй итеративки? То есть, никакого “Аджайл vs Водопад” не существует, точнее существует, но лишь в головах спорщиков и только от незнания “матчасти”? Ответить на этот вопрос я предлагаю вам самостоятельно.

И как с этим жить?

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

Итеративная разработка

Если у вас крупный проект, который выглядит как тот самый слон, которого надо есть по частям, ибо целиком ни в рот, ни куда-либо ещё он не помещается - лучшим выбором будет итеративная разработка. Не ведитесь на то, что заказчик хочет “водопад”. Он хочет устранить свои страхи: неизвестность со сроками и стоимостью проекта. Оценить точно можно лишь случайно угадав, а потому:

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

Не беритесь писать ТЗ в котором вы сразу будете прописывать технические решения на весь проект. ТЗ - это техническое задание, то есть, требования, а не способы их решения. Если заказчик знает как надо решать - пожалуйста, добавляйте это в ТЗ сразу, но акцент делайте на то, “что надо сделать” а не на “как надо сделать”. Исчерпывающую информацию на этот счёт вы можете получить на авторском курсе Юлия Минькина “Школа аналитика” и “Школа руководителя проекта”. Крайне рекомендую вам записаться на его курсы.

Скрам

Как по мне - самый часто упоминаемый фреймворк, который полностью задокументирован его создателями(17). Однако, по причине того, кто большинство из тех, кто его обсуждают, видимо, поленились прочитать гайд по его использованию на 20-ти страницах на хорошем русском, вокруг него и ходит столько мифов. Кому-то он совершенно не нравится, кому-то помогает побеждать всё и вся.

С ним всё просто. Ему надо либо следовать полностью, либо, у вас не Скрам. Так считают его создатели. Используйте его если выполняются следующие условия:

• У вас маленькая проектная команда. По гайду от 2020 года - не больше 10 человек.
• Состав работ, который требуется заказчику однородный. Скрам требует кросс-заменяемости членов команды. Поэтому отделите от вашего Скрама кодинга Скрам на дизайн и на прочее, где можно объединить участников проекта по однородности знаний и занятий.
• У вас в проекте есть человек, который прочитал скрам гайд и понял, что там написано.
• Заказчик может быть оформлен в единый источник непротиворечивых требований.
• И заказчик и вы прочитали манифест Аджайл и согласны с его принципами. Ведь вы будете работать без ТЗ и будете всегда идти на встречу пожеланиям заказчика, а он в свою очередь - оплачивать вашу работу.
• Вы с заказчиком готовы тратить время на соблюдение всех атрибутов Скрама и работать над его артефактами.
• Если что-то в спринт добавили после его начала, что-то равновесное бэклог спринта обязано покинуть.

Скрам очень хорошо подходит, если на старте проекта заранее известно, что денег у заказчика на весь скоуп его хотелок точно не хватит. Тут главное, чтобы у заказчика хватило денег на MVP. Ну а у вас дара убеждения, что если он потратит их на рюшечки, то он не получит даже MVP. Дело в том, что его MVP должен иметь свойство приносить доход. Заказчик может наскрести деньжат на следующие спринты, пока идут те, которые он уже оплатил. А там, глядишь, MVP начал себя окупать.

Скрам использует итеративную разработку, только с сильно посеченными этапами, которые должны укладываться в длительность спринта.

Канбан

Дитя японского гения и, возможно, самый старый фреймворк из ныне здравствующих. Характеризуется тем, что устанавливает чёткие границы для ёмкости команды. Используйте правило, которое запретит заниматься одному специалисту двумя задачами сразу и вы увидите, как заказчик сам начнёт разбираться в приоритетах задач и накидывать “рюшечки” до реализации MVP. Спринтов нет, но совесть от этого терять не стоит - старайтесь укладываться в первоначальную оценку.

Канбан использует итеративную разработку и его следует выбирать, если у заказчика не такая напряжёнка как в Скраме.

Заключение

Конечно же фреймворков/методологий/технологий/подходов больше, чем упомянуто в этой заметке. Они все разные, но имеют сходные черты, т.к. у них один исток. Но у меня и не было цели описать их все. Вы можете рассказать о своём опыте использования какой-нибудь “диковинки” в комментариях, а я же в свою очередь, с интересом об этом почитаю.

Главное, чего я хотел достичь этой заметкой - пролить свет на предмет заметки, лишить “гибкие технологии” мифичности, обозначить тонкости. Надеюсь, что мне это удалось.

Ссылки и сноски:

1. Канал Михаила Софонова на YouTube: https://www.youtube.com/@sofonov
2. Видео Михаила Софонова, которые кардинально изменили моё отношение к гибким технологиям:

• О том, как часто аджайлом прикрывают бардак и отсутствие способностей к управлению проектами: https://youtu.be/c84HVg_xAyw
• О том, когда применять Скрам: https://youtu.be/LzdSjPWULX8
• О том, как сделать Скрам и Аджайл работающими: https://youtu.be/hv0hTO91_DI
• О том, как запустить Скрам в компании: https://youtu.be/xM-LZXcWCe0
• О том, как пользоваться схемой time&material: https://youtu.be/KkW1UUmMhxo
• О том, как укладываться в сроки и бюджет: https://youtu.be/JoQ7LhiWP6k

1. Штатная численность сократилась с “больше сотни” до одного десятка сотрудников. “Эффективного руководителя” уволил собственник после чего дела пошли в гору. В 2019 году их годовой оборот был уже около миллиарда рублей и в штате снова было больше сотни человек.
2. Википедия о “водопаде”: https://ru.wikipedia.org/wiki/Каскадная_модель
3. Википедия об “итеративной разработке”: https://ru.wikipedia.org/wiki/Итеративная_разработка
4. Википедия про PMI: https://ru.wikipedia.org/wiki/Институт_управления_проектами
5. Например: Джон Ромеро, Ларри Пейдж и Сергей Брин, Гвидо ван Россум, Билл Гейтс, Линус Торвальдс и многие другие звёзды той эпохи.
6. Википедия о методологии: https://ru.wikipedia.org/wiki/Методология
7. Википедия о “гибкой методологии”: https://ru.wikipedia.org/wiki/Гибкая_методология_разработки
8. Провал игры Киберпанк на релизе: https://ixbt.games/news/2022/06/21/cyberpunk-2077-trevoznyi-zvonocek-proval-cd-projekt-red-ispolzuyut-kak-argument-pri-perenose-reliza-.html
9. История появления Agile manifest: http://agilemanifesto.org/history.html
10. Манифест аджайл: http://agilemanifesto.org/iso/ru/manifesto.html
11. Принципы аджайла: http://agilemanifesto.org/iso/ru/principles.html
12. Википедия о Скраме: https://ru.wikipedia.org/wiki/Scrum
13. Википедия о Канбане: https://ru.wikipedia.org/wiki/Канбан
14. Атлассиан об “Аджайл”: https://www.atlassian.com/ru/agile
15. Скрам гайд на русском: https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Russian.pdf

PS Эту заметку я посвящаю моему покойному папе, который в начале 1990-х году опубликовал статью “Мифы и рифы приватизации” в которой он на заре приватизационных процессов происходивших в странах бывшего СССР предупреждал о тонкостях её осуществления и о том, чего не следует допускать при её реализации. Он был главным методологом приватизационных процессов в Узбекистане и до конца своей жизни считал своей заслугой то, что в Узбекистане не сложились условия для появления олигархов.