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

Agile включает в себя множество вариантов процессов, наиболее известные - Scrum, XP, Kanban, и семейство xDD. Из них Scrum и Kanban - управленческие, а остальные - преимущественно разработческие, при этом многие из них можно применять совместно или создавать комбинированный вариант. Что их принципиально отличает от традиционных практик - это категорический отказ от микроменеджмента, явного назначения задач и ставка на самоорганизующуюся команду.

Scrum - это способ решить проблему нехватки руководителей проектов, особенно острую в наукоемких и творческих областях, таких как как в программировании. Программисты обычно не очень горят желанием заниматься организационными буднями руководства, а менеджеры, умеющие лишь управлять не слишком справляются из-за особенностей предметной области. Scrum обеспечивает это за счет деления повседневных обязанностей менеджера на две части: product owner направляет работу, это близко программистам, а организационные будни перекладываются на команду, которую слегка организует scrum master. Дополнительные выгоды - хороший product owner получает возможность руководить большим числом продуктов, а хороший менеджер - присматривать за большим числом команд. Потому что часть организационной рутины с них сняли.

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

Хенрик Книберг - один из крупнейших практиков Agile. Его книга Scrum and XP from the Trenches описывает практики Scrum и, на мой взгляд, является лучшей по этому вопросу. Во всяком случае, именно она в 2007 вдохновила нас на внедрение Scrum в нашей компании. Сейчас она доступна в русском переводе.

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

Роли и их разделение.

• Product Owner отвечает за продукт, а SCRUM Master — отвечает за процесс в команде. И это бьется очень четко и всеобъемлюще.
• PO — продукт целиком, его интересует общая скорость и другие характеристики. Ответственность включает ROI и экономические составляющие, включая выход и стоимость команды. Но внутрь команды он не смотри, для него команда — целиком, в том числе с точки зрения стоимости.
• SM — ответственность за процесс, внутренняя (coach) и внешняя (коммуникации с внешними людьми). Именно он представляет реальный вклад сотрудников команды, смотрит кому и где надо помочь и это организует. Не административно, а предлагая, но в целом — его scope. В том числе — может организовывать привлечение экспертов, если это повысит производительность — согласовав с PO, так как стоимость команды тоже возрастет.
• Деление PO-SM, помимо прочего, позволяет сделать явным поиск компромисса и вовлечь в процесс команду.
• Новые члены — с учетом мнения команды, интервью все или хотя бы один (это уже после HR, естественно).
• За технические решения отвечает команда. Она может инициировать включение в PBL задач, касающихся архитектуры, рефакторинга и прочего, высказывать мнение по приоритетам, которые следуют из техники реализации. Но принятие решения по приоритетам — за PO, он команду слушает, но решает сам.
• Еще есть менеджер, но он — один на много команд. Его задача — зарплата, контракт с сотрудником и подобные вещи. При этом для обратной связи о вкладе человека, его эффективности — он общается со SM. Плюс — может приходить на DSM и прочие мероприятия, беседовать и так далее — для получения нужной ему информации.
• Полной взаимозаменяемости нет, все люди — разные, с разным опытом и по-разному решают задачи. Разделение труда в команде есть или может быть. Жесткость — зависит от конкретного проекта. PO и/или SM могут стремиться к увеличению опыта членами команды за счет непрофильных задач или наоборот, пренебрегать рисками и ориентироваться на то, чтобы каждый брал профильные задачи. В зависимости от этого меняется стратегия оценки при планировании: могут брать оценку для профильного сотрудника, или среднюю, но команда должна договориться. Плюс, когда спринт не сбалансирован с опытом команды — она это учитывает при оценке.

Планирование и организация.

• Есть release plan (на 8-10 спринтов, 20-30 недель), который в крупном, в feature или user story, и он предварительно, в крупном, оценен командой.
• Поскольку есть оценка — то достижение результата в крупном, скорость реализации — контролируется.
• Но спринт — тоже, естественно, оценивается. Оценка может совпасть или нет, по разным причинам. Может быть особенность задачи, а может быть ситуация, когда команда набрала опыт и научилась точнее оценивать. Во второй ситуации PO может понять о коррекции начальных планов и что-нибудь предпринять по этому поводу.
• Исходные данные для формирования SBL итерации — не только PBL, но и цели: business, learning, risk, technical dependencies.
• Важно ограничивать число тем итерации, переключения контекста — дорого. В идеале — один основная тема и одна фоновая. От итерации к итерации темы можно менять.
• Есть мероприятие — Backlog workshop, проводится каждую неделю, PO + команда, оценивается текущее состояние, могут вноситься изменения.
• Окончательно перешли к оценке в попугаях (story point). В них меняют velocity на спринт, а при планировании из нее получают объем спринта в SP (с учетом фактических человеко-дней). Если есть фиксированные по времени мероприятия, то их надо вычесть из длительности спринта. SP оценки спринта и релиза, в общем случае — разные, коэффициент уточняется по прошедшим спринтам.

