Как же часто мне приходилось слышать от рекрутеров одну и ту же фразу:
Мы работаем по Agile. Спринты по 1-2 недели
Под Agile они, конечно же, имеют в виду Scrum. Но я с уверенностью могу сказать, что ни в одной компании, что я работал, Agile даже и не пахло. И тут я даже не говорю о том, что Agile каким он был задуман в принципе не дошел до массовой разработки (о чем рассказывал один из создателей Agile Дейв Томас на конференции GOTO 2015). Я говорю об Agile в общепринятом значении этого слова.
В дальнейшем, на техническом интервью, если спрашивать по пунктам, практически любой реальный работник компании подтвердит вам, что никакого Agile в компании нет, а используются лишь элементы Agile.
По некоторым причинам команде разработчиков либо не получается наладить работу по Agile, либо руководство знает, как лучше, и навязывает собственное видение методологии разработки. Эту проблему адресовал в своей статье Рон Джефрис (вот перевод на русский), дав красноречивое название подобным практикам — "Dark Scrum". Существует и более мягкая формулировка для тех, кто считает подобное положение вещей скорее фичей, а не багом — "Pseudo Agile" или "Post Agile".
В этой статье я постараюсь расставить точки над Ё и разобраться, что такое Agile на самом деле, и какие проблемы существуют у современных гибких методологий.
Agile
Agile (гибкая методология разработки) был представлен миру как манифест и набор принципов, который выкатили миру горстка разработчиков в порыве вдохновения во время отдыха в 2001 году на горнолыжном курорте Snowbird. Ну выкатили и выкатили, скажете вы, и что? Что такого было в этом манифесте, что он стал настолько общепринятым? Да ничего особенного, просто здравый смысл.
Собственно, содержание Agile манифеста:
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану
А также 12 принципов:
Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения
Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев
На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе
Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды
Работающий продукт — основной показатель прогресса
Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта
Простота — искусство минимизации лишней работы — крайне необходима
Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд
Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы
Agile представил принципы, которые должны были стать основой для будущих методологий. Даже не так, эти принципы должны были стать парадигмой, которую можно внедрить в любую методологию, чтобы она стала гибкой. Ключевые принципы Agile описывали как построить грамотное взаимодействие бизнеса и разработки, как верно выстраивать приоритеты при разработке и чем руководствоваться при принятии решений.
Изначально, Agile хоть и стал обсуждаемой темой, применялся в основном в небольших компаниях или среди энтузиастов. В то время в мире правил Waterfall. И даже когда требования к разработке программного обеспечения изменились, и бизнес переключился с модели выпуска единичного продукта и его поддержку на последовательную итеративную разработку, Agile все равно оставался в немилости. Манифест с расплывчатыми принципами тяжело продать корпоратам. Причина, собственно, одна: подобно Копенгагенской интерпретации квантовой механики Agile хорошо отвечал на вопрос "что делать", но не отвечал на вопрос "как делать". Данные упущения постарались исправить Scrum и Kanban.
Scrum
Scrum появился задолго до того, как были представлены принципы Agile, первый раз эта методология упоминается аж в 1986 году в статье The New New Product Development Game.
В 1995 программист Джефф Сазерленд совместно с Джоном Скамниотейлзом, Кеном Швабером и Джеффом МакКенном, сформировал принципы, которые стали основой для современной методологии Scrum. В 2001 году Джефф Сазерленд вместе с другими разработчиками также отдыхал на горнолыжном курорте Snowbird и вместе с единомышленниками участвовал в формировании манифеста Agile.
После этого, в 2001-2002 году Scrum усилиями Сазерленда и Швабера был переработан в Scrum Framework, который должен соответствовать принципам Agile. В 2002 году Шварбер основал компанию Scrum Alliance и создал сайт scrum.org. Scrum Framework и Scrum сегодня — это одно и то же, слово Framework опускают для сокращения. Результатом работы компании является "Руководство по Scrum" за авторством Кен Швабера и Джефф Сазерленда, которое описывает принципы работы Scrum.
Так как Scrum по своей сути является продуктом, его руководство — это интеллектуальная собственность компании. Пользоваться руководством и работать по принципам Scrum можно бесплатно, но соблюдение этих принципов обязательно, иначе вы не можете называть свою методологию Scrum. Цитата из руководства:
Описанный здесь фреймворк Scrum не подлежит изменению. Хотя использование отдельных элементов Scrum допустимо, полученный результат не будет Scrum. Scrum существует только в качестве цельного фреймворка; при этом он успешно работает в качестве контейнера для других техник, методологий и практик.
(с) Руководство по Scrum 2020
Компания Scrum Alliance имеет программу выпуска сертифицированных Scrum мастеров (Certified Scrum Master, CSM). Она предоставляет услуги по внедрению и курированию Scrum для компаний и является единоличным владельцем прав на торговую марку Scrum.
Scrum работает по достаточно простой схеме:
У вас есть продуктовый беклог (Product Backlog) — весь список задач для разработки
Разработка идет итерациями с продолжительностью до одного месяца, которые называются спринтами (Sprint)
У каждого спринта есть цель (Sprint Goal), которая обсуждается на планировании спринта (Sprint Planning), это обсуждение является отправной точкой начала спринта.
Спринт представляет собой набор задач (Sprint Backlog) из продуктового беклога, в процессе спринта набор задач изменять нельзя. Задачи, которые команда решила взять в спринт должны способствовать выполнению цели спринта. Не все задачи должны попадать под этот критерий, и спринт может считаться выполненным, если все задачи, которые способствовали выполнению цели спринта закончены.
После этого, каждый день вы проводите совещания (ежедневный Scrum, Daily Scrum), где обсуждаете результаты работы за предыдущий день и возможность выполнения цели спринта к его окончанию
В конце спринта, на отдельном совещании вы обсуждаете результаты спринта (Sprint Review). Удалось ли достичь цели спринта? Что поменялось во время работы над спринтом? Это обсуждение ограничено четырьмя часами, не является презентаций, а скорее активным обсуждением.
Также, в конце спринта производится ретроспектива (Sprint Retrospective) и решаете, какие изменения вам необходимо произвести, чтобы работа стала эффективнее в отличие от Sprint Review, тут обсуждаются изменения, которые можно произвести, чтобы следующий спринт был эффективнее предыдущего.
Ретроспектива заканчивает спринт
После того как заканчивается спринт, начинается новый спринт
Scrum подразумевает разделение ролей в команде (Scrum Team):
Developers — это разработчики, которые выполняют задачи спринта.
Владелец продукта (Product Owner), который манипулирует приоритетом задач в продуктовом беклоге и является звеном между бизнесом и разработкой. Владелец продукта должен устанавливать Product Goal — долгосрочную цель по улучшению проекта. Он не участвует в ежедневном Scrum.
Scrum-мастер (Scrum Master) — человек, единственной задачей которого является обеспечение выполнения принципов Scrum. Scrum мастер участвует во всех обсуждениях.
Каждая задача в спринте считается законченной, если удовлетворяет определением готовности (в прошлом называлось Definition of "Done"). Требования могут быть произвольными, например:
код написан;
юнит-тесты написаны и успешно выполнены;
код прошел ревью;
документация обновлена;
функциональное тестирование успешно завершено;
регрессионное тестирование успешно завершено.
Если задача закончена, она добавляется к остальным задачам, которые были завершены в рамках спринта. Совокупность завершенных в рамках спринта задач называется инкрементом (Increment). В процессе спринта может быть создан один или несколько инкрементов, произведен один или несколько деплоев.
Задачи оцениваются не в человеко-часах, а в некоторых абстрактных сторипоинтах (Story Points). Один сторипоинт представляет собой сложность некоторой тривиальной задачи, или самой простой задачи в спринте. Далее, все остальные задачи оцениваются как число сторипоинтов относительно этой тривиальной задачи.
Kanban
Родоначальником методологии Kanban можно считать компанию Toyota.
Подумайте, как вы посещаете магазин. Чаще всего, вы планируете поход в супермаркет, когда у вас кончаются продукты. Супермаркеты, в свою очередь, заказывают новую партию продуктов, когда полки начинают пустеть, и только столько, сколько необходимо для наполнения полок. Специалисты Toyota (в частности Тайити Она) переработали подход розничных продаж в производственный процесс. Каждый этап производства при нехватке ресурсов запрашивал новые в необходимом количестве.
Этапы производства в современном виде метафорически представляют собой доску Kanban, а в качестве ограничения выступают WIP лимиты (ограничение на вместимость, как полка в супермаркете). Все задачи помещаются на первом этапе Kanban доски, разработчики разбирают задачи в порядке приоритета, и перетаскивают их по этапам разработки. В каждый момент времени на одном этапе не может быть больше задач, чем указано в WIP лимите. Этапы разработки выбираются произвольно в зависимости от требований команды (например, "Запланировано", "В работе", "Готово к тестированию", "Завершено").
В Kanban нет беклога и спринтов, и нет никаких ролей (Scrum мастера или владельца продукта). Основной целью команды разработки является оптимизация скорости доставки функционала конечному клиенту, что подразумевает отсутствие планирования релизов, тут идеальным подходом является Continious delivery.
Начнем прожарку
Хотя Scrum и Kanban называют разновидностями Agile, в полной мере они ими не являются. Первый пункт манифеста Agile гласит:
Люди и взаимодействие важнее процессов и инструментов
Этот пункт отражал важную идею. Для эффективной разработки программного обеспечения вам необходимо найти хороших людей, которые могут эффективно сотрудничать. Выбор инструментов, которые они используют, или процесса, которым они должны следовать, является второстепенным. Команда должна выбирать собственный путь.
На самом деле, можно пойти дальше, потому что команда должна не просто выбирать процесс, но и активно поощрять развитие этого процесса, изменение его по мере продвижения разработки. Идейно Agile противопоставляет себя идеям тейлоризма (см. Фредерик Тейлор — основоположник научного труда и менеджмента). В 20 веке в Америке процессами занимались отдельные люди, повсеместно внедрялись лестницы власти, состоящие из менеджмента. Agile же, наоборот, настаивал на сотрудничестве разработчиков и бизнеса, и внедрении гибкого процесса, который управляется "снизу".
Возникает противоречие. Получается, чем больше менеджмент пытается внедрить конкретную методологию, тем сильнее они отдаляются от Agile. На конференциях по Agile все меньше разработчиков, и все больше менеджеров, которые пытаются выяснить, как эффективнее управлять персоналом. Круг замыкается, и мы идем к тому, откуда пришли — отделению работника от организации его труда.
Согласно Agile, мы должны воспринимать Scrum и Kanban как отправные точки, но вместо этого, зачастую, обозначаем их конечными целями. Сама идея того, что методология должна разрабатываться компаниями противоречит Agile. Все 17 основоположников Agile отказались от идеи занять управленческие роли, когда возникла идея создания организации, посвященной Agile:
Один из вопросов звучал так: «Должны ли первые 17 человек, написавшие манифест, занимать особое место в этой организации?» Чем я горжусь, так это тем, что мы, 17 авторов, сказали «нет». Мы написали манифест. Мы проделали хорошую работу, мы будем частью того, что будет происходить в будущем, но у нас нет особой роли в этом будущем. Мы сказали: «Придут новые люди и сделают великие дела», что и произошло.
(с) Мартин Фаулер, один из создателей Agile
Возьмем, к примеру, Scrum, который представляет собой продукт компании Scrum Alliance. Scrum-мастер — это не менеджер, это консультант. Он не контролирует показатели, и не ведет совещания. Он не может командовать и принимать решения. Вся его функция — это наблюдать за ходом вашей разработки и давать советы тут и там, чтобы команда продолжала соблюдать принципы Scrum.
Во-первых, само по себе присутствие человека, который не участвует в разработке, но при этом формирует процесс, уже нарушает манифест Agile. Во-вторых, для меня, ситуация с Scrum-мастером напоминает темный паттерн. Что-то похожее я встречал в разработке на 1C. При обновлении, в вашем продукте обязательно что-то сломается, и вам придется нанимать специального человека от 1С, который придет и все починит. За отдельную плату, конечно же.
Scrum-мастер — это scam мастер.
Я считаю, что нас просто обвели вокруг пальца. Манифест Agile не предполагает никаких людей, которые должны учить Agile. Scrum-мастер — это порождение маркетинга, и компаний, которые занимаются внедрением Scrum. Это средство извлечения прибыли, а не путь к хорошему коду.
Одна вещь, о которой все забывают
Вопреки общему мнению, Agile не является средством руководства — это средство разработчика! И задумывался создателями исходя из принципов написания хорошего кода. Методологии, которые основаны на Agile должны развиваться и эволюционировать. Они должны подстраиваться под требования разработки, именно поэтому Agile и называют "гибкой".
Бизнес плохо понимает, как пишется код. Agile должен был стать мостом между бизнесом и разработчиками, и создать среду для разработки качественного и надежного программного обеспечения с возможностью изменения требований и частых релизов.
Существует мнение, что быстрый выпуск программного обеспечения возможен только в том случае, если вы готовы мириться с огромным количеством ошибок. И если вы хотите, чтобы программное обеспечение было надежным, вы должны мириться с тем, что разработка будет медленной и неповоротливой. Это неверно. И мы видим, как накапливается все больше доказательств обратному. И Agile в своей сути направляет разработчиков на развитие методов для того, чтобы это стало возможным.
Необходимо понять важность модульности, автотестов и базовых принципов хорошего кода. Когда разработчику нужно добавить функцию в программу, а текущая архитектура не позволяет это сделать, ему прежде всего нужно изменить архитектуру таким образом, чтобы данное изменение стало возможным и простым.
Если вы хотите внести изменения, сначала сделайте их легкими. (Предупреждаю, это может быть сложно.) Затем сделайте легкие изменения.
(c) Кент Бек
Рефакторинг должен стать неотделимым от процесса разработки. Небольшие качественные изменения кода, которые позволят в будущем легче поддерживать и воспринимать код должны стать непрерывным процессом, а не откладываться в долгий ящик.
Именно поэтому так важен диалог между бизнесом и разработчиками. Когда фокус смещается в сторону хорошего кода, выигрывают обе стороны. Вместо этого, Agile все чаще воспринимают как форму менеджмента и пытаются превратить Scrum и Kanban в инструменты эффективной разработки, где главную роль играет количество, а не качество, что мотивирует разработчиков писать плохой код.
С таким подходом со временем разработка становится дороже, а программы все менее стабильными. И мы виним в этом разработчиков, хотя на самом деле, проблема зачастую кроется в противоположной стороне. Разработчикам ставят неверную мотивацию, и лишают возможности повлиять на ситуацию.
Если в вашей компании Scrum не работает, это не потому что вы неправильно используете Scrum, не потому что у вас плохая команда. Увольте вашего Scrum-мастера, откажитесь от идеи Scrum и дайте разработчикам самим организовать процесс. Основной целью должно быть написание хорошего поддерживаемого кода, взаимодействие людей и гибкость процессов, ведь в конечном итоге: люди и взаимодействие важнее процессов и инструментов.
Всем кода.
