English Version

Антипаттерн: Agile против всего на свете

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

www.enter-agile.com


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

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

Анализ требований

Если не пытаться понять, что в действительности стоит за общей формулировкой фичи, которую записали на бумажке, то очень вероятно, что вам придется просто переделывать "имплементацию не того, что ожидалось". И тут стоит вспомнить, что в Водопаде и RUP управление требованиями - это отдельная дисциплина, в которую инвестируется много усилий. Итак, напомним себе, зачем нам нужен Agile с точки зрения требований: для того, чтобы доставить максимальную ценность пользователю максимально быстро. Переменной величиной, которой как раз нужно уметь правильно управлять, является объем работы (scope), так как он как раз и не равен конечной пользе. Иными словами, задача управления требованиями в Agile - минимизировать scope как можно ближе до уровня только полезной функциональности. Но это искусство и тяжелый труд, в котором дисциплина работы с требованиями стоит на первых позициях! Если этой дисциплины нет, а вся культура управления требованиями сведена к написанию карточек и последующей их произвольной интерпретацией, то тогда Agile ничем не лучше Водопада, где недостаток работы с требованиями состоит только в том, что они разрабатываются заранее и поэтому далеко не всегда соответствуют знаниям, приобретенным под конец разработки системы. Тогда Водопад даже лучше, потому что в данном отношении более предсказуем - нам хотя бы известно, в чем мы ошибаемся. Итак, вывод №1:

Управление требованиями в Agile требует огромной дисциплины, примеры которой следует позаимствовать в RUP или Waterfall.

Документация

Документация - это не часть управления требованиями (хотя пересечения существенны), поэтому я вынес ее в отдельный пункт. Отказ от документации, как от первородного зла, ведет к тому, что приобретенный ценный опыт и знания будут недоступны тогда, когда они нужны. Это документация к коду, требованиям, схеме дэплоймента... да вобще к чему угодно. Итак, в отношении документации мы должны помнить, почему мы предпочитаем Agile другим методам разработки - потому что Agile позволяет приобретать знания о системе значительно быстрее других методов разработки. Но если у команды нет культуры работы со знаниями, то это преимущество теряется. Итак, вывод №2:

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

Архитектура системы

Часто архитектура как сущность вобще отвергается, а привычные из RUP артефакты (представление 4+1, к примеру или его составляющие: use-case сценарии, диаграммы дэплоймента и т. п.) возводятся в ранг ругательств. Почему они не нужны? Да потому, что у нас среди гибких методов есть все на замену традиционным. Не верите - вот вам трюк на этот случай: система безопасно эволюционирует под действием двух факторов - постоянного рефакторинга и полного покрытия юнит-тестами... На самом деле обычно нет ни одного, ни другого. Эти два фактора действенны, но мало кто из команд, называющих себя гибкими, действительно умеют этим пользоваться. Наоборот, "технический долг" системе неумолимо накапливается и в конце концов приводит к горьким последствиям. Почему мы выбираем Agile с точки зрения архитектуры? Потому, что Agile дает возможность быстро строить новые системы и поддереживать в них изменения. Но если мы невнимательно относимся к архитектуре системы - ни то ни другое невозможно. Итак, вывод №3:

Разработка и поддержка архитектуры так же важна в Agile, как и в RUP или Waterfall. Несмотря на отличия в жизненном цикле архитектуры, дисциплину и отдельные методы следует заимствовать у традиционных методов.

Подведем итог

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

Основы пользовательских историй. Часть 1. Введение.

Этим постом я начинаю серию публикаций, посвященных отдельным частям книги “Гибкие требования: бережливые практики управления требованиями для команд, программ и предприятий”, автор которой, Дин Леффингуэл любезно предоставил право на перевод и публикацию для русскоязычных читателей. Дин неоднократно приезжал в Украину и Россию, в это время (2006-2008) я управлял разработкой в компании под его началом. По этой причине я прекрасно знаю, как работают описываемые им методы на практике и ту практическую пользу, которую они приносят. Приятного прочтения!..

Основы пользовательских историй


Дин Леффингуэл (Dean Leffingwell), Пит Беренс (Pete Behrence)

Автор перевода: Александр Якима (www.enter-agile.com)

Аннотация:
В этой статье мы предлагаем обзор происхождения и приложений пользовательских историй, являющихся ключевым механизмом в гибких методах разработки и служащих проводником требований заказчика сквозь поток ценностей. В свою очередь, пользовательские истории являются критическим элементом в статьях “Бережливая и масштабируемая информационная модель требований для гибких компаний” и “Общая картина гибкости компании”, обе статьи можно найти в блоге http://scalingsoftwareagility.wordpress.com/. Текущая же статья извлечена из будущей книги “Гибкие требования: бережливые практики управления требованиями для команд, программ и предприятий”, издание которой запланировано на 2010 год. Отдельная благодарность Дженнифер Фосетт (Jennifer Fawcett) и Дону Видригу (Don Widrig) за их вклад в работу над книгой.

