AGILE UKRAINE

Agile Product Roadmapping — как это было в IPLand

noreply@blogger.com (Anonymous) — Thu, 7 Dec 2017 16:35:00 +0200

Автор: Алексей Кривицкий

Agile Product Roadmapping

Эта статья описывает подход построения долгосрочных и среднесрочных планов развития продукта и составлена по следам проведения двухдневного воркшопа в украинской продуктовой компании IPLand коучами из Scrum Ukraine.

Читать дальше >>>

Нет такой вещи как Проект, или профессиональная деформация коуча

noreply@blogger.com (Unknown) — Mon, 13 Jul 2015 15:14:00 +0300

Автор: Наталья Тренина

В последние пару лет, примерно раз-два в месяц, я получаю сообщения, похожие по своему содержанию. К примеру:

Наталья, здравствуйте. Хочу попросить у вас совета, как специалиста в области Agile и Scrum. Я нахожусь в процессе изменения вектора в своей карьере. Давно зрел, и сейчас окончательно решил стать Project Manager. Хочу быть причастным к созданию чего-то полезного. Дальше, как правило, следует беспокоящий вопрос, или просьба посоветовать что-то конкретное. Это очень волнительный момент, сколько бы раз происходило. Влиять на развитие организации морально куда легче, чем давать советы конкретному человеку. К тому же, #яжкоуч - прекрасно понимаю что советы редко бывают верны, и размывают ответственность за принятое решение.

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

Вскормленная книгами Барри Боэма и Тома ДеМарко, за годы фриланса, класическая девочка-задрот, постепенно перевоплощалась из программиста в предпринимателя. Особым шагом в развитии стал крах небольшой компании, которую мы с партнером строили на доверии работы с одним ключевым заказчиком. Которому, как вы догадываетесь, не стоило доверять
Моя первая управленческая седина проявилась именно тогда: кризис 2005-го, слабый маркетинг, недостаток связей и общего жизненного опыта, желание спрятать голову от проблем в теплом ламповом свечении строчек кода.

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

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

Я не романтизирую корпорации :), просто хочу отметить что страхи и предубеждения людей, которые никогда не работали на предприятии больше сотни человек, бывают сильно преувеличенными. Между делом, у нас случались проекты стоимостью больше ляма и сроком больше года с резолюцией “Проект признан успешным. Система к промышленной эксплуатации не пригодна”.

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

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

7 июля 2009 года я начала себя с чистого листа. Эти 6 лет были мощными во всех отношениях развития - как Agile-коуча, так и предпринимателя. Мне повезло - у меня был невероятный партнер, прекрасные учителя, поддерживающая команда, и много возможностей для практики.
Но есть один побочный эффект: я стала совершенно непригодна для давания советов в винтажном управлении проектами. И честно извинилась перед коллегой за свою бесполезность в том случае, если он планирует развиваться по траектории PMP .

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

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

Теперь, на высоком уровне абстракции - там, где формулируется моя профессиональная миссия - попросту нет Проекта.

Есть Продукт. И есть Команда.
Есть Жизненный цикл Продукта.
И есть Жизненный цикл Команды.
Продукт, Команда и их постоянное, взаимообуславливающее развитие.

Как же быть, если вы PM, но ваш внутренний вектор все более отчетливо направляется в сторону Agile, Scrum, Lean StartUp..? Отличия ролевой парадигмы, особенности работы над видением и требованиями, развитие высокопродуктивных команд и предпринимательского духа компании, нюансы внедрения изменений - все это в программе одесского сертификационного класса.

ХВОСТ ВИЛЯЕТ СОБАКОЙ: создаем мини-привычки для устойчивых и безболезненных изменений.

noreply@blogger.com (Unknown) — Tue, 7 Jul 2015 16:22:00 +0300

Автор: Наталья Тренина

Внедрение любых реорганизационных изменений - будь то гибкие процессы на базе Scrum или Kanban, или освоение технических практик, таких как TDD, парное программирование, автоматизация тестирования в инженерную культуру команды, связано с изменением привычного поведения человека.

Мы можем многое говорить о культуре организации, стиле управления, уровне вовлеченности сотрудников, особенностях проекта - всем том, что коучи одним словом называют “контекстом”, когда увиливают от давания советов ;)

Но, в конечном счете, способность организации совершенствоваться упирается в способность каждого ее конкретного сотрудника изменяться. И эта способность может быть тренирована как навык!

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

Я не могу быть гидом и советчиком по каталке в Гудаури, никогда не побывав там. Но опустившись до уровня базовых законов природы (гравитации, к примеру), вполне могу давать советы начинающему лыжнику: “чем круче склон, тем более наклоненным вперед должен быть корпус твоего тела в момент начала движения”. Ведь только в перпендикулярном склону положении корпуса, лыжа становится управляемой.

Я помню свое прозрение, когда впервые услышала об этом от тренера. Более “естественным” движением было присесть на пятую точку, пытаться примагнититься спиной к склону.. что угодно - но только не корпусом вниз. И только после слов инструктора и массирования силы воли, телом начала понимать закон природы.

Точно такое же противоречие раздирает начинающих скрам-мастеров и менеджеров проекта когда они слышат “Чем больше автономии - тем больше дисциплины”. Как в поговорке, “если любишь - отпусти”.

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

Что же мы упускаем, когда просто отпускаем?

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

Почему одной только мотивации не достаточно?
Как связаны мотивация, автономность и сила воли?
Как усыпить свое экономное (ленивое) подсознание?
Чем отличается личная дисциплина от командной?
Как же начать устойчиво и радостно меняться самому?
И как помогать это делать своим командам и заказчикам?

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

Взгляд сквозь линзу Agile

noreply@blogger.com (Unknown) — Mon, 5 May 2014 18:55:00 +0300

Автор: Браян Барр (Brian Barr)
Переведено с английского проектом Agile Translations

Существует множество заблуждений о том, что означает Agile. Вот несколько из наиболее распространенных мнений:

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

Итак, что же такое Agile?

Когда вы рассматриваете процесс разработки или фреймворк для поставки ПО, думаете о расстановке приоритетов для нужд бизнеса, о том, как построить привлекательный продукт, как организовать его выпуски, как создать и мотивировать команды или финансировать инициативы, просто посмотрите на все это через линзу Agile. И тогда решения и действия, которые вы предпримите, будут направлены на создание максимальной бизнес-ценности.

Давайте рассмотрим несколько примеров так, будто мы на приеме у окулиста. Вспомните, как окулист переставляет разные линзы и неоднократно спрашивает: "С или без?"

Пример № 1: Новая версия продукта выпущена, но важное требование не было включено.

Без линзы Agile: Вы тщательно анализируете весь жизненный цикл разработки ПО; определяете каждый случай, где требования могли быть не должным образом задокументированы, реализованы или протестированы. И добавляете многошаговый процесс проверки, чтобы трижды убедиться, что каждое требование отслеживается.
С линзой Agile: Вы проводите ретроспективу релиза с командой и принимаете решение, что вам нужны более частые встречи между бизнесом и ИТ-командами во время спринта. Теперь вся команда, бизнес и ИТ, заинтересованы реализовать продукт таким, как задумывалось.

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

Пример № 2: За четыре недели до запланированного релиза появляется новое, относительно небольшое требование.

Без Agile-линзы: Соберется комитет управления изменениями, чтобы рассмотреть новое требование и определить, следует ли задержать релиз или продолжить его, не включая новое требование. Учитывая все последствия на столь поздней стадии цикла выпуска, никто не знает, как успеть реализовать это новое требование до релиза.
С Agile-линзой: Владелец Продукта и команда встретятся с клиентом, чтобы рассмотреть новое требование. Потом быстро разработают Пользовательскую Историю с соответствующими приемочными критериями. Эта история оценивается и принимается в следующий спринт (потому что это относительно небольшое изменение), который начинается через несколько дней. Команда готова к новым изменениям и постоянно работает, чтобы сделать бизнес успешным.

Agile-линза позволяет увидеть, что принцип “реагирование на изменения важнее, чем следование плану” (Agile Manifesto) является более правильным для создания бизнес-ценности.

Пример № 3: Сейчас апрель, и отдел маркетинга хочет знать, какая функциональность будет готова к релизу поздней осенью (т.е. через 6 месяцев).

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

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

Переведено с английского проектом Agile Translations
Дарья Ершова, Светлана Каща, Алина Проскурина, Сергей Сидоренко

Оригинальная статья: "Seeing the World Through Agile-Colored Glasses" by Brian Barr

Шаблоны декомпозиции Пользовательских Историй (User Stories)

noreply@blogger.com (Unknown) — Mon, 5 May 2014 14:38:00 +0300

Автор: Richard Lawrence
Переведено с английского проектом Agile Translations

