Подходы Agile Software Development, за последние пять-семь заслужили доверие, и нашли популярность во всем мире. С вами поделятся своим опытом гибкой разработки более сорока докладчиков, из таких стран как: США, Канада, Бельгия, Польша, Словакия, Чехия, Финляндия, Эстония и, конечно же, - Украина, Россия, Беларусь.

На сегодняшний день, Аджайл - это не только мейнстрим в мире управления проектами. Де-факто, это стандарт успешных проектов во многих компаниях. Докладчики представляют опыт таких звезд мировой индустрии, как Toyota, Nokia, 3M и др.

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

Ютта Екштайн (Jutta Eckstein), автор книги Agile Software Development in the Large поделится своим опытом построения эффективных моделей распределенной разработки с элементами Agile.

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

На Agileee в числе ключевых докладчиков вы сможете послушать, поучиться и пообщаться с Мери Поппендик (Mary Poppendieck) - автором серии книг по Lean тематике, среди которых бестселлер: Implementing Lean Software Development: From Concept to Cash.

В числе докладчиков два сертифицированных Скрам-тренера (CST): Робин Даймонд (Robin Dymond) и Борис Глогер (Boris Gloger).

И много-много-много других прекрасных людей и сверхинтересных докладов.

Этот яркий профессиональный праздник пройдет в Киеве. И у вас есть шанс стать его частью на два полных дня!

Официальный сайт конференции - agileee.org

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

Похоже, то самое начинается с аджайлом. Мы недавно запускали новый проект. Проект со старта имеет довольно развесистую структуру. Представить графически эту развесистую структуру – довольно сложно. Однако для релиз плэннинга надо не только структуру представить, но и рамки очертить. Мы использовали для этого UML и Sparx Enterprise Architect. UML потому что юзкейс-диаграммы все с грехом пополам читают, Sparx – потому что удобно рисовать и все отрисованные юзкейсы можно поддерживать в синхронизации с Visual Studio Team System 2008, который используется на проекте. Соответственно затем пользуясь интеграцией Team System + Microsoft Office делаем релиз плэннинг – хоть в Excel, хоть в Project.

Подход исключительно прост, польза для проекта очевидна, удобство для команды знакомой с UML и Sparx – тоже очевидно. Рассказал про это камрадам в Питере. Что тут было! ЕСЛИ ВЫ ИСПОЛЬЗУЕТЕ UML, ЗНАЧИТ У ВАС НЕ АДЖАЙЛ! ИБО В АДЖАЙЛЕ СКАЗАНО – НИКАКОЙ ДОКУМЕНТАЦИИ! Дорогие камрады, это распространенное заблуждение. На самом деле:

1. Если посмотреть множество диаграмм с примерами, хотя бы из книжек Бека или специальных изданий, то становится ясно – диаграммы вообще и UML-диаграммы в частности как визуальное средство коммуникаций очень ценились отцами-основателями.
2. Аджайл не требует отсутствия документации. Если бы требовал – фотографии доски тоже были под запретом, потому что это хоть и кривая, но тоже документация. Аджайл требует минимальной и достаточной документации – и UML-диаграммы (при условии что у вас их все умеют читать) отлично эту задачу решают.

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

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

Обеспечивает ли следованию процессу качество? Возможно, если процесс ориентирован на качество и имеет средства для его поддержания. И на проекте «правильные» люди.

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

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

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

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

• Требования
• Создание
• Предупреждение проблем в будущем

Требования

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

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

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

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

Создание

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

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

Для этого команда может использовать:

• Архитектуру
• Definition of done
• Peer code review
• Рефакторинг
• Тестирование (unit, integration, ручное, производительности и т.д.)

Архитектура

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

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

Definition of done

В Scrum есть хорошая концепция “done”. История или сделана, или нет. Она не может быть «сделана, но…» или «почти сделана». Как определить, что история на самом деле сделана и нет никаких «но»? Используйте definition of done.

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

Если мы хотим встроить качество, то definition of done отличное место для этого. Например, чтобы избежать простейших ошибок, команда может решить включить условие, что «Нет новых предупреждений от PMD или FindBugs».