О терминологии (примечания автора перевода):
Центральным объектом статьи, как читатель уже мог догадаться, является пользовательская история, в оригинале звучащая как user story. Существует несколько различных, в том числе и довольно экстравагантных переводов этого термина (напр., “пожелание”). Однако при переводе я решил пользоваться исключительно практическими мотивами, именно поэтому мы используем термин “пользовательская история” в несколько официальном ключе и для непосредственных выкладок - “стори”. Дело в том, что именно этот термин преобладает в быту большинства гибких команд при работе с англоязычными заказчиками и поэтому вполне оправдан.


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

- паж Моль к Костарду, “Напрасный труд любви”, Уильям Шекспир

Введение

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

Стори служит также метафорой всему нашему подходу, базирующемуся на инкрементальной доставке ценностей, а именно:

Определить полезную стори – реализовать и оттестировать в рамках короткой итерации – продемонстрировать и/или доставить ее пользователю – получить фидбек - усвоить информацию – повторить в цикле!

Я уже вкратце приводил обсуждение пользовательских историй в контексте моих более широких статей: “Бережливая и масштабируемая информационная модель требований для гибких компаний” и “Общая картина гибкости компании”[1], в которых наряду с темами, эпосами и фичами, стори являются первостепенными артефактами требований, используемых гибкими командами.

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

Пользовательские истории: обзор

В вышеупомянутых статьях и связанных с ними публикациях в блоге я подчеркивал существенность вклада Скрам-модели в гибкие практики для компаний, отмечая, к примеру, само определение роли продакт оунера (product owner), являющейся неотьемлимой по отношению к работе с требованиями. Но самим изобретением пользовательской истории мы обязаны XP и именно сторонники XP и разработали всю широту и глубину этого артефикта. Хотя это значительно менее значимое “методологическое распутье”, чем это может показаться, так как пользовательские истории сейчас обычно входят в рамки Скрам-курсов как средство построения бэклога и определения состава Спринта. Наверняка мы должны благодарить Майка Кона (Mike Cohn) за большую часть этой интеграции, так как он обстоятельно проработал пользовательские истории в своей книге User Stories Applied [см. Cohn 2004], и был очень активным в сообществе Scrum Alliance.

Для наших целей мы определим пользовательскую историю так:

Пользовательская история – это короткая формулировка намерения, описывающая что-то, что система должна делать для пользователя.

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

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

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

Примеры:


- Залогиниться в мой портал мониторинга энергопотребления
- Посмотреть ежедневный уровень потребления
- Проверить мой текущий тариф



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

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

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

Билл Вейк (Bill Wake), один из создателей XP, описывает это следующим образом[2]:

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

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


Пользовательские истории – это не требования

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

• Они не являются детальным описанием требований (то-есть того, что система должна бы делать), а представляют собой скорее обсуждаемое представление намерения (нужно сделать что-то вроде этого)
• Они являются короткими и легко читаемыми, понятными разработчикам, стейкхолдерам и пользователям
• Они представляют собой небольшие инкременты ценной функциональности, которая может быть реализована в рамках нескольких дней или недель
• Они относительно легко поддаются эстимированию, таким образом, усилия, необходимые для реализации, могут быть быстро определены
• Они не занимают огромных, громоздких документов, а скорее организованы в списки, которые легче упорядочить и переупорядочить по ходу поступления новой информации
• Они не детализированы в самом начале проекта, а уже более детально разрабатываются “точно в срок”, избегая таким образом слишком ранней определенности, задержек в разработке, нагромождения требований и чрезмерно ограниченной формулировки решения
• Они требуют минимум или вовсе не требуют сопровождения и могут быть безопасно отменены после имплементации[3]

---------------------------------------

1. www.scalingsoftwareagility.wordpress.com



2. http://xp123.com/xplor/xp0308/index.shtml



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


---------------------------------------

[Cohn 2004] Cohn, Mike. 2004. User Stories Applied: For Agile Software Development. Boston, MA: Addison-Wesley.

Тренинг: Управление требованиями в Agile

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

www.enter-agile.com


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

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

