Эффективное управление бэклогом в Scrum и других моделях

В нашей LinkedIn-группе, Agile Requirements & Quality, появился вопрос о том, как эффективно управлять очередями требований в Scrum. В частности, как предотвращать эффект длинных, а значит, плохоуправляемых и плохопредсказуемых очередей (см. пост посвященный обсуждению эффекта длинной очереди), из-за которых очень сложно и часто просто невозможно вложиться в заданные самой же командой временные рамки.

Опишем интересующую нас ситуацию как можно более обобщенно, чтобы мы могли применить решение в разнообразных процессных моделях. Для этого, вместо рассмотрения только случая со Scrum, мы возьмем гораздо шире, и даже шире, чем семейство Agile-методов. А именно, будем рассматривать все процессы, в которых доставка может делаться часто - от нескольких дней, до 2-3 недель (мы говорим "может", поскольку часто речь идет о методах, где "внутреняя доставка" происходит более часто, чем "внешняя", конечному пользователю). Очевидно, сюда попадает Scrum, где доставка производится каждые две недели (или же "внутренняя" - каждые 2 недели, а внешняя, возможно, как результат нескольких спринтов). Сюда попадает XP и другие Agile-методы (Crystal, DSDM, ...). Сюда подпадает Kanban, где доставка делается либо сразу же по ходу завершения задачи, или же по заданному (1 или 2-х недельному) ритму. Сюда даже может попасть некий вариант Cowboy Coding, только бы доставка делалась часто. Некая широкая категория процессов с частой доставкой, причем доставляется конечная ценность (обычно это работающая функциональность системы). Эти процессы в некотором смысле противоположность пофазному процессу, где все требования проходят сквозь систему один раз, одним большим пакетом.

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

На практике часто получается удивительная ситуация: методы как бы и "быстрые", но стейкхолдеры этого могут совершенно не ощущать и не испытывать отнюдь ни малейшей радости от процесса. Причина - плохая предсказуемость процесса. А получается так потому, что входная очередь (бэклог) совершенно неправильно управляется и понимается. Типичный сценарий в Scrum, например: владелец продукта, по просьбе одного из стейкхолдеров помещает в бэклог определенную задачу. Для стейкхолдера это звучит как обещание того, что о его задаче вскоре обязательно позаботятся, тогда как добавление задачи в и без того уже разросшийся бэклог не будет de facto подразумевать ровным счетом ничего. Задача может пролежать очень долго, пока до нее дойдет очередь с одной стороны потому, что длинная очередь, как мы раньше видели - это огромная вариация по времени, а с другой - постоянная переприоритезация может еще дальше отсрочивать задачу. Ну а если мы ставим ее сразу в главу очереди, то подобному эффекту поддается не она, а другие задачи, которые она вытеснит...

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

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

Для того, чтобы бэклог стал "работать", нужна весьма простая вещь, которая, тем не менее, может быть болезненной во многих случаях, обнажая целый ряд проблем с управлением ожиданий:

Входная очередь (бэклог) должна быть существенно ограничена. Эта очередь и ее жесткое ограничение по размеру должно быть известно всем стейкхолдерам и быть частью правил игры. В таких условиях управление бэклогом будет производиться прозрачно для всех и ожидания будут соответствовать действительным возможностям команды по доставке. 

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


1) Команда производит поддержку системы (скажем, применяя Канбан), устраняет дефкты на проде, доставляет еженедельно или же сразу по мере критичности дефекта. В таком случае входная очередь, содержащая объем задач, приблизительно требующий 2 недели работы команды может быть близким к оптимальному. Хотя может быть и короче, если новые дефекты возникают часто, в противоположность случаю, когда новых дефектов не так много, а есть "запас" ранее обнаруженных.

2) Scrum-команда, работающая над новым продуктом. Очень удобно входную очередь отождествлять с бэклогом релиза - обычно это несколько спринтов, 2-6. Если команда релизит после каждого спринта, входная очередь может быть ограничена до приблизительного объема на 2 спринта вперед.