Оценка в SP.

• Почему перешли на оценку в SP (story point)? Это — опыт. При такой оценке команда быстрее приходит к согласию, чем при оценке в идеальных днях/часах. И легче калибровать разные команды, передавать им подходы к оценке. А точность — не уменьшается. Для рефлексии о причинах падения скорости SP обычно хватает, если какая-то одна-две задачи несоразмерно выросли.
• Как первоначально получают оценку в SP? На начальной оценке release PBL берут простую и понятную всем историю, которую оценивают, например, в 3 SP или 5 SP. Получается начальный масштаб, от которого дальше пляшут. Когда переходят к оценке спринта и оценивают task, на которые поделили user story, то оценка user story задает некоторый масштаб, пока команды не привыкнут. Но при этом укладываться и подгонять не обязательно, более того у многих есть практики не показывать на планировании спринта оценки user story, во всяком случае сначала — чтобы они не влияли на оценки отдельных задач. Но в случае расхождений — разбираться, вопрос в подробностях задачи или более систематично что-то поплыло.
• Новичкам для калибровки оценок полезно посмотреть оценки предыдущих спринтов до первого планирования. И, опять-таки, оценить задачу как «похожую на ту» легче, чем прикинуть часы.

О SM

• Если кто не разделяет цели — гнать из команды. Движение должно быть сонаправленным. Размер шага (скорость) — не так важны, это тренируется, если человек разделяет цели. Ответственность за фиксацию таких проблем — на SM.
• Про SM, не смотря на много «управляющих» функций по процессу, явный акцент Книберга на самовыдвижении и отсутствии формальной власти. И SM создает условия для самоорганизации, а не управляет. Основне средство — вопрос «А что вы думаете о …» (а не «Давайте решим такую проблему…»).
• Если есть персональные проблемы, например, кто-то систематически не соблюдает стандарт кодирования и на review это вылезает, то задача SM — это выявить. Хотя на ретро об этом могут не говорить. Поговорить до ретро с членами команды, а дальше по обстановки — можно индивидуально, можно на ретро. То, что это в компетенции SM — «по умолчанию».

Процесс в целом

• Практика, когда задачу заранее готовят к выполнению, например, постановка силами той же команды или согласование с заказчиком — распространенная. И хорошая техника — вместе с DoD сделать Definition of Ready — check list, что должно быть у задачи, чтобы ее можно было запускать в спринт. Пример DoR: есть bug, grade S/M/L, есть acceptante test.
• Еще раз сформулировали — кросс-функциональная команда — не значит, что каждый заменяет каждого. Но значит, что нет критичного для процесса человека, и в целом компетенции сбалансированы с потоком задач с учетом отклонений. Техника: матрица деятельность (DB/Java/Design/Test, например) — сотрудник, на пересечении — оценка: пусто/точка/звездочка. Должно быть минимум две звездочки и несколько точек, если нет, то включаем в цели их прокачку у конкретных участников в ходе спринта за счет выполнения задач (например).
• Project Manager в смысле CMMI поделен в SCRUM примерно так:
  • release plan — PO
  • build team — SM
  • архитектура — команда
  • раздача задач — task board
  • набор персонала — за рамками команды
• Надо ограничивать количество задач, находящихся в работе. На это есть мат.модель (правда тут надо смотреть, насколько плюшевая, я готов рассказать подробности). Кратко так. Если дело проходит через несколько стадий, и на каждой имеет некоторую неопределенную трудоемкость (например, от 1 до 3), то с некоторого числа дел в работе мощность выходит на плато, но чем меньше дел в работе — тем быстрее новое дело, вкинутое на вход, появится на выходе. И это — без узкого горла. Если стадий 5, то в работе оптимально 7 начатых дел. Практически это мощное ограничение, особенно с учетом дорогого переключения контекста, и надо этим пользоваться, и того, что люди не могут одновременно держать много целей.
• Working smart more important than working hard. Не рубите деревья бензопилой, а пилите, и вообще не рубите деревья молотком. Используя SCRUM смотрите, насколько подходит.