На этом тренинге вы:
  • Получите полноценное представление о жизненном цикле требований в Agile
  • Научитесь правильно подготавливать и сопровождать "пользовательские истории"
  • Научитесь правильно применять INVEST-модель при построении "историй"
  • На практике освоите работу с Карточками, Диалогами и Подтверждениями
  • Освоите искусство правильной грануляции требований
  • Увидите требования как средство эффективного общения с заказчиком и обретения доверия
  • Ознакомитесь с таким важным средством динамического управления требованиями как Спайк
  • Научитесь управлять требованиями в рамках релиза и итерации
  • Получите цельное представление об оптимальной роли и сотрудничестве разработчиков, тестировщиков, бизнес-аналитиков в команде
Тренинг предназначен для разработчиков, тестировщиков, менеджеров проектов, бизнес-аналитиков, архитекторов.

Продолжительность: 6 часов. Тренинг состоит из теоретической и практической частей.

Максимальный объем аудитории: 15 человек.

Тестирование в гибких методах - доклад с конференции Test-Labs

Автор: Александр Якима (www.enter-agile.com)

Участие в качестве докладчика на конференции Test-Labs было кое в чем еще интересней, чем PM-Labs. Очень приятно видеть в одном месте столько людей, посвятивших себя борьбе за качество.

View more presentations from alexyakima.

Как мотивировать команду сделать невозможное - доклад с конфереции PM-Labs

Автор: Александр Якима (www.enter-agile.com)

Представляю вашему вниманию презентацию моего доклада на прошедшей конференции PM-Labs.

View more presentations from alexyakima.

Правильный фокус - заказчик

Автор: Александр Якима (www.enter-agile.com)

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

В чем суть этой проблемы? Мы не будем сейчас говорить о причинах, номинально
выходящих за рамки влияния команды разработчиков, тем не менее, могущих привести к
потере заказчика (резко поднятые рейты1, упразднение определенных пунктов в контракте, низкий темп стаффинга2 и т.д). Мы поговорим об ошибках команды, которые приводят к проблеме и, что хуже всего, незаметны для самой команды.

Итак, основная суть:

Один и тот же софтверный продукт имеет две основные проекции: 1) заказчика и 2)
команды разработчиков. Итак, если мы производим цилиндрический вал:


заказчик может видеть его так:



а мы - так:


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

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

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

2. Отслеживание и своевременное "закрытие" всех без исключения открытых вопросов от
заказчика крайне важно. Ни один пункт не может тихо раствориться в инбоксе или
исчезнуть в избирательной памяти сразу после общения с заказчиком по телефону.

3. Команда не разрабатывает ПО, а кладет деньги на два банковских счета. Один из них -
текущий, краткосрочный. Команда кладет туда деньги, если успешно сдает итерацию, релиз, проводит успешное привью и т д. И, соответственно, снимает деньги с него, если
проваливает итерацию, или релиз. Вкратце, баланс на этом счету отражает текущее
положение дел в отношениях команда-заказчик. Другой счет - долгосрочный. Он отражает общую картину впечатления заказчика о команде, репутацию команды. Команда кладет сюда деньги, когда, например, демонстрирует глубокие знания в бизнес-области проекта, какие-то изначально необязательные, но сейчас очень интересные заказчику скилы, когда находит правильный эмоциональный тон, приносящий обоюдное удовлетворение от общения и т д. По сути, первый (текущий) счет дает возможность заказчику ответить на вопрос, "выполняет ли команда свои текущие обязательства?", второй (долгосрочный) ассоциируется для заказчика с вопросом: "почему мы сотрудничаем именно с этой конкретной командой?". Счета - это всего лишь удобная метафора, позволяющая легко представлять себе прямые последствия действий команды. Провалили итерацию: минус $100 с текущего счета. Задали глупый вопрос на демо, свидетельствующий о некомпетентности - сняли $300 с долгосрочного счета. Сдали успешно релиз: + $800 на текущий. Предложили новую фичу, которая пришлась по душе продуктовой команде - положили автоматически + $1K на долгосрочный. Кто-то из команды преуспел в изучении английского и недавно приятно удивил заказчика эффектной идиомой - плюс $250 на тот же счет. Опять таки, все это относительные цифры и важно только то, чтобы команда обрела интуитивное чувство того, как их каждое действие воспринимается заказчиком.

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

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

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

Как все сказанное выше соотносится с гибкими методами разработки? Не ставят ли эти
принципы Agile на задний план?

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

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

Agile: иллюзии и реальность

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

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

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

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

