Хенрик Книберг - Scrum и XP: заметки с передовой

• Название: Scrum и XP: заметки с передовой
• Автор: Хенрик Книберг
• Издательство: C4Media
• Жанр: Прочая околокомпьтерная литература
• Год: 2007
• ISBN: 978-1-4303-2264-1

Эта книга исключительна полезна. С одной стороны она про такой хорошо (если не излишне) раскрученный термин как Scrum, на который ведутся большинство (если не все) начальников. С другой стороны, она упирает на то, что Scrum без инженерных практик не живёт. Не знаю сознательно ли Хенрик заложил этот месадж в книгу или так получилось случайно, но получилось именно то, что доктор прописал :-)

---

И все-таки, я бы предложил вам сначала оценить значение детального отслеживания изменений в спринте. После того как спринт закончен и рабочий код вместе с документацией был отослан заказчику, будет ли кто-нибудь разбираться, сколько историй было закончено на 5й день спринта? Будет ли кто-нибудь волноваться о том, какова была реальная оценка для задачи «Написать приемочный тест для истории Депозит» после того, как история была закончена?

Как мы оцениваем: в днях или часах?

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

Однако мы отказались от этой практики по следующим причинам:

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

• Оказалось, что всё равно все оценивают в человеко-днях, а когда нужно получить оценку в человеко-часах, просто умножают дни на шесть. «Хм, эта задача займёт примерно день. Ага, я должен дать оценку в часах. Что ж, значит шесть часов».

• Две разных единицы измерения вводят в заблуждение. «Это оценка в человеко-днях или человеко-часах?»

Поэтому мы используем человеко-дни в качестве основной единицы при оценке времени (мы называем их story point’ы). Наше наименьшее значение — 0.5. Т. е. любые задачи, оцененные менее чем в 0.5, либо удаляются, либо комбинируются с другими, либо оценка остаётся 0.5 (ничего страшного в слегка завышенной оценке нет). Изящно и просто.

Как мы обустроили комнату команды

Уголок обсуждений

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

Поэтому мы пытаемся оформить это место как отдельный «уголок обсуждений»

Это и в самом деле полезно. Нет лучшего способа посмотреть на систему в целом, чем стать в уголок обсуждений, посмотреть на обе стены, а потом сесть за компьютер и пощелкать последний билд системы (в случае, если вам повезло, и у вас внедрена практика «непрерывной интеграции» системы (см. стр. 62 «Как мы сочетаем Scrum с XP»)

«Стена проектирования» — это просто большая доска, на которой развешены самые важные для разработки наброски и распечатки (блок-схемы, эскизы интерфейса, модели предметной области и т. п.)

На фотографии: ежедневный Scrum в вышеупомянутом уголке.

Хммммм… Эта burndown диаграмма выглядит подозрительно красивой и гладкой, правда? Но команда настаивает на том, что это правда: o)

Усадите команду вместе

Когда приходит время расставить столы и рассадить команду, есть одно правило, которое сложно переоценить.

Усадите команду вместе!

Чуть поясню, что я имею в виду:

Усадите команду вместе!

Людям не нравится переезжать. По крайней мере, в тех компаниях, в которых работал я. Они не хотят собирать все свои вещички, выдергивать шнуры из компьютера, переносить весь свой скарб на другой стол, и снова втыкать все шнуры. Чем меньше расстояние, тем больше недовольство. «Да ладно, шеф, НА КОЙ ЧЕРТ меня пересаживать всего на 5 метров вправо»?

Но когда мы строим эффективную команду по Scrum’у другого выхода нет. Просто соберите команду вместе. Даже если придется им угрожать, самому переносить все их имущество, и самому вытирать застарелые следы от чашек на столах. Если для команды нет места — найдите место. Где угодно. Даже если придется посадить команду в подвале. Передвиньте столы, подкупите офис-менеджера, делайте всё, что нужно. Но как бы то ни было, соберите команду вместе.

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

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

«Вместе» значит:

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

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

Автономно: если вдруг вся ваша команда поднимется и начнет внезапную и очень оживлённую дискуссию об архитектуре системы, никого из не-членов команды не окажется достаточно близко, чтобы ему это помешало. И наоборот.

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

А как быть с распределённой командой? Ну, тогда вам не повезло. Чтобы уменьшить негативные последствия, используйте как можно больше технических средств: видеоконференции, вебкамеры, средства для совместного использования рабочего стола и т. п.

Не подпускайте product ownerа слишком близко

Product owner должен находиться настолько близко к команде, чтобы в случае возникновения вопросов, команда могла бы спросить его лично, и чтобы он имел возможность на своих двоих подойти к доске задач. Но он не должен сидеть в одной комнате с командой. Почему? Потому что есть вероятность, что он не сможет не вдаваться в подробности, а команда не сможет правильно сработаться (т. е. не достигнет состояния полной автономности, самомотивации и сверхпродуктивности).

Если честно, то это всего лишь догадки: в действительности, я сам никогда не видел, чтобы product owner сидел рядом с командой, а, значит, у меня нет оснований говорить, что это плохая идея. Мне это просто подсказывает внутреннее чутьё и другие ScrumMaster'а.

Не подпускайте менеджеров и тренеров слишком близко

Эту главу мне писать немного тяжело, ведь я был как менеджером, так и тренером …

Тесная работа с командами входила в мои непосредственные обязанности. Я создавал команды, переходил из одной команды в другую, программировал с ними в парах, тренировал ScrumMaster'ов, организовывал планирования спринтов и т. д. Оглядываясь назад можно сказать, что я творил Хорошие Дела. И это всё благодаря моему опыту в гибкой разработке программного обеспечения.

Но потом меня назначили (звучит тема Дарта Вейдера) руководителем отдела разработки. В общем, я стал менеджером. Это означало, что моё присутствие автоматически делало команду менее самоорганизующейся. «О! Шеф тут. У него, небось, есть куча идей о том, что надо сделать, и кто должен этим заняться. Давай-ка послушаем».

Я придерживаюсь следующей точки зрения: Если вы Scrum-тренер (и возможно совмещаете эту роль с ролью менеджера), не бойтесь очень плотно работать с командой. Но только в течение определённого промежутка времени, а потом оставьте команду в покое и дайте ей возможность сработаться и самоорганизоваться. Время от времени контролируйте её (однако не очень часто). Это можно делать, посещая демо, изучая доску задач или принимая участие в ежедневном Scrum’е. Если вы увидите как можно улучшить процесс, отведите ScrumMaster'а в сторонку и дайте ему дельный совет. Не стоит поучать его на глазах у всей команды. Посещение ретроспективы (см. стр. 51 «Как мы проводим ретроспективы») тоже будет не лишним. Если степень доверия к вам со стороны команды невелика, то сделайте доброе дело, не ходите на ретроспективы, а то ваше присутствие заставит команду молчать о своих проблемах.

Если Scrum-команда работает хорошо, обеспечьте её всем необходимым, а потом оставьте в покое (за исключением демо, разумеется).

Как мы проводим ежедневный Scrum

Наш ежедневный Scrum очень похож на то, как это описывают в книгах. Каждый день он начинается в одно и то же время, в одном и том же месте. Вначале, мы предпочитали проводить его в отдельной комнате (это были дни, когда мы использовали sprint backlog'n в электронном формате), однако сейчас мы проводим ежедневный Scrum у доски задач в комнате команды. Нет ничего лучше!

Обычно мы проводим встречу стоя, поскольку это уменьшает вероятность того, что продолжительность нашей «планёрки» превысит 15 минут.