A G I L E - AGILE GROUP UKRAINE

Тренинги в Днепропетровске

noreply@blogger.com (Alexey Krivitsky) — Wed, 23 Jul 2008 15:32:11 -0500

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

24 и 25 июля в Днепропетровске "Тренинговый Центр Люксофт" проведёт два тренинга на темы:

Практический опыт применение Agile методологии в распределенной команде
Инженерные практики Agile

Конференция SEC(R) 2008

noreply@blogger.com (Alexey Krivitsky) — Wed, 23 Jul 2008 14:41:49 -0500

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

AgileUkraine выступает информационным партнёром четвёртой международной научно-практической конференции SEC(R)-2008.

23-24 октября 2008 в Москве состоится Четвертая международная конференция по программной инженерии SEC(R) 2008 с дополнительными семинарами Гуру 21, 22 и 25 октября, которая ставит перед собой достаточно амбициозную цель по консолидации локальных сообществ разработчиков и интеграции их в международные сообщества.

Впервые на конференцию и в Россию приедет эксперт в области MDA [Model-Driven Architecture] Стив Меллор (Stephen J. Mellor). Стив один из тех, кто подписал Agile Manifesto. Появление этого документа ознаменовало начало новой эры в software development. На конференции Стив выступит с докладом «Agile MDA» и проведет семинар по комплексной архитектуре программного обеспечения в дополнительный день конференции, посвященный семинарам мировыхэкспертов.

Со 2 июля 2008 года открыт прием докладов и регистрация слушателей. Докладчики освобождаются от взноса за участие в конференции. Информация для докладчиков (Call for papers).

За годы конференция приобрела заслуженный авторитет одного из крупнейших международных мероприятий, посвященного программной инженерии и смежным с ней вопросам. Сотни компаний, учебных заведений, индустриальных ассоциаций из десятков стран мира представлены своими ведущими экспертами, авторитетными представителями и лидерами всех уровней.
Список ключевых докладчиков прошлых конференций включает Майкла Кузумано, Лари Константина, Клаудию Дент, Стива Мастерза, Майкла Фэгана, Билла Хэфли, Ивара Якобсона, Рика Казмана, Марка Полка и других лидеров индустрии.

Конференция ориентирована на различных профессионалов индустрии разработки программного обеспечения: менеджеров, ведущих разработчиков и системных архитекторов, специалистов и менеджеров по качеству, руководителей компаний-разработчиков и ИТ-департаментов, менеджеров по персоналу и руководителей корпоративных тренинговых центров, бизнес аналитиков, IT-менеджеров, исследователей и ученых и др. из Армении, Беларуси, Казахстана, России, Украины и других государств СНГ, стран Балтии, Европы и США.

Организаторы конференции — компания ТЕКАМА и ГУ ВШЭ.
Событие традиционно поддерживается лидерами индустрии высоких технологий, в том числе Intel, INTSPEI, Borland, EMC2, IBM, Microsoft, ORACLE, Siemens, Sun Microsystems и Telelogic, а также промышленными ассоциациями RUSSOFT и АПКИТ.

Наши тренинги в августе по Agile

noreply@blogger.com (Alexey Krivitsky) — Fri, 18 Jul 2008 05:36:16 -0500

Базовые концепции Agile и SCRUM
15 августа
Тренер Алексей Кривицкий

Automated Acceptance Testing
16 августа
Тренер Николай Алименков

Agile club

noreply@blogger.com (Alexey Krivitsky) — Wed, 23 Jul 2008 15:04:58 -0500

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

31 июля с 19:00

Ул. Боженко, 86д ссылка на карту

Тема вечера: Планирование релизов в Agile

В программе:

просмотр и обсуждение видео по теме;
мини-доклады (5-15 минут каждый);
open-space дискуссии;
пиво, соки и закуски.

Вход бесплатный.
Ждём всех желающих.

Agile Gathering 5: album

noreply@blogger.com (Alexey Krivitsky) — Wed, 02 Jul 2008 03:07:20 -0500

Фотографии доступны в нашем веб-альбоме.

Спасибо Наде Плаховой за чудесные фотографии.

Acceptance Testing: Test First