Две команды на одном продукте.

• Итерации — рекомендуется синхронно, и общий релиз. Иначе сложно с кодом.
• Задачи на итерации делить можно на общей сессии: все задачи висят на доске, команды у них и высказывают желания, а PO — отдает. Как вариант — в каждой команде свой «локальный PO», который берет задачи от общего, так тоже можно.

Разные техники.

• Варианты с 2-3 командами на одном продукте с общим кодом и нескольких продуктов для одной команды — вполне рабочие.
• Команды должны быть стабильны. В цифрах это означает устойчивое существование 3-6 месяцев.
• Новая команда по опыту выходит на плато скорости за 1-2 месяца.
• В презентации есть интересные ссылки на исследования психологов — как оценивает команда одну спецификацию в зависимости от разных факторов. Например, от числа листов, полученного увеличением размера шрифта (коэффициент 1.5) или предварительно высказанной оценки стороннего эксперта. Первичку, кто интересуется, думаю, можно найти — ссылка была на Simula research lab, Еstimation …, Oslo 2006.
• «Не бывает низкой скорости, бывают нереалистичные планы». Потому что скорость сама — не поднимется, над этим надо работать.
• Что мотивирует (это известно, но, тем не менее):
  • Autonomy = свобода, самоопределение (да. в рамках, но рамки — они везде есть)
  • Mastery = передовые технологии
  • Purpose = понятные, осмысленные и ценные задачи, которые делаем
• Если у команды период активной поддержки, то можно резервировать на это некоторую долю времени при планировании спринта, а можно — вставлять в SBL задачи типа «фиксируем 10 самых критичных багов».
• Если возник стресс и запарка — найдите силу воли сделать паузу и проанализировать причины.
• Любопытный пример. Kanban of SCRUM, на 60 человек. Большая доска, слева область для подготовки, потом область выполнения — разбита на 4 части для отдельных scrum-команд — задача уходит на их доску, а после спринта — возвращается на общую. Впечатляет. И, возможно, на проектах с несколькими командами типа ГПБ — может быть полезным.
• Где-то всплыл сайт http://userstories.com - всякие тулы и прочее для поддержки. Может, кому интересно — даю ссылку.

Метафоры и образы.

• Водопад как последовательные выстрелы из лука: облако заказа, Req стреляет — получает требования, Designer — получает проект, разработчики — результат. Все как-то промахиваются, естественно — наводят на одно, получают другое. Ну и Заказчик реально хотел не то, что заказал.
• Водопад как стрельба из пушки по движущейся мишени. Agile (SCRUM) как самонаводящаяся на цель ракета вместо этого.

Повсеместная работа с карточками меня впечатлила. Техника ведения трека через карточки, которые сначала есть в PBL, потом помещаются на мини-доску Todo/Doing/Done, а потом — в сделанное в рамках спринта может быть полезна на собраниях с повесткой дня. Я, во всяком случае, буду пробовать. Приоритеты — тоже через них. И bring down на планировании — user story на доске, пишем task и вешаем.

Общение с другими.

• Было много участников, успешно применяющих scrum и приехавших. чтобы улучшить опыт. Сам scrum — разный, в том числе в варианте, когда scrum master близок к менеджеру. У других — упор на PO, есть те, у кого он в команде.
• Была практика, когда один SM ведет две команды, и это — его полная загрузка, а задача его — именно наладить процесс. При этом он знает разряды сотрудников и следит за адекватным вкладу разрядом, говоря о проблемах индивидуально. На ретро или эскалируя.
• Планирование 2-недельной итерации вместе с декомпозицией story на task — полдня, 4 часа.
• SCRUM позволяет делать качественные вещи, вопрос в применяемых практиках. Например, может быть жесткое требование, что по каждой user story — пишем acceptant test (пишет или утверждает PO), который развертывают в test case. И все это делает команда.
• Есть практика тех.лидов, тоже поделенных на 2 команды и занимающихся техническими архитектурными вопросами.