Идея definition of done может быть предложена кем угодно, но принимать решение об использовании должна команда (а не менеджер проекта или ScrumMaster). Если команда не видит пользы, то она найдет способ обойти эти критерии.

Definition of done можно расширить за пределы истории – например, команда может ввести definition of done для спринта или релиза (провели тестирование производительности, система хорошо работает под Windows и под Linux). Это помогает удостовериться, что система удовлетворяет нефункциональным требованиям.

Peer code review

Одним из мощных средств по улучшению качества является peer code review (к тому же оно позволяет передавать знания и выстроить общее понимание и стандарты внутри команды, а также разрабатывать навыки и учиться быстрее). Иногда команда забывает про code review, иногда сроки сдачи близки (да, deadline весьма часто где-то очень близко ), но команда не проводит code review. Чтобы избежать этой проблемы, команда может просто включить code review в definition of done – и тогда не получится двигаться дальше, пока не провели code review.

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

Рефакторинг

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

Тестирование

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

Ручное тестирование может проводиться разработчиками (когда завершили историю), тестировщиками, а также командой Product Owner’а (это может быть и один человек) во время приемочного тестирования.

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

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

Предотвращение проблем в будущем

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

Качество как часть разработки

Все вышесказанное можно просуммировать как простой контрольный список:

• Сделайте требования достаточно адекватными реальной бизнес-проблеме
• Встройте качество в процесс создания
  • Архитектура
  • Unit/integration тесты
  • Definition of done
  • Рефакторинг
  • Peer code review
• Протестируйте
• Проверьте, что результат это то, что запрашивалось
• Проверьте, что результат это то, что на самом деле нужно

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

И самое главное – не забывайте про людей. Очень важно, чтобы команда понимала, как эти практики могут помочь им. И тут необходим консенсус. Jean Tabaka в ее книге “Collaboration Explained” определила консенсус как решение, которое каждый готов поддерживать и нет таких, кто категорически не согласен с этим решением. Команда должна определиться с набором практик, которые каждый член команды готов поддерживать.

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

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

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

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

Если вы были на конференции и не задали мне вопрос, то самое время сделать это ниже в комментариях.

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

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

Очевидные цели ретроспективы:

• Собрать информацию, получить обратную связь
• Что-то улучшить на основе полученной информации

Звучит красиво, но на практике это не так легко. Основными проблемами являются:

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

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

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

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

• Преимущества с разных точек зрения
• Как проводить
• Различные инструменты и подходы
• Ретроспектива на более высоком уровне

Преимущества с различных точек зрения

С точки зрения компании:

• Получение информации и обратной связи
• Обучение и улучшение
• Создание открытой атмосферы (хотя не для всех компаний это преимущество)
• Поощрение людей к действию и активности

С точки зрения менеджера проекта:

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

И, наконец, преимущества с точки зрения команды:

• Возможность быть услышанным
• Подстройка процесса под реальные нужды, устранение лишних вещей

Как проводить

Для ретроспективы нужна хорошо продуманная организация. Я бы выделил 3 области:

• Подготовка
• Проведение
• Реализация решений

Подготовка

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

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

Проведение

Для ретроспективы обязательно нужен ведущий (фасилитатор). Это может быть член команды, Scrum master, человек из другой команды или даже профессиональный ведущий. Периодически можно менять фасилитатора.

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

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

Затем необходимо определить, что работает хорошо, а что является проблемой. После определения проблем предлагаются решения. На практике выявление проблем и решения для них предлагаются часто одновременно.

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

В результате ретроспективы у нас есть:

• Список работающих практик
• Список проблем
• Action log с конкретными действиями и ответственными людьми

Реализация решений

Ретроспектива без реальных изменений – это просто трата времени. Action log помогает сконцентрироваться именно на действиях, а не просто на разговорах.

Имеет смысл сделать action log наглядным и заметным. Например, распечатать и повесить в комнате команды. Когда какой-нибудь элемент завершен, можно сразу отмечать это на распечатке (например, перечеркнуть или поставить галочку). Когда команда видит, что что-то реально улучшается, энтузиазм в отношении ретроспективы повышается.

Различные инструменты и подходы

Существует большое количество инструментов и форматов для проведения ретроспективы. Рассмотрим только некоторые:

• What went well/What could be improved
• Keep this/Ongoing problems/Try this/
• Bug fix analysis/Knowledge sharing/Fix process/Roles/Practices
• Starfish
• Timeline

What went well/What could be improved

Это один из самых простых форматов. Вопрос “What went well?” помогает выявить хорошо работающие элементы. А второй вопрос направлен на выявление проблем. Ответами на второй вопрос являются проблемы, но формулировка подчеркивает конструктивный подход.

Keep this/Ongoing problems/Try this

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

Starfish

Этот набор вопросов основан на starfish диаграмме.

Starfish diagram

• Start doing – что нужно начать делать (например, регулярный peer code review)
• Stop doing – что нужно прекратить делать (например, собирать бесполезные метрики)
• Continue doing – это хорошо работает, нужно сохранить
• More – этим вещам нужно уделять больше внимания (времени)
• Less – этим вещам нужно уделять меньше внимания (времени)

Bug fix analysis/Knowledge sharing/Fix process/Roles/Practices

Этот вариант предложил Владимир Лешкевич.

Во время bug fix analysis исследуются допущенные ошибки и как их не повторять. Knowledge sharing – knowledge sharing :-). В рамках фазы Fix process анализируется процесс – убираются или добавляются роли и практики.

Timeline

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

Есть несколько подходов к построению timeline – в течение спринта или в начале ретроспективы. Первый позволяет не забыть события, но второй подход проще.

Борис Лебеда предложил вариант с black box’ом – в комнате команды ставится ящик, в который можно бросать заметки с событиями. На ретроспективе все эти заметки достаются, сортируются, выкидываются малозначительные – и получаем набор фактов.

Ретроспектива на более высоком уровне

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

Можно проводить вертикальную ретроспективу (спасибо Юре Шиляеву за идею), включающую заинтересованных лиц с разных уровней (например, команда + division manager, или менеджеры проектов + несколько разработчиков + division manager + CEO). Это облегчает общение между уровнями. Но стоит учитывать психологический аспект – если команда на уровне «performing», она сможет достаточно эффективно проводить такие ретроспективы, члены менее «зрелой» команды могут просто замолчать проблемы. В случае многоуровневых ретроспектив правильная организация обсуждения еще более важна.

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

Это долговременный инструмент

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

Никому не приходит в голову сказать “о! классная штука – автомобиль! давайте ее использовать, только мотор выкинем!” или “мысль понятна, но вот про заливание бензина – мне кажется лишнее, он денег стоит, пусть она без бензина едет”. Маразм? Маразм, все понимают. И мастерство водителя здесь совершенно ни при чем – вроде никому в голову не приходит говорить “вот продемонстрируй, какой ты профессиональный водитель – настоящий профессионал должен уметь ездить даже на машине без мотора!” или “настоящий водитель никогда не заправляется!”.

Теперь описываю принципиальную схему agile-проекта. Есть продукт, который производится часто и при релизе имеет пригодный для эксплуатации вид. Его производит команда, которая реализует “хотелки” заказчика, для чего Заказчик каждый день плотно работает с командой. Чтобы темп производства не падал, используются ежедневные собрания, на которых люди говорят “что сделано” и на которых им совестно сказать “ничего не сделано”. Им совестно так сказать потому что они очень хотят выпуска продукта и потому что они уважают коллег, в глазах которых они не желают упасть как профессионалы. Иными словами – профессионалы которые хотят зарелизить продукт собираются каждый день похвастаться друг перед другом успехами в деле выпуска этого продукта через что происходит высокая интенсивность работы над пожеланиями Заказчика который все время находится рядом чтобы направлять команду, и как следствие – мы способны релизить часто, релизить со смыслом и пользой, и добиваться при этом приемлемого качества.  Принципиальная схема думаю понятна. А теперь внимание.

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

Да, даже в таких условиях проект можно сделать. Но в такой ситуации не тренинги по аджайлу нужны, а сержант Хартманн. И никакой аджайл здесь не заработает, я про это уже писал. Тренинги или не тренинги, fogbugz или rally, subversion или VSS – это совершенно неважно.

Один из 12 принципиальных узлов, из которых построен грузовик agile – projects built around motivated individuals. Это один из принципиальных узлов, это мотор (команда) и топливо (мотивация) грузовика. Нет мотора – грузовик, даже самый совершенный, не тронется с места.

Что сделать, чтобы люди хотели сделать проект? Ответ – думайте. Из своей практики могу сказать, что никто обычно не скрывает от чего в работе он приходит в восторг, а отчего впадает в депрессию. Обычно не требуется ничего сверхъественного для того, чтобы человеку было интересно работать над проектом. У кого-то преобладают социальные мотивы, у кого-то – материальные, и есть растения, которые не хотят ничего – но это не повод не анализировать мотивацию своих коллег.

Потому что одно могу сказать точно – ваш проектный agile-грузовик без мотора и бензина не поедет. Можете убиться веником – но мотор (команда) и бензин (мотивация) нужны. Нет, можно конечно запрячь в грузовик четверик, но эффективная телега – это совсем другая система, и фирма Caterpillar явно бы не одобрила свой логотип на такой колымаге (так что подумайте прежде чем говорить “мы делаем agile”, ага).

Есть еще такая распространенная байка – “настоящий девелопер самомотивирован” – почему-то в контексте "его можно поставить разгребать любой свинарник”. У каждого осмысленного человека есть мотивация (набор мотивов деятельности) – это факт. Каждый осмысленный человек ищет путей реализации этих мотивов – это факт.

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

Это разъяснение я написал чтоб в конце красным сделать вот такое сообщение: Камрады менеджеры, пока вы не поймете принцип projects built around motivated individuals и не увидите девелоперов, страстно желающих начать ваш проект – не приходите ко мне с просьбами “мои люди не хотят делать agile\проект, и тренинг по agile они не хотят, но надо провести для них тренинг чтоб переубедить!”. Слезно вас прошу – отстаньте! перечитайте текст выше, реализуйте принцип на практике – и тогда они сами попросят у вас тренинг.

Цель

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

Свое участие уже подтвердил Денис Петелин, основатель Agile сообщества Беларуси.

Программа

Начало в 10:00.
Завершение в 18:00.

В основном планируются дискуссии в формате open space.

Программа отдельно

Участие

Участие бесплатное.
Регистрация обязательна, помещение рассчитано на не более чем 25 человек.

Как добраться

Московская, 15 (Республиканский институт высшей школы), аудитория 804 - на лифте до 7-го этажа, потом по лестнице до 8, найти аудиторию 804
Это рядом со станцией метро Институт культуры.
Надеюсь, эта карта поможет соориентироваться - http://www.gorodalive.by/minsk/gis/19960.

В ближайшее время планируется начать проводить Agile practitioners gathering. Основная задача - собрать вместе практиков, чтобы можно было пообщаться, обменяться опытом, обсудить реальные проблемы вживую, лицом к лицу. Предполагаемый формат - open space + workshops + discussions, темы генерятся в начале встречи (естесственно, каждый заранее продумывает, что ему хотелось бы обсудить), выбираются наиболее актуальные, далее происходит обсуждение. В дальнейшем будем приглашать практиков из AgileRussia и AgileUkraine, а также профессиональных коучей и консультантов (например, Асхата Уразбаева или Алексея Кривицкого).
Детали первой встречи будут сообщены позже.

После всех теоретических рассуждений о разных способах оценки (смотри Оценка. Часть 1 и Оценка. Часть 2) давайте рассмотрим примеры оценки нескольких гипотетических проектов.

Проект «МегаХ»

Большая система, time & materials. Заказчик за Scrum, но просит изначально оценить примерные затраты и хочет иметь возможность видеть общий прогресс проекта. Хороший заказчик.

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

Для оценки всего проекта решено выбрать story points. Учитывая свой предыдущий опыт, PM рассказывает команде, почему именно story points и что они дадут (иначе команда будет считать в днях и просто называть их story point). Уф, команда за story points – тем более, что у некоторых уже есть опыт. Проводится небольшой тренинг по оценке.

Заказчик хочет Scrum, но не готов писать user stories, хотя согласен быстро отвечать на вопросы и объяснять непонятные моменты. Проблем особых нет – PM становится Proxy Product Owner и с помощью заказчика пишет истории.

Истории написаны и согласованы с заказчиком. Ок, можно приступать к оценке.

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

Story points есть, как оценить примерные затраты? Выбрали 5 user stories, каждый индивидуально оценил в днях. Посчитали, сколько стоит средний story point. Сказали заказчику, предварительно объяснив, что это достаточно примерная оценка. Его устраивает. Команду тоже.

Как оценивать задачи в спринте? Решили использовать инженерные часы. В коэффициент ушли тесты, code review, исправление ошибок, стандартный оптимизм команды, перерывы. Для начала взяли коэффициент 2 (т.е. 4 инженерных часа = 8 реальных).

На основе velocity (которая в story points) выбираем историй немного больше, чем мы обычно успеваем сделать за спринт. Каждую историю сначала разбиваем на задачи. Когда все истории разбиты (и уже более-менее понятно, что и как делать), начинается непосредственно оценка. Как обычно, используется poker planning. Если оценки сильно отличаются, то те, кто положил самую маленькую и самую большую оценку, рассказывают, какие подводные камни или очень простые решения они видят. После этого проводится еще один раунд poker planning. Как правило, третьего раунда нет, так как уже на втором раунде оценки в целом одинаковы.

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

Истории выбраны, команда готова их сделать за этот спринт. Делаем.

После каждого спринта пересчитывается velocity в story points, и соответственно, общая продолжительность проекта (так как мы знаем, сколько еще story points нам надо сделать, зная скорость, можем узнать время). Через некоторое время заметили, что скорость увеличивается. Приятно. Заказчик доволен.

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

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

Проект «Fixed»

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

Заказчик не готов писать user stories (хотя уже имеет опыт работы со Scrum проектами). Ок, PM пишет user stories и согласовывает с заказчиком.

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

Согласования с заказчиком. Контракт подписан.

Для оценки спринта использовали инженерные часы и poker planning.

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

Проект «Конь и вакуум»

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

Приехали.

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

Много думаем. Решили взяться.

User stories какие-то уж очень большие и расплывчатые (понятно, что их писать пришлось самим). Оценку решили делать в неделях, так как требования все еще не до конца понятны, Полную команду не собирали – только потенциальные PM и tech lead. Использовали подход 3 оценок. Оценили. Опять загадочные манипуляции PM’a с цифрами. В этот раз итоговая оценка больше отличается от простой суммы оценок. Начали подозревать, что за действиями PM’a что-то есть.

Выиграли тендер. Собрали команду.

Для спринта использовали стандартную схему (инженерные часы + poker planning).

В итоге проект сделали. Анализируя, поняли, что если бы изначально попытались все определить, то были бы большие проблемы – несмотря на то, что человек со стороны госорганизации был очень толковым, требования все-таки менялись. Но мы-то были готовы к изменениям.

Все довольны.

Inspect and adapt

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

Уважаемые коллеги, с удовольствием представляем вам очередное интересное событие.  1–22 мая 2009 года в Выставочном центр «Инфопространство», г. Москва пройдет Международная конференция Software People 2009, которая объединит на своих площадках профессионалов в области управления процессом разработки программных продуктов из России, Белоруссии, Украины, СНГ и других стран мира.

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

Software People 2009 — это свыше 300 участников, 60 докладчиков, самые актуальные темы в пленарных сессиях и самые острые вопросы и дискуссии круглых столов, вечерние мастер-классы и семинары Гуру, телемост с участниками Software Engineering Forum 2009 (г. Минск), online-трансляция в Интернете, выставка и разнообразная программа дополнительных мероприятий.

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