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

Тут можно читать онлайн Хенрик Книберг - Scrum и XP: заметки с передовой - бесплатно полную версию книги (целиком) без сокращений. Жанр: Прочая околокомпьтерная литература, издательство C4Media, год 2007. Здесь Вы можете читать полную версию (весь текст) онлайн без регистрации и SMS на сайте лучшей интернет библиотеки ЛибКинг или прочесть краткое содержание (суть), предисловие и аннотацию. Так же сможете купить и скачать торрент в электронном формате fb2, найти и слушать аудиокнигу на русском языке или узнать сколько частей в серии и всего страниц в публикации. Читателям доступно смотреть обложку, картинки, описание и отзывы (комментарии) о произведении.

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

Scrum и XP: заметки с передовой - описание и краткое содержание, автор Хенрик Книберг, читайте бесплатно онлайн на сайте электронной библиотеки LibKing.Ru

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

Scrum и XP: заметки с передовой - читать онлайн бесплатно полную версию (весь текст целиком)

Scrum и XP: заметки с передовой - читать книгу онлайн бесплатно, автор Хенрик Книберг
Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

Да — работает, если вы (или ответственный за проведение этого собрания) очень строги относительно того, чтобы собрание было сжатым.

Формат собрания:

1. Новости и уточнения со стороны руководителя разработки. Например, информация о предстоящих мероприятиях, событиях.

2. «Карусель». Один человек из каждой продуктовой группы [7] группы команд, вовлечённых в разработку одного продукта (прим. переводчика) отчитывается в том, что было сделано за прошлую неделю, что планируется сделать на этой неделе и о проблемах. Некоторые другие люди так же отчитываются (например, начальник отдела по работе с клиентами, начальник отдела контроля качества).

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

Это собрание для подачи сжатой информации, а не для дискуссий или рефлексии. Если этим и ограничиться, то 15-ти минут вполне хватает. Иногда оно занимает больше времени, но очень редко больше 30ти минут. Если завязывается интересная дискуссия, я её приостанавливаю и предлагаю всем заинтересованным остаться и продолжить её после собрания.

Почему мы проводим «Пульс» всем коллективом? Потому, что мы заметили, что Scrum-of-Scrums уровня компании посвящен преимущественно отчётности. На нём очень редко возникали дискуссии. Кроме того, информация, озвучиваемая на Scrum-of-Scrum'е, очень интересна и многим из тех, кто на него не попадает. Обычно командам интересно, чем занимаются другие команды. И мы посчитали, если всё равно нужно тратить время на информирование друг друга, то почему бы не присутствовать всем.

Чередование ежедневных Scrum'ов

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

Этот пример расписания относится к тому периоду, когда у нас был ежедневный scrum в разных комнатах, а не в комнате совещаний команды. Обычно встречи планируются на 15 минут, но каждая команда получала 30 минутный временной слот на случай, если ей надо было немного задержаться.

Это очень удобно по двум причинам:

1. Люди, подобные мне и product owner’а могут посетить все ежедневные scrum’ы за одно утро. Нет лучшего способа получить представление о том, как проходит спринт, и в чем основные проблемы.

2. Команды могут посещать ежедневные Scrum'bi друг друга. Не очень часто, но иногда случается, что две группы работают в смежных областях, и участники групп заглядывают друг к другу на ежедневные Scrum’ы, чтобы быть в курсе происходящего.

Обратная сторона медали заключается в ограничениях для команды — теряется возможность изменить время проведения ежедневного Scrum'а. Хотя, на самом деле, для нас это не составляло проблемы.

«Пожарные» команды

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

Мы разрубили этот гордиев узел тем, что выделили специальную «пожарную» команду и отдельную Scrum-команду.

Задачей Scrum-команды (с благословления Product owner’а) была стабилизация системы и предотвращение потенциальных пожаров. А «пожарная» команда (её мы назвали «командой поддержки») выполняла две задачи:

1. Тушить пожары.

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

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

В каждую команду были включены старшие разработчики, чтобы команды не слишком зависели друг от друга.

В основном этот подход был решением проблемы внедрения Scrum'а. Как вообще можно начать практиковать Scrum, если команда не может спланировать свою работу больше, чем на один день вперёд? Нашим ответом на это, как сказано выше, было разделение команд.

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

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

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

Разбивать product backlog или нет?

Предположим, у вас есть один продукт и две Scrum-команды. Сколько вам нужно product backlog'ов? Сколько Product owner’а? Выбор достаточно сильно повлияет на то, как будут проходить встречи по планированию спринта. Мы оценили три возможных подхода.

Подход первый: Один product owner — один backlog

«Должен остаться только один». Наш любимый подход.

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

Ближе к делу. Давайте посмотрим, как проходит встреча по планированию спринта для этой команды. Встреча по планированию спринта проходит на нейтральной территории.

Прямо перед встречей product owner называет одну из стен «стеной product backlog» и развешивает на ней истории (учетные карточки), отсортированные по приоритету. Он продолжает вешать их, пока не займёт всю стену. Как правило, такого количества историй более чем достаточно для спринта.

Каждая Scrum-команда выбирает пустой участок стены и вешает там своё название. Это будет их «командная стена». После этого каждая команда отклеивает истории со «стены product backlog», начиная с самых важных, и переклеивает их на свою «командную стену».

Читать дальше
Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать


Хенрик Книберг читать все книги автора по порядку

Хенрик Книберг - все книги автора в одном месте читать по порядку полные версии на сайте онлайн библиотеки LibKing.




Scrum и XP: заметки с передовой отзывы


Отзывы читателей о книге Scrum и XP: заметки с передовой, автор: Хенрик Книберг. Читайте комментарии и мнения людей о произведении.


Понравилась книга? Поделитесь впечатлениями - оставьте Ваш отзыв или расскажите друзьям

Напишите свой комментарий
x