Agile Gathering 5: video

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

Как многим известно в плошлую субботу 28го июня мы провели пятую конференцию, посвящённую гибкой разработке ПО - Agile Gathering 5.

Спасибо огромное всем, кто пришёл. Ещё раз спасибо нашим партнёрам, без которых у нас не было бы такого помещения:


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


AgileAlliance присоединился к числу партнёров 30 июня.


Спасибо ребятам за информационную поддержку.

Доклады, опросник и другая полезная информация будут доступны на сайте немного позже. А сейчас...

Сейчас мы выкладываем видео! Все пять фрагментов!

Спасибо ребятам из WebTube - первого украинского веб хостинга за съемку и монтаж!

1. Вступительное слово. Алексей Кривицкий


ссылка на видео

2. "Аджализация QA. Интеграция разработчиков и тестировщиков в проекте. Сложности и возможные пути их решения". Николай Алименков и Алексей Кривицкий. Презентация часть 1, презентация, часть 2




ссылка на видео

| View | Upload your own

| View | Upload your own

3. "Как не следует внедрять Agile. Опыт одного проекта. Попытка анализа причин неуспеха. Попытка прогноза результатов". Маргарита Котова. Презентация


ссылка на видео

| View | Upload your own

4. "War for Agile: Внедрение Agile в сложных условиях. Невозможное возможно!". Николай Алименков. Презентация


ссылка на видео

| View | Upload your own

5. "Тенденции внедрения Agile в Украине. Результаты опросов и интервью".
Алексей Кривицкий. Презентация


ссылка на видео

| View | Upload your own

Главарь банды - шесть качеств хорошего скрам-мастера (Майк Кон)

Автор: Алексей Тигарев.

Недавно я понял, что мне необходимо делегировать другим людям полномочия скрам-мастера в своих командах. А самому сосредоточиться на работе Product Owner'а (прокси-продукт-овнера, на самом деле) и коачинге новоиспечённых скрам-мастеров в командах.

Не потому, что мне принципиально трудно сочетать роли ScrumMaster и Product Owner. А просто потому, что мне не хватает времени на обе эти роли.

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

С целью дать командам информацию о критериях выбора хорошего скрам-мастера, я нашёл и перевёл статью Майка Кона "Главарь банды. Шесть качеств хорошего скрам-мастера." (Mike Cohn, Six Attibutes of a Good ScrumMaster). Заодно перевёл и комментарии к этой статье, оставленные на сайте ScrumAlliance, которые, на мой взгляд, прекрасно дополняют статью.

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

Представляю его вам:

Leader of the Band: Six Attributes of a Good ScrumMaster >by Mike Cohn | 05 Feb 2007

Главарь банды: Шесть качеств хорошего скрам-мастера Майк Кон, 5 февраля 2007 перевод – Алексей Тигарев, 11.06.2008

In my last column I asserted that in an ideal world a team would select its own ScrumMaster, but that it isn’t always practical. I promised that my next column would discuss what to look for in a potential ScrumMaster, whether the selection is being made by the team itself or by someone outside the team. In this week’s column, I present six attributes that your next ScrumMaster should demonstrate.

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

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

Agile Gathering 5: новый адрес зала !

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

Внимание: из-за большого количества заявок на участие в конференции Agile Gathering 5, мы приняли решение поменять адрес места проведения.

Новый зал вмещает до 200 участников:


Да и добраться до него проще:

Адрес: Киев, гостиница "Экспресс", бул. Шевченко 38/40.
Район м. Университет, прямо возле предварительных ж/д касс.
В прямой видимости от ж/д вокзала, что несомненно удобно для приезжих.

Открыть карту Yandex.

Начало регистрации в 10:00.
Открытие конференции в 11:00.
Вход: бесплатный.
Ждём всех! Теперь места хватит :)

open space

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

На встрече-конференции Agile Gathering 5 помимо докладов мы планируем провести сессию в формате "open space".

Ниже приведено описание базовых концепций open space, с которыми мне довелось познакомиться и опробовать на практике.


Цель open space:

• Обсудить в открытом формате (когда каждый может высказаться) интересующие аудиторию темы, которые формируются по ходу проведения общения.
  

Условия для проведения open space:

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

Правила такие:

1. Когда бы это ни началось - это правильное время.
2. Кто бы ни пришёл - это те, кто нужны.
3. Что бы ни произошло - это единственное, что могло произойти.
4. Когда закончилось - тогда закончилось.

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

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

Шаги проведения:

1. Участники (все присутствующие на мероприятии) формирует агенду - что, где и когда будет обсуждаться.
   
   Для этого желающие наклеивают на заготовленную стену стикеры с названием темы, временем и номером зоны, где предполагается провести эту дискуссию.
   
   
   
   
2. После того, как начальная агенда готова (нет больше тем для обсуждения или заняты все тайм слоты и зоны), участникам даётся время на ознакомление с агендой и реструктуризацией (группировкой) тем, если это необходимо.
   
   
   
   
3. Когда агенда готова, начинается время дискуссий.
   
   Согласно агенде участники расходятся по зонам общения, где пребывают сколько хотят. Участники могут переходить из зоны в зоны по своему желанию ("правило ног").
   
   
   
   
4. По завершении тайм слота, о котором напоминает фасилитатор, участникам рекомендуется вернуться к стенду с агендой и подготовиться к следующей дискуссии.
   
   
5. Так продолжается пока агенда, время или интерес не будут исчерпаны.
   

Вот собственно и всё!

Приходите, подискутируем! :)

Подготовка к Agile Gathering 5

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

До конференции Agile Gathering 5 осталось 13 дней.

Подготовка к конференции идёт полным ходом: уже получено более 80 регистраций, опросник собрал 90 уникальных ответов.

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

Так что событие ожидает быть интересным. Зовите друзей и приходите!

Вы ещё не добавили событие в свой Google календарь? Сделайте это сейчас:

Generic Agile

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

XP, SCRUM, DSDM, Crystal... - всё это бренды и конкретные "best practices", стоящие за ними. Как следуя одной из этих методологий, вы всё ещё может сказать, что ваши процессы не преобладают над людьми и их интересами?

В интервью Rachel Davies рассказывает про свой подход - "Generic Agile", когда команды берут лучшее из XP, SCRUM и других книжных подходов, и адаптируясь, развивают свой процесс, становясь более эффективными.

Видео интервью с Rachel Davies.

Диаграммы Ганта и Agile проекты. Так уж они несовместимы?

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

"Планы бесполезны, планирование необходимо".
Ейзенхауэр

Диаграммы Ганта – это традиционный механизм визуального планирования, который получил свою популярность благодаря артефакту традиционных проектов, который назывался Work Breakdown Structure (WBS), и продуктам Microsoft Project и Microsoft Project Server, которые позволяли конструировать и хранить WBS.

Пропоненты Agile принципов много внимания уделяют визуализации и открытости планирования. Так почему же так часто в контексте Agile мы слышим критику в адрес диаграмм Ганта?

Давайте разберёмся.

Пару слов о терминологии.

В данной статье "традиционными подходами" к управлению проектами (или просто традиционными проектами) называются те подходы или проекты, которые противопоставляются Agile проектам. Я не использовал термин «водопадных проектов», так как во-первых на практике настоящих водопадных проектов не так много, а во-вторых по мимо водопадных и Agile проектов есть ещё множество других, которые тяжело классифицировать.

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

Давайте рассмотрим, как выполняется планирование в идеальном Agile проекте:

1. Для того чтобы получить наиболее полную картину, вся команда вовлечена в процесс планирования.
   
   Выполняя коллективное планирование команда обсуждает цели, тактику их достижения, что несомненно является полезным групповым упражнением, объединяющим команду вокруг общих целей и взаимных обязательств.
   
   Ответственность за адекватность планов лежит на плечах всей команды, а не одного человека.
   
   
2. Планирование Agile проекта выполняется в течение всего жизненного цикла проекта.
   
   Планы уточняются по мере того, как команда и заказчики узнают больше о разрабатываемом продукте, технологиях, возможностях команды. Это непрерывный процесс, "agile planning" - это действие, не артефакт.
   
   Такой подход постепенной детализации планов позволяет экономить время на планирование, за счёт того, что более далёкие аспекты проекта, которые с большей долей вероятности подвержены изменениям, не прорабатываются с такой же степенью детализации, как те аспекты, которые будут пущены в работу в ближайшее время. Зачем тратить время на то, что ещё не факт войдёт ли в проект?
   
   
3. Механизмы управления требованиями в Agile проетках (к примеру product backlog, user stories) позволяют уменьшить зависимости между единицами требований, таким образом Agile проекты не нуждаются в таком детальном отслеживании зависимостей в требованиях, как единицы требований, используемые в традиционных проектах.
   
   При помощи отслеживания зависимостей и задержек выполнения плана WBS
   традиционного проекта помогает предсказать дату завершения фазы проекта. В Agile проектах для предсказания дат и объёма работы, используется метрика Velocity, для использования которой нет необходимости в отслеживании зависимостей между требованиями и работами.
   
   Зависимости же между задачами в Agile проектах осуществляются командой благодаря ежедневной синхронизации на т.н. standup митингах.

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

Что можно посоветовать:

1. Я думаю, что рисовать WBS стоит всей командой, а не отдельному человеку - менеджеру. В этом случае WBS становится достоянием команды и его можно использовать в виде настенного постера - WallGantt. Смотрите ссылки ниже.
   
   
2. Стоит обновляйте WallGantt как только вы узнаете нечто, что влияет на планы. Скорее всего не реже, чем раз в итерацию. Это позволит содержать Гант up-to-date и избежать ложности планов, к которой многие из нас так привыкли при традиционном планировании.
   
   
3. Если рисовать WBS не по задачам, а по требованиям (элементам product backlog), то это позволит избежать микроменеджмент команды, но всё-таки позволит сгенерировать информацию, полезную для команды. В противном же случае вы рискуете заменить ежедневное живое планирование артефактом. Это точно не то, чего мы добиваемся в Agile проектах.
   

Полезные ссылки:

• http://c2.com/cgi/wiki?AgileGantt
• http://c2.com/cgi/wiki?WallGantt
  http://weblogs.asp.net/rosherove/default.aspx