Хорошие Пользовательские Истории следуют INVEST модели, предложенной Биллом Вейком (Bill Wake). Они независимые (Independent), обсуждаемые (Negotiable), ценные (Valuable), поддающиеся оценке (Estimable), небольшие (Small) и тестируемые (Testable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели.
Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая”, однако, не сможет похвастаться тем же в случае с “независимая” и “ценная”. За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.
(Примечание автора: Как в случае с шаблонами любого языка, я не придумывал их, я только наблюдал и объединил их. Например, Ласс Коскела (Lasse Koskela) на сайте radio.javaranch.com дает имена некоторым шаблонам, которые я заметил, но не назвал, в частности, “Весомое усилие.”)

Насколько маленькая?

Насколько мелкой должна быть история? Я рекомендую 6-10 историй за итерацию, так что насколько большими они должны быть зависит от скорости разработки (velocity) вашей команды. Перед следующем планированием Спринта, подсчитайте, какая оценка должна сигнализировать,что историю нужно разделить. Для большинства команд это будет 8 или 13. Но на своем последнем проекте мне было необходимо разделять истории и в 5 стори-поинтов. Когда вы во время планирования попадаете в оценку, сигнализирующую о необходимости разделения историй, возьмите список подсказок, находящийся в конце этой статьи, и попробуйте применить несколько шаблонов, пока не подберете хорошее разделение.

Какой шаблон использовать

Вы часто будете замечать, что можете разделить истории, используя несколько шаблонов. Какое разделение стоит выбрать? Я использую два правила :

Выбирайте разделение, которое позволит понизить приоритет или отбросить историю. Принцип 80/20 гласит, что бОльшая часть ценности истории реализовывается небольшой частью функциональности. Бывает, что один способ разделения историй позволяет выявить истории с низкой ценностью, а другой способ - не позволяет этого сделать. Это значит, что при использовании второго разделения каждая из новосозданных историй будет содержать в себе напрасные потери. Продолжайте разделять используя другой шаблон, который позволит отбросить то, что имеет низкую ценность.
Выбирайте разделение, которое даст вам наиболее равные по размеру истории. Раздеделение, превращающее историю в 8 стори-поинтов в 4 истории по 2 стори-поинта, намного полезней, чем разделение на 5 и 3. Оно дает Владельцу Продукта больше свободы для приоритизации отдельных частей функциональности.

Шаблон #1: Шаги рабочего процесса (Workflow Steps)

Приведу пример истории системы управления контентом (content management system), которую делал один из моих клиентов:

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

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

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

Шаблон #2: Варианты бизнес-правил

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

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

Углубление в понятие “гибкие даты” выявит несколько разных бизнес-правил, каждое из которых само по себе может быть хорошей Пользовательской Историей:

… “N дней между X и Y”
… “выходные в декабре”
… “± N дней от X и Y”.

Шаблон #3: Основное усилие

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

Как пользователь, я могу оплатить мой билет картами VISA, MasterCard, Diners Club или American Express

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

… я могу оплатить одной из карт (VISA, MC, DC, AMEX).
… я могу оплатить всеми четырьмя картами (VISA, MC, DC, AMEX) (предполагается, что оплата одной из карт уже релизована).

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

Шаблон #4: Простые/Сложные

Во время обсуждения истории на планировании, история становится все больше и больше (“а как насчет Х?”; “ты учел Y?”). Остановитесь и спросите “Как сделать это максимально просто?”. Запишите этот простой способ как отдельную историю. Вероятно, вам также на месте придется определить ее критерии завершенности, чтобы она оставалась простой. А потом разделите все вариации и сложности на отельные истории. Вот, к примеру, история:

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

будет оставаться простой, если вынести в отдельные вариации историй

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

Шаблон #5: Вариации данных

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

Как пользователь, я могу искать перевозчиков по месту отправляения и месту назначения.

с нашим Владельцем Продукта, я понял, что пока мы не создадим развитую географическую информационную систему (Geographic Information System, GIS), моделирование географии будет оставаться достаточно сложным. Мы остановились и спросили: “Как мы можем построить минимально удовлетворяющую нас географическую модель, чтобы сконцентрироваться на другой ценной функциональности?” Мы сошлись во мнениях на варианте

Как пользователь, я могу искать перевозчиков по стране отправления и стране назначения.

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

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

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

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

Шаблон #6: Методы введения данных

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

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

Шаблон #7: Отложите производительность

Иногда значительная часть усилий тратится на то, чтобы сделать функционал быстрым, при этом основная разработка не является такой сложной. Но вы можете выиграть больше, разработав медленную функциональность, которая уже будет иметь некую ценность для пользователя и позволять ему делать то, что иначе было бы еще невозможно. В таком случае разбейте историю на “заставить работать” и “сделать быстрой”:

Как пользователь, я могу искать рейсы между пунктами отправления и назначения.
… (медленно — просто сделать поиск, показывать анимацию “в процессе”)
… (меньше чем за 5 секунд).

Шаблон #8: Операции (например, CRUD)

Слово “управлять” в истории использования показывает, что история покрывает несколько операций. Таким образом, нам предлагается очевидный путь разделения истории, например:

Как пользователь,я могу управлять моим аккаунтом.
… я могу войти в систему, используя мой аккаунт.
… я могу редактировать настройки моего аккаунта.
… я могу удалить мой аккаунт.

Шаблон #9: Отделение Спайка (Spike)

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

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

Тогда разделите ее на:

Исследовать обработку кредитных карт.
Реализовать обработку кредитных карт.

В “исследовательской” истории критерием завершенности должен быть вопрос, на который вы пытаетесь ответить. Сделайте минимально необходимое исследование, которое позволит ответить на вопрос, и остановитесь; во время исследования очень легко отклониться от первоначальной цели.
Шаблон отделения спайка описан последним в этой статье, потому что к этому подходу следует прибегать лишь в крайнем случае. Вероятней всего, вы знаете достаточно для того, чтобы хоть что-то разработать. Сделайте это — и вы узнаете больше. Так что постарайтесь применить какие-то из предыдущих восьми шаблонов, прежде чем отделять спайк.

Заключение

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

Здесь можно скачать подсказки по разделению историй: Story Splitting in Russian (or, Как Разделять Истории Пользователей)

Переведено с английского проектом Agile Translations
Дарья Ершова, Светлана Каща, Сергей Гердов

Оригинальная статья: "Patterns for Splitting User Stories" by Richard Lawrence

8 Параметров социальной жизни команды: как измерить неизмеримое

noreply@blogger.com (Unknown) — Thu, 13 Feb 2014 17:47:00 +0200

Автор: Наталья Тренина

Около полугода назад мне в руки попала книга Чарли Пелерина How NASA builds teams. В книге описывались социальные проблемы крупных технологических проектов, которые обошлись в миллионы долларов космической промышленности США. И, что более ценно - выводы, сделанные Чарли, в форме системы оценки социального контекста проектов NASA 4-D. По ссылке вы можете открыть весьма олдскульный сайт с анкетой, рекомендациями по заполнению и довольно обширными выдержками из книги. Однако, после нескольких экспериментов со знакомыми аджайл-командами, я пришла к выводу, что в мире современного user experience и живого общения, любую мудрую систему можно сделать чуть проще и человечнее :)
Итак, спустя несколько месяцев в моей практике появился такой вот
ВОРКШОП ПО “СОЦИАЛЬНЫМ ТЕРМОМЕТРАМ”
Как его провести? Небольшой мануал ниже.

Подготовка

Любую командную активность лучше начинать с прелюдии. История полна примерами провалов отнюдь не в силу технологической не реализуемости проекта, а в силу тех или иных “человеческих” факторов. Используйте историю космической обсерватории Hubble из книги Чарли, или нагуглите софтверные эпические фейлы. Любая история, которая демонстрирует важность социального здоровья проекта будет хорошей затравкой, но хорошая история потребует подготовки.
Подготовьте набор из 8-ми карточек с описанием шкалы. Ниже я опишу каждую из шкал в свободной форме, а сами карточки в формате PDF размером A6 вы можете выкачать по этой ссылке.
Подготовьте наборы карт с цифрами от 2-х до 5-ти для каждого участника. Мы будем использовать эти карточки для непредвзятой оценки, по подобию той, которую даем всей командой в Planning Poker.
Подготовьте по листу бумаги для флипчарта A1. Его мы делим на 4 части и в каждой из частей рисуем по 2 шкалы. Вот что должно получиться (картинка).
Еще нам потребуется явно видимый таймер, что бы у участников было здоровое ощущение границы времени. Дискуссия может поднять на поверхность немало вопросов, которые не обсуждались ранее. Обсуждение всех шкал может занять 30-60 минут, в зависимости от количества членов команды и открытости к обсуждению. Сам формат воркшопа построен таким образом, что бы помочь высказаться всем.
Ну и наконец, не забудьте пригласить участников и предупредить клиентов о том, что вам потребуется этот час-полтора времени. Совет: “продайте” это как тематическую ретроспективу. Это так и есть. В результате у вас получится сырье для плана улучшений.

Проведение

Расскажите свою историю и предложите воспользоваться системой NASA 4D в “Обертке” от SCRUMguides ;)
Договоритесь о том, кто будет командным “летописцем” на время воркшопа. В ходе обсуждения шкал, вы можете услышать интересные вещи, о которых раньше не вспоминали открыто. Важно сохранить эту информацию, и использовать для улучшения процесса, взаимоотношений внутри команды или на уровне всей организации.
Пройдитесь по шкалам, и убедитесь в том, что каждая из них понятна команде. По каждой шкале полезно договориться о “максимуме”. Что это значит - что у нас с этим фактором все замечательно? Примеры таких максимальных значений приведены в описании ниже. Команда может их корректировать по своему усмотрению. Главное, что бы у всех было ощущение “эталона”, с которым можно сверить текущую ситуацию.
Самое интересное: как мы будем мерить? Процесс такой:
- Ведущий зачитывает объяснение шкалы
- Команда договаривается о максимальном ее значении
- Каждый участник выбирает карту с цифрой, которая, по его мнению характеризует текущее положение дел по этой шкале и кладет карту значением на стол
- Когда все участники положили свои карты, карты одновременно вскрываются
- Каждый участник по очереди отвечает - почему он выбрал именно эту карту? Чего, по его мнению, не хватает в команде/процессе, что бы добиться 5-ки? Какая история, ситуация символизирует его оценку?
- Летописец записывает важные идеи, истории, предложения на стикерах и помещает рядом со шкалой, что бы вернуться к ним во второй части встречи
- Как вы видите, в этом процессе все члены команды должны включиться в дискуссию, к этому “обязывает” использование карт. В такой ситуации снижается порог “смелости”, необходимой для высказывания мнения, ведь его выражают все. Важно обратить внимание команды - что “играют” (выбрасывают карты) все, и объясняют свой выбор так же все.
- Каждый участник ставит точку на той отметке, которую он выбросил. Или это делает за всех ведущий/фасилитатор/скрам-мастер. Как и в случае с покером планирования, значения не суммируются, точки ставятся “как есть”. Это можно сделать до или после объяснения выбора участниками.
Итак, в результате первой части, у нас есть плакат с отметками на 8-ми шкалах и стикеры с “сырьем” для улучшений. Похоже, тут есть что подебрифить ;)
- Какая самая “здоровая” наша шкала?
- Какая шкала требует серьезных улучшений?
- По какой шкале у нас самые совпадающие оценки?
- По какой шкале наши мнения различаются более всего?
- Изменения в какой шкале приведут к максимальным изменениям в остальных?
- На какую шкалу мы сами можем повлиять более всего?
- Над какой шкалой мы хотели бы поработать в следующей итерации?
Как вы видите, мы плавно подошли ко второй части - брейнстормингу шагов/улучшений.

На этапе дебрифа ясна картина по всем шкалам и команда выбирает одну-две самые важные из них. Поэтому полезно отделять сбор “сырья” и его “переработку”, т.е. не проводить брейнсторм по каждой шкале во время ее обсуждения. Иначе воркшоп может сильно затянуться :)
Думаю, что полтора-два часа вместе с генерацией плана улучшений - адекватное время для этой активности. Из расчета на среднюю команду в 5-9 человек.
Не буду рассказывать как именно генерировать и отбирать идеи. Думаю, вы хороши в этом и без меня, благодаря регулярной “зарядке” - практике ретроспективы.
Приятного времяпровождения и полезных дискуссий вам! Кстати, насколько мне удалось заметить - этот процесс доставлял удовольствие и даже веселье участникам. Возможно, стоит немного настроить их на то, что это не “серьезный разговор”, а скорее - активность for fun. А от пользы им и так не отвертеться ;)

Описание шкал

I. CULTIVATING

1. Выражение благодарности и признания. Людям нравится чувствовать признание своих достижений и благодарность за работу со стороны окружающих. Через выражение искреннего признания создается атмосфера взаимного уважения членов команды.
Максимум шкалы: Признание и благодарность выражаются регулярно, искренне, своевременно, конкретно и соразмерно вкладу каждого участника.
2. Знание и использование общих интересов. Люди предпочитают взаимодействие в команде своим личным интересам тогда, когда понимают общие цели и выгоду от совместной работы. «Интересы» — это выражение ценностей и взглядов. Можно определить общие интересы задаваясь вопросом: «Что они хотят такого, чего я тоже для них хочу?».
Максимум шкалы: Члены команды знают интересы друг друга, их пересечения и умеют использовать их в разрешении споров и конфликтов.

II. INCLUDING

3. Правильное включение в процессы. Людям важно ощущать сопричастность к общей работе. Мы чувствуем «включенность» через обмен информацией, делегирование, выражение и учет мнений. Типичный пример недостаточного включения — принятие важного для всех решения неполным составом команды. Пример избыточного включения — скука на встречах и злоупотребление опциями СС и “Ответить всем” в почте.
Максимум шкалы: Члены команды обмениваются информацией, принимают решения, участвуют в реализации, избегая недостаточного или расточительного включения участников.
4. Соблюдение всех договоренностей. Людям нравится работать в атмосфере доверия, а доверие развивается путем соблюдения договоренностей, возможности “положиться” на принятое решение и на коллег, которые его поддержали. Кроме этого, правила обычно принимаются, что бы повысить эффективность работы. Если придерживаться договоренностей сложно, прежде чем от них отказаться или нарушить — обязательно обсуждайте причины и способы их корректировки.
Максимум шкалы: Принимаются только те правила, которые все участники договорились соблюдать и члены команды строго следуют договоренностям.

III. VISIONING

5. Выражение реалистичного оптимизма. Людям важно верить в позитивное будущее. Оптимизм усиливается через понимание конечных выгод и соотнесение с ними временных трудностей. Проблемы важно обсуждать открыто и своевременно, в атмосфере поддержки и здравого оптимизма.
Максимум шкалы: Все члены команды понимают цели и верят в их достижимость, поэтому придерживаются оптимистичного настроя даже когда сталкиваются с трудностями.
6. Приверженность конечной цели. Фокус на конечной цели повышает энергию и вовлеченность команды. Люди, нацеленные на результат, переживают изменение восприятия и начинают видеть дополнительные возможности (В английском языке есть класивая поговорка: «Where attention goes, power flows»).
Максимум шкалы: Члены команды демонстрируют 100%-ю приверженность и следование общим целям.

IV. DIRECTING