2. Бизнес и Инжиниринг работают как одно целое. Это случается очень редко. Часто между Бизнесом и Разработчиками царит непонимание, недоверие, дефенсивность. Опять-таки, "одно целое" следует понимать как иллюзию. Но, как и в предыдущем случае, имеет огромный смысл к этому идеалу приблизиться. Это с позиции Инжиниринга возможно, если:
- Если у команды нет видения, то она добивается его у Бизнеса. Часто Бизнес сам страдает близорукостью и не может или не считает нужным четко определять, к каким глобальным целям двигаться. Тогда Инжиниринг не просто требует видения, но принимает участие в его формировании, предлагая к рассмотрению не только вопросы, но и решения.
- Инжиниринг исходит из того, что существует только Win-Win исход для них и Бизнеса. Даже когда Бизнес, по мнению разработчиков, ведет себя похабно, поведение команды стабильно конструктивное.
- Инжиниринг делает все, чтобы идеи Бизнеса сработали в разрабатываемом продукте/сервисе и из этого постепенно зарождается доверие между Бизнесом и командой по Разработке.

3. Приветствуются любые изменения требований, в частности самые поздние. Вот это "самые поздние" - неприятный и опасный момент. Правильное понимание этого принципа покоится в одном склепе с видением различия между исходом итерации и релиза. Да, действительно, при гибкой разработке команда способна делать частые релизы с продакшн-качеством. Также правильно и то, что каждая итерация заканчивается рабочим билдом продукта, а не спецификациями, дизайном или еще чем-то. Но "рабочий билд" и "релиз-версия" - это разные вещи. Вкратце, отличает их качество. Для того, чтобы последний релиз-кандидат стал полноценной релиз-версией, необходимо время на стабилизацию. К примеру, вся однонедельная итерация посвящена стабилизации версии - фиксание багов, дополнительное ручное тестирование, финальное тестирование конфигураций и деплоймента и т д. Если времени на это не будет, то на выходе получится просто "рабочий билд" и ваши пользователи найдут много дефектов вместо вас. Правильное понимание принципа таково - изменение требований является необходимой реальностью, при которой обе стороны (Бизнес и Разработка) имеют возможность вносить изменения на протяжении всего релиза, кроме периода стабилизации (последние 10%-15% графика релиза). Речь идет не только о серьезных изменениях логики системы - жизнь изобилует примерами, когда за несколько дней до релиза Бизнес присылает 50-70 безобидных изменений (там текст поменять, там выравнивание переорганизовать и т.д.) и полностью съедает время на стабилизацию.


Примеры и обсуждение:

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

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

- Много воды утекло с того момента, когда я познакомился с Дином Леффингуэлом и начал работать на его проекте. Он решил поэкспериментировать с однонедельными итерациями, поскольку видел в этом потенциальные плюсы. Подход оказался удивительно эффективным. Много точек для принятия решений, изменения тактических целей и т д. Но в отношении развития команды - просто супер! Каждую неделю (в случае успеха) команда выкатывает функционирующий билд с новым функционалом. Каждую неделю - маленькая победа, достигнутая вместе. Через определенное количество итераций это входит в привычку. Кстати, на основных проектных задачах ограничиваться не стоит - можно играть в футбол, Unreal Tournament - вообще что угодно. Важно только чувствовать как все вместе добиваются результата.

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

Подведем итог.

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

Трудность масштабирования Agile

Перевод Части 8 из книги Дина Лэффингуела (Dean Leffingwell) "Scaling Software Agility. Best practices for Large Enterprises".

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


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

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

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

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

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

Явные ограничения в самом методе

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

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

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

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

Небольшой размер команды

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

Заказчик как неотъемлемая часть команды

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

Коллокация

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

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

Архитектура появляется сама

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

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

Недостаточный объем требований и задокументированной спецификации

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

Культура и физическая среда

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

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

Ограничения компании

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

Организации управлений процессами и проектами

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

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

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

Существующие формализованные политики и процедуры

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

Корпоративная культура

Компании со временем возделывают устойчивую культуру, определенные моменты в которой могут не быть выгодными для agile. Например, как мы уже ранее заметили, один вид среды гибкой разработки может показаться несоответствующим. Вдобавок, если преданность компании измеряется количеством отработанных часов, а не эффективностью, гибкая команда не будет чувствовать себя достаточно мотивированной, адекватно оцененной и вознагражденной. Поскольку agile интенсивен в тактическом плане, а также в силу ежедневной и еженедельной сфокусированности и фактической отчетности, 40-часовая рабочая неделя оказывается единственным выходом, так как именно там лежит максимальная продуктивность. (Принцип из Манифеста гибкой разработки: "Гибкие процессы способствуют устойчивой разработке") Если требуется сверх этого - гибкая разработка не будет верным выбором.

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

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

Фиксированный график, фиксированная функциональность

