Agile. Перезагрузка.

Автор: Александр Якима


Король умер. Да здравствует король!

Долгое время, наблюдая за различными Scrum-командами в разных странах мира, ловлю себя на мысли о том, что…

…при всей полезности наиболее распространенной из методологий – Scrum – что-то очень важное в ней оказывается «за бортом», теряется за «стори-поинтами», «скрам-митингами» и «покерами». Получается определенный вариант Agile-метода скорее по букве, а не по духу гибкой разработки.

Тут стоит на мгновение остановиться и отметить, что огромное (позитивное) влияние Scrum на индустрию неоспоримо – став одной из ключевых методологий за последние несколько лет, Scrum может по праву претендовать на роль «убийцы различного рода псевдонаучных Тейлористких концепций в разработке ПО». Это так, хотя я однажды строго-настрого дал себе обещание не сравнивать больше Agile-методы с Водопадной моделью – это моветон, которому, к огромному сожалению, продолжают предаваться многие в индустрии. Но что произошло в итоге такого «изничтожения»? Известный сценарий: «Король умер. Да здравствует король!». Масса команд по всему миру работает в Scrum-модели, хотя одни при этом пытаются «натянуть» Scrum на одну из привычных для них моделей управления проектами (например, PMP), другие находят в ней глубокое методологическое обоснование для собственной недисциплинированности, третьи с огромным рвением принимают всю увлекательную красочность ритуалов, не видя за ними ключевого мотива, написанного на скрижалях Манифеста Гибкой Разработки. А Scrum в аутсорсинге? Это же вообще отдельная тема – можно зубы сговорить. А код? То, что выдают многие Scrum-команды – просто ужас, а не код.

