Как же часто мне приходилось слышать от рекрутеров одну и ту же фразу:
Мы работаем по 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 и дайте разработчикам самим организовать процесс. Основной целью должно быть написание хорошего поддерживаемого кода, взаимодействие людей и гибкость процессов, ведь в конечном итоге: люди и взаимодействие важнее процессов и инструментов.
Всем кода.
Комментарии (51)
SadOcean
26.10.2022 12:12+1Спасибо, очень интересный разбор.
Справедливости ради, заголовок несколько провокационный, и если прочитать и полностью принять текст, то сильных противоречий между Agile и кастомными вариантами scrum нет (ну, если вы не ставите целью обязательно называть его Scrum Framework) - вы можете адаптировать их.
in5anity Автор
26.10.2022 12:26+2Справедливо. Если инициатива по модификации произошла от разработчиков, и направлена на улучшение качества кода, то это действительно в духе Agile. Если же модификация произошла от руководства, и внедряет темные практики, тут мы начинаем встречать проблематику, которая описана в статье (Dark Scrum).
guryanov
26.10.2022 13:08+1Принципы agile очень разумными выглядят.
А вот идею спринтов я вообще не могу принять. Даже название неверное - типа бежим стометровку и как только пересекли финишную черту начинается вторая стометровка?
Вот проходит неделя спринта и я почему-то должен делать задачу номер 12 а не 23 просто потому что ее положили в спринт а 23 не положили, хотя у меня возникла идея по поводу задачи 23 и сейчас я ее сделаю за день а задачу 12 - за неделю, потому что не хочу ей заниматься прямо сейчас.
Релизы - гораздо более разумные чекпоинты. Хотя бы понятно, что ты делаешь задачу не потому что просто менеджер выбрал что-то рандомное а потому что задачу пообещали какому-то клиенту выпустить в конкретный срок и результат работы над релизом - это новая версия продукта а не просто закрытые задачи в жире.
vassabi
26.10.2022 14:19+1вроде на планировании следующего спринта именно такие вопросы и задаются.
Конечно, всегда есть место самодурам ("вы - программисты, вы всего лишь исполняете, вам планировать нельзя"), но тогда скорее всего - стоит обновить своё резюме ...
k0rinf
26.10.2022 14:34+2Идея проста, бежим 100 метровку по определенной дороге, и никто не должен вам на эту дорогу добавлять препятствий или ям. Вы заранее видите весь участок в 2 недели. Не должно быть такого, чтобы вам в спринт постоянно прилетали новые задачи, которые двигают все остальные. Если у вас и бывает очень много багов с прода, то спринт планируется с запасом времени под такие баги. Условно у вас забито 8 дней задачами и 2 дня под возможные баги с прода. Если вы выполнили все задачи из спринта, то это никогда не означает что оставшееся время вы ничего не делаете.
А что за работа такая где вы сами определяете что бизнесу нужно прямо сейчас? То есть как это вы решили что бизнесу задача 23 важнее чем задача 12? Ну ок, если есть какие то мысли по поводу задачи 23, ну пометьте себе в todo и продолжайте задачу 12. Как правило спринт имеет цель, которая согласована с продукт оунером. И он ожидает что вы сделаете задачу 12, и на демо покажите именно ее, а не задачу 23. Согласитесь было бы странно, если бы он пришел посмотреть на задачу 12, а вы ему говорите что у вас там была идея и вы сделали задачу 23 вместо задачи 12. Если ваша идея позволит вам сделать задачу 23 за 1 день, то какая разница, сегодня это или через неделю?
С релизами не всегда все однозначно. Какие то задачи могут уходить в релиз по готовности, а какие то с фичатогл флагами. Одна большая фича может по частям добавляться в релизы, а доступной для всех пользователей она может стать намного позже. И нет смысла ждать окончания спринта, если задача уже сделана, и ничего не мешает отдать ее в прод. Релизы это не всегда конец спринта.guryanov
26.10.2022 15:06+3Если бы программисты были бездушными искусственными интеллектами то да, назначил любые задачи - всё переварят.
В реальности производительность программиста может меняться в десятки раз если не сотни раз в зависимости от того, в каком порядке и какую работу он делает. Сейчас я задачу 23 сделаю за час а через месяц - за неделю. Зачем мне надо ждать планирования, вместо того, чтобы сделать задачу 23 прямо сейчас? Она лежит в беклоге, на неё есть постановка, она точно нужна бизнесу и она точно так же как и задача 12 должна быть сделана к релизу, который будет через месяц. Почему бы не оптимизировать и не сделать задачи в том порядке, в котором я сделаю их быстрее?
k0rinf
26.10.2022 16:00+2Я совсем вас не понял. Вы задачу оцениваете перед тем как ее делать? Как может быть такое что, сейчас вы задачу оценили в 1 час, а через месяц вы оцените эту же задачу в 7 дней? Разработчики всегда оценивают задачи с учетом какого то запаса времени, но это не 7 дней к задаче на 1 час. Именно поэтому многие уходят от оценки по времени, в оценку в сторипоинтах. Именно поэтому есть такие встречи как скрам покер.
Задача в беклоге уже лежит оцененная. Мы берем в спринт задачи которые точно успеем сделать. Если вы способны вырабатывать в спринт 40 часов, то никто не возьмет на вас задач на 80 часов. Если вы не успеваете в ваши же оценки, то это лично ваша проблема. Это говорит о том что у вас какая то проблема с оценкой. Оценили задачу в 1 час, то и сделайте ее в 1 час. Сегодня или завтра, или через месяц.
Помимо этой задачи в беклоге есть еще 100500 задач. И все они нужны бизнесу, иначе их бы не было в беклоге. И приоритет задач не может управляться желанием исполнителей, иначе мы получим ситуацию где все делают только то что хотят делать, а то что нужно бизнесу будет сдвигаться на потом по различным причинам. Парадокс, бизнес платит зарплату, за то что разработчики делают то что они хотят делать прямо сейчас, а не то что нужно бизнесу прямо сейчас.guryanov
26.10.2022 16:29+1Я не про оценки говорю а про реальное время работы над задачей. Пример - я сейчас закончил какую-то похожую задачу, у меня настроено окружение, готовы данные, запущены все нужные сервисы локально чтобы сделать задачу 23. И я сам нахожусь в контексте, весь код у меня прямо в голове в быстрой памяти. Надо только потратить час на написание кода.
А через неделю мне придется потратить день на подготовку окружения, день я буду сидеть и ничего не делать злой, из-за того, что мне пришлось опять всё готовить хотя я мог бы сделать раньше. день надо потратить на то, чтобы все вспомнить и после этого я еще 2 дня буду писать код.
Бизнесу на самом деле наплевать, когда будет сделана задача 12 а когда задача 23, главное чтобы в сумме за полгода было сделано более-менее много всего.
Есть очень редкие исключения, когда надо срочно сделать что-то, чтобы получить какой-то большой контракт например. В таких случаях имеет смысл потратить неделю сейчас и получить контракт, чем затратить час когда-нибудь потом и контракт не получить. Но если таким руководство будет злоупотреблять, то в сумме за полгода будет не сделано ничего.
hoack
26.10.2022 17:58+4"Бизнесу на самом деле наплевать, когда будет сделана задача 12 а когда задача 23, главное чтобы в сумме за полгода было сделано более-менее много всего."
Это совсем не так. То есть ну просто СОВСЕМ не так. Каждая задача происходит от какого-то бизнес-проекта. Что-то обещано уже существующим клиентам, что-то нужно для новых, что-то - чтобы выполнить всевозможные требования или законы... Зависит от бизнеса, конечно. Но даже если речь идет просто о развитии продукта, то на выполнение задач в определенное время может быть завязано очень много чего - связи с другими компонентами, тестирование, документация...
А что касается переключений контекста... При планировании спринта эти соображения вполне нужно высказать, и совершенно нормально (если только не зверский цейтнот) включить задачу в спринт именно потому, что уже делается что-то близкое. Но вообще меня как руководителя весьма заинтересовало бы, почему на переключение окружения нужен целый день. Ну а про два дня на "буду сидеть злой" и "буду вспоминать" даже как-то и говорить неловко. Но да, переключение контекстов не бесплатно, и при планировании спринта это обычно по возможности стараются учитывать.
guryanov
26.10.2022 19:04+3Чтобы клиенту доставить к определенному сроку фичу есть механизм релизов. Я же написал, что релизы я понимаю. Я не понимаю, почему я должен обязательно делать какую-то задачу просто потому что ее положили в спринт и больше нипочему. А более того, почему я не могу сделать задачу, которую не положили в спринт, при условии, что спринтовую я всё-равно успею сделать.
k0rinf
26.10.2022 20:17+2Ну потому что задачу не просто положили в спринт, а весьма осознано и обдумано положили именно в этот спринт а не какой-то другой. Задача команды сперва убрать все риски по провалу спринта, а потом уже делать все остальное. Ваше условие, что спринтовую вы все ровно успеете, оно имеет какую то вероятность. И никто не хочет рисковать, чтобы потом на ретро не рассказывать, о том что вы рискнули, но не получилось, и поэтому спринт провален.
guryanov
27.10.2022 13:21То что спринт провален не повлияет вообще ни на что, если в итоге к релизу всё-равно всё будет готово. И наоборот, если сделали успешных спринта и поняли что в третий надо впихнуть в 5 раз больше задач, иначе не успеется к релизу - вот это будет катастрофа.
guryanov
26.10.2022 16:32+3Вот такие оценки - что задача займет час независимо от того, сейчас, через неделю или через полгода её делают - это вообще величайшее заблуждение менеджеров.
k0rinf
26.10.2022 20:07Поясните, что влияет на вашу оценку задачи сегодня, и через неделю? Я понимаю когда за полгода в проекте поменяется кодовая база и потребуется переоценка некоторых задач. Но даже эта переоценка не поменяется ведь у вас через неделю? Вы что, разное время задачи указываете с поправкой на то, что вы злой будете, или не будете? То что вы про контекст подготовки и переключения написали, это должно учитываться в оценке изначально.
Как вы с коллегами работаете в команде? Допустим вы оценили задачу в 8 часов, а ваш коллега оценивает эту же задачу в 4 часа. Что после этого происходит?
То что вы говорите, о том что бизнесу неважно время доставки фич, это не так. Бизнесу очень важно время появления той или иной фичи в продукте, я бы даже сказал жизненно важно, потому что рынок решает. Представьте что у вашего конкурента вышел релиз с новой важной фичей, а у вас аналогичная фича появится примерно где то в сумме в пол года в вперемешку со всем остальным. Вы не боитесь что за эти пол года ваши клиенты уйдут к вашему конкуренту из-за как раз той самой новой фичи, которая у него уже есть, а у вас появится непонятно когда? Выбирать приоритеты задач это на самом деле отдельное искусство. И можно очень сильно с этим накосячить или наоборот очень сильно преуспеть.guryanov
27.10.2022 13:37+1Обычная оценка довольно большая и учитывает то, что нужно время, чтобы погрузиться в задачу, но есть много вариантов, как это время можно сильно сократить. Например починить 5 однотипных багов подряд займет не намного больше времени, чем 2. Или можно взять задачу в работу, понять задачу и отложить ее, пока в голову не придет хорошая идея и начать делать другую задачу.
Задачу обычно берет тот разработчик, которому меньше всего придется разбираться с чем-то и большую часть времени он потратит именно на написание кода.
По поводу сроков доставки задач вот тут есть трейдофф. Можно либо сделать большую пропускную способность либо маленьку задержку при выполнении задач. Я считаю что надо в первую очередь обеспечивать высокую пропускную способность и свести к минимуму вот такие случаи, что надо что-то срочно сделать чтоб через 2 недели было готово. Но даже в таких случаях спринты ну никак не помогут.
Вот допустим чтобы сделать фичу надо чтобы C++ разработчик потратил 3-5 дней, после python-разработчик 5-10 дней а потом frontend - 2-4 дня. На мой взгляд тут следует выбрать более-менее надежных исполнителей, собрать всех троих вместе, объяснить важность выполнения срока и сказать, чтобы каждый следующий приступал к работе сразу после того, как закончит предыдущий. Да, в этом случаи какие-то другие задачи могут отодвинуться, зато успеем к сроку. И 2 недельные интервалы никак не помогут при планировании.
Krey
27.10.2022 12:31+2Так ведь вы сами, вместе с командой и оцениваете задачи. Не менеджеры. И вы же принимаете участие в обсуждениях какие задачи брать в следующий спринт, а какие пока просто положить, оставить в product backlog
SadOcean
26.10.2022 15:26Я думаю в названии отражается стремление к итеративности и фрагментации фич.
То есть мы не пытаемся бежать марафон, потому что не знаем, куда на самом деле бежать.
Поэтому мы пробегаем дистанцию пошустрее, останавливаемся и оцениваем, куда прибежали и куда нужно бежать дальше.
Справедливости ради есть случаи когда спринт может быть не оптимален - может быть одна крупная фича, которую крайне сложно оценить без реализации всех компонентов.
Соответственно пытаться уложить ее в пайплайн со спринтами - значит получить просто несколько неоптимальных недофич, которые ничего не покажут, но понести все издержки реализации промежуточных решений - промежуточные настройки, тестирование, взаимодействие компонентов, которые будут выкинуты в корзину после полной реализации.
Соответсвенно спринты могут не подходить для некоторых стадий разработки, но хорошо подходят для регулярной работы по улучшению функциональности.
Впрочем аджайл то сам по себе не требует спринтов, он просит сосредоточиться на доставке качественного продукта.guryanov
26.10.2022 15:46Поэтому мы пробегаем дистанцию пошустрее, останавливаемся и оцениваем, куда прибежали и куда нужно бежать дальше.
Вот это почему-то всегда вне рамок спринтов делалось везде где я работал со спринтами. Почему-то на этот ключевой пункт обычно забивают.
Anastasia_Trud
26.10.2022 17:43Не очень понятен ваш тезис про задачу 12 и 23. Смысл не в том, чтобы разработчик кодил быстрее, а в том чтобы в работу шли важные и приоритетные задачи для клиента. Не надо брать задачу 23,возьмите задачу 12,т.к. она для продукта важнее. И при хорошем owner это может быть как техническая, так и бизнесовая, если диалог у команды разработки и owner встроен адекватно.
guryanov
26.10.2022 18:59А мне не понятно, что тут может быть непонятно :) Если дать разработчикам чуть больше свободы в выборе задач, то скорость работы программистов вырастет в несколько раз (а расходы на зарплату сократятся, так как нужно будет меньше людей). Я не говорю, что они будут пилить ненужные фичи, они будут брать бизнес задачи из беклога или задачи на улучшение и рефакторинг кода, просто в том порядке, в котором им этого хочется.
Для того чтобы доставить задачу клиенту к определенному сроку есть релизы и апдейты, спринты вообще там не причем.
SHLab
26.10.2022 19:54Хорошо жить в иллюзорном мире, где все просто, как у ребенка. Вот это хочу и буду делать, а остальные пусть подождут.
Простой пример из реальной жизни. Компания задумала акцию к новому году, закупилась товарами, разработала и подготовила рекламную компанию, в том числе на ТВ, но на сайте программисты так и не сделали нормальную работу с этой акцией, потому что другая задача показалась им «важнее именно сейчас». В итоге убытки в миллионы рублей :)
guryanov
27.10.2022 13:39Да, я про это говорил, что есть задачи, которые надо обязательно сделать к какому-то сроку. Но не надо ставить такой конкретный срок для абсолютно каждой задачи, так как в этом случае в сумме будет сделано гораздо меньше за большой срок, за год, например.
Krey
27.10.2022 12:14Идея спринтов чётко завязана на процессы CI/CD, на постоянную и регулярную доставку ценностей заказчику в краткие сроки для получения обратной связи и как следствие быстрой реакции если что-то идёт не так.
Релизов, мейлстоунов этот подход не отменяет.
Гибкости при принятии задач в работу тоже.
И кстати, в противовес мнению автора статьи, рефакторинг тоже не отменяет. А наоборот утверждает что 15-20% спринта, вынь да полож на техдолг.
k0rinf
26.10.2022 14:46+1А разве Sprint Retrospective не является тем самым "Люди и взаимодействие важнее процессов и инструментов" ? Ведь как раз на этой встрече и нужно поднять вопрос о том как люди взаимодействовали, какие инструменты нужны или не нужны. Именно тут надо все это выяснять и фиксировать.
Допустим команда решила что общается в slack, но один из людей будет постоянно общаться со всеми в telegram. Он же не может ссылаться на то что у нас Agile и люди и взаимодействие важнее процессов и инструментов?in5anity Автор
26.10.2022 14:54Agile - это командная методология. Идея в том, чтобы команда сама решала, чем ей пользоваться, какие технологии и инструменты использовать. Первый пункт подчеркивает эту идею.
Если разработчик решает идти против команды - это уже не относится к методологии, это просто внутренние проблемы команды.
aqua__vita
26.10.2022 14:54+1В современном мире практически у каждой компании свое понимание scrum,agile,kanban
Мне кажется, нет такой компании, которая строго следует какому-либо манифесту/методологии и люди всегда меняют под себя
Плохо ли это ? На мой взгляд нет: идеи не умерли, а стали развиваться и превращаться, наследуя от родителя какие либо признаки, но добавляя что-то своеin5anity Автор
26.10.2022 14:58Да! И это замечательно. Проблемы начинаются, когда людям не дают сформировать свое понимание, и используют методологию как инструмент повышения эффективности, а не средство к достижению лучшего продукта.
Даже слово "Agile" изначально задумывалось как "прилагательное", можно было сделать что угодно "угловатым". Этим подчеркивалось, что Agile - это не что то конкретное, это просто принципы (как KISS, например), и каждый мог по своему их внедрять под свои нужды.
Alexander_Front-end
26.10.2022 14:54Интересная статья, спасибо!
Пойду покажу коллегам, как оно бывает :)
progchip666
26.10.2022 16:44Практически со всем согласен, особенно с итоговыми выводами, хотя я занимаюсь не чистым IT, а комплексной разработкой электронных устройств проблемы те же.
Огромная проблема - взаимодействие с заказчиком. Большинство любят работать по схеме - сдал рамочное ТЗ и забыл...
Считая что я должен на 100% угадать его затаённые желания, о которых он сам на этапе составления договора не подозревает!
Thebear
26.10.2022 16:47Хорошая статья, полезно иногда напоминать историю. Вот только с посылом противопоставления программистов, которые дескать знают как код писать, если им не мешать и бизнеса, который ничего не знает, я не согласен.
Програмисты пишут то, что бизнесу нужно. Когда хотелок много, какие-то приоритеты уползают, какие-то детали теряются в процессе формализации задачи. Картина мира и понимание важности каждой фичи в глазах разрабов отличается от картины мира в голове продакта и так далее.
В идеальном мире, разрабы и бизнес могли бы друг друга понимать и синхронизироваться, в реальности так почти никогда не бывает, и нужны доп костыли чтоб хоть как-то доковылять до финиша. И мерам мастера в различных ипостасях это как раз один из костылей, точнее способ удержать разрабов, которые не всегда понимают зачем они что-то делают от растекания мыслью.
Paramourka
26.10.2022 22:49+2С посылом согласна на 100%. Но есть грубые неточности, которые режут глаз.
Agile это не методология, это именно что набор ценностей и принципов. Можно называть философия, но не методология.
Dark Scrum автор называет именно неудавшийся Scrum. Не Agile. Ещё есть названия типа ScrumBut, или по-русски СкрамНо. Это и правда "отступление" от скрам гайда.
Тут как раз скрам мастер или другой опытный пользователь методологий, объединяющихся под Agile, скажет, что юной и неопытной в Agile подходах команде в первый раз нужно научиться работать по типовому фреймворку/методологии, по её четким правилам.
Когда команда уже понимает, что ценности и принципы у них работают и как работают - вот тут можно крутить/вертеть процессы на своём опыте, опираясь на Agile. Без стартового опыта эксперименты будут дольше и болезненнее как для команды, так и для продукта и для бизнеса.
И самое болезненное для меня, душнилы этого вечера, Scrum - продукт 2х авторов ещё 90х годов прошлого века, которые обоснованно ввели роль Scrum master в своем гайде. Они не входят сейчас в сам альянс (на сколько мне известно из открытых источников). Кен например сейчас в Scrum.org состоит. Альянс только сертифицирует людей по гайду.
Я к тому, что посыл отличный и как действующий тестировщик и практикующий Scrum master согласна. Было бы круто, если бы аргументы проверялись на точность.
in5anity Автор
26.10.2022 23:20Спасибо за отзыв!
Действительно, Agile - это не методология, тем не менее, во многих источниках (Википедия, например) ее называют гибкой методологией разработки. Но я лично считаю по другому. Поэтому описывая историю Agile я написал, что Agile - это скорее парадигма, цитата:
Agile представил принципы, которые должны были стать основой для будущих методологий. Даже не так, эти принципы должны были стать парадигмой, которую можно внедрить в любую методологию, чтобы она стала гибкой.
По поводу неопытной команды, согласен. Но я постарался осветить проблемы применения Agile в общем плане, а не для начинающих.
Если команде подходит Scrum - пожалуйста! Статья направлена не на критику Scrum. Я лишь говорю, что если вам пытаются навязать Scrum сверху, когда у вас он не работает, или работает плохо, это не Agile. Scrum — это инструмент, а не панацея.
Они не входят сейчас в сам альянс (на сколько мне известно из открытых источников).
Я ничего не говорил по поводу того, входят ли сейчас оригинальные основатели компании в нее. Исторический экскурс рассказывал только про создание Scrum Framework (Scrum).
Krey
27.10.2022 09:12Подходит agile\scrum команде или нет, определяется не командой, а теми задачами, которая эта команда решает. Не важно сверху внедряется scrum или нет, но если он в принципе должен работать для решаемых задач, но не работает, значит проблема, видимо, не в самом scrum, а в том, что команда как то не так его использует или под видом scrum практикует нечто другое. Так что если сверху для решения этой проблемы спускают не просто директивы, а скрам-мастеров и обязательные тренинги, это не противоречит agile.
Отсюда же растут ноги у другого вашего противоречия. Скрам-мастер это не человек, это роль. То что на первых этапах внедрения scrum это отдельный, часто сторонний человек, ничего не меняет и ничему не противоречит.
Waterflow это не ругательство, а подход к разработке для задач, решения которых хорошо известны.
in5anity Автор
27.10.2022 10:23Ну что же вы сразу так про Waterflow, никто ничего плохого про него не писал :)
Не важно сверху внедряется scrum или нет, но если он в принципе должен работать для решаемых задач, но не работает, значит проблема, видимо, не в самом scrum
Вполне может быть что именно в Scrum. Я уже писал, что Scrum - не панацея, а инструмент. У нас кажется конфликт интересов. Вы как Scrum мастер не хотите увидеть другую сторону и посмотреть шире. В статье я писал про Agile, а не про Scrum.
Топик статьи - отделение организации труда от работника. А вы пытаетесь свести его к тому, нужны ли Scrum мастера.
Krey
27.10.2022 10:54Не панацея, не важно agile вообще или scrum в частности имеется ввиду. Гибкие методологии стоит применять только для решения определённых типов задач, а именно для таких, решения которых ещё не наработаны, отсутствуют Best practise, но в то же время это уже не хаос.
Если scrum применяется неверно или agile применяется там, где он не нужен, или даже вреден, это не проблемы методологии, принципов, фреймворков итд. Это проблемы именно применения, неправильного позиционирования себя, своих решений, своих задач.
Вы же отталкиваетесь от команд, организаций, а не от задач. И видите противоречия там где их нет.
Вот начиная с "прожарки", все видимые вами противоречия на самом деле не в самом agile, а в том что вы сами игнорируете границы его применимости.
PS я простой разработчик
Krey
27.10.2022 10:07+2Имхо вредная статья
В скрам-гайде есть про принцип сюхари. Автор находясь на этапе СЮ, ещё сам не разобравшись, не научившись правильно понимать scrum, позиционирует себя в РИ
klimkinMD
27.10.2022 10:08Вопрос к практикующим(!): как Scrum или Kanban управляются с разветвленными зависимостями задач?
Aygul_Bayzigitova
27.10.2022 16:27+1"Причина, собственно, одна: подобно Копенгагенской интерпретации квантовой механики Agile хорошо отвечал на вопрос "что делать", но не отвечал на вопрос "как делать". Данные упущения постарались исправить Scrum и Kanban."
Agile пригоден в условиях неопределённости. Если вы не знаете, как сделать в ваших условиях, никто не скажет вам "как" делать
"Компания Scrum Alliance имеет программу выпуска сертифицированных Scrum мастеров (Certified Scrum Master, CSM). Она предоставляет услуги по внедрению и курированию Scrum для компаний и является единоличным владельцем прав на торговую марку Scrum."
А как насчёт Scrum.org? И здравого смысла?)
"Спринт представляет собой набор задач (Sprint Backlog) из продуктового беклога, в процессе спринта набор задач изменять нельзя"
Цель изменить нельзя, задачи можно.
Именно поэтому метрика %выполнения спринта - бесполезная метрика"В конце спринта, на отдельном совещании вы обсуждаете результаты спринта (Sprint Review), где обсуждаете результаты спринта. Удалось ли достичь цели спринта? Что поменялось во время работы над спринтом? Это обсуждение ограничено четырьмя часами, не является презентаций, а скорее активным обсуждением."
Основная цель Sprint Review - не пообсуждать, а получить обратную связь по дельте разработки
"Developers — это разработчики, которые выполняют задачи спринта."
Только задачи спринта выполняют?)
"Владелец продукта (Product Owner), который манипулирует приоритетом задач в продуктовом беклоге и является звеном между бизнесом и разработкой. Владелец продукта должен устанавливать Product Goal — долгосрочную цель по улучшению проекта. Он не участвует в ежедневном Scrum."
Манипулирует - не самое лучшее слово. В дейлике участвовать ему никто не запрещает
"Задачи оцениваются не в человеко-часах, а в некоторых абстрактных сторипоинтах (Story Points). Один сторипоинт представляет собой сложность некоторой тривиальной задачи, или самой простой задачи в спринте. Далее, все остальные задачи оцениваются как число сторипоинтов относительно этой тривиальной задачи."
Этого в скрам-гайде нет ;)
"Родоначальником методологии Kanban можно считать компанию Toyota."
Канбан-метод и канбан в тайоте - это разные канбаны. И официально, Канбан-метод - это не Agile. А альтернативный путь к гибкости)
"Хотя Scrum и Kanban называют разновидностями Agile, в полной мере они ими не являются. Первый пункт манифеста Agile гласит:
Люди и взаимодействие важнее процессов и инструментов"Scrum и Kanban - конкретные инструменты, не разновидности.
Да, начинать нужно с людей.
Интересный факт, Scrum помогает понять, с кого начать ????"Во-первых, само по себе присутствие человека, который не участвует в разработке, но при этом формирует процесс, уже нарушает манифест Agile"
Неверное утверждение. Скрам-мастер не формирует процесс, формирует команда. Скрам-мастер помогает. В идеале при выходе скрам-мастера из команды все процессы должны остаться действующими и стабильными. Потому что они управляются командой, а не скрам-мастером.
"Увольте вашего Scrum-мастера, откажитесь от идеи Scrum и дайте разработчикам самим организовать процесс"
Интроверты-программисты уткнулись в свои компы и привет организованный процесс
Вообще говоря, наверно, у нас эта схема и сработала. В скрам-мастера я вышла, будучи разработчиком????
Стоит посмотреть на тезисы статьи с другой стороны.
Одно дело, когда менеджмент нагоняет Agile, а разработчики не хотят.
Другое дело, когда разработчики хотят, а менеджмент прямо или косвенно против.
Это в статье никак не рассмотрено
ngekht
28.10.2022 07:12Комментарий - золото!
Про неопределенность - самая ценная фраза... ППКС, в это и есть смысл Аджайл и разница с предсказательным подходом который зачем-то называют водопадом. :-) Хотя суть именно в этом - можем уверенно предсказать - то не нужен Аджайл. Не можем - не сработает никакой водопад.
А насчет процесс или люди - они ж не зря приписали сразу же после 4-х пунктов: "мы не отрицаем важности того что справа, но ценим то что слева больше". Как раз видимо предполагая что будут интерпретации манифеста в стиле статьи - противопоставлением людей и взаимодействий процессам и инструментам. :-(
ngekht
28.10.2022 07:01Статья написана про распространенную проблему - о том как “делают Ажайл ради Ажайла”, не понимая ни сути, ни цели. Проблема действительно есть, и проблема действительно легко выявляется простой проверкой применяются ли на самом деле 4 ценности и 12 принципов. Если бы статья этим ограничилась - была бы просто шикарная, полезная статья. И хороший эталонный образец мышления как его хотят от Аджайл команд.
Но с тем что дальше, когда начали жарить… Пережарили. К сожалению Аджайл хорошего кода и не мешания программистам - ничуть не лучше и не ближе к тому что описано в манифесте. Соавтор скрама и один из авторов манифеста, Кен Швайбер в своей книге очень четко сказал про “не мешать”, объясняя смысл тайм-боксов: “ничто так не стимулирует творчество как веревка на шее”.
Люди о которых шла речь и ради которых задумывался аджайл вообще и скрам в частности - не исполнители. Это пользователи. Это именно для них создается работоспособный продукт, это с ними взаимодействие важнее формальных документов, а они сами - важнее красивого процесса. Собственно Швайбер и пошел дальше, развив идеи в EBM - Evidence-Based Management (управление на основе доказательств). Мы работаем ради того, чтобы принести пользу потребителям. Это и есть профессионализм (ага, то самое “скрам-команда должна состоять из мотивированных профессионалов”). И измеряют наш успех не по крутости и чистоте кода. А по удовлетворенности конечного пользователя. В этом плане Аджайл как раз не за красивый код. Слово которое там постоянно - just enough. То код ровно настолько хороший, чтобы принести требуемую пользу. И ни граммом больше.
Ну а в остальном выше правильно сказали - и про Shu-Ha-Ru, принцип привнесенный в Agile еще одним подписантом - Алистером Коберном. О том что конкретная техника не цель, а отправная точка. И да, глупость считать ее целью. Но не меньшая глупость начинать сразу с изобретения велосипеда. Впрочем, те же PMI в Disciplined Agile не просто так постоянно повторяют что их плейбук - это начальная точка, а не цель :-) Видно наелись.
Ну и в комментарии выше - есть самая ценная фраза, но боюсь большинство ее пропустило. Аджайл о том когда непонятно. По науке - когда мы столкнулись со сложной системой, которую не способны понять и предсказать своим ограниченным умом. Именно поставка результата, при минимизации потерь, в условиях когда предсказать нельзя - и есть цель. Если смотреть на это так - станет понятнее многое. От принципа “… через ЧАСТУЮ поставку” (потому что поставка - это ЕДИНСТВЕННАЯ возможность проверить свои предположения) до принципа спринтов - коротких, эффективных и контролируемых экспериментов по проверке гипотез. И оно конечно подход DevOps с ежедневной и даже несколько раз в день поставкой - еще лучше чем спринт, но давайте будем честными - для большинства программистов даже раз в месяц - уже болезненно. Поэтому месяц - хорошая отправная точка. Быстрее всегда лучше будет, но пусть для начала раз в месяц сделают.
Как-то так. И да, я знаю что интерпретация Аджайла в статье греет душу, а то что написал я - с точностью до наоборот. Но если рыть в то что на самом деле писали и говорили те, кто подписал манифест - как-то так оно и выходит. Такие дела.
KarimAminov
28.10.2022 13:04Что прям "шоркнуло". "дайте разработчикам самим организовать процесс" - как показывает практика, такие команды месяцами пилят релиз и ничего не выводят. Такая команда строит комфортный для себя процесс, не ориентируясь на требования бизнеса.
SigSauer
28.10.2022 15:36А автор понимает разницу между производственным Канбан родом из Тойоты и Канбан-методом авторства Андерсона? А то кажется что смешались люди и кони.
sepulkary
Спасибо большое, очень внятный текст, наконец-то стала проясняться разница между Scrum и Agile (пойду обновлю резюме :).
Надеюсь, в комментариях будут представлены оппозиционные точки зрения.