Если к команде снисходит поручение доставить функциональность X за период времени Y имея в распоряжении ресурсы Z, то это уже по определению не удовлетворяет сакральным правилам agile, состоящим в фиксированном времени, но нефиксированном объеме функциональности. И потому гибкие команды окажутся обескураженными уже в самом начале проекта . Этот способ управления является все-таки обычным в индустрии, и его еще придется в будущем преодолеть. Действительно, командам присуще желание иметь способность в точности предсказывать, когда и какую функциональность они смогут доставить, но они осознают, что это просто невозможно и для них представляется откровенно глупым, когда менеджмент просто требует: "Сделайте, чтоб было именно так".

Трения между командой разработчиков и прокси заказчика

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

Для команды же разработчиков кажется очевидным, что их внешние стейкхолдеры "просто не понимают, что это исследование и разработка, а не просто разработка". Нельзя определенно сказать кто из них прав, а кто нет, но однозначно в agile им придется работать в непосредственной близости. (Принцип из Манифеста гибкой разработки: "Люди бизнеса и разработчики должны совместно работать каждый день на протяжении всего проекта".) Им необходимо научиться доверять навыкам и посильному вкладу друг друга. Установить такой уровень доверия - задача не простая, но результат себя окупает и служит сильным стимулом для всех вовлеченных сторон.

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

Высокая степень распределенности

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

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


Итоги

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

Как найти подходящих людей для Agile

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

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

The best architectures, requirements, and designs
emerge from self-organizing teams.
From The Agile Manifesto


Правильные люди

Перед тем, как начать подыскивать человека в Agile команду, следует четко представлять себе, что мы ожидаем от этого человека. На самом деле, важно понимать, что подбор персонала — это шахматная партия, в которой текущий ход зависит от предыдущих, равно как и определяет в огромной мере последующие. Естественно, команда юниоров не превратится в гибкую команду — не стоит пробовать, Agile —это прежде всего реализм. Но это не означает, что гибкая команда состоит из 100% старших разработчиков, тестеров и т.д. Итак, перечислим основные необходимые качества для человека в гибкой команде:
  • Ответственность
Человек, не способный свято следовать командному commitment'у будет серьезной проблемой для команды.
  • Коммуникабельность
Общение — центральная ценность в agile. Человек должен иметь желание делиться знаниями и ни в коем случае не испытывать проблем узнать что-то у кого-то. Это повседневная реальность гибкой команды. Также не должно быть проблем с языком заказчика, так как коммитмент каждый член команды несет напрямую перед заказчиком.
  • Решительность
Принимать решения в гибкой команде приходится каждому ее члену. Члены команды должны иметь достаточно полномочий, чтобы реализовать свой коммитмент. Но, очевидно, они должны быть к этому готовы. Также, член команды должен обладать достаточным мужеством, чтобы в случае объективной необходимости удалить свой код, написанный за целый день, отказаться от разработанной архитектуры и т д. Рефакторинг, иначе говоря, требует не только мастерства, но и психологической готовности.
  • Гибкость
Умение переключаться с одной задачи на ту же, но с качественно иной формулировкой, требованиями и ожиданиями очень важна.
  • Мотивированность
Успешный продукт удастся разработать быстро и эффективно только команде мотивированных людей. Подспорье для мотивации у разных людей разное, но мотивация должна присутствовать. Не стоит брать в гибкую команду низко мотивированного человека в надежде в последствии развить в нем мотивацию практически с нуля.
  • Практичность
Человек даже глубоко понимающий технологии, способный уверенно двигаться вперед, наращивая невероятно сложную функциональность, но не способный посмотреть на систему с точки зрения пользователя, мыслить в терминах выгоды и удобства для конечного пользователя, а также безразличный к качеству будет в большой степени бесполезен в команде.
  • Логика
Нужно уметь не просто принимать решения. Они в большинстве своем должны быть разумными.
  • Технологии
Знание большинства (но не обязательно всех) технологий, необходимых на проекте, является необходимым).

Как эффективно проводить интервью

Мы рассмотрим весьма простую и эффективную практику проведения интервью. Интервью состоит из двух основных частей:

Телескрин

Простой телефонный разговор продолжительностью 15-25 минут. Цель телескрина весьма тривиальна: получить первое представление о человеке по всем основным областям — как следствие либо назначить очное интервью или отказаться от проведения очного, если сразу видно, что кандидат не подходит под вакансию. На типичный вопрос: «не является ли телескрин пустой тратой времени?», я привожу нередкостный в практике пример:
Телескрин. Мы ищем старшего C++ разработчика на проект. На вопрос, «кем вы видите себя на проекте ?» следует уверенный ответ: «менеджером проекта, конечно!».
Итак, мы потратили 5 минут, пожелали кандидату удачи в трудоустройстве и вернулись к текущей работе. Но ни кандидат, ни мы не потратили 1-2 часа своего времени на очное интервью, транспорт и т д. Приведем пример вопросов на телескрине. В первую очередь обязательно расскажите кандидату о вашем проекте и скажите, что это Agile проект. Это важно. Практика показывает, что не все чувствуют себя комфортно (или вообще видят себя) на проекте, где полноценная версия демонстрируется заказчику каждую неделю или, скажем, каждые две.