7. Отпор обвинителям и жалобщикам. Состояния драмы отнимают слишком много энергии. Лучше фокусироваться на разрешении проблем вместо поиска виновных или обстоятельств. Не вступайте в “клуб” жертв и агрессоров и культура команды станет более здоровой.
Максимум шкалы: В команде не принято обвинять других или жаловаться на обстоятельства. Члены команды избегают таких способов ухода от ответственности и “помогают” в этом другим обратной связью.
8. Ясность функций, подотчетности и полномочий. Успех определяется через соответствие ожиданиям или возможность их превзойти. Прояснение ролей, функций, подотчетности, ожидаемых результатов и “власти”, необходимой для их достижения – помогает команде работать успешно.
Максимум шкалы: Ожидания от ролей членов команды ясны и согласованы со всеми важными сторонами; зоны ответственности распределены и снабжены соответствующей автономностью и властью.
И еще раз ссылка на скачивание карточек.

Перевод статьи Хенрика Книберга «ATDD from Trenches» (ATDD с передовой)

noreply@blogger.com (Unknown) — Wed, 5 Feb 2014 11:19:00 +0200

Автор: Хенрик Книберг (Henrik Kniberg)
Перевели с английского: Александр Андронов, Антон Бевзюк и Дмитрий Павлов.

ATDD с передовой
Разработка через приемочное тестирование для начинающих

Если вы когда-нибудь бывали в такой ситуации:

Тогда эта статья для вас — конкретный пример того, как начать разработку через приемочные тесты (Acceptance-test driven development) в действующих проектах с легаси кодом. В ней описан один из способов решения проблемы технического долга.
Это пример из реального проекта, со всеми изъянами и недостатками, а не отполированное упражнение из книги. Так что надевайте свои берцы. Я буду использовать Java и JUnit, без всяких модных сторонних библиотек (которыми, как правило, злоупотребляют).
Предупреждение: Я не утверждаю, что это единственный Правильный Путь, существует много других “стилей” ATDD. Так же в этой статье не так много чего-то нового и инновационного, здесь просто описаны хорошо себя зарекомендовавшие подходы и опыт из первых рук.

Что я хотел сделать

Несколько дней назад я начал делать защиту паролем для webwhiteboard.com (моего проекта — хобби). Пользователи уже давно просят добавить возможность защитить паролем виртуальные доски, так что настало время это сделать.
На словах звучит просто, но на самом деле нужно сделать довольно много изменений в дизайне. Пока что предполагалось, что webwhiteboards.com используется анонимными пользователями, без всяких логинов и паролей. Кто должен иметь возможность защитить доску паролем? Кто сможет получить к ней доступ? Что если я забуду пароль? Как реализовать это простым, но в то же время достаточно надежным способом?
Код webwhiteboard хорошо покрыт юнит тестами и интеграционными тестами. Но приемочные тесты, то есть тесты, проходящие через все слои с точки зрения конечного пользователя, полностью отсутствуют.

Рассмотрим дизайн

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

Анонимный пользователь не может защитить доску паролем. Но он может открыть уже защищенную доску. Ему не нужно будет входить в систему, а нужно только ввести пароль защищенной доски.
Управлять логинами и паролями будет внешний OpenId/Oauth компонент, первоначально предполагался Google. Таким образом, пользователю не придется создавать еще одну учетную запись.

Подход к реализации

Здесь много неопределенности. Я не знал, как это должно работать, не говоря уже о том, как это реализовать. Вот что я решил сделать (собственно ATDD):

Шаг 1. Задокументировать предполагаемый процесс
Шаг 2. Превратить его в запускаемый приемочный тест
Шаг 3. Запустить приемочный тест, убедиться что он упал
Шаг 4. Починить приемочный тест
Шаг 5. Почистить код

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

Шаг 1: Задокументировать предполагаемый процесс

Представим, что функционал Готов. Будто ангел спустился с небес и сделал все, пока я спал. Звучит слишком хорошо, чтобы быть правдой! Как мне проверить, что работа уже сделана? Какой сценарий проверить первым? Давайте этот:

Я создаю новую доску
Устанавливаю на нее пароль
Джо пытается открыть мою доску, система спрашивает пароль
Джо вводит неправильный пароль, доступ запрещен
Джо пробует еще раз, вводит правильный пароль и получает доступ. (Надо понимать, что “Джо” — это я сам, просто из другого браузера)

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

Шаг 2: Превратить его в запускаемый приемочный тест

Это не так-то просто. Других приемочных тестов нет, так с чего же мне начать? Новая функциональность будет взаимодействовать с некоторой внешней компонентой, отвечающей за аутентификацию (сначала я решил использовать Janrain). Еще будет база данных и куча непростых веб штучек с всплывающими диалоговыми окнами, токенами, переходами между страницами и всякое такое. Уфф.
Пора сделать шаг назад. Прежде чем решать проблему “как мне написать приемочный тест”, мне нужно решить более простую проблему “как вообще писать приемочные тесты с существующим кодом”?
Чтобы ответить на этот вопрос, я сначала напишу тест на “самый простой сценарий” их тех, которые уже есть в системе.

Шаг 2.1 Написать самый простой автоматический приемочный тест

Вот сценарий, с которого я начал:

Попытаться открыть несуществующую доску
Проверить, что я не могу ее увидеть

Как написать такой тест? С помощью какого фреймворка? Каких инструментов? Следует ли мне тестировать через пользовательский интерфейс или нет? Следует ли мне включать в тестирование клиентский код или напрямую вызывать сервис?
Куча вопросов. Трюк: не отвечайте на них! Просто притворитесь что все уже магически сделано и просто напишите тест на псевдокоде.
Например:

public class AcceptanceTest { @Test public void openWhiteboardThatDoesntExist() {//1. Попытаться открыть несуществующую доску//2. Проверить, что я не могу ее увидеть}}

Я его запустил и он прошел! Ура! Эм, но подождите, это же неправильно! Первый шаг в треугольнике TDD (“Красный — Зеленый — Рефакторинг”) это Красный. Так что мне нужно сначала сделать так, чтобы тест упал, чтобы доказать, что это требование еще не реализовано.

Пожалуй, я начну с написания некоторого настоящего кода. Но тем не менее, псевдокод помог мне сделать шаг в правильном направлении.

Шаг 2.2 Сделать самый простой автоматический приемочный тест Красным

Чтобы это сделать, я выдумал класс AcceptanceTestClient и притворился, что он магически решил все проблемы и предоставляет мне прекрасный высокоуровневый интерфейс для запуска моих приемочных тестов. Вот насколько просто его использовать:
client.openWhiteboard(«xyz»);
assertFalse(client.hasWhiteboard());
Как только я написал этот код, я фактически придумал интерфейс, который наиболее хорошо подходит для сценария моего теста. В тесте должно быть примерно столько же строк кода, сколько было в псевдокоде.
Дальше, используя горячие клавиши Eclipse, я автоматически сгенерировал пустой класс AcceptanceTestClient и методы, которые мне нужны:

public class AcceptanceTestClient {
    public void openWhiteboard(String string) {
        // TODO Auto-generated method stub
    }

    public boolean hasWhiteboard() {
        // TODO Auto-generated method stub
        return false;
    }
}

Вот как выглядит тестовый класс полностью:

public class AcceptanceTest {
    AcceptanceTestClient client;

    @Test
    public void openWhiteboardThatDoesntExist() {
        //1. Попытаться открыть несуществующую доску 
        client.openWhiteboard("xyz");

        //2. Проверить, что я не могу ее увидеть 
        assertFalse(client.hasWhiteboard());
    }
}

Тест запускается, но падает (потому что client — null). Хорошо!
Чего я добился? Не сказать чтобы многого. Но это начало. Теперь у меня есть зародыш класса-помощника для приемочных тестов — AcceptanceTestClient.

Шаг 2.3. Сделать самый простой автоматический приемочный тест Зеленым

Следующий шаг — сделать приемочный тест зеленым.

Теперь мне нужно решить намного более простую проблему. Мне не нужно заботиться ни о аутентификации, ни о нескольких пользователях, ни о чем таком. Я смогу добавить тесты на эти сценарии позже.
Что касается AcceptanceTestClient, его реализация была довольно стандартной — поддельная (mock) база данных (у меня уже был код для этого) и запуск версии всей системы webwhiteboard в памяти.
Вот так выглядит настройка:

Технические детали: Web Whiteboard использует GWT (Google Web Toolkit). Все написано на Java, но GWT автоматически переводит клиентский код в javascript, и магически вставляет вызовы RPC (Remote Procedure Calls) чтобы спрятать все низкоуровневые детали реализации асинхронного взаимодействия клиента с сервером.
Перед запуском приемочного теста, я “замыкаю” систему напрямую и вырезаю все фреймворки, внешние компоненты и сетевое взаимодействие.

Так что я создаю AcceptanceTestClient, который разговаривает с сервисом webwhiteboard точно также, как это делал бы реальный клиентский код. Отличия спрятаны за занавесками:

Реальный клиент общается с интерфейсом сервиса web whiteboard, который запускается в окружении GWT, которое автоматически превращает вызовы в RPC и отправляет их на сервер.
Приемочный тест тоже общается с веб интерфейсом сервиса web whiteboard, но он напрямую вызывает реализацию сервиса, без RPC и, следовательно, GWT не используется во время запуска тестов.

Кроме того, AcceptanceTestClient в своей конфигурации подменяет реальную mongo базу данных (облачная NoSQL база данных) на фейк, хранящий данные в оперативной памяти.
Главная причина для подмены всех зависимостей — упростить окружение, ускорить выполнение тестов, и убедиться в том, что тесты покрывают бизнес логику в изоляции от всех компонент и сетевых соединений.
Может показаться, что вся эта настройка чересчур сложна, однако на самом деле это всего лишь один метод init, состоящий всего из 3х строчек кода.

public class AcceptanceTest {
    AcceptanceTestClient client;

    @Before
    public void initClient() {
        WhiteboardStorage fakeStorage = new FakeWhiteboardStorage();
        WhiteboardService service = new WhiteboardServiceImpl(fakeStorage);
        client = new AcceptanceTestClient(service);
   }

    @Test
    public void openWhiteboardThatDoesntExist() {
        client.openWhiteboard("xyz");
        assertFalse(client.hasWhiteboard());
    }
}

WhiteboardServiceImpl — это настоящая реализация сервиса webwhiteboard.
Обратите внимание, что конструктор AcceptanceTestClient теперь принимает экземпляр WhiteboardService (шаблон проектирования “инъекция зависимости”). Это дает нам дополнительный побочный эффект: он не заботится о конфигурации. Один и тот-же класс AcceptanceTestClient можно использовать и для тестирования настоящей системы, просто передав ему экземпляр WhiteboardService, настроенный на реальную базу.

public class AcceptanceTestClient {
    private final WhiteboardService service;
    private WhiteboardEnvelope envelope;

    public AcceptanceTestClient(WhiteboardService service) {
        this.service = service;
    }

    public void openWhiteboard(String whiteboardId) {
        boolean createIfMissing = false;
        this.envelope = service.getWhiteboard(whiteboardId, createIfMissing);
    }

    public boolean hasWhiteboard() {
        return envelope != null;
    }
}

Подводя итог, AcceptanceTestClient ведет себя так-же, как настоящий веб клиент webwhiteboard, в то же время предоставляя высокоуровневый интерфейс для приемочных тестов.
Вы можете спросить “зачем нам нужен AcceptanceTestClient, если у нас уже есть WhiteboardService, который мы можем вызвать напрямую?”. На это есть 2 причины:

Интерфейс сервиса WhiteboardService более низкоуровневый. AcceptanceTestClient предоставляет именно те методы, которые нужны приемочным тестам, и именно в том виде, который позволит сделать тесты максимально понятными.
AcceptanceTestClient скрывает всякие мелочи, которые не важны для теста — например, понятие WhiteboardEnvelope, булевое createIfMissing, и другие детали низкого уровня. На самом деле в нашем сценарии используются и другие сервисы, такие как UserService и WhiteboardSyncService.

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

@Test
public void openWhiteboardThatDoesntExist() {
    myClient.openWhiteboard("xyz");
    assertFalse(myClient.hasWhiteboard());
}

Следующий шаг — немного прибраться.

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

@Test
public void createNewWhiteboard() {
    client.createNewWhiteboard();
    assertTrue(client.hasWhiteboard());
}

Ура, у нас есть тестовый фреймворк! И без всяких модных сторонних библиотек. Только Java и Junit.

Шаг 2.4 Написать приемочный тест для Защиты Паролем

Теперь пришло время добавить тест на защиту паролем.
Я начну с того, что опишу “спецификацию” моего теста на псевдокоде:

@Test
public void passwordProtect() { 
    //1. Я создаю новую доску
    //2. Я защищаю ее паролем
    //3. Джо пытается открыть мою доску, его просят ввести пароль
    //4. Джо вводит неправильный пароль и ему отказывают в доступе
    //5. Джо пробует снова, вводит правильный пароль и получает доступ
  }

И теперь, как и раньше, я пишу тестовый код, притворившись, что у класса AcceptanceTestClient уже есть все, что мне нужно. Эта методика чрезвычайно полезна.

@Test
public void passwordProtect() {
    //1. Я создаю новую доску
    myClient.createNewWhiteboard();
    String whiteboardId = myClient.getCurrentWhiteboardId();

    //2. Я устанавливаю на нее пароль
    myClient.protectWhiteboard("bigsecret");

    //3. Джо пытается открыть мою доску, его просят ввести пароль
    try {
        joesClient.openWhiteboard(whiteboardId);
        fail("Expected WhiteboardProtectedException");
    } catch (WhiteboardProtectedException err) {
        // Хорошо
    }
    assertFalse(joesClient.hasWhiteboard());

    //4. Джо вводит неправильный пароль и ему отказывают в доступе
    try {
        joesClient.openProtectedWhiteboard(whiteboardId, "wildguess");
        fail("Expected WhiteboardProtectedException");
    } catch (WhiteboardProtectedException err) {
        // Хорошо
    }
    assertFalse(joesClient.hasWhiteboard());

    //5. Джо пробует снова, вводит правильный пароль и получает доступ
    joesClient.openProtectedWhiteboard(whiteboardId, "bigsecret");
    assertTrue(joesClient.hasWhiteboard());
}

Я потратил всего несколько минут на то, чтобы написать этот код, потому что я просто придумывал то, что мне было нужно, по ходу написания. Почти ни одного из этих методов нет в классе AcceptanceTestClient (пока нет).
Пока я писал код, мне уже пришлось принять несколько решений. Не нужно думать слишком усердно, просто делайте то, что первое приходит в голову. Лучшее — враг хорошего, и сейчас все, чего я хочу — это получить достаточно хороший результат, то есть тест, который можно запустить и который упадет. Позже, когда тест станет зеленым, я отрефакторю свой код и подумаю более тщательно над тем, как улучшить его дизайн.
Есть большой соблазн начать причесывать код прямо сейчас, особенно отрефакторить эти ужасные операторы try/catch. Но один из законов TDD — сделать тест зеленым до начала рефакторинга, тесты будут защищать вас, когда вы будете рефакторить. Так что я решил повременить с причесыванием кода.

Шаг 3 – Добиться, чтобы приемочный тест запустился и упал

Следуя треугольнику тестирования, мой следующий шаг — добиться, чтобы мой тест запустился и упал.

Я снова пользуюсь горячими клавишами Eclipse, чтобы создать пустые методы. Отлично. Запускаем тест и вуаля, он Красный!

Шаг 4: Сделать приемочный тест зеленым

Теперь мне придется написать продуктовый код. Я добавляю несколько новых сущностей в систему. Иногда код, который я добавлял, был довольно нетривиальным, так что его нужно было покрыть юнит тестами. Я делал это при помощи TDD. Это тоже самое, что ATDD, но в меньшем масштабе.
Вот как ATDD и TDD работают вместе. Считайте, что ATDD — это внешний цикл:

Для каждого цикла написания приемочного теста (на уровне новой функциональности), мы делаем несколько циклов написания юнит тестов (на уровне классов и методов).

Так что, несмотря на то, что на высоком уровне я сфокусирован на том, чтобы сделать мой приемочный тест Зеленым (на что может потребоваться нескольких часов), на низком уровне я занят тем, что, например, делаю мой следующий юнит тест Красным (что обычно занимает несколько минут).
Это не совсем хардкорный “TDD с кожаной плеткой”. Это больше похоже на “по меньшей мере убедись, что юнит тесты и production код зачекинены вместе”. И такой чекин происходит несколько раз в час. Можете это называть “в духе TDD” :o).

Шаг 5 Почистить код

Как обычно, как только приемочный тест стал зеленым, время заняться уборкой. Никогда не экономьте на этом! Это примерно как мыть посуду после еды — лучше это сделать сразу.

Я чищу не только production код, но и код тестов. Например, я выделил грязноватый try-catch во вспомогательный метод, и получился чистый и опрятный тестовый метод:

@Test
public void passwordProtect() {
    myClient.createNewWhiteboard();
    String whiteboardId = myClient.getCurrentWhiteboardId();

    myClient.protectWhiteboard("bigsecret");

    assertCantOpenWhiteboard(joesClient, whiteboardId);

    assertCantOpenWhiteboard(joesClient, whiteboardId, "wildguess");

    joesClient.openProtectedWhiteboard(whiteboardId, "bigsecret");
    assertTrue(joesClient.hasWhiteboard());
}

Моя цель — сделать приемочный тест настолько коротким, чистым и читабельным, что коментарии становятся излишними.
Первоначальный псевдокод и комментарии выполняют только роль шаблона — “вот каким чистым должен быть код!”. Удаление комментариев дает ощущение победы, а в качестве бонуса делает метод еще короче!

Что дальше?

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

Вот полный список тестов, которые я сделал для этой функциональности (пока что):

passwordProtectionRequiresAuthentication
protectWhiteboard
passwordOwnerDoesntHaveToKnowThePassword
changePassword
removePassword
whiteboardPasswordCanOnlyBeChangedByThePersonWhoSetIt

Наверняка я добавлю еще несколько тестов позже, если я обнаружу баги или придумаю новые сценарии использования.
В общем и целом, это заняло примерно 2 дня кодирования. Большую часть времени я провёл, возвращаясь к ранее написанному коду и дизайну, а вовсе не так линейно как это может показаться, читая эту статью.

Как насчет ручного тестирования?

Разумеется, я делал достаточно много ручного тестирования после того, как получил зеленые приемочные тесты. Но поскольку автоматические приемочные тесты покрывают как основную функциональность так и много специальных случаев, я мог сфокусироваться на более субъективном и исследовательском тестировании. Как насчет общего впечатления пользователя? Имеет ли смысл эта последовательность действий? Легко ли ее понять? Куда лучше добавить поясняющий текст? Хорош ли дизайн с эстетической точки зрения? Я не собираюсь выигрывать никаких наград по дизайну, но я и не хочу чего-то монументально уродливого.
Мощный набор автоматических приемочных тестов избавляет от скучного монотонного ручного тестирования (известного как “обезьянье тестирование”), и освобождает время для более интересного и значимого типа ручного тестирования.
В идеале мне бы следовало начать с автоматических приемочных тестов с самого начала, так что отчасти я вернул немного технического долга.

Ключевые моменты

Надеюсь, этот пример был вам полезен! Он демонстрирует довольно типичную ситуацию — “Я хочу добавить новую фичу, и было бы круто написать на нее автоматический приемочный тест, но в проекте пока нет ни одного приемочного теста, и я не знаю какой фреймворк использовать и с чего стоит начать”.
Я очень люблю этот шаблон, он позволял мне сдвинуться с мертвой точки много раз. В итоге:
1. Притворитесь, что у вас уже есть превосходный фреймворк, инкапсулированный в действительно удобный вспомогательный класс (в моем случае AcceptanceTestClient).
2. Напишите очень простой приемочный тест для того, что уже работает сегодня (например простое открытие вашего приложения). Используйте этот тест для того, чтобы написать классы вроде AcceptanceTestClient и связанную с ними обвязку теста (такую, как подмена настоящей базы данных или других внешних сервисов).
3. Напишите приемочный тест для вашей новой функциональности. Добейтесь чтобы он выполнялся, но падал.
4. Сделайте тест зеленым. По мере написания кода, пишите юнит тесты для любого более-менее сложного кода.
5. Рефакторьте. И, может быть, напишите еще несколько юнит тестов для того, чтобы улучшить метрику, или наоборот – удалите лишние тесты или код. Держите код чистым, как яйца у кота!
Как только вы это сделали, вы преодолели самый трудный барьер. Вы начали применять ATDD!

Перевели с английского: Александр Андронов, Антон Бевзюк и Дмитрий Павлов

Оригинальная статья: "ATDD from the Trenches" by Henrik Kniberg

Аджайл Менеджер Проектов – кто это?

noreply@blogger.com (Unknown) — Wed, 15 Jan 2014 15:44:00 +0200

Автор: Карлтон Неттлетон (Carlton Nettleton)
Переведено с английского проектом Agile Translations.

Несколько недель назад я получил сообщение от своего бывшего ученика с печальными новостями – его компания уволила всех Скрам-мастеров и заменила их на “Аджайл Менеджеров Проектов”. Теперь он остался без работы, а Cкрам потерпел серьезную неудачу в их организации. Это было довольно грустно :(

Когда я первый раз прочитал это сообщение, я задался вопросом: "А кто же такие Аджайл Менеджеры Проектов?” Поэтому я решил поискать различные статьи о том, когда этот термин появился (примерно в начале 2008) и почему компании отдают предпочтение им, а не Скрам-мастерам.

Что такое “Аджайл Менеджмент Проектов” – краткое описание от Майка Кона (Mike Cohn) в основном совпадает с официальной версией Скрама о менеджменте в Скрам-командах.
Управление проектами по гибкой методологии – VersionOne дает свое определение Аджайл Менеджеру Проектов и приводит много доказательств в пользу своей точки зрения. Однако, это неудивительно, если учесть тот факт, что VersionOne разрабатывает и продает программные продукты для менеджеров, работающих по гибкой методологии.
“Почему Аджайл Менеджер Проектов – это секретный компонент успеха проекта” – в этой статье на InfoQ Леонардо Абдала (Leonardo Abdala, @leonardoabdala) объясняет, почему он считает, что большие проекты нуждаются в Аджайл Менеджере Проектов, основываясь на своем опыте с распределенными командами.
Профессионал по управлению проектами (PMP) против Аджайл Менеджеров Проектов: Столкновение Титанов – в этой статье на сайте Scrum Alliance Хуан Банда (Juan Banda, @juanbandajara) сравнивает сертифицированных PMP (по определению PMI – Института по управлению проектами) с Аджайл Менеджерами Проектов.
Гибкость и Институт по управлению проектами (PMI) – также существует мнение Кена Швабера (Кеn Schwaber), основанное на его многолетнем опыте применения и внедрения Скрама вместе с Джеффом Сазерлендом (Jeff Sutherland) .

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

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

Из своего опыта, я склонен считать, что менеджеры проекта и Скрам часто взимоисключают друг друга. Если вы читали Кена Швабера, то он говорит нам о том, что менеджеры проекта нарочно не были добавлены в Скрам. По его мнению, менеджеры проекта пагубно влияют на умственную работу, а также снижают творческий потенциал и интеллект команды (мне кажется, я слышу дружное “Гип-гип-ура!” от людей, поддерживающих данное высказывание, и не менее дружное “Что за бред!” от людей, которые не согласны с Кеном). Строгое следование определению менеджера проекта по версии PMI, скорее всего сделает из менеджера либо человека, который говорит людям, как нужно делать их работу, либо няньку для проектной команды. Оба варианта крайне негативно воспринимаются высококвалифицированными профессионалами и сводят на нет уважение, доверие и самоорганизацию в команде, а также принятие командой обязательств и фокусирование на главном. Когда люди говорят мне, что их компания сократила Скрам-мастеров в пользу Аджайл Менеджеров Проектов, то мне становится очевидно, что в компании хотят обозначить одного определенного человека, которого можно обвинить в случае неудачи проекта.

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

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

Переведено с английского проектом Agile Translations
Алина Проскурина, Дарья Ершова, Тимофей Евграшин

Оригинальная статья: "What is an Agile Project Manager?" by Carlton Nettleton

Обзор интересной литературы на Agile-тематику за 2013 год

noreply@blogger.com (Unknown) — Thu, 26 Dec 2013 17:15:00 +0200

Автор: Илья Павличенко

Утекают последние деньки 2013 года, и у меня возникло желание составить список заслуживающих внимания книг по Аджайл/Скрам тематике, вышедших в этом году. 2013ый оказался урожайным на качественную литературу, что меня искренне радует.

Ровно 20 (двадцать) лет назад появилась первая Скрам команда в компании Easel, 12 (двенадцать) лет как подписан Аджайл Манифест. За это время появилось большое количество великолепных тренеров, которые смогли переварить десятки проектов, набить кучу шишек и накопить горы опыта. Теперь эти тренеры-практики пишут умные книжки, в которых описывают результаты многолетней работы с Аджайл/Скрам командами. Мне кажется, глупо не воспользоваться их багажом. А стоит это совсем немного.

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

Growing Agile: A Coach's Guide to Training Scrum

Автор: Саманта Лэйнг и Карен Гривс.
Тематика: книга написана двумя сертифицированными тренерами Скрам Альянса и представляет собой ни что иное, как детальное описание тренинга Certified Scrum Master(CSM). Тренинг описан в формате Training From The Back Of The Room (TFTBOTR). Если вы – практикующий Аджайл/Скрам тренер, то это книга точно вам пригодится.
Будет полезной она и для Скрам Мастеров, в ней вы можете найти массу полезных упражнений для своих команд.
Избранные цитаты: Всегда начинайте курс с установления контакта между людьми. Это поможет вам создать атмосферу доверия в классе между участниками тренинга и тренером.

The Lean Mindset: Ask the Right Questions

Автор: Мэри и Том Поппендик.
Тематика: Сказать, что эту книгу ждали все – значит, не сказать ничего. Великолепная книга от Мэри и Тома. Конечно о Бережливом Производстве, но больше об образе мышления, о новых тенденциях, о возможном будущем IT индустрии. В книге причудливо и органично соединена практика и теория. Очень интересна концепция медленного и быстрого образа мышления, которая описана в начале.
Избранные цитаты: Бережливое производство – это образ мышления, ментальная модель того, как работает Мир. Исследования показывают, что большинство решений мы принимаем инстинктивно, основываясь на образе мышления, который у нас уже выработан.

Scrum Shortcuts without Cutting Corners

Автор: Илан Голдштейн
Тематика: Автор книги – известный австралийский сертифицированный Скрам тренер Илан Голдштейн. Книга представляет собой сборник различных практических советов, лучших практик и разбора тонкостей применения Скрама. Главы не связаны логически между собой, и книгу можно читать в произвольном порядке, перескакивая с главы на главу.
Избранные цитаты: Хочу вам дать совет, который, как мне кажется, наверняка давали вам родители. Если вы что-то делаете, то делайте это хорошо. Или делайте все, что от вас требует фреймворк Скрама, или просто не называйте это Скрамом.

Peopleware: Productive Projects and Teams

Автор: Том ДеМарко, Тим Листер.
Тематика: Неувядающая классика, и этим все сказано. Третья редакция культовой книги, которая впервые была опубликована еще в 80-х годах. Книга, которую должен прочитать каждый, кто имеет хоть какое-то отношение к IT индустрии. Вы узнаете, почему закон Паркинсона не работает.
Избранные цитаты: Разработка программного обеспечения в корне отличается от обычного производства. Но, к сожалению, много менеджеров принимают решения, исходя из философии, взятой из производства. Это бы имело хоть какой-то смысл, если бы мы работали в индустрии фаст-фуда, но это не так. Подходы, основанные на «купить чизбургер - продать чизбургер» могут быть фатальными в IT.

Scrum Mastery

Автор: Геофф Воттс
Тематика: Книга просто напичкана практическими советами и лучшими практиками для Скрам команд. Книга построена на противопоставлении того, что делает Good Scrum Master и что должен делать Great Scrum Master. Каждая из глав посвящена конкретной проблеме. Вы узнаете, что общего между работой Скрам Мастера и няни.
Избранные цитаты: Скрам Мастер должен быть для команды как скала во время шторма. Какой бы сложной не была проблема, первой реакцией Скрам Мастера должна быть мысль: «Надо спросить у команды, что они думают по этому поводу». Второй совет, который я хочу вам дать – всегда ставьте перед собой цель вырастить команду, которой вы будете не нужны.

The People's Scrum: Agile Ideas for Revolutionary Transformation

Автор: Тобайас Майер.
Тематика: Бриллиант этого года, книга, к которой, возможно, вам захочется возвращаться не один раз. Тобиас выбрал лучшие блог посты с 2004 года и связал их в одну книгу. Концепция «человеческого» Скрама – нить, которая проходит через всю книгу. Многое из того, о чем пишет автор, часто не вкладывается в обычные представления о Скраме, по настоящему «ломает» мозг. Это книга, которая может изменить ваш образ мышления.
Избранные цитаты: Распределенные команды – не команды. В лучшем случае это группы людей, которые время от времени коммуницируют. Но общение(communication) не равняется взаимодействию(collaboration), это лишь жалкое подобие.

The Professional ScrumMaster's Handbook

Автор: Стейсия Вискарди
Тематика: И опять книга от сертифицированного Скрам тренера с многолетним опытом работы. Много полезной теории, которая смешана с большим количеством практики. Стейсия подробно рассказывает, как проводить планирование, ретроспективы, как высчитывать способность выполнить определенный объем работы команде. Хардкорные практические инструменты, которые можно просто взять и начать использовать в своей команде.
Избранные цитаты: Я всегда готовлю агенду к встрече за несколько дней. Я сажусь за стол с ручкой, бумагой и представляю в голове будущую встречу. Я визуализирую себе команду, наше общение, смех людей и то, что мы должны будем обсудить.

Scrum – A Pocket Guide

Автор: Гюнтер Верхейен.
Тематика: Я уверен, что книга станет культовой в ближайшие несколько лет, и к ней будут часто обращаться, чтобы объяснять, чем же является Скрам на самом деле. Гюнтер - директор программ Scrum.org, человек, который много лет работает с Кеном Швабером. Книга основана на Скрам Гайде последней редакции (июль 2013 года). С согласия автора я перевел одну из ключевых глав на русский язык и опубликовал в блоге. Рекомендую книгу всем, кто любит отделять шелуху от зерен.
Избранные цитаты: Дом Скрама - уютное и комфортное место. Это дом, двери которого всегда открыты. В этом доме работают, учатся и становятся лучше люди, пришедшие сюда из различных мест, имеющих отличные друг от друга навыки, таланты и персоналии. Дом Скрама - это место теплых открытых и коллаборационных взаимоотношений между людьми.

Вот и все. На этом мой список закончен. Конечно, невозможно объять необъятное. Сейчас выходит большое количество интересных книг по Agile тематике и, не исключаю, что пропустил много стоящего. Что можете посоветовать почитать? Чем расширите список уходящего года?

Scrum On!

Ротация роли Скрам-мастера

noreply@blogger.com (Unknown) — Fri, 13 Dec 2013 15:50:00 +0200

Автор: Майк Кон (Mike Cohn)
Переведено с английского проектом Agile Translations.

Стараясь выбрать лучшего Скрам-мастера, некоторые команды выбирают стратегию ротирования (передавания) этой роли между членами команды. Я не сторонник такого подхода, так как не думаю, что постоянная ротация демонстрирует должное уважение к трудностям и значимости этой роли. В моей семье мы по очереди убираем со стола и загружаем посудомоечную машину. Любой из нас может сделать эту работу. Однако, мы не готовим ужин по очереди. Моя жена намного лучше готовит, чем кто-либо в семье. И мы хотим, чтобы наша пища была приготовлена как можно лучше, потому и не чередуем приготовление ужина.

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

Боб Шатц (Bob Schatz) и Ибрагим Абделшафи (Ibrahim Abdelshafi) из Примавера Системс (Primavera Systems) привели другой пример, когда ротация может быть полезной:

Со временем команда может начать относиться к Скрам-мастеру как к менеджеру. Скрам-мастер в такой ситуации обычно замечает эти изменения, но продолжает ответственно выполнять уже новую роль. В результате рушится практика самоорганизации в команде. При поочередной смене ответственности в начале каждого спринта, роль распределяется и становится общей ответственностью команды, восстанавливая тем самым равновесие сил. (The Agile Marathon in the Proceedings of Agile 2006).

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

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

Переведено с английского проектом Agile Translations
Наталья Новотная, Дарья Ершова, Алина Проскурина, Александр Лутсаевский

Оригинальная статья: "Rotating the ScrumMaster Role" by Mike Cohn

Погоня за велосити убивает гибкость

noreply@blogger.com (Unknown) — Thu, 21 Nov 2013 14:24:00 +0200

Автор: Джим Хайсмит (Jim Highsmith)
Переведено с английского проектом Agile Translations.

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

Это крайность в употреблении неплохого инструмента для неправильных целей:

Велосити все чаще используется в качестве метрики продуктивности (а не в качестве способа нормирования нагрузки команды, как задумывалось), что слишком фокусирует внимание на объеме законченных стори поинтов.
Фокусировка на объеме отвлекает внимание от качества удовлетворения потребителей и достаточного инвестирования в механизм поставки (в техническое качество).
Полный контроль Владельца Продукта/Менеджера Продукта над приоритетами только ухудшает ситуацию — мы уходим от фокусировки на клиентах к контролю клиентов, который сдвигает равновесие все дальше от инвестирования в механизм поставки к разработке новой функциональности.
Особенно для таких видов бизнеса, где необходим быстрый ответ рынку (цикл поставки измеряется днями или неделями), инвестиции в механизмы поставки также важны, как и новая функциональность.
Руководству необходимо распределять ресурсы между новой функциональностью и техническими улучшениями, а также создать команду владельцев продукта, включающую Владельца Продукта и технического лидера для совместного определения приоритетов.
Такие метрики, как ценность новой функциональности и время цикла помогут сбалансировать разрушительное влияние метрики велосити.

Чрезмерное внимание к велосити вызывает проблемы из-за того, что она часто используется как метрика продуктивности команды. Велосити правильно использовать в качестве инструмента для определения допустимой загрузки команды, чтобы делать планирование исходя из нагрузочной способности команды, как это описывает Кент Бек в “Экстремальном Программировании” (Kent Beck: Extreme Programming: Embrace Change). Измерения продуктивности вообще имеют не так много смысла для умственной работы, но это уже тема для другой статьи.

Велосити — это очень соблазнительная метрика, потому что ее легко посчитать. Даже несмотря на то, что количество стори поинтов, законченных за итерацию, подсчитываются на базе функциональности, готовой к релизу, все же велосити акцентирует внимание именно на приложенных усилиях. В то время как Agile команды стараются сфокусироваться на поставке функциональности с наивысшей ценностью для бизнеса, они отвлекаются на отчетность о своей продуктивности. Время от времени я слышу о комментариях от менеджеров или Владельцев Продукта, “Ваша велосити упала c 24 в прошлую итерацию до 21, что пошло не так? Давайте поднимем велосити до предыдущего значения, а еще лучше - выше.” В этом сценарии велосити превратилась из полезного инструмента планирования (какова наша нагрузочная способность на следующую итерацию?) в инструмент измерения производительности. Это говорит о пренебрежении к двум вещам: качеству удовлетворения пользователей (количество функциональности доминирует над улучшением юзабилити) и улучшению механизма поставки (техническому качеству).

Гибкость — это способность отвечать на изменения для того, чтобы процветать в непрерывно меняющейся экономической обстановке. Это означает, что нам нужно создать и поддерживать непрерывный механизм поставки, а не выпустить много функциональности в первом релизе, а затем быстро снизить производительность. Основное проявление гибкости в разработке программного обеспечения — это непрерывная поставка (continuous delivery). Нашей целью должна быть не продуктивность, но “быстрая поставка программного обеспечения, имеющего ценность для пользователей — снова и снова.” Чтобы реагировать на изменения бизнеса, технологий и действия конкурентов, мы должны сфокусироваться на превосходном удовлетворении пользователей, создании новой функциональности и улучшении механизма поставки, который позволит нам быстро выпускать функциональность в каждом релизе.

Усугубляя проблему, Аджайл движение фокусировалось на высоких уровнях вовлеченности клиента — отличная вещь сама по себе — но мы зашли слишком далеко. Большое количество аджайлистов с осуждением говорят о том, что они не могут заставить организации сфокусироваться на технических практиках — но почему это вызывает удивление, если мы поощряем Владельцев Продукта принимать все решения по приоритету, а также измерять продуктивность, используя велосити? По сравнению с традиционной методологией, мы с избытком компенсируем отсутствие фокуса на клиенте путем передачи Владельцу Продукта полного контроля над приоритетами. Зачастую мы сваливаем всю необходимую техническую работу в пользовательские истории, предполагая, что мы сможем убедить Владельца Продукта/Менеджера Продукта согласиться на выполнение этой дополнительной работы. Это излишняя корректировка традиционных подходов, когда месяцы технических работ предшествовали разработке функциональности, которую сможет увидеть пользователь (что было даже худшей проблемой).

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

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

В книге Дона Райнертсена, “Принципы Потока Разработки Продукта” (Don Reinertsen: The Principles of Product Development Flow), он предлагает такую формулу:

Время цикла/Время добавленной ценности = 1/(1 - Утилизация)

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

Бизнес сдвинулся из мира периодических изменений к миру непрерывного изменения. Параллельно с этим, разработка программного обеспечения эволюционирует от проектно-ориентированной работы (поставка программ большим куском и затем его поддержка) к продуктно-ориентированной (непрерывная поставка). Чтобы направлять поведение в правильном направлении, нам нужно включать такие метрики, как ценность, время цикла поставки и техническое качество в наши критерии продуктивности. Нам нужно высчитать ценность новой функциональности наряду с ее объемом (стори поинты). Время цикла может быть превосходной метрикой, потому что оно зависит от оптимальной работы механизма поставки программного обеспечения и это метрика, понятная бизнесу. Когда мы спрашиваем: “Стоит ли нам работать над новой функциональностью или повышением качества (сокращением технического долга, и т.д.)?”, Владельцу Продукта легко ответить, “разумеется, работайте над новой функциональностью.” Вместо этого нам нужно спросить: “Как нам сбалансировать поставку новой функциональности и уменьшение времени цикла?” [Примечание: Цена Отсрочки, из книги Дона Райнерстена (Дон Reinertsen) также может быть полезной метрикой].

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

Примечание: Спасибо Мартину Фаулеру (Martin Fowler), Джезу Хамблу (Jez Humble) и Кену Кольеру (Ken Collier) за их комментарии и дополнения к этой статье.

Переведено с английского проектом Agile Translations
Алина Проскурина, Тимофей Евграшин, Дарья Дубинина

Оригинальная статья: "Velocity is Killing Agility" by Jim Highsmith

Скрамбан - собираем лучшее

noreply@blogger.com (Unknown) — Thu, 1 Aug 2013 12:36:00 +0300

Автор: Илья Павличенко.

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

Привожу цитату Алана Шалловея, одного из родоначальников Канбана (полностью его блог-пост по этому вопросу можно прочесть здесь):

«Теперь стало модно у многих Скрам команд уходить от итераций и кросс-функциональных команд и говорить, что теперь у них внедрен Канбан. Я принимаю то, что в Канбане отсутствует и первое, и второе. Но Канбан не определяется отсутствием итераций или кросс-функциональных команд. Он определяется визуализацией, управлением потока, наличием явных полиси и т.д. Если у вас был Скрам и вы решили уйти от итераций - у вас не Канбан. Вы даже и близко не подошли к тому, чтобы приблизиться к Канбану. На самом деле теперь ваш процесс не является даже одним из определенных Аджайл методов/фреймворков. Все, точка».

Итак, давайте разбираться.

Определение Скрама.

Скрам – гибкий Фреймворк для решения сложных адаптивных проблем. Скрам очень минималистичен, прост для понимания, но чрезвычайно сложен в использовании. До недавнего времени была путаница в определении того, что же на самом деле можно называть настоящим Скрамом. После выхода Скрам Гай да, написанного Джеффом Сазерлендом в соавторстве с Кеном Швабером, вопрос был снят. Все, что описано в этом лаконичном документе, является обязательным для каждой Скрам команды.

«Роли, артефакты, события и правила Скрама не могут изменяться. Несмотря на то, что возможно использование лишь отдельных частей Скрама, результат не будет Скрамом.» (ScrumGuide, 2011)

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

«Скрам может быть использован только целиком и функционировать как контейнер для других техник, методологий и практик» (ScrumGuide, 2011)

Определение Канбана.

Формальное определение этого метода можно найти в уже ставшей классикой книге Дэвида Андерсона «Kanban». Метод состоит всего лишь из пяти правил и не является методологией или Фреймворком. Я уже писал об этом в своем блог-посте «Канбан как НЕ процесс, НЕ методология, НЕ фреймворк».

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

«Канбан не является методологией. Также Канбан - это не способ разработки программного обеспечения. Не существует процесса Канбана для разработки программного обеспечения. По крайней мере, я не знаю такого. Я никогда о таком не писал. Невозможно вести разработку с помощью одного Канбана. Метод Канбана сам по себе не содержит достаточно практик для продуктовой разработки». (Дейвид Андерсон)

Вы можете работать в «старом добром» Водопадном процессе и при этом успешно пользоваться Канбаном. Одно другому не противоречит. За это на Канбан обрушивается большой поток критики со стороны Аджайл сообщества. Многие даже не считают его частью Аджайла. Канбан является техникой ограничения работы в процессе (WIP), которую можно «натянуть» на любой уже существующий в команде процесс.

Объединяем Скрам и Канбан в Скрамбан

Скрамбан является полноценным Скрамом, внутри которого применяется техника Канбана. Один из главных идеологов Канбана и Лина – Кори Ладас издал замечательную книгу «Scrumban». В ней он указал на слабые места Скрама и показал, каким образом, добавив Канбан, можно повысить продуктивность команды и оптимизировать поток внутри Спринта. Формула Скрамбана следующая: Scrumban = Scrum + Kanban

Глядя на формулу, становится понятно, что у команды должен быть внедрен полнофункциональный Скрам и в дополнение «навешен» Канбан. Такое сочетание является очень эффективным. Типичная СкрамБан команда использует полноценный Скрам и доску для визуализации своей работы с явно проставленными ограничениями на работу (иначе это не Канбан) в прогрессе. Зачем это нужно?

Давайте представим, что Скрам команда начала работать над ВСЕМИ элементами Беклога Спринта в первый же день сразу после планирования. Иначе выражаясь, все элементы Спринт Беклога «поехали» одновременно. Формально это никаким образом не нарушает правила Скрама. Действительно, Скрам не разъясняет, каким образом команда разработки должна доставлять выбранный на планировании функционал. Спринт - это черный ящик, в котором не видно, что происходит. На входе такого ящика – Спринт Беклог и Цель Спринта, а на выходе – Инкремент продукта (Potentially Shippable Product Increment).

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

СкрамБан команда эффективно решает эту проблему тем, что ограничивает работу в прогрессе. Доска преображается и уже выглядит так:

Нет плохих инструментов, есть неверный контекст их использования

Использование Скрама и Канбана очень эффективно. С помощью Скрама мы решаем наши стратегические задачи и работаем, используя циклы обратной связи и прозрачность. С помощью Канбана решаем тактические задачи внутри Спринта и выравниваем поток.
Как утверждается в библии управления процессами (“ProcessDynamics, Modeling, andControl“, 1994), плохих процессов нет. Тем не менее, иногда процессы применяются в неверном контексте. Скрам – эмпирический процесс, построенный на принципах Бережливого Производства. Более всего он подходит для решения комплексных сложных задач и поэтому очень успешен в области разработки программного обеспечения, где больше неизвестного и неопределенного.

“Скрам, Канбан и XP – дополняющие друг друга, конкурирующие и часто конфликтующие модели. Но это не является большой проблемой. Просто мы должны быть осторожными и достаточно критичными в использовании этих моделей и знаний, которые они нам дают” (Юрген Апелло, Management 3.0)

Scrum On

Эстимация нефункциональных требований

noreply@blogger.com (Anonymous) — Wed, 3 Jul 2013 16:27:00 +0300

Автор: Майк Кон (Mike Cohn)
Переведено с английского проектом Agile Translations.

Несколько недель назад я обещал написать статью об особых сложностях, связанных с оценкой (эстимацией) нефункциональных требований. Для начала давайте вспомним, что нефункциональные требования – это требования, которые больше связаны с состоянием самой системы, нежели с деталями ее функциональности. Обычно нефункциональные требования касаются производительности, корректности, удобством сопровождения системы (maintainability), функциональной совместимости (interoperability), ее переносимости на другие платформы (portability) и т.д. Кстати, нефункциональные требования также могут быть описаны в виде Пользовательских Историй. Трудность при их эстимации состоит в том, что эти требования имеют двойные издержки. Первый тип издержек – это стоимость первоначального соответствия, а второй – стоимость непрерывного соответствия этим требованиям. Давайте рассмотрим конкретный пример, чтобы на практике разобраться с этими типами издержек.

Представим, что наша команда работает над новым продуктом, к которому имеются требования к производительности. В течение первого спринта команда может помнить об этих требованиях, но, скорее всего, они не будут сразу заниматься тестированием производительности продукта, поскольку еще написано недостаточно кода. Несомненно, на протяжении последующих нескольких спринтов команда будет писать код, и, скажем, к пятому спринту она решит, что кода написано уже достаточно и захочет занятся тестированием его производительности. Помните, мы говорили, что первый тип издержек – это стоимость первоначального соответствия? В данном случае она будет равняться выполненному в пятом спринте объему работ по тестированию производительности. На самом деле, его не намного сложнее оценить, чем остальные элементы Беклога Продукта, которые команда оценит в идеальных днях или же условных единицах работы - "story points".

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

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

Возвращаясь к вопросу, как же нам оценивать данные издержки? Я думаю, лучше это делать раздельно. Для начала оцените стоимость первоначального соответствия, так же, как вы это делаете для любого другого элемента Беклога Продукта. Команда и Владелец Продукта так же должны оценить, когда они смогут его выполнить. Добавление тестирования производительности после пяти спринтов очень отличается от его добавления после двадцати. Для согласования доли этого налога команда и Владелец Продукта определяют, когда будет проходить его «выплата» – каждый спринт или же каждые n спринтов. Тогда команда сможет прикинуть, сколько работы необходимо выполнить на протяжении запланированного количества спринтов, и распределить этот объем на каждый спринт.

Для примера представим, что команда и Владелец Продукта договорились проводить тестирование производительности продукта каждый четвертый двухнедельный спринт. Если команда оценила этот объем в 6 условных единиц работы, то на каждый спринт приходится примерно по 1,5 единицы. Если скорость (velocity) составляет 30 таких единиц, то эти 1,5 единицы составляют 5%-ный налог. Вероятно, что в первый раз команда ошибется с точностью такой оценки. Это не страшно, так как с количеством пройденных спринтов она сможет четко отследить, сколько усилий уходит на тестирование производительности, и использовать эти наблюдения для корректировки последующих оценок стоимости непрерывного соответствия продукта нефункциональным требованиям.

Переведено с английского проектом Agile Translations - Ильей Павличенко, Дарьей Дубининой, Андреем Перервой и Игорем Добритским.

Оригинальная статья: "Estimating Non-Functional Requirements".

Какие проекты лучше всего подходят для применения Agile

noreply@blogger.com (Anonymous) — Wed, 3 Jul 2013 16:06:00 +0300

Автор: Майк Кон (Mike Cohn)
Переведено с английского проектом Agile Translations.

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

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

Сегодня на обед я пошел в свой любимый китайский ресторанчик. Я заказал себе блюдо «тройной супер острый халапеньо». Вероятно, это был первый раз, когда они готовили это блюдо именно таким способом, поэтому оно было в какой-то мере новым и уникальным. Тем не менее, повар приготовил его чудесно, а поскольку я мог наблюдать их кухню, я вам скажу с уверенностью, что им не понадобились Daily stand-up митинги и даже TDD, чтобы приготовить мой обед (хотя, я там заметил некоторые признаки канбана :)

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

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

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

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

Переведено с английского проектом Agile Translations - Дарьей Дубининой, Андреем Перервой, Натальей Новотной и Ильей Павличенко.

Оригинальная статья: "Deciding What Kind of Projects are Most Suited for Agile"

Почему ваши оценки сроков не имеют значения

noreply@blogger.com (Anonymous) — Tue, 18 Jun 2013 15:49:00 +0300

Автор: Морган Альстром
Перевод с английского проектом Agile Translations.

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

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

Как вы видите, нам необходима еще и оценка нагрузочной способности команды (capacity), чтобы эстимация имела хоть какой-то вес и связь с реальностью. Но беда в том, что и этого не достаточно. Когда мы занимаемся эстимацией, нам нужно быть в четком согласии друг с другом на счет того, что именно мы эстимируем. Нам надо иметь общий взгляд на предполагаемое качество выполнения, причем как на внешнее, так и на внутреннее. Каждый участник этого процесса должен ясно представлять себе ожидаемое поведение нашего решения. Если, скажем, заказчик ожидает на выходе Лексус, но разработчик наивно полагает, что ему предстоит изготовить детскую коляску – то в таком случае эстимация не будет иметь абсолютно никакой ценности. Каждый участник команды должен иметь одно и тоже представление об уровне внутреннего качества продукта. Может так случится, что разработчика вполне устраивает качество Windows 95, в то время как тестировщик ожидает от продукта качество уровня современной флагмагманской операционной системы – в таком случае эстимация так же не будет иметь никакого веса.

Теперь мы ясно видим, что помимо эстимации и оценки нагрузочной способности команды, нам необходимо еще и общее понимание качества продукта. Немаловажно понимать, что если мы делаем эстимацию, и она вдруг оказывается неверной – то эффект этой ошибки скорее всего растворится с течением времени (конечно, если речь идет не о систематических ошибках в эстимации). Скажем, если некой задаче была дана приблизительная оценка в 5 дней, но по факту она заняла все 10 (т.е. мы имеем 100%-ную ошибку в эстимации), то негативный эффект от этой ошибки в рамках 6-месячного проекта сведется всего к 4%. С другой стороны, любая ошибка в оценке нагрузочной способности имеет свойство умножать свое негативное влияние, если ее оставить без внимания.

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

Обобщенно это можно выразить так:

Ошибка в эстимации – последствия с течением времени линейно убывают;
Ошибка в оценке нагрузочной способности (capacity) – последствия с течением времени линейно возрастают;
Ошибка в качестве – последствия с течением времени возрастают экспоненциально.

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

Переведено с английского проектом Agile Translations.
Оригинальная статья "Why your estimates don’t matter".

Что следует и чего не следует делать Канбан-коучу

noreply@blogger.com (Anonymous) — Wed, 3 Apr 2013 22:16:00 +0300

Автор: Дэйвид Андерсон (David Anderson)
Перевод с английского.

Взято с www.software-kanban.de

Я осознаю, что большинство Agile-коучей и консультантов довольно часто неправильно понимают, что же это значит – быть Канбан-коучем. Следовательно, они склонны считать, что Канбан – это всего лишь еще одна методика, которую они могут легко внедрить, применяя свои привычные тренерские техники, проверенные на опыте внедрения Agile. Но это предположение является в корне ошибочным! В результате него, некоторые Agile-коучи хотят предлагать Канбан, как один из многих инструментов, наряду с их остальными тренерскими услугами. Тем самым они недооценивают важность посещения специализированных мастер-классов по Канбану для тренеров, менеджеров и консультантов.

Особенно интересным является тот факт, что я не замечаю подобного у консультантов по другим областям, таким как CMMI, Six Sigma (6 сигм), Lean (бережливое производство), Теория ограничений, управление рисками и т.д. Они не приходят с предвзятым убеждением, что «Канбан – это не более чем еще одна Agile-методика, поэтому мне нужно только освоить ее основные механизмы и принципы, а затем внедрить, как тот же Скрам или TDD». И это радует, так как на самом деле вы не сможете (по крайней мере, не должны) внедрять Канбан, так же, как Скрам или TDD.

Так что же делают Канбан-коучи и чего, что еще более важно, они не делают?

Прекратите отстаивать! Прекратите пропагандировать! Вместо этого наблюдайте

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

Канбан-коучи не отстаивают и пропагандируют Agile, они наблюдают и советуют.

Канбан не осуждает сложившуюся ситуацию

Канбан-коуч никогда не должен выражать осуждение. Текущее положение дел таково, как оно есть, и стало оно таким из-за текущей команды, их обстоятельств и требований клиента, так что жалеть по этому поводу абсолютно бесполезно. Критиковать людей за то, что их текущие практики не соответствуют модному и современному подходу или же «системе верований» – занятие крайне неуважительное.

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

Подходит ли нам Канбан?

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

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

Хороший канбан-коуч всегда оценивает уместность применения данной методики, прежде чем ее рекомендовать. Вы не должны «продавать» эволюционный подход, революционно настроенному клиенту. Ситуативная осведомленность является неотъемлемым навыком канбан-коуча.

Канбан должен быть подобен воде

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

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

Построение канбан-систем – это продвинутый навык

Хорошие Канбан-коучи знают, что нет смысла силой навязывать изменения, встречаемые с отпором. Они должны избегать построения канбан-системы, которая бы сразу же решила все проблемы существующего процесса, выявленные при начальном наблюдении. Возможно, введение ограничений на выполняемую в текущий момент работу (WIP – work in progress), в качестве решения проблемы перегруженности команды, вызвало бы сопротивление с их стороны? Это сопротивление можно предвидеть заранее, если понимать с эмоциональной точки зрения, как это может отразиться на всех участниках команды, их личном образе, самооценке, эго, социальном статусе и других аспектах.

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

Переведено с английского проектом Agile Translations.
Оригинальная статья "WHAT KANBAN COACHES DO, AND DON’T DO" опубликована на сайте http://agilemanagement.net.

Оценивание и планирование необходимы для повышения поставляемой ценности

noreply@blogger.com (Anonymous) — Mon, 11 Mar 2013 17:06:00 +0200

Автор: Майк Кон (Mike Cohn)
Перевод с английского.

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

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

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

А что насчет оценивания? Действительно ли нам нужно оценивать? Да, потому что оценивание является предпосылкой для планирования. Вы не сможете планировать без оценок. Эти оценки могут быть очень неформальными и очень неявными. В данный момент я лечу в Калифорнию. Перед посадкой я снял деньги в банкомате. Я предположил, что на предстоящие нужды мне необходимо $200. Эта оценка забрала у меня менее секунды, и я даже не осознал, что я что-то оценивал.

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

Команды, которые говорят “Мы не будем оценивать. Мы будем делать все пользовательские истории одинаковыми по объему работы”, на самом деле оценивают. Они предполагают, что объем работ в каждой новой истории такой же как и в остальных. Я готов поспорить - сложнее сделать все истории одинакового размера, чем использовать небольшой диапазон оценок усилий для разных историй. Такие оценки должны быть сделаны. Да, они могут быть подсознательными, но они сделаны. Те, кто пишут в блогах и новостях “оценивание - пустая трата времени, не делайте его”, - игнорируют такие типы оценивания.

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

Скорее всего да, но не всегда. Команда должна оценивать и планировать только до тех пор, пока это приводит к большей уверенности в дате сдачи проекта, лучшей расстановке приоритетов, и т.п., если это не так, то стоит прекратить оценивание и планирование.

К примеру, мы недавно добавили немного функционала на наш сайт по удаленному обучению eLearning course on Agile Estimating and Planning. Я не просил программиста, который делал эту работу, дать мне более чем поверхностную оценку. Я всё ещё достаточно хорошо разбираюсь в программировании, чтобы иметь понятие о том, как долго разрабатывать новый функционал. Также я достаточно давно с ним работаю и знаю насколько он быстр. Более детальная оценка ничего бы не изменила в данном проекте.

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

Переведено с английского проектом Agile Translations.
Оригинальная статья: Estimating and Planning Are Necessary for Maximizing Delivered Value.

Правила или общепринятые практики Скрам

noreply@blogger.com (Anonymous) — Mon, 25 Feb 2013 12:54:00 +0200

Автор: Майк Кон (Mike Cohn)
Перевод с английского.

В одной из мартовских заметок своего блога, я ввел термин, который в то время пробовал ввести в обсуждениях и некоторых классах. Термин был "GASP" и расшифровывался как общепринятая практика Скрам (англ. Generally Accepted Scrum Practice). В чем я сейчас действительно заинтересован и, надеюсь, вы мне в этом сможете помочь, так это создать список всех общепринятых Скрам-практик которые мы знаем.

Читать дальше >>>

Как Spotify создает продукты

noreply@blogger.com (Anonymous) — Sat, 23 Feb 2013 22:04:00 +0200

Автор: Хенрик Книберг (Henrik Kniberg)
Перевод с английского проектом Agile Translations.

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

Spotify - шведский низкобюджетный стартап с замечательными показателями выпуска продуктов. Их продукты любимы пользователями и артистами, они распространяются со скоростью вирусов - у них более 20 миллионов активных пользователей, 5 миллионов платных подписчиков, и быстрый рост продолжается. К примеру, чтобы в США начать с нуля и дорасти до 1 миллиона платных подписчиков, им потребовался приблизительно год, а ведь это иностранный рынок, где присутствует множество крепких игроков.

Главная идея Spotify – предоставить вам музыку для каждого момента. Это неограниченный доступ к любой музыке мира и возможность быстро ею поделиться. Чем больше музыки «расшарено» и проиграно, тем больше денег поступает артистам. Начавшись c музыкального проигрывателя несколько лет назад, их продукты сегодня превратились в повсеместно присутствующую и всем знакомую платформу для открытия новой музыки и установления непосредственной связи между артистами и поклонниками.

Их продукты просты, персональны и забавны. Даже музыканты «Металлики», долгое время выступавшие непримиримыми оппонентами любых сервисов для трансляции музыки, теперь считают Spotify "наилучшим транслирующим сервисом" и "поражены его простотой и удобством".

Однако здесь есть парадокс: успешные компании, такие как Spotify, просто хотят выпускать продукты, которые будут нравиться людям. Но им неизвестно, что именно нравится людям, пока этот продукт ими не выпущен.

Как же они узнают об этом?

Цель этой статьи - создать общее представление о том, как Spotify подходит к разработке продукта.

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

Благодарности.
Эта модель изобретена не мной. Материал этой статьи базируется на дискуссиях с Gustav Söderström, Oskar Stål, Olof Carlson, их внутренних документах и моделях, таких как “Think It, Build It, Ship It, Tweak It”. Также я многое узнал их разговоров с дизайнерами, разработчиками и тренерами гибкой разработки. Спасибо всем вам!

Обзор

Сущность нашей философии такова:

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

Все основные направления деятельности по созданию продукта проходят 4 стадии:

Think It (обдумай)
Build It (построй)
Ship It (доставь)
Tweak It (подстрой)

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

Четыре фаза разработки продукта Spotify

Более подробную версию этой схемы вы увидите в конце статьи.

Think It = выясни, какой тип продукта мы разрабатываем и для чего.

Build It = создай минимально работоспособный продукт, готовый для реальных пользователей.

Ship It = постепенно предоставь 100% пользователей доступ к нему, измеряя параметры и улучшая продукт.

Tweak it = Постоянно совершенствуй продукт. Это действительно окончательное состояние; продукт находится здесь, пока не будет закрыт или пересмотрен (= вернуться к Think It).

В Spotify более 30 команд (это маленькие, кроссфункциональные самоорганизующиеся команды, больше описано в статье: "Scaling Agile @ Spotifywith Tribes, Squads, Chapters, and Guilds”) и множество разных продуктов, поэтому для того, чтобы следить за происходящим в остальной компании и представлять это зрительно, мы используем таблицу состояния продукта, показывающую на какой из стадий находится данный продукт. Приблизительно она выглядит так:

Таблица состояния продуктов Spotify

Кроме того, мы испытываем прогностические инструменты, а команды отвечают за регулярное обновление таблицы сроков (дата А-дата Б), показывающие, когда они предполагают достичь следующей стадии.

Зачем 4 стадии?

Самый большой риск – построить неправильный продукт: ведь он не приносит радости нашим пользователям, не улучшает показатели успеха, такие как привлечение пользователя, удержание пользователя, т.д. Мы называем это "риск продукта".

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

График снижения рисков продукта

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

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

Итак, давайте теперь присмотримся к каждой из стадий.

Think It

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

Стадия «Обдумай» означает появление у кого-либо совершенно новой идеи продукта или желания переделать уже существующий продукт.

Фаза "Think It"

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

Определение продукта - это короткий документ, отвечающий на следующие вопросы:

Зачем нам это разрабатывать?
Кому и какая от этого польза?
Какие ключевые показатели призван улучшить данный продукт?
Это может быть определено как количество транслируемой музыки, количество загрузок, число подписчиков.
Каковы гипотезы?
Как мы узнаем, что продукт удался?
Будет ли это "качественным скачком" (таковым считается продукт, позволяющий, по крайней мере, двукратно улучшить избранный для оценки критерий)? Если ожидается лишь незначительное улучшение показателей, возможны другие причины для его разработки, например, соображения стратегии.

Определение продукта - это не документ с перечнем требований или план проекта. В нем нет списка приложений, бюджетов, планирования ресурсов и тому подобного. Это скорее описание цели проекта на основании данных.

Наиболее важная часть определения продукта - это его история или нарратив. Что он расскажет миру? Как будет выглядеть его пресс-релиз?

Вот, например, недавний продукт Spotify - таблица «Discover». Приведем выдержку из двухминутного видео, представляющего данный нарратив:

Мы предлагаем вам новый способ совершить музыкальное открытие.
Смотрите! Любимый артист делится с вами песней. Мы как никогда сближаем артистов с фанатами. Нравится артист? Просто фолловьте их и делитесь своими открытиями с друзьями.

Другой пример - это Mobile Free Radio, с нарративом "Radio you can save". В данном случае мы использовали Google Adwords, чтобы испробовать разные нарративы вживую и выяснить, какой из них был наиболее убедителен.

Самое важное здесь, чтобы нарратив был написан еще до того, как построен продукт! Таким образом, мы обеспечиваем убедительный вид продукта, даже еще не разработав его.

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

Выбор и отбраковка продуктов

Этот процесс носит циклический характер, жестких сроков здесь нет.

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

Как показывает кривая риск/издержки, приведенная выше, стадия «Обдумай» позволяет нам снизить риск продукта весьма рентабельным путем - мы просто разрабатываем прототип и экспериментируем. Это позволяет нам дешево и безопасно ошибаться, так что мы можем вести испытания, пока не выясним, каков тот самый правильный продукт, который мы собираемся разрабатывать.

Критерий завершения:

Стадия «Обдумай» заканчивается, когда команда и менеджмент приходят к общему пониманию того, что данный продукт стоит разработки (или же данный продукт никогда не станет достоин разработки и должен быть отбракован). Это субъективное решение, которое не поддерживается никакими вещественными данными. Эти вещественные данные задействуются на стадии «Доставь», поэтому мы хотим добраться до нее как можно скорее.

Build It

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

Цель стадии «Построй» - разработать MVP (минимально работоспособный продукт), который достаточно хорош, чтобы выпустить его для внешних пользователей, и также достаточно хорош, чтобы улучшить кое-что в самом продукте. MVP разрабатывается повторно при помощи методов гибкой разработки, таких как Скрам, Канбан, экстремальное программирование.

Фаза "Build It"

Здесь важно найти баланс, и это иллюстрируется шкалой "от бесполезного к совершенному".

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

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

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

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

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

Критерий Завершения:

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

Мы готовы к Моменту Истины!

Ship Ip

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

Фаза "Ship It"

Команда начинает с релиза для небольшого процента пользователей (обычно от 1-5%) для сбора данных. Как поведут себя эти пользователи в сравнении с остальными 95-99%?

Помните, мы на стадии «Think It» определили для продукта несколько гипотез. Сейчас мы сможем наконец-то проверить, насколько они правильны, при необходимости повторно улучшив продукт. Очень редко можно получить правильный продукт с первой попытки, и сила данной модели отчасти и в том, что нам не приходится этого делать.

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

Критерий Завершения:

Стадия «Ship It» завершается, когда продукт доступен всем пользователям. Помните, что этот продукт еще не "завершенное приложение". Завершения фазы «Ship It» означает, что продукт (MVP + необходимые усовершенствования) был выпущен на 100%. Такой вещи как "законченное приложение" не существует, поскольку продукт постоянно совершенствуется даже после этой стадии.

Tweak It

Это самая важная стадия, поскольку именно сюда попадают все продукты (если не отправляются в мусорную корзину по пути), именно в этом месте продукты проводят наибольшее время.

Фаза "Tweak It"

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

Хотя в определенной степени он уже проверил себя на стадии «Ship It», всегда остается довольно много пространства для улучшений. Отряд продолжает экспериментировать, проводить A/B тестирование и улучшать продукт, в то же время наблюдая за его показателями. Это может включать в себя важные новые приложения или же тонкие настройки.

Однажды в будущем отряд может достичь момента уменьшения обращений к продукту. Продукт великолепен, наиболее важные улучшения внесены, но соотношение цена/польза выглядит менее привлекательно. Если же взглянуть на показатели, окажется, что новые усовершенствования не приводят к большим переменам. Это означает, что продукт достиг "локального максимума".

Подстройка и локальный максимум продукта

В такой момент менеджмент и отряд обсуждают, довольны ли они этой горой, или стоит поискать вершину повыше? Если первое верно, команда может постепенно переключиться на новые продукты. Иначе, команда может вернуться к "Think It", чтобы переделать этот продукт и совершить прыжок к локальному максимуму (или более высокому пику).

Подстройка и переосмысление

Одним из примеров может служить сайт www.spotify.com. Этот сайт настраивался 4 года, пока летом 2012 мы не решили переделать его. Этот сайт передает главную идею Spotify совершенно иначе и куда более эффективным образом.

Обзор всего процесса

Весь процесс разработки продуктов Spotify

Заключение

Надеюсь, эта статья понравилась вам!

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

Эта модель вовсе не что-то новое и удивительное, это работающая штука, а новая она или старая, неважно.

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

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

Хенрик Книберг: henrik.kniberg@spotify.com
http://www.crisp.se/henrik.kniberg

Переведено с английского проектом Agile Translations.
Оригинальная статья: How Spotify Builds Products.

Ретроспектива спринта - эффективный формат

noreply@blogger.com (Anonymous) — Sat, 16 Feb 2013 16:38:00 +0200

Автор: Майк Кон (Mike Cohn)
Перевод с английского

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

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

Хотя существует множество способов организации Ретроспективы спринта, я рекомендую проводить ее в формате «старт-стоп-продолжить» (start-stop-continue) . Это, пожалуй, самый простой, но часто наиболее эффективный способ проведения ретроспектив. При таком подходе каждому участнику команды будет предложено определить конкретные вещи, которые команда должна:

Начать делать
Прекратить делать
Продолжать делать

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

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

Переведено с английского проектом Agile Translations.
Оригинальная статья: Sprint Retrospective.

Три статьи

noreply@blogger.com (Anonymous) — Fri, 15 Feb 2013 16:46:00 +0200

Автор: Алексей Кривицкий

Как многим уже известно, мы стартовали инициативу по переводу наиболее востребованных и популярных статей - проект Agile Translations.

Часть этой активности взяли на себя активисты сообщества AgileUkraine, а часть спонсирована SCRUMguides.

Переводы, опубликованные в феврале:

Планирование релиза: уходим от термина, но не от практики
Майк Кон

Общепринятые практики работы с Беклогом Продукта
Майк Кон

Менеджер 2.0: роль менеджера в Скраме
Пит Димер

Присоединяйтесь к нашей команде переводчиков. Мы используем Канбан и командный подход для выпуска переводов.

Планирование релиза: уходим от термина, но не от практики

noreply@blogger.com (Anonymous) — Tue, 5 Feb 2013 23:04:00 +0200

Автор: Майк Кон (Mike Cohn)
Перевод с английского.

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

В течение многих лет я учил команды делать именно так. Скажем, мы могли сказать, что “Мы уверены на 90%, что через шесть месяцев сможем выпустить продукт с функционалом в диапазоне между 150 и 200 стори поинтов.” Я до сих пор считаю эту практику полезной и каждый Скрам-мастер должен знать как это делается.

Что на самом деле потеряло смысл, так это сам термин “планирование релизов”.

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

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

Я вижу как усиливался этот тренд за последних несколькл лет. Я действительно понял, что мы достигли критической точки, когда этот термин вызвал непонимание на одном из моих классов. Я описывал “планирование релиза” как проекцию того, что мы делаем на протяжении нескольких спринтов. Кто-то в классе подумал, что “планирование релиза” значило ежедневное планирование того, что мы будем выпускать в конце дня.

Возможно, пришло время изъять фразу “планирование релиза” из словарей Скрам и гибкой разработки. Но поймите меня правильно. Иметь возможность планировать на 3, 6 и 12 месяцев вперед до сих является основополагающим понятием для многих команд и Скрам-мастеров. Но сам по себе термин уже неточен. Нам нужен новый термин.

За последние несколько лет я пробовал использовать несколько различных терминов на моих Сертификационных классах для Скрам-мастеров. Мне не хочется называть это “долгосрочным планированием”. Может быть в современном мире "бережливых стартапов" (пл англ. lean startup), три месяца и можно назвать “долгосрочным планированием”, но мне, все же, и это кажется неверным. Я считаю, что термин “среднесрочное планирование” могло бы иметь право на жизнь.

Итак, техники остаются, но термины уже пережили себя.

Переведено с английского проектом Agile Translations.
Оригинальная статья: Release Planning: Retiring the Term but not the Technique.

Общепринятые практики работы с Беклогом Продукта

noreply@blogger.com (Anonymous) — Sat, 2 Feb 2013 16:57:00 +0200

Автор: Майк Кон (Mike Cohn)
Перевод с английского.

Последнее время я задавался вопросом – не подходит ли Скрам к тому моменту, когда в нем появится еще один митинг – Backlog Grooming Meeting (дословно “встреча по уходу за беклогом”). Потому как подобные встречи проводятся каждый спринт всё большим и большим количеством команд, чтобы убедиться, что беклог будет готов к следующему спринту.

Для того, чтобы понять почему Backlog Grooming Meeting всего в нескольких годах от того, чтобы стать общепринятой практикой Скрам, давайте вспомним начало 2000-ых годов.

Читать дальше >>>

Менеджер 2.0: роль менеджера в Скраме

noreply@blogger.com (Anonymous) — Fri, 1 Feb 2013 17:00:00 +0200

Автор: Пит Димер (Pete Deemer)
Перевод с английского.

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

Скрам определяет только три роли: Владелец Продукта, Команда и Скрам-мастер, а главная инструкция для всех остальных в организации – «поддерживать их или убраться с дороги». Не слишком ясная формулировка, особенно если ваше начальство ожидает от вас, как старшего менеджера, что все складывается благополучно.

Читать дальше >>>

8-я конференция AgileBaseCamp: VALUE Driven Development, 2 февраля, Киев

noreply@blogger.com (Unknown) — Mon, 17 Dec 2012 15:32:00 +0200

В самом начале февраля пройдет зимний кемп по гибкой разработке. Последние 2 конференции были тематическими и мы продолжаем эту традицию.

Что на этот раз в фокусе программы?

Do right things. Do things right. Do them fast.

Три ключевых постулата гибкой разработки начинаются с ценности. Ясное видение “правильного” продукта является мощным драйвером командной работы, технологической изобретательности и эффективных процессов.

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

Три категории докладов: "Drive VALUE", "Drive TECH" и "Drive TEAM" покроют темы продуктовых техник, инженерных практик и командной работы.

Что нового в формате конференции?

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

Послеобеденный сон развеют бодрые короткие доклады в формате lightning talk, а вечернюю усталость как рукой снимет афтепати ;)

Когда регистрироваться?

Пока идет работа над программой (выступят Vasco Duarte, Алексей Кривицкий, Павел Габлиель, Наталья Тренина, Надежда Земскова, Артем Сердюк, Егор Назаркин, Дмитрий Миндра, Алексей Атемасов, Макс Климишин), самые ранние птички уже регистрируются!

Цены в 2013-м уже не будут такими низкими как в предновогодней суете :)

Получить билет по низкой цене>

Как следить за новостями?

Оставайтесь на связи в социальных сетях, приглашайте коллег и следите за обновлениями: