Переведено с разрешения автора.
Давайте поговорим о так называемом «Мрачном Скраме». Слишком часто, по меньшей мере в разработке ПО, создаётся впечатление, что Скрам угнетает людей. Слишком часто Скрам не приносит результата так быстро, надёжно и постоянно, как должен был бы. В результате - все страдают. И чаще всего сильнее чем все остальные страдают разработчики.
В последнее время я часто размышляю над следующим:
Мой первый aджальный ментор Кент Бек (Kent Beck) как-то раз сказал, что изобрёл Extreme Programming, чтобы сделать мир более безопасным для программистов. Получается, что мир всё ещё небезопасен для прграммистов. Цитируя Кена Швабера (Ken Schwaber), одного из соавторов Скрама, но в другом контексте: «Это меня огорчает».
Скрам, если используется относительно неплохо, — хороший фреймворк. Я говорю это искренне. Очень полезно иметь сильную связь с бизнесом при определении приоритетов: что нужно сделать, а что — отложить. Очень хорошо, когда в команде есть весь набор талантов и умений, чтобы выпустить продукт. Хорошо, когда каждые несколько недель команда может построить осязаемый и протестированнный продукт. Хорошо, когда его можно показать стейкхолдерам, а также проанализировать, как всё прошло и что может быть улучшено. Я изучал Скрам, размышял о нём, и работал по Скраму в течение многих лет, всё в Скраме хорошо. Пусть не идеально, но действительно хорошо.
К сожалению, так можно утверждать только о Скраме как концепции, Скраме как идеале, правильно реализованном Скраме. Как и с любой хорошей идеей, при реализации могут возникнуть сложности. Я называю такой результат « Мрачным Скрамом»*.
* Мне кажется, что это хорошее название для описания неправильных форм Скрама. Если вы согласны, предлагаю вам начать использовать этот термин. Если пожелаете, буду вам благодарен за указание моего авторства этого термина для описания важной темы в истории Agile и Scrum.
Мрачный Скрам: несколько типичных злоупотреблений Скрамом
Давайте рассмотрим, как всё может пойти под откос в Мрачном Скраме, совсем скоро после начала. В этой части статьи мы рассмотрим, как команда окажется в плену Мрачного Скрама. Намерения у лидеров, внедряющих Мрачный Скрам, добрые, они просто делают всё неправильно.
Самоорганизация — дело медленное
Очевидно, что для того, чтобы освоить Скрам, нужно время. В нём есть новые роли и активности. И, что особенно тяжело, он требует принятия новых ценностей. Нам предстоит дать возможность нашим девелоперам организоваться самим, чтобы выполнить работу. Легко созывать Скрам митинги и называть друг друга новыми Скрам ролями. Но по сути очень нелегко по-настоящему делать Скрам.
Обычно внедрять Скрам начинают, когда ещё очень мало людей прошли обучение, ещё меньше людей, действительно понимающих, что такое Скрам, но много тех, которые уверены, что понимают, что нужно делать. Неудивительно, что зачастую всё делается неправильно.
Очень часто современные носители власти* считают, что их работа заключается в определении того, что людям нужно делать, донесении это до исполнителей и слежении, чтобы люди это выполняли. Скрам же учит другому: объясните людям, что именно ожидается на выходе, а потом отойдите в сторону и дайте людям самостоятельно организоваться для выполнения поставленной цели.
* Я буду использовать собирательный термин «носители власти» или «власть имущие», чтобы описать людей, особенно в Мрачном Скраме, у которых есть какая-то власть над девелоперами или полномочия, которыми они активно пользуются. У всех этих людей добрые намерения. Однако, в Мрачном Скраме использование власти обычно ошибочно. И неважно, кто её применяет: тим лид, девелопмент менеджер, владелец продукта или даже Скрам-мастер. У всех этих людей есть полноправная роль в настоящем Скраме. В Мрачном Скраме они просто пока не нашли своё место.
Невозможно одномоментно переключить сознание людей на новую операционную парадигму Скрама. Людям нужно время, чтобы отучиться от старых подходов. Должно пройти время, чтобы научиться новым привычкам, время, чтобы научиться доверять команде - если можно выделить главный посыл этой статьи, то вот он. Для тех, кто попадёт на тренинг по Скраму, обучение Скраму является началом процесса обучения доверию к команде.
Мрачный Скрам рождается в тот момент, когда люди, которые знают, как делать свою старую работу, но не знают, как выполнять свою работу в по-новому, начинают работать по Скраму. Дело обстоит так:
Отлично, мы можем помогать команде каждый день!
Ежедневно команда должна собираться и планировать свою работу на день. Эта практика (Daily Scrum) навязывается любой команде. Возможно, в комнате есть один человек — Скрам-мастер — которому рассказали, как эту встречу нужно проводить. Программистам ничего не рассказывали. Довольно часто даже Владельцу Продукта тоже ничего не рассказали. И почти наверняка ничего не рассказали никому из власть имущих в компании.
Но носители власти уже знают, как выполнять свою работу. Их задача: быть в курсе всего, что делают другие люди; следить, чтобы они делали именно то, что нужно; а также направлять тех, кто делает не то. Как удобно, что каждый день есть обязательная для всех встреча, на которой они, собственно, и будут солировать!
Что получаем на выходе? Вместо того, чтобы команда объединялась вокруг общей миссии и выбирала подходящую стратегию на сегодня, кто-то извне вытягивает из них информацию, обрабатывает её у себя в головах, а после ещё и рассказывает, кому что делать. Так как всё всегда идёт не так, как мы ожидали вчера, эти активности идут в комплекте с поиском виновных и давлением на участников.
Мрачный Скрам угнетает команду каждый день. Самоорганизации неоткуда появиться.
У нас также есть удобное частое планирование!
Каждый спринт Владелец Продукта в Скраме, по идее, должен встречаться с командой, чтобы рассказать, что нужно бизнесу. Команда, в свою очередь, прикидывает, что они могут сделать, чтобы удовлетворить запрос, и приступает к разработке. Ну, по крайней мере так должно быть в теории. На практике же, может случиться, что нет Владельца Продукта от бизнеса, а, если и есть, то этот человек не научен, как исполнять эту роль*.
* На сентябрь 2016 в мире насчитывается около 388,000 сертифицированных Scrum-мастеров, 82,000 сертифицированных Scrum Владельцев Проукта, что означает, что порядка 80% команд работают без владельца продукта, который прошёл обучение. Эти данные также говорят о том, что порядка двух миллионов программистов работают "под началом" этих Скрам-мастеров. В мире сейчас от 10 до 15 миллионов профессиональных программистов. Нам предстоит ещё долгий путь, чтобы все они могли работать в безопасной среде.
Что же, возможно, власть имущие и только начинали разбираться в Скраме, но они точно знают много о том, как решать такую проблему. Каждые пару недель они приходят и рассказывают программистам, что им нужно разработать. О, эти программисты будут возражать! Они ленивые и с гонором. Но власть имущие не поддадутся и будут давить дальше, ведь именно так и нужно управлять людьми. Итак, они говорят команде, что нужно сделать и лучше бы тем подчиниться.
Безусловно, власть имущие слабо или вообще не представляют, как нужно программировать (разработчики же обычно имеют хотя бы отдалённое представление об этом). Власть имущие понятия не имеют, в каком состоянии код, но программисты обычно хорошо это знают. В Скраме разработчики должны сами решать сколько работы они берут, но в Мрачном Скраме власть имущим виднее. Они накидывают сверху, даже когда больше не лезет, потому что видят в этом свою работу — быть двигателем команды.
Результаты никогда не отличаются — команда искренне старается выполнить требуемое. Они понимают, что бесполезно говорить, что это невыполнимо, даже если так и есть. Их только обвинят в лени, глупости и конфликтности. Поэтому они стараются работать как можно лучше, но этого никогда не достаточно.
В конце спринта результаты не будут соответствовать изначальным запросам. Чуда опять не произошло. Разработчики опять облажались. К счастью, у нас есть отличная возможность их исправить — Sprint Review!
Критикуй всё: и то, что было сделано, и то, что не было!
Каждый спринт стейкхолдеры рассматривают, чего команда смогла добиться, и предлагают советы, как двигаться дальше. Отлично выглядит в теории, на практике работает так себе, так как организация слабо разбирается в Скраме.
На практике мрачного Sprint Review начинается с того, что кто-то напоминает всем об «обещаниях» команды. (Имеется в виду то, что требовалось от команды перед тем, как они ответили: «Мы постараемся». Это же обещание, да?) После мы переходим к рассмотрению жалкой картины, которую принесла команда.
И что бы вы думали? Организация требовала больше, чем могло быть сделано, и в итоге команда сделала не всё. Команда старалась, и в этом старании они срезали путь как могли, чтобы выполнить все необоснованные запросы. Они бегло протестировали, попроектировали на скорую руку. Они даже работали тогда, когда уже не соображали от усталости.
Они не оправдали ожиданий, а то, чего они успели сделать - сделано неудовлетворительно. Команда залажалась. Опять.
К счастью, в Мрачном Скраме у нас есть власть имущие, владельцы продукта и стейкхолдеры, которые должны приложить усилия, чтобы исправить ситуацию. Они обязательно донесут до программистов, как плохо те справляются. Это должно вдохновить всех на новые свершения. Как раз для этого у нас есть ретроспетива спринта (Sprint Retrospective)!
Мы расскажем им, как стать лучше...
По идее, на ретроспективе спринта команда рассматривает предыдущий спринт и учитывает весь накопленный ранее опыт. Они отмечают, что вышло хорошо, а что — не очень. Они думают над тем, как улучшить процесс на будущее.
На практике, лидеры Мрачного Скрама придут и здесь на помощь. Они напомнят команде обо всех неудачах, и неважно, что сами микро-менеджерили команду весь спринт. Лидеры постараются донести до разработчиков, что их неудача — а это несомненно неудача — наступила исключительно из-за их лени и некомпетентности.
Чтобы вдохновить команду на улучшения, они обрисуют последствия отсутствия изменений, которые обязательно включают «летящие с плеч головы». Обычно именно эти слова заставляют команду слушать внимательнее.
Иногда команда выступает с какими-то предложениями. Позвольте мне подготовить всех нас - лидеров Мрачного Скрама к работе с возражениями команды. Ниже приведены часто встречающие предложения от команд, а также наши аргументированные ответы на них:
— Разработчики: Нам нужно больше тестов, чтобы снизить количество багов.
— Власть имущий: Нет. Вы и так уже не успеваете выпускать фичи. Вам нужно писать код лучше. Прекратите вписывать в код баги, тогда вам не придётся от них избавляться. Нам нужны фичи, а не тесты!
— Разработчики: Архитектура становится неработоспособной. Нам нужен рефакторинг, чтобы её улучшить.
— Власть имущий: Нет. Зачем вы изначально сделали такой плохой дизайн? Никто не говорил вам делать плохой дизайн. Прекратите делать плохой дизайн и исправьте то, что не работает. Скоро выходные, как раз всё и исправите.
— Разработчики: Требования нечёткие. Нам никто их не объясняет, поэтому то, что мы делаем, не принимается в последнюю минуту.
— Власть имущий: Мы наняли вас, потому что вы умные и можете сами разобраться. Вы должны самоорганизоваться и решить эти проблемы самостоятельно. Хватит рассиживаться и ныть, делайте то, что мы просим!
В целом, идею вы поняли. Держите этих людей между молотом и наковальней. Ведь именно так и разрабатывается ПО, всегда так было. Скрам ничего не поменяет.
У... это печально
Безусловно, Скрам пытается это всё поменять. Но пока не поменяется содержимое голов и сердец в организации, слишком часто будут случаться приступы менеджмента «старой школы»: сейчас это случается каждые пару недель, а зачастую даже и каждый день!
Так а что же делать нам, девелоперам?
Вещи, которые случаются в Мрачном Скраме — это злоупотребления властью, противоположные тому, чему Скрам пытается нас научить. Ни один эксперт по Скраму в здравом уме не предложит вам их использовать. Люди, которые практикуют подобное, делают всё неправильно. И тут не может быть альтернативных мнений. Я считаю, что злоупортеблений не избежать, если люди действительно не поймут принципы и ценности Скрама.
Может показаться, что команде разработки не остаётся ничего кроме как смириться с неизбежным угнетением. К счастью, это не так. Хорошо, что в наших руках есть очень мощное оружие. Плохо, что сделать это непросто. Но, опять же, хорошо, что в основном нужно будет программировать, а это мы делать умеем.
Основной причиной давления со стороны Владельца Продукта и/или других носителей власти является то, что они не видят чётко, над чем мы работаем, что конкретно мы делаем. Если мы сможем наглядно показать наш кристально-чистый (извините за каламбур - здесь не имеется в виду agile-метод "crystal") прогресс, мы можем изменить отношение к нам.
Если в продукте имеется много известных дефектов, руководство испугается, что их там на самом деле ещё больше. Из-за страха они станут давить ещё сильнее. А так как страх часто сопряжён со злостью, они будут злиться на нас. Как показывает жизнь, очень сильно злиться.
Если мы примемся за разработку дизайна и инфраструктуры перед тем, как начнём разрабатывать фичи, сложится ощущения, что мы затягиваем выпуск продукта. Это поселит страх среди руководства, что мы опоздаем к релизу или вообще его зафейлим. Опять же, весь страх и злость будут направлены на нас.
Если мы замедлимся из-за того, что не успеваем с архитектурой, мы будем выпускать меньше фич. Меньше фич, больше страха, больше злости, больше давления.
Когда руководство не видит работающего ПО, они начинают беспокоиться о будущем — и небезосновательно. Они проявляют свой страх неконструктивно и, безусловно, это неприятно. Но разработчики могут это прекратить. Я знаю только один путь — выпускайте ПО. Настоящее, работающее, "задеплоенное" ПО. И с внятными фичами!
Сила инкремента
Скрам просит выпускать протестированный, интегрированный, работающий и готовый к выпуску инкремент продукта каждый спринт. Мы чуть ниже поговорим о том, как это делать. На сейчас, давайте просто представим, что уже умеем это делать: у нас есть возможность поставлять рабочий инкремент продукта каждые несколько недель.
Большая часть страха улетучится сама собой, потому что руководство увидит реальные результаты. Однако, часть страха останется, потому что реальные результаты будут несколько отставать от надежд и мечтаний. Все мечтают о спортивной машине, но иногда нам достаётся только велосипед. Возможно мечты были о пони, но подарили тебе кошку, даже не собаку - её-то хоть можно было бы уважать. (Что-то я отвлёкся.)
Всё же, имея на руках полноценный, протестированный, интегрированный инкремент продукта с основными фичами, которые просили сделать, тон разговора изменить проще:
— Власть имущие: Вы мало делаете, вы должны делать больше.
— Разработчики: Мы делаем всё, что можем. И мы стараемся совершенствоваться. Что же касается продукта: всё, что в нём есть работает и всем можно пользоваться. Будет также мудро использовать для планирования и прогнозирования нашу реальную скорость разработки. Также логично было бы работать сначала над самыми приоритетными элементами беклога. Давайте попробуем их чуть облегчить и уменьшить, чтобы выпускать самое важное ещё быстрее.
Чуда сразу не случится, но понемногу начнёт работать. И чем более полноценным и настоящим будет наш продукт, тем больше это будет заставлять людей смотреть на вещи реально и, соответсвенно, базировать свои управленческие решения на этих фактах. И не смотря на то, что так зачастую может казаться - руководители не идиоты. Они стараются принимать наилучшие решения в рамках той информации, которая у них есть. Если мы можем дать им больше полезной информации, в виде работающего ПО, они начнут использовать эту информацию. И чем больше они будут оперировать этими данными, тем реже будут прибегать к давлению и злоупотреблению властью.
Хочу ещё раз подчеркнуть - это не волшебство, и за день ничего не изменится. Однако, я видел, как изменения происходили раз за разом. Конечно, абсолютно дисфункциональным организациям уже ничего не поможет, но мне кажется, что мало кто из читателей этой статьи работает именно в таких. В остальных же случаях это сработает, если мы попробуем.
Но есть загвоздка
Загвоздка есть всегда. В данном случае загвоздка заключается в том, что если мы хотим изменить ход диалога с власть имущими, чтобы снизить давление, и уменьшить частоту злоупотреблений - инкремент продукта должен по-настоящему работать. Он реально должен быть протестировать, проинтегрирован и быть готовыми к поставке, содержать все элементы беклога, которые мы взялись сделать.
Это сделать непросто. Что ещё хуже, нас такому не учат даже на факультетах компьютерных наук. Этому нас не научат на коммерческих курсах, об этом не пишут в книгах «Мой любимый язык программирования для чайников». Для этого есть целые практики, которые были созданы специально для того, чтобы разрабатывать ПО инкрементами, качественно протестированным, с хорошим дизайном, сфокусированным на фичах и готовым к выпуску в любой момент.
Если мы собираемся перевоспитать Мрачный Скрам в Скрам - то, каким он должен быть, нам стоит научиться этим практикам. К счастью, они не особо сложные для понимания, но, как и программирование, требуют практики и трудолюбия, если мы хотим ими овладеть на достаточном уровне. В других статьях этой серии я опишу их более детально, а сейчас давайте их рассмотрим кратко.
Приёмочное тестирование
Довольно часто в конце спринта идут бурные осуждения, разработала ли команда именно то, что «хотел» Владелец Продукта. Эти обсуждения обычно бесполезны и разводят Владельца Продукта и разработчиков по разные стороны баррикад. Мы же хотим, чтобы они активно работали вместе, а не воевали.
Очень важной практикой для Владельцев Продуктов и разработчкиов является согласование конкретных и исполняемых приёмочных тестов для каждой истории. Полезно о них думать, как о «примерах».
— Команда: OK, мы хотим, чтобы система показывала всех клиентов с задолженностью в 30 дней, а также общую сумму задолженности. Вот список с клиентами, попадающих под этот критерий, с указанием суммы.— PO: Нет, это не совсем так. Мы не хотим видеть клиентов с задолженность в 30 дней, только больше 30.
— Команда: OK, вот так? — PO: Точно! Дерзайте!
Каждый маленький пример станет приёмочным тестом для истории или элемента беклога, о котором идёт речь. Договоритесь, что, пока история не протестирована, она не считается законченной. В противовес этому, если тестирование было произведено, Владелец Продукта и команда соглашаются, что было сделано то, что просили.
Вполне вероятно, что Владельцу Продукта не понравится результат. Но риторика уже изменилась. Владелец Продукта не может просто сказать: «Это не то, что я хотел!». Это именно то, что он хотел, когда соглашался. Скорее всего он узнал что-то новое и теперь хочет что-то другое. И это хорошо, потому что задачей Владельца Продукта является создание наилучшего продукта. Совместная работа над конкретными приёмочными тестами помогает нам понять, что именно требуется, когда мы этого достигли, а также совершенствует наше понимание изменений и учит правильно составлять запросы на изменения.
И ещё один важный бонус, если мы автоматизируем эти примеры, мы можем их все запустить и с уверенностью показать, что продукт всё ещё делает всё то, о чём мы договаривались.
Инкрементальный дизайн архитектуры
В Скраме ожидается, что команда выдаёт в конце спринта протестированный, работающий, потенциально готовый к поставке инкремент продукта. Очевидно, что мы не можем представить и описать всю необходимую архитектуру в начале разработки: ведь мы можем представить и то довольно в общих чертах, как будет выглядеть продукт. И, конечно же, в конце концов нам нужно будет иметь адекватную архитектуру. Поэтому дизайн ПО должен разрабатываться инкрементально, т.е. понемногу в течение всего процесса разработки.
В этом нет ничего страшного: пока продукт ещё совсем мелкий и завершённый ему не нужно много архитектуры. По мере же его развития роль дизайна возрастает: ему нужен более стабильная, продуманная, сложная архитектура. Нам просто нужно научиться развивать дизайн синхронно с продуктом.
«Просто» — самое опасное слово в разработке ПО*. Разрабатывать архитектуру во время разработки не просто, это требует мастерства в дизайне, тестировании и рефакторинге. Мы рассмотрим их вкратце ниже и также в других статьях.
Но непреложная истина остаётся неизменной: если мы хотим выпускать инкремент продукта каждый спринт, нам нужно научиться делать хороший дизайн архитектуры инкрементально.
Рефакторинг
На сегодня нам не известно лучшего способа разработки инкрементального дизайна архитектуры, чем то, что называется "рефакторингом". Это процесс улучшения дизайна существующего кода - не ломая его.
Рефакторить не значит переписывать. Безусловно, если у программы плохой дизайн архитектуры, мы можем написать новую программу, используя лучшую идею дизайна. И, пожалуй, я мог бы вам сказать: «просто написать», так как такой трюк редко работает, скажем так: в теории это можно было бы сделать. Нэто заняло много времени, которого в Скраме у нас нет. Так что вместо переписывания нам нужен улучшенный дизайн до конца спринта.
Рефакторинг — это процесс трансформации кода, обычно очень маленькими шажками, с целью сделать его лучше. Современные IDE могут нам в этом помочь: большинство из них предлагают разнообразные автоматизированные рефакторинги. Они могут вытащить наиболее используемый кусок кода и сделать из него метод или функцию. Они могут перемещать код между классами. Они могут переименовывать объекты или изменять сигнатуру методов.
Если мы сможем правильно пользоваться рефакторингом, мы будем инкрементально улучшать наш дизайн по ходу разработки. Ударение на слово «правильно», именно этому нам придётся научиться.
Улучшение инкрементального дизайна необходимо. Рефакторинг — это то, как мы этого добиваемся.
Тестирование программистом
Помимо приёмочного тестирования, нам нужны тесты, которые нужна автоматические тесты кода, которые будут писать разработчики. Каждая фича, которую мы разрабатываем, состоит из множества шагов программирования. Мы можем допустить ошибку в любом из них. Хорошим примером автоматизации тестирования является разработка через тестирование (Test-Driven Development, TDD), которая проходит следующим образом:
Подумайте о следующем маленьком шаге на пути к нашей фиче. Напишите тест, который должен проходить, когда этот шаг реализован. Удостоверьтесь, что тест не работает (красный).
Напишите код, чтобы реализовать этот шаг. Удостоверьтесь, что тест работает (зелёный).
Проверьте, что код читаем и чист. Если нет, проведите рефакторинг. Запустите тест ещё раз, чтобы удостовериться, что он всё ещё работает (зелёный).
Повторяйте пока не закончите фичу.
Это не единственный способ автоматизации тестирования, но это пока лучший из тех, что нам известны. Так или иначе, полезно иметь множество различных мелких тестов, которые поддерживают каждый большой приёмочный тест, потому что мелкие тесты показывают, в каком шаге ошибка, тогда как приёмочные тесты просто орут нам в лицо: «Что-то поломалось!».
Также эти тесты могут помочь нам в более масштабных рефакторингах. Думаю, что идеальный TDD программист может проделать все улучшения дизайна архитектуры в рамках TDD цикла, но, как показывает мой опыт, проблему с дизайном не всегда можно заметить сразу. Рано или поздно, работая с этим куском кода, я смогу заметить эту проблему, тогда мне потребуется дополнительно потрудиться над рефакторингом. Также как и при разработке новой фичи, тесты смогут нам помочь удостовериться в том, что мы ничего не сломаем, после того, как проведёт изменение дизайна.
Непрерывная интеграция (CI)
Скрам требует от нас работающий, тщательно протестированный, полезный в использовании инкремент продукта, содержащий в себе ценность всех элементов беклога из предыдущих спринтов: целостную, работающую, протестированную, исправную программу.
Очевидно, что для достижения этой цели в конце спринта вся команда должна выдать единый результат: интегрированный, протестированный и работающий. Отложенная интеграция припрячет проблемы, для решения которых потребуется значительные усилия отладки. Чем дольше мы затягиваем, тем хуже становится. И наоборот, если мы проводим интеграцию после каждого незначительного изменения, всё становится значительно проще.
Итак, мы пришли к тому, что автоматизация сборки с прогоном всего набора тестов, является неотъемлемой частью процесса разработки любой Скрам команды. В большинстве случаев, чем чаще команда готовит билд, тем лучше для проекта. А ещё лучше проводить сборку «постоянно», именно поэтому эта практика и называется Непрерывной Интеграцией.
Как пережить времена Мрачного Скрама?
Существует распространённый, возможно неизбежный этап Мрачного Скрама на пути внедрения Скрама
Все случаи Мрачного Скрама неуникальны, обычно они развиваются по одинаковому сценарию
Команда разработки может улучшить ситуацию для себя и помочь организации перейти от этапа Тёмного Скрама к Скраму Реальному - более счастливому месту для существования.
Если вы хотите внести вклад в общее дело, напишите мне письмо на ronjeffries @ acm точка org.
(Если же у вас комментарии к переводу и редактуре этой статью: alexey @ krivitsky точка com)
Comments