Итак, вопросы:
  1. Роль на нашем проекте? Почему считаете, что сможете успешно подойти и реализовать себя в этой роли? (О желаемой роли мы именно спрашиваем, а не утверждаем ее. Очень желательно, хотя и не всегда возможно, чтоб человек попал именно на ту роль, на которую претендует. Если он, конечно, вас заинтересовал. Если чувствуете незаинтересованность в вашем проекте — задайте вопрос напрямую. Если проект, либо стиль разработки не интересен — не тратьте свое время и время кандидата даром, пожелайте друг другу успеха и попрощайтесь).
  2. Почему ищете новую работу?
  3. Наиболее интересный проект, в котором вы участвовали? Почему интересен? Ваша роль?
  4. Масштабы предыдущих проектов, методологии и подходы, проблемы и решения? (Ни в коем случае не делайте плохих выводов из того, что кандидат не практиковал или не знает, что такое Agile. Если у человека гибкий ум, полнценное «вертикальное» мышление, сфокусированность на существенном — этот человек вам подходит. Больше требовать не нужно).
  5. Юнит тестирование, рефакторинг? Опыт?
  6. Технические вопросы. Имеет смысл привлекать 1-2-ух людей из команды для успешного и быстрого кросс-интервью по технологиям.
  7. English. В какой-то момент интервью, после ответа кандидата попросите его сказать то же самое (1-2 предложения) на английском. Очень помогает.
  8. Ожидания от новой работы?
Несколько советов
  1. Во время интервью не задаем наводящих вопросов. Это просто трата времени. Плюс, во время телескрина, не следует таким способом излишне располагать к себе кандидата. Обе стороны должны быть хорошо сфокусированы на главном — получении наиболее адкеватного первого представления друг о друге.
  2. Проводите телескрин в первой половине дня. По крайней мере старайтесь. Причина проста: уставший кандидат + уставшие интервьюверы — низкая адекватность телескрина как результат.
  3. Держим хороший темп. Если нет ответа на текущий вопрос некоторое время — пропускаем и движемся дальше.
  4. «Каждый вопрос интервью – первый». Под этим мы понимаем, что перед каждым вопросом мы стараемся забыть о текущем впечатлении о кандидате. К сожалению, впечатление имеет свойство накапливаться. На самом же деле плохой или хороший ответ на вопрос «каков порядок сложности алгоритма поиска по хэш-таблице?» не должен влиять на впечатление от ответа на следующий по счету вопрос: «какова цель юнит-тестирования?».
  5. Во время проведения скрина, интервьюверы не обмениваются мнениями, удивленными взглядами и т д.
  6. Не все интервьюеры должны читать резюме. Если резюме содержит фото — тот, кто его первый увидел, предупреждает и никто больше (!) фото не смотрит. В большинстве случаев резюме портит представление о человеке, часто — неадекватно. В 99% случаев фото работает также против кандидата. Но ни то ни другое не имеет ничего общего с тем, насколько успешным будет человек на проекте.
После окончания собеседования интервьюверы просто говорят друг другу — приглашать на очное собеседовние или нет. Очень желательно обмениваться аргументами после того, как каждый сказал свое мнение. Если мнения в пользу кандидата или даже неоднозначно разделились — следует приглашать.

Очное интервью

Принимать на работу человека без проведения очного интервью очень рисковано. Очное интервью должно показать, на что человек способен. Если вы принимаете на работу разработчика — вы обязаны (!) попробовать его в деле — дать ему возможность покодировать. Как это можно делать:
  1. Начните с довольно простой задачи. Важно: реалистичной задачи! Не ограничивайте слишком возможные решения, формулируйте только основную суть задачи — дайте кандидату возможность проявить изобретательность.
  2. После реализации текущей задачи добавьте новые требования и/или измените старые. Итак — все время по ходу сессии кодирования.
  3. Просите написать юнит тесты. Если даже нет под рукой подходящего UT-фреймворка, с которым ваш кандидат знаком, – попросите просто их написать и ограничьтесь ривью. Главное – как человек покрывает код тестами. Важно его отношение к качеству кода.
  4. После сессии кодирования, попросите человека открыть notepad и написать текст письма виртуальному заказчику, где нужно описать, что написанный им сниппет делает и для чего. Так вы проверите не только письменный английский.
