English Version

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

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

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

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