3) Cowboy coding. 5-10 задач, над которыми типично работает команда, чтобы было легко следить за происходящим.



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

Однако это только общие примеры, "подгонку" команда все равно делает самостоятельно.

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



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


Заложники Длинных Очередей


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

Что общего между очередями и умными людьми (и не только), ставшими заложниками неэффективного процесса? Очень много общего!

Начнем с самих очередей и их поведения. Без излишних математических выкладок понятно, что длинная очередь (чего-либо) - это в большинстве случаев большая неопределенность. Если я нахожусь в короткой очереди, например, третий по счету на регистрацию пассажиров авиарейса и если в среднем регистрация одного пассажира занимает 3 минуты, то с довольно хорошей точностью можно сказать, что минут через 10 и меня обслужат.

Если я последний в очереди, состоящей из 100 человек - ситуация иная. Сказать с надежностью, что это будет 300 минут нельзя, вариация может быть огромна, процесс может легко отнять в два раза больше времени. Кто-то релоцируется и у него 5 чемоданов и он не знал, что за перевес придется доплатить и кроме полезного времени еще минимум 5 минут повозмущается по поводу обираловки. Кто-то летит далеко с многими пересадками и оператору придется позвонить в центральный офис, чтобы узнать, нужна ли гражданину, скажем, Индии транзитная виза в Британию, если он летит через Хитроу. Кто-то не знал, что даже грудному ребенку нужно покупать билет и т.д. Задержка по времени может легко составить час а то и больше...

Где в разработке ПО появляются очереди? Повсюду. Если рассматривать работу над проектом как процесс продвижения требований от некого определенного состояния до полной имплементации, то легко заметить, что между различными этапами возникает целый ряд очередей. Так, в классическом пофазовом процессе большая очередь только что определенных требований (например, в виде SRS - Software Requirements Specification) направляется к следующему шагу - разработке архитектуры. Затем, когда будет определена архитектура (опять же, для всего продукта целиком в случае такого процесса), эта очередь вся целиком движется дальше - к этапу разработки. Потом точно так же - на тестирование.

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

Самое неприятное, что при этом множество талантливых архитекторов, разработчиков, бизнес-аналитиков и тестировщиков становятся заложниками такого процесса, часто обреченными на работу по выходным, экстра-время по будням, выгорание и т.д. А все потому, что процесс, который используется совершенно не принимает в рассмотрение эффект длинной очереди.

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

Не бывает так, чтобы в Lean-проектах были одни умники, а в традиционных проектных моделях были бы профессионалы чем-то хуже. Просто, к огромному сожалению, даже отличные специалисты могут здорово пострадать (и страдают) от беспощадной "мести" длинных очередей.

Научиться мыслить и оперировать очередями - это просто вопрос порядка выживания для софтверных команд.

*      *      *

Добавлено 01-05-2012.

Важно действительно понимать "масштаб бедствия". На диаграмме можно увидеть "скорость", с которой наростает разброс времени обслуживания очереди с ростом ее длины. Диаграмма показывает функции распределения плотности вероятности для очередей с длинами от 5 до 100 элементов. Для простоты сравнения все они "отцентрированы".

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

Для интересующегося математическим обоснованием читателя заметим, что вышеизложенное следует из Центральной Предельной Теоремы, которая также указывает, что "разброс" (среднеквадратическое отклонение) растет пропорционально корню квадратному из n, т. е. длины очереди. Также, вероятность того, что время примет среднее ожидаемое значение, быстро убывает с ростом n (обратно пропорционально корню из n). Вряд ли наш великий соотечественник, Александр Михайлович Ляпунов, подозревал, что так "отожжет" в IT.   

Аналогия с написанием книги...

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