После этого поговорите с человеком о том, что вы ожидали бы от него на новой должности. Попросите рассказать, чего ожидает он и как представляет себе свою роль и обязанности в новой среде. Также пообшайтесь немного о чем-то, не имеющем отношения к работе. Вам нужен не робот, а нормальный человек. Никогда не принимайте решения в присутствии кандидата. Принимайте его, когда и вы и остальные интервьюверы вышли из контекста собеседования, тогда впечатления уступают место здравому смыслу.

Дополнительно
Bill Wood (VP Software Engineering, Ping Identity), более чем успешно практикующий Agile, советует перед тем, как приглашать человека на интервью, дать ему домашнее задание – выше среднего уровня. Это покажет, хочет ли действительно человек работать на вашем проекте.
Никогда полностью не делегируйте интервью кому-то извне команды. Если даже вы не знаете технологий, у вас в команде также нет специалистов в этой области – старайтесь присутствовать на техническом интервью, если оно даже проводится внешним тех-интервьювером. Обязательно плотно сами пообщайтесь с кандидатом.
И, наконец, подчеркнем, что вам нужен не кодер, а именно полноценный участник процесса гибкой разработки, ответственный не за написание кода, а за успех проекта.

Разработка через интеграцию

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

В статье мы рассмотрим основные принципы и техники Integration Driven Development (IDD), апеллируя к реальным примерам разработки на Agile проекте.

Под Integration Driven мы будем понимать разработку, в основе которой лежит быстрая разработка мокапов основных модулей, их моментальная интеграция и постепенное наращивание функциональности вплоть до полной реализации системы. При этом предполагается изменение интерфейсов между модулями, содержания модулей, исчезновение или появление новых модулей в системе.
Итак, как это работает? Приведем типичный workflow:


В продолжении статьи мы будем обращаться к примеру IDD-разработки на основе реального проекта - кластерной системы с интенсивной обработкой данных. Мы рассмотрим этап перехода на новую архитектуру как пример эффективного применения IDD.

Up-front design vs. Emerging design.

Не бывает в разработке информационных систем возможности предусмотрения всех существенных рисков. Принимая это во внимание, возникают сомнения, что big up-front дизайн (будучи неотъемлемым атрибутом водопадной модели) является эффективным. Но и на 100% emerging design вряд ли приведет к оптимальному результату. Если сравнивать две этих парадигмы с ежедневным походом на работу, то получается что-то следующее:

Up-front. Встаю утром, выхожу на балкон. Вдали виднеется здание моего офиса. Запоминаю путь к нему и вперед! Все время в течение пути неуверенно осматриваюсь и, сравнивая реальность с перспективой из балкона, задаю себе вопрос - "где я?".
Emerging. Просыпаюсь. Квартира без балкона - он мне не нужен! Выхожу из подъезда, закрываю глаза и начинаю на ощупь двигаться, каждые пять минут переспрашивая прохожих, далеко ли еще до Голосеевской, 7?

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


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

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

Спонтанное парное программирование

Дальнейшее уточнение интерфейсов происходит по парам и по времени совпадает с началом разработки мокапов. Каждый член команды комитится на определенный модуль или модули. И, собственно, если модули A и B имеют общий интерфейс, то люди, ответственные за эти модули, работают в паре. Это не означает, что имеет место парное программирование. Это на самом деле есть спонтанное парное программирование, целью которого является:
  • Совместное обсуждение интерфейсов
  • Обмен знаниями об архитектуре системы
  • Совместная отладка / решение текущих проблем реализации
Такое спонтанное парное программирование предполагает приблизительно 10%-15% рабочего времени, проведенного в парах. Спонтанным мы его называем поскольку люди работают в парах по мере надобности - спонтанно. Поскольку обычно модуль имеет интерфейсы к более, чем одному модулю, то пары перегруппировываются сами по себе. Это поможет каждому разработчику в команде владеть пониманием всей архитектуры.
Ротация

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

Изменения интерфейсов

Как мы уже отмечали, IDD не есть big up-front design. Поэтому, в IDD мы заведомо предполагаем эволюцию интерфейсов в процессе разработки. Что, тем не менее, не мешает их планированию в рамках разумного и, по-этому, отличает IDD от парадигмы "emerging design". Приведем основные причины и условия изменения интерфейсов:

Новая user story. Это нормально для Agile. Не просто нормально, но и в некоторой мере необходимо. Изменение scop'а поддерживает и команду и код в форме.

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

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

Все эти изменения интерфейсов приводят к качественным изменениям архитектуры или качественным инкрементам, если угодно. Мы называем их срезами (cuts).

Запланированная эволюция

