Вводная

Итак, в первой сводке, я расскажу немного о компании и об особенностях Agile'a, применяемого в нашей компании.

Agile in Russia , Impossible!

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

Заказчик - иностранная компания, занимающаяся разработкой встроенных систем назовем ее компания AA, для конспирации :).

Собственно в моем случае компания RR предоставляет ресурсы в качестве команды разработчиков компании AA.

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

Собственно Agile методологию(а точнее Scrum составляющую) активно внедряет менеджер из компании AA во всех своих командах и в нашей команде в том числе.

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

Remote Agile. Pain in the Ass!

Как я писал выше наши заказчики из компании AA управляют командой разработчиков сами. Поэтому наш Agile довольно специфичен все таки удаленный Scrum Master это нелегко.

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

Решение оказалось достаточно простое:

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

Как это не странно в таких условиях работает большая часть практик Scrum'a.

Product Backlog

Product backlog - это список задач, описанных с точки зрения бизнеса, называемых User Stories.
Пример : Как пользователь я хочу иметь возможность сохранять сообщение без его публикования.

Так же у нас в Product Backlog заносятся так называемые Tech Stories - задачи технического характера, Пример: Настроить сервер сборок.

Product backlog представлен в 2х сущностях:

• в электронном виде в Xplanerr'e
• в виде укрупненных User Stories(задачи с точки зрения заказчика в Scrum'e) на TaskBoard'e.

Причем так как у нас нет возможности использовать типичный TaskBoard(хотя первое время пытались) было найдено следующее решение в виде Excel'a файл,

Daily Scrum

Daily Scrum - ежедневная встреча для обсуждения трех вещей:
Что сделано ? Что запланировано на сегодня ? Что мешает работе ?
Встреча ограничена по времени - максимум 15-20 минут.
Поэтому ее традиционно проводят стоя, долго на ногах не простоишь просто :).
Удаленный Daily Scrum Meeting отличается только тем, что проходит по Skype'у и не проводиться стоя, в остальном все тоже.

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