В прошлом посте, "Осторожно с аналогиями. Lean и TOC в разработке", мы обсуждали несоответствия в аналогии между "производством" и "разработкой ПО". Как справедливо отметил один из наших читателей, Владимир Дзеба (обсуждение можно посмотреть в LinkedIn-группе Agile Requirements & Quality), действительно хотелось бы предметно представлять, как себя вести с учетом целого ряда несоответствий в одной из общепринятых аналогий. Вопрос хороший и, признаюсь, заставил здорово призадуматься, а какая модель (или аналогия с чем-то) соответствовала бы тому эффекту в разработке ПО, что работа в текущий момент может повлиять на результат уже ранее выполненной работы.

Идея пришла вчера... сама собой, за чтением очередной "дежурной" книги. Наша аналогия - это написание книги (скажем, романа или вообще любого литературного произведения).

И действительно, то, что мы добавим к существующим на данный момент главам, способно совершенно кардинально повлиять на предыдущие главы. К примеру, представим себе, что вдруг взяли и дописали что-то к "Братьям Карамазовым" Достоевского. Если дописать, например, что Иван Карамазов симулировал болезнь, дабы в конечном итоге избежать ответственности, это разрушит всю этическую составляющую романа, все то, что Ф. М. пытался подчеркнуть в человеке. Но это еще куда не шло, просто меняет суть романа. А если дописать в конце, что Грушенька ушла в какое-то реалити-шоу - тут-то и найдет на читателя ступор и такое произведение просто не будет "компилиться" в его голове. Таким образом, и тут, как и в разработке ПО имеем два типа ошибок - физические, при которых даже не "скомпилится" и логические: "компилится, но ведет себя не так, как хотелось бы".

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

Дальше еще интересней... Как упоминал Евгений Петров о формате их (с Ильей Ильфом) сотрудничества: "Привычка думать и писать вместе была так велика, что, приступая к сочинению нашей последней книги -- 'Одноэтажной Америки', которую мы писали порознь, по главам, мы очень мучились." (Ссылка на мемуары Е. Петрова, 1942 г.). То же самое видим, например, у братьев Вайнеров: "И в ту же ночь братья засели за план рассказа. Он занял... 40 страниц. Остановиться они уже не могли, и каждый вечер и ночь под кофе на пишущей машинке сочиняли рассказ, который вылился через несколько месяцев в пухлый роман в 600 страниц под названием «Часы для мистера Келли»." Очень напоминает гибкие практики разработки, не правда ли?

В одном из интервью братьев Стругацких есть просто "контрольный выстрел" в этом направлении:

ВОПРОС: Бывает ли так, что герои выходят из-под вашего контроля? Ведут себя так, как вы и не предполагали вначале?

А.Н.СТРУГАЦКИЙ: Как только герой, который нам уже понравился, начинает поступать вразрез с нашими намерениями – нужно менять намерения.

Ну... просто концепция "responding to change over following a plan" (Agile Manifesto).

Этой аналогией, как оказывается, вовсю пользуются Тех-писатели - применяют общеизвестные практики из разработки ПО (например, системы контроля версий) и, в частности, гибкие практики в своей работе (инкрементальную доставку) - см. например блог о тех-писательстве.

Наверняка, как и всякая другая аналогия, и у этой удастся обнаружить свои недостатки. Я пока не успел об этом детально поразмыслить, но абсолютно уверен, что они есть... как неоспоримо есть тот суслик из "ДМБ".

Завершим сегодняшние выкладки рекомендациями для "авторов" из тематического форума (оставляем их в оригинале):

Here are a few of my ideas (Content Writing Best Practices):
1. Chunk your content - no long paragraphs
2. Write in an active voice - provides, creates, develops
3. Write for the reader - not the search engines
4. Deliver a clear and concise message - take out the unnecessary words
5. Write call to action statements - prompt the user to take action
6. Create 250-500 word pages - not too long, not too short
7. Edit, rewrite, and edit again

...Как будто Мартина Фаулера читаешь.

Удачи!..

Осторожно с аналогиями. Lean и TOC в разработке.

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