Поставим себе простую и достижимую цель. На протяжении этой статьи попробуем вместе с читателем проанализировать и, если нужно, отказаться от всего второстепенного в преобладающей сейчас методологии, оставив только то, что будет действительно первичным, важным связующим звеном с Манифестом (http://agilemanifesto.org/). Задача для старателя, можно сказать. Попробуем вместе намыть настоящего золота.

Мышление от результата.

Итак, первое, чего хотелось бы достичь – это четкой и ясной практической реализации принципа, который гласит, что Рабочее ПО важнее и ценнее всего другого и является основным мерилом прогресса разработки (Ценность #2, Принципы #1, #3, #7). Таким образом, мы хотели бы паче всего остального удостовериться в том, что по окончании каждой итерации мы сможем предоставить стейкхолдерам рабочее (т.е.: функционирующее и оттестированное ПО). Увы, для этого одного только написания пользовательских историй оказывается мало. «Карточки» весьма часто и остаются только карточками и ни чем иным на протяжении всей итерации. С другой стороны, у многих команд совершенно атрофирована способность показать что-то «материальное» в итоге итерации. У других же есть желание, но не срастается все в целостный инкремент продукта… просто не выходит. Итерация завершается «работой в прогрессе». Тут, к сожалению, работает принцип, прекрасно отмеченный Экзюпери в его «Цитадели»: «Логика приводит туда, где назначаешь ей свидание». То есть, в нашем случае она приведет нас ровно к нашим же предположениям, не более того. Для того чтобы под конец итерации получилось что-то вещественное, нужно это «вещественное» себе четко представить, а не только предполагать: что бы мы не написали на карточке – оно как-то будет продемонстрировано. А для этого на планировании, вместо выписывания историй в якобы продвинутых форматах, мы просто сядем вместе всей командой и зададимся вопросом:

Что именно мы покажем через 2 недели?

Итак, не пишем пока что никаких карточек, а попробуем… порисовать и поговорить. Именно так, потому что на демо мы ничего не пишем и не читаем. На демо итерации мы показываем софт и объясняем, как он работает. Так давайте с этого и начнем. Если мы планируем доставить за итерацию некий пользовательский сценарий – нарисуем очень грубый набросок скринов. О… в виду такой первичной визуализации у некоторых членов команды уже возникают вопросы: а как мы это сделаем, асинхронно или все одним post-методом? Какая там вообще валидация должна быть для редактируемого дроп-даун-списка? Очень хорошо! Теперь мы хотя бы закрепили в голове ожидаемый конечный результат. Итак, по ходу дела вокруг нашей диаграммы вырастает несколько карточек или просто надписей – аннотаций к этому сценарию. А теперь фокус (который точно не понравится производителям колод карт для плэннинг-покера и большим зелотам от Scrum) – берем этот флип-чарт-лист и принимаем в качестве части плана. Следующая порция ценности на очереди – API для третьих сторон – пользователей нашей системы статистики. Опять рисуем и озвучиваем. Рисуем XML, которым будут обмениваться стороны, рисуем «клиент», который будет эмулировать третью сторону (и тут сразу же у кого-то идея – ребята, а неплохо бы пригласить на демо кого-то из такой компании). Замечательно. Опять целый ряд аннотаций, вместе с которыми мы принимаем и этот лист как часть плана. Обратите внимание – нет историй. Мы уже видим, что такое «мышление от конечного результата» говорит нам гораздо больше, чем карточка с «СМС-кой» на ней. Продолжаем до тех пор, пока команда не решит, что хватит. А решит она это просто, на ощупь, по опыту. Мы учтем только самые базовые календарные нюансы – сколько выходных в итерации, у кого отпуск или отгул и… рискнем положиться на командное чутье. Мы не будем с вами утверждать, что все теперь – цифрам бой. Нет, если команда захочет перестраховаться – пожалуйста, но на практике оказывается, что точность оценки зависит вообще не от того, используются ли цифры (стори-поинты или идеальные человеко-дни) или же такого рода «командное чутье». Значительно важнее то, насколько плотно сотрудничают друг с другом члены команды в рамках своих задач и, потому, могут надежно полагаться на групповое впечатление как результат сверки различных точек зрения. Итак, команда заканчивает сессию планирования тем, что в какой-то точке останавливается и говорит Владельцу Продукта: «все, свыше этого не можем вместить в спринт. А на это готовы брать обязательства». Владелец продукта (все время наблюдавший за процессом планирования и делавший корректировки) таким планом доволен – у него есть четкое представление о том, что он увидит через 2 недели. Искушенный читатель наверняка заподозрил, что чего-то не хватает. Точно! Нет тасков! Об этом поговорим немного позже, а пока что, поскольку план принят, берем все эти листы и тащим их на стенку, у которой у нас будут проходить ежедневные стэндап-митинги или их некое подобие. Итак, планирование итерации мы провели.

Взаимодействие.

А команда у нас будет такая: 5 разработчиков и 2 тестировщики. Тестировщики у нас, представим себе, мануальные. С таким составом и начнем.

Итак, пусть это не звучит как откровение, но большей ошибки при выборе названия для своей методологии, чем назвать ее “Scrum”, трудно себе представить. Почему? Да потому, что надо было назвать «Регби». По крайней мере, это избавило бы тысячи (а может и десятки тысяч) команд по всему миру от ложного представления, что ежедневное стояние на Scrum-митинге делает их Scrum-командой. Я не преувеличиваю. Суть Scrum-методологии теряется за ритуалами, в то время как основа Scrum – это сотрудничество между членами команды для достижения цели (занести мяч за линию – т.е., сделать “try” или “try at goal”), что приносит команде очко. В Регби мяч пройдет чрез целый ряд членов команды, прежде чем удастся занести его за линию. Любой Scrum-тренер возразит: «так мы же используем волшебную игру ScrumBall (также известную как BallPoint Game), дабы преподать понимание этого принципа»; см., напр.: http://dpwhelan.com/blog/uncategorized/learning-scrum-through-the-ball-point-game/. Да, это так, однако, это никак не помогает в реальной жизни, когда два разработчика готовы найти десяток причин, по которым они не могут работать над одной бизнес-задачей вместе. Например, потому что «она не распараллеливается» - это наиболее типичный «аргумент», и часто потом следует «контрольный выстрел в голову»: «только и дело, что будем друг другу на ноги наступать…». А суть проблемы гораздо более глубокая –

Сотрудничество подразумевает существование культуры сотрудничества.

Покорнейше прошу у читателя прощение за кажущуюся тавтологию, но именно так и есть – сотрудничество либо становится привычным культурным сценарием для команды, либо от него останется одно лишь название. А это значит, что мы, как команда, уже не оперируем понятиями «эффективности работы», «распараллеливания», «независимости задач», а вмиг представляем себя на стадионе Ellis Park, где мы играем против сильной, хорошо сбитой Южноафриканской регби-команды. О чем мы сейчас думаем? Об одном – как протащить мяч на ту сторону поля любой ценой, и уж точно не о том, пробежит ли при этом каждый член нашей команды равную дистанцию по полю и сможет ли он что-то делать независимо от товарищей по команде.

Итак, в нашем случае два разработчика, Иван и Вивек, берутся за первый «лист», на котором изображен конечный ожидаемый результат вышеупомянутого пользовательского сценария. Они исходят из простого принципа – они вместе доставят этот кусок бизнес-ценности, а какое распределение работы между ними это подразумевает, несет только вторичное значение. Более того, «параллелится» ли задача или нет – в их лексиконе нет даже такого слова. К ним примыкает Ольга – тестировщик. У нее уже есть первичное представление о том, как «это» тестировать (поскольку она видит рисунок) и огромное желание поскорее начать.

Наша текущая проблема в том, что Scrum не говорит ни слова об инженерных практиках. Просто он так задуман Швейбером и Сазерлэндом – как общий процессный каркас, некий скелет, на котором команда, исходя из своего контекста, уже сможет «нарастить мясо» - именно то, что подходит ей. К огромному сожалению, и, невзирая на все благородство изначальных намерений авторов методологии в их желании оставить командам огромную свободу выбора практик, на многие команды это произвело скорее негативный эффект. А именно, породило представление, что того, что есть в Scrum вполне достаточно для успешной Agile-разработки. А это уже, в свою очередь, исключает такую (голую) имплементацию Scrum из семейства Agile-методов (см. Манифест Гибкой Разработки, Принципы #9, #10, #11).

Сейчас мы и попробуем сформулировать минимальный набор необходимых инженерных практик.

Тонкие вертикальные срезы.

Итак, Ольга хорошо помнит типичный сценарий каждой итерации – первую половину (а то и две третьих) просто нечего делать, а потом под конец – бу-бум! Наваливается куча функциональности, которую протестировать нормально просто не хватает времени. Соответственно и нет времени на баг-фиксинг у разработчиков. Так в прошлом спринте команда не смогла доставить один из «больших листов» - разработчики закончили слишком поздно, и не было шанса пройтись даже один раз по всей функциональности. Да и если бы это была единственная проблема. Оказалось, что они при этом поломали много другой функциональности. Плюс ко всему, Владелец Продукта далеко не всем был доволен с точки зрения нюансов поведения системы – на «листе», все же, всего не нарисуешь, а когда увидел все на демо – оказалось уже поздно.

Поэтому в текущей итерации команда решает изменить тактику – теперь они постараются сделать так, что…

функциональность появится гораздо раньше, будет постепенно и ощутимо наращиваться и будет «зафиксирована» с помощью автоматических тестовых скриптов.

Иными словами, команда попытается

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

Для этого Иван, Вивек и Ольга прикидывают (потенциальный) план инкрементальной разработки, который просто обозначает их намерение уже в первый вторник итерации завершить такой-то срез, в четверг – такой-то и т.д. Каждый срез – это функционирующая система, вот только это часть функциональности, а не вся функциональность. Вот почему им не нужны таски! Таски – это завуалированный под гибкие методы старый-недобрый метод Work Break-down Structure (WBS). Наша команда решает, что настоящий статус измерим только с помощью вещественной функциональности, а не состава работ, вовлеченных в доставку этой функциональности. У Ольги вопрос к разработчикам: во-первых, как она вообще сможет писать тесты и, во-вторых, она всегда будет запаздывать «на один срез». Вивек, большой популяризатор простых подходов в команде, предлагает Ольге довольно хитрое решение – они сядут вместе за его компьютер, он набросает основные интерфейсы (в его случае это публичные методы Java-классов) и они вместе напишут один-два теста по ее мануальным сценариям. Он также объяснит, как работает единственный известный ему фреймворк для тестирования – Junit. Отметим, что команда и думать не хочет о тестировании этого сценраия через GUI, тестироваться будет бизнес-логика напрямую. Так быстрее и надежней, считает команда.

Так и происходит, к удивлению Ольги, писать тесты не так уж сложно, а кое-какой опыт написания программ на Турбо-Паскале в университете оказался не таким уж бесполезным. Вначале коряво, но со временем все четче и уверенней, она добавляет новые тесты к уже существующим интерфейсам, время от времени работая с Вивеком – то приглашая его за свой компьютер, когда дело зашло в тупик и нужна помощь в java-реализации тест сценария, а знаний еще не хватает, то за его компьютер, когда у него какой-то из тестов «валится». Два раза Вивек корректировал интерфейсы и это повлекло за собой незначительный рефакторинг тестов со стороны Ольги, но в общем все неплохо, потому что во вторник таки появился первый функциональный (вертикальный) срез. Ольга дописывает тесты, но функциональность уже можно показать Владельцу Продукта, пусть сейчас скажет, что мы реализовываем правильно, а что нет. И у него таки возникает ряд важных уточнений. Это касается и Вивека, и Ивана, которые сразу же, основываясь на этом фидбеке от Владельца Продукта, довешивают аннотации на «листе». Несмотря на то, что сотрудничество Вивека и Ивана пока что оказалось за кадром, оно происходит по сценарию, подобному тому, как Вивек работал с Ольгой. Вивек и Иван решили делать бизнес-логику и схему данных соответственно (именно поэтому Вивек с Ольгой работал плотнее). Часто стоя вместе у доски и вырисовывая части логики, потом работая вместе за одним компьютером, потом работая врозь, потом опять вместе, потом опять независимо, потом опять у доски и т.д., проводя таким образом 20%-30% времени совместно, Иван и Вивек всецело воспользовались, тем, что в индустрии принято называть спонтанной парной работой (Spontaneous Pair Work) или Программированием Бок-о-бок (Side-by-side programming). Это очень простая и легкодостижимая альтернатива Парному Программированию, хорошо известному из XP.

Во вторник после обеда Ольга закончила с тестами. Нужно сказать, что с тестами она особо переусердствовать не пыталась, исходя из принципа:

Лучше покрыть один-два ключевых сценария и двигаться дальше, чем позволить команде застрять.

Тесты для первого среза уже есть, поскольку есть интерфейсы (хотя это и «пустышки») для остальной функциональности, Оля спокойно продолжает писать новые тесты. Вивек и Иван решают интегрировать текущий срез с остальной частью команды…

Инженерные практики и общение.

Ага! Полезло! Оказывается, что Иван и Клаус, другой разработчик, работающий над вторым «листом», независимо друг от друга создали две разных копии таблиц в базе для одного и того же типа сущностей – и там и там нужен лог действий пользователя. После прогонки тестов по функционалу Вивека и Ивана, Клаус удивился, почему это лог системы (в его представлении) оказался без изменений. Ура! Ошибку удалось обнаружить. У команды предостаточно времени, чтобы ее исправить. Однако Клаус задумался, а потом сказал: «Иван, мы же с тобой оба были на стэндап-митинге сегодня утром, а к этому моменту и у меня и у тебя уже было по таблице… и мы этого, естественно, не смогли обнаружить. Я, честно говоря, вообще ничего толкового на стэндапе не услышал». Иван, кивает. Иван и Клаус быстро собирают всю команду на 2-х минутный митинг, чтобы объявить всем, что Лог-таблица для пользователей уже существует и называется она USER_EVENT_LOG. Молниеносно следует вопрос от напарника Клауса, Иштвана Петровича: не мог бы Иван создать для него заодно таблицу для логирования покупок вместе с функциональностью доступа к таблице, поскольку они со своей API-задачей и так с трудом успевают. У Ивана будет немного времени и он соглашается помочь, но прежде этого, Иштван Петрович ведет его к их «листу», они что-то там несколько минут обсуждают, потом он показывает Ивану код, увлеченно тыкая пальцем в монитор и в конце концов Иван уходит с идеей имплементации.

В четверг, когда у Ивана и Вивека готов следующий срез, а Ольга уже опережает их по разработке тестов, они снова решают интегрироваться с остальными. И опять обнаружилась проблема, хотя уже и совершенно другой природы. Проблему, конечно, решили, но к стэндапам доверие окончательно подорвано – сегодня стэндап прошел так же безоблачно. И команда решает их просто впредь не делать. Вместо этого они приходят к выводу, что им нужно интегрироваться почаще, лезть в код друг друга, брать «чужие» участки кода от итерации к итерации, использовать практики «легковесной» парной работы и главное – общаться, когда нужно, а не раз в день в формате, который не позволяет даже настоящих проблем выявить. Итак,

Команда подчиняет формат общения инкрементальному ритму разработки, частой интеграции, легковесной парной работе и постоянному вовлечению Владельца продукта.

Таким образом, команда преуспевает в отношение: Ценности #1, Ценности #4, и Принципов #2, #4, #5, #6 Манифеста гибкой разработки.

Кайдзен.

А теперь обратим внимание на то, как действовала команда, когда сталкивалась с проблемами. Во-первых, нужно отдать им должное, они сразу пытались каждую проблему сразу вынести наружу, сразу обсудить, сразу применить хотя бы какое-то решение. Это важно – проблему нужно научиться обнаруживать и безжалостно атаковать, если ты Agile-команда. Но что случилось после второй интеграции – команда поняла, что ежедневные Scrum-митинги для них неэффективны и, как только убедились в этом, - приняли решение. Это означает, что команда больше не смотрит на ретроспективу, как на единственный обязательный этап для рефлексии, вместо этого…

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

Ретроспективу, кстати, они решили из своей каденции не исключать, просто она превратилась в сессию, где команда резюмирует усовершенствования за последние две недели и просматривает, что из более ранних инициатив не удалось стабилизировать и необходимо вернуться к проблеме.

Оставшаяся часть итерации прошла довольно быстро. Демо в этот раз не было большим сюрпризом. Владелец продукта остался доволен – некоторые отличия от изначального плана были, но о них он знал заранее, так как уже видел промежуточные «вертикальные срезы». А команда после демо попросила Владельца Продукта просто, как подметил Клаус, одной булевой переменной описать результат итерации для всей команды, на что Владелец Продукта с уверенностью подтвердил: «Итерация принята!».

Итоги метода.

Теперь давайте подведем итоги нашего метода в виде компактного списка основных необходимых практик.

1. Команда работает итеративно, итерации короткие, обычно 1 или 2 недели, команда выбирает и поддерживает единый ритм итерации.
2. Итерация завершается демонстрацией работающего ПО (и других возможных артефактов - результатов спайков и т.д.). Демонстрируется все!
3. Команда начинает итерацию с того, что строит четкое представление о том, что и как будет демонстрироваться в конце итерации. Визуализация и озвучивание ожидаемого конечного результата – основной метод.
4. Сотрудничество на задачах и постоянная ротация по областям системы гораздо полезней для взятия реалистичных обязательств на итерацию, и для их выполнения, чем привычные способы эстимирования.
5. Каждая бизнес-задача реализовывается в результате последовательных «тонких» вертикальных срезов функциональности, занимающих не более 1-2 дней.
6. Команда интегрирует весь код несколько раз за спринт, преимущественно каждый день. Интегрированные срезы демонстрируются Владельцу Продукта для получения первичного фидбека.
7. Команда делает, по крайней мере, легковесное покрытие функциональности автоматическими тестами, начать которые можно уже после первого среза. Тесты всегда пишутся в той же итерации, без тестов нет приемки.
8. Общение команды подчинено практикам разработки: частой интеграции «срезов», сотрудничества на задачах и т.д. – то есть происходит там, где нужно и тогда, когда нужно.
9. Команда ни на минуту не останавливается в поиске текущих проблемных зон и ограничений в их работе, внимательно анализирует и сразу же принимается за решение проблем и шаги по совершенствованию процесса.

1 comment:

 
Powered by Blogger