В нашем подходе мы рассматриваем два аспекта плана реализации архитектуры - кратко- и долгосрочный. Краткосрочный - это видение на одну-две итерации вперед. Это - "вид до следующего поворота". Это цель, достижение которой не будет требовать существенного рефакторинга в процессе краткосрочной реализации, так как является вполне обозримой. Долгосрочный - это "весь путь до самого офиса". Долгосрочный план дизайна - это "размытый" план. Он предполагает достижение некоторых high-level целей, но не определяет архитектуру в деталях, в отличие от краткосрочного плана. Важно отметить, что определение дизайна архитектуры (кратко- или долгосрочное) не подразумевает каких либо CASE-артефактов и т.д. На самом деле это все прекрасно осуществимо с помощью свободных рисунков на whiteboard'ах, например.
Долгосрочный план предполагает рефакторинг двух видов:
  • Непредусмотренный. Мы рассмотрели его выше.
  • Запланированный. Мы предполагаем на высоком уровне, как система должна эволюционировать и также предполагаем, что на некоторых этапах будет необходим рефакторинг, цель которого - переход на качественно новый уровень архитектуры.

Рассмотрим примеры кратко- и долгосрочного планирования. В нашем примере краткосрочным планом был план архитектуры на итерации 1 и 2. Итерация 1 - определение модулей и интерфейсов, 2 - наполнение модулей функциональностью с целью реализации части функций системы. Тех функций, которые позволят выявить на раннем этапе большую часть рисков и получить по большему счету функционирующую систему. Текущий (краткосрочный) план предполагал односерверную архитектуру. Долгосрочная архитектура - кластерная система. Таким образом, у нас два вида рефакторинга: непредусмотренный (ошибки в интерфейсах и т.д.) и запланированный (изначально система разрабатывается для одного сервера, соответственно, модули - обычные C++ libraries; в 3-ей и 4-ой итерациях происходит рефакторинг, целью которого является превратить C++ libs в сетевые сервисы с соответствующими политиками конкурентного доступа и т.д. ).
Краткосрочный план создается на начале каждой итерации. И, естественно, построение очередного краткосрочного плана может внести изменения в долгосрочный план.

Преимущества подхода

Одно из наиболее важных преимуществ IDD - скорость разработки. Достигается в силу того, что мы не ждем, пока дизайн архитектуры "появится сам". Насколько єто нам позволяет наше "зрение", мы пытаемся предусмотреть. Опять же, не более, чем это разумно. Быстрая валидация архитектуры через интеграцию (начинающуюся с интеграции мокапов) минимизирует ошибки архитектурного характера.
Другое преимущество - подход сработает в случаях, где и up-front, и emerging дизайн окажутся с большой вероятностью бессильными. Это, прежде всего, системы, где performance очень принципиален и является ключевым требованием к системе.

В нашем случае performance - основной фокус системы; высокоуровневой целью системы есть быстрая обработка документов суммарным объемом 3-5 TB. IDD себя полностью оправдал. Без краткосрочного и долгосрочного планирования дизайна, как это было показано выше, реализовать систему вряд ли удалось бы.
В конце отметим, что IDD прекрасно живет в рамках Scrum или близких к нему средах. Поскольку IDD является только подходом к планированию и реализации архитектуры продукта, то он не накладывает существенных ограничений на техники самого программирования.

Agile для команд: быстрый старт

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

Содержание курса

Продолжительность курса составляет 16 часов.

Курс покрывает следующий объем вопросов:

• Представление о гибкой разработке
• Работа в итерационном режиме
• Бэклог продукта
• Роли в Scrum и их дополнение
• Пользовательские истории, эпосы
• Оценка
• Деление пользовательских историй и эпосов
• Определение приемочного критерия и основы Специфицирования Примером
• Планирование итерации
• Define-Build-Test практика
• Понятие о гибких инженерных практиках и инкрементальной архитектуре
• Демо итерации, PBR, воркшопы по специфицированию
• Непрерывное совершенствование, ретроспективы
• Самоорганизация, дисфункции в команде
• Работа в Agile-релизе
• Основы эстимирования больших задач
• Эффективные коммуникации и разработка в распределенной среде
• Основы проксирования Продакт-Оунера

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

Аудитория и оборудование

Аудитория: до 25 человек
Тренинг проводится на площадке компании-клента. Для эффективного проведения тренинга необходимо отдельное помещение, столы (4-6 человек за одним столом), проектор, доска или флип-чарт для тренеров, флип-чарты или большие листы (на 1 стол), стикеры и маркеры в достаточном количестве.

По поводу проведения тренинга или за дополнительной информацией обращайтесь на alex[at]yakyma.com


Посмотреть другие тренинги
Newer Posts Older Posts Home
Powered by Blogger