Подходы Lean и TOC (Theory Of Constraints - Теория Ограничений) весьма популярны в разработке ПО. Особенно Lean в последние несколько лет. Самый яркий последний пример - это Kanban. Модно по самое "немогу". И полезно тоже, однако как повествует известный анекдот о героях романа Д. А. Фурманова: "но есть нюансы..."

Кстати, это типичная болезнь современной теоретической науки, математики, например... Строим модель действительного феномена, не сильно заботясь о ее адекватности, а потом наворачиваем на этом неимоверный теоретический аппарат (так как получившуюся систему дифф-уравнений придется решить или, скажем, группу симметрических преобразований кристалла полностью описать). И все прекрасно работает... для статей и диссертаций. И в большинстве случаев не подразумевает ни единого случая применения! ...А может это и хорошо.

Итак, наша основная "модель", используемая в Lean - это производство. Автомобилей, привычно, так как Lean принято считать методологическим продуктом Toyota. Возможны и дроугие (эквивалентные) аналогии: например, кухня в ресторане "производит" блюда и т.д. В случае с разработкой ПО, аналогией "автомобилей" (или "блюд") являются фичи продукта, которые похожим образом "проходят сквозь производство" и заканчиваются готовой функциональностью. Много в чем эта модель позитивна, например в идее ограничения работы в прогрессе или постоянном стремлении уменьшить Lead Time - общее время от "заказа фичи" до ее "доставки". Но есть и серьезные концептуальные отличия. Вот основное из них:

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

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

все фичи реализовываются в одной и той же системе и связаны друг с другом физически.

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

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

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. Команда ни на минуту не останавливается в поиске текущих проблемных зон и ограничений в их работе, внимательно анализирует и сразу же принимается за решение проблем и шаги по совершенствованию процесса.

Канбан в аэропорту Дели

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

Стоя в очереди на проверку багажа (и меня) на безопасность и медленно продвигаясь к "конвейеру", я быстро заметил то, чего ренее в аэропортах не видел - пластиковые таблички, достаточно большие, с номерами. Чем-то похоже на гардеробные, но раза в три-пять больше и с ручкой. Как я впоследствии обнаружил - они используются с двойной целью:

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

во-вторых, они не используют все пары, а только то количество, которое считают оптимальным, чтобы очередь непрерывно двигалась. Это в чистом виде ограничение на "работу в прогрессе". Таким образом, одновременно "на конвейере" не более N-го количества пассажиров.

Интересно...

На самом деле, это даже не Канбан, если быть точным, а, так называемый, CONWIP, если мы рассматриваем этот конвейер, как отдельную систему. В CONWIP, являющимся другой "пулл-системой", альтернативной к Канбан, ограничение на работу в прогрессе ставится не на отдельно взятый шаг в процессе, а на всю систему целиком. CONWIP, кстати, это дословно и означает - CONstant WIP. Эта модель процесса может на первый взгляд выглядеть не такой "продвинутой" и не такой конфигурабельной, как Канбан, но она имеет одно мощное преимущество - простоту внедрения, а, таким образом, конечный эффект весьма большой. Я особо ценю этот метод организации процесса еще и потому, что он идеально подходит к бизнес-процессам, в которых границы между "фазами" размыты. Наилучший пример CONWIP в разработке ПО это... Scrum, где ограничение ставится на всю систему - "в этом спринте мы доставим стори-поинтов не более, чем наша скорость (velocity)". При этом мы понимаем, что пользовательская история в 2 или 5 или сколько бы то ни было пунктов содержит и определение интерефейсов, и разработку, и покрытие юнит-тестами, и мануальное функциональное тестирование, и деплоймент на стейджинг для приемки и т. д.

Удачных полетов!

Приритезация бэклога для практиков: три важных аспекта

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

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

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

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

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

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

Массу полезных аспектов приоритезации вы сможете разобрать в рамках практических упражнений на нашем открытом воркшопе по приоритезации, который пройдет 22 декабря в Киеве.
 
Powered by Blogger