noreply@blogger.com (Alimenkov Nikolay) — Tue, 01 Jul 2008 15:14:54 -0500

Автор: Алименков Николай.

На последнем Agile Gathering V мне неоднократно задавали вопрос: "Как можно писать acceptance тесты на несуществующий функционал?". Я приводил примеры написания таких тестов с использованием некоторых фреймворков. Но потом я в очередной раз задумался о самом понятии acceptance теста. Acceptance (приемочное) тестирование служит для того, чтобы принимать сделанный функционал и делать выводы о его готовности. Когда функционал принят, то все acceptance тесты переходят в разряд регрессионных тестов (для проверки работоспособности существующего функционала).

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

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

Неочевидная проблема заключается в том, что ручное тестирование склонно к компромисам. Я попытаюсь пояснить на примере веб приложения. Предположим заказчик хотел иметь кнопку для перехода на другую страницу. Разработчики посчитали нужным сделать вместо этого ссылку. При проверке QA (уставший после рабочего дня или же просто по невнимательности) подумал что ссылка тоже неплохо и принял функционал. И тут проявляется парадокс готового функционала: "Автоматизация acceptance теста на готовом функционале ограничивает его рамками конкретной реализации". Если на странице не будет кнопки, то ее нажатие никто не зафиксирует. Изначально автоматизированный тест "беспощаден" и не пропустит неточность даже если будет прогоняться 1000 раз.

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

На мой взгляд современные средства для acceptance тестирования позволяют достаточно легко писать тесты наперед. Это помогает разработчикам повысить уверенность в законченности своей работы и правильности (полноте) требуемого функционала без постоянного взаимодействия с QA. Таким образом команда становится более целостной и помогает друг другу достигнуть единой цели - разработки качественного продукта.

У нас с Алексеем Кривицким в планах проведение тренингов по acceptance тестированию, в которых будут освещаться эта и другие проблемы. Ждите анонсов на сайте и в рассылках. ;)

Agile Gathering 5: presentations

noreply@blogger.com (Alexey Krivitsky) — Wed, 02 Jul 2008 03:07:51 -0500

Презентации с конференции доступны!

| View | Upload your own

Agile Gathering 5: video

noreply@blogger.com (Alexey Krivitsky) — Tue, 01 Jul 2008 16:19:01 -0500

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

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

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

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

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

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

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

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

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

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

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

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

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

| 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

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

noreply@blogger.com (Алексей Тигарев) — Mon, 30 Jun 2008 04:56:53 -0500

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

Недавно я понял, что мне необходимо делегировать другим людям полномочия скрам-мастера в своих командах. А самому сосредоточиться на работе 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: новый адрес зала !

noreply@blogger.com (Alexey Krivitsky) — Sun, 22 Jun 2008 12:42:13 -0500

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

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

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

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

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

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

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

open space

noreply@blogger.com (Alexey Krivitsky) — Tue, 17 Jun 2008 02:20:48 -0500

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

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

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

Цель open space:

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

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

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

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

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

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

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

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

Участники (все присутствующие на мероприятии) формирует агенду - что, где и когда будет обсуждаться.

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

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

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

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

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

noreply@blogger.com (Alexey Krivitsky) — Sat, 14 Jun 2008 22:33:38 -0500

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

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

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

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

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

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

Generic Agile

noreply@blogger.com (Alexey Krivitsky) — Wed, 11 Jun 2008 23:36:57 -0500

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

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

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

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

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

noreply@blogger.com (Alexey Krivitsky) — Mon, 09 Jun 2008 15:59:36 -0500

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

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

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

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

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

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

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

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

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

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

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

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

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

Такой подход постепенной детализации планов позволяет экономить время на планирование, за счёт того, что более далёкие аспекты проекта, которые с большей долей вероятности подвержены изменениям, не прорабатываются с такой же степенью детализации, как те аспекты, которые будут пущены в работу в ближайшее время. Зачем тратить время на то, что ещё не факт войдёт ли в проект?
Механизмы управления требованиями в Agile проетках (к примеру product backlog, user stories) позволяют уменьшить зависимости между единицами требований, таким образом Agile проекты не нуждаются в таком детальном отслеживании зависимостей в требованиях, как единицы требований, используемые в традиционных проектах.

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

Зависимости же между задачами в Agile проектах осуществляются командой благодаря ежедневной синхронизации на т.н. standup митингах.

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

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

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

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

Конференция "Agile Gathering 5", 28 июня, Киев

noreply@blogger.com (Alexey Krivitsky) — Mon, 30 Jun 2008 11:26:54 -0500

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

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

Внимание, изменился адрес места проведения конференции! Детали ниже.

Вход бесплатный, для участия достаточно заполнить форму регистрации.

Доклады

1. "War for Agile: Внедрение Agile в сложных условиях. Невозможное возможно!".
Николай Алименков, Zoral Labs

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

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

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

Дополнительные материалы

Так как среди тем докладов не будет базовых концепций, а все они будут расcчитаны на людей с опытом применения Agile и SCRUM, то 27 и 29 июня SCRUMguides проводят тренинги на тему Базовые концепции Agile и SCRUM.

Если вы не применяли Agile и SCRUM ранее или находитесь на начальной фазе внедрения этих практик, то этот тренинг для вас.

Формат

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

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

Партнёры

.

Хотите помочь? Не стесняйтесь, нам нужна ваша помощь!

Детали

Дата: 28 июня, суббота
Время: 11:00 - 19:00
Вход: бесплатный
Адрес: Киев, гостиница "Экспресс", бул. Шевченко 38/40.
(район м. Университет, прямо возле предварительных Ж/Д касс).

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

Unfinished work in sprints

noreply@blogger.com (Alexey Krivitsky) — Sat, 24 May 2008 03:56:14 -0500

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

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

Вот к примеру вопрос, который я слышу довольно часто:

"Что делать с историями, которые не полностью сделаны за итерацию?".

Читайте на scrum.com.ua

Опросник: "Agile в наших проектах"

noreply@blogger.com (Alexey Krivitsky) — Fri, 30 May 2008 09:34:29 -0500

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

Я решил запустить опросник и собрать статистику применимости и применения Agile в типичных украинских проектах.

Цель - узнать в какой фазе находятся проекты людей, интересующихся Agile; какие конкретные практики используются; какие есть проблемы; кто вдохновляет процесс внедрения Agile.

Я собираюсь представить результаты опроса на нашей конференции в июне.

Прошу потратить 3-5 минут и ответить на 10 вопросов опросника.
Спасибо!

Вакансии в Scrum проект, Инфопульс

noreply@blogger.com (Alexey Krivitsky) — Thu, 22 May 2008 05:37:53 -0500

Для своего киевского офиса компания Infopulse предлагает две горячие вакансии для Scrum проекта:

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

noreply@blogger.com (Alex Yakima) — Wed, 21 May 2008 04:47:55 -0500

Александр Якима

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

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

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

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

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

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

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

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

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

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

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

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

Agile Gathering 5 - call for papers

noreply@blogger.com (Alexey Krivitsky) — Wed, 14 May 2008 07:48:50 -0500

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

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

В настоящий момент активно ищутся докладчики, желательно с практическим уклоном. Длительность докладов от 20 до 40 мин.

Присылайте заявки на alexey (AT) agileukraine.org.

Ниже приводится список горячих тем.

QA

Тестирование в Agile (сложные длительные проекты)
QA motivation
Agile in testing (QA)
QA в agile-проэктах
Автоматизированное тестирования в Agile проектах

Individuals and teams

Мотивация разработчиков
Создание микроклимата в команде
Психологические отношения скрам-мастер - программист )

Practical cases

Обмен опытом по решению практических проблем в Agile проектах
Сравнение разных agile практик от человека который их пробовал
Примеры (workflow) из реальных проектов (анализ, тест, разработка, коммуникации)

Negative cases

Несостоявшийся "SCRUM в больших проектах"
Agile разработчик в не-agile среде
Где Scrum не работает и почему

Project management

Управление agile-проектами
Управление рисками

Complex projects

Внедрение Agile в крупных проектах и распределенных командах
Agile в крупных проектах - more information

Engineering

Инженерные практики
Паттерны TTD

Other

Agile и фриланс
Эффективное поэтапное введение Scrum в проекте, где его не было
Трекинг Agile проектов