Как мы проводим Scrum-of-Scrums. Читать онлайн "Scrum и XP: заметки с передовой" Предисловие Майка Кона

Хенрик Книберг

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

К сожалению, на благодарности нам выделили всего лишь страничку. Поэтому я постараюсь представить всех наших активистов в фактах.

Максим Харченко умудрялся переводить даже на море. Спасибо Гипер. NET

Дима Данильченко - директор и по совместительству (да и такое бывает ☺) один из самых активных переводчиков в нашем проекте.

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

Боря Лебеда автоматизировал конвертацию оригинала из word’а в wiki формат. Я и понятия не имел, что это можно сделать так легко.

Ярослав Гнатюк знает Хенрика лично.

Антон Марюхненко - самый молодой и перспективный.

Сергей Петров - самый старший и опытный.

Марина Кадочникова - наша единственная девушка-переводчица.

Серёжа Мовчан, конечно же, я про тебя не забыл ☺. Просто хотел сказать тебе отдельное спасибо. Ты был тем вторым локомотивом, благодаря которому нам удалось дотянуть до победного конца. Ведь как говорится в одной японской поговорке: «Начинать легко, продолжать сложно».

Спасибо Марине Зубрицкой и Лёше Мамчию за финальную вычитку и редактуру. Им удалось найти свыше ста ошибок, в уже, казалось бы, вылизанном тексте. Нет предела совершенству.

Не забудем мы и про тех, у кого было желание, но, как часто это бывает, не было времени: Сергей Евтушенко, Артём Марченко, Алексей Тигарев, Тим Евграшин, Александр Кулик.

Лёша Солнцев,

инициатор и координатор первого украинского краудсорсингого проекта, Certified Scrum Master

P.S. Оригинал книги вы можете скачать по адресу http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

Предисловие Джефа Сазерленда

Командам необходимо знать основы Scrum’а. Как создать и оценить product backlog? Как получить из него sprint backlog? Как работать с burndown-диаграммой и вычислять производительность(velocity) своей команды? Книга Хенрика - это базовое руководство для начинающих, которое поможет командам перейти из состояния «мы пробуем Scrum» в состояние «мы успешно работаем по Scrum’у».

Хорошая реализация Scrum"а становится всё важнее и важнее для команд, которые хотят получить инвестиции. Я выступаю в качестве тренера по гибким методологиям для группы компаний с венчурными инвестициями, помогая им в стремлении вкладывать деньги только в настоящие Agile-компании. Глава группы инвесторов требует от компаний, составляющих инвестиционный портфель, ответа на вопрос, знают ли они производительность своих команд. Многих этот вопрос ставит в тупик. Будущие инвестиции требуют от команд знания собственной производительности разработки программного обеспечения.

Почему это так важно? Если команда не знает собственной производительности, следовательно product owner не может разработать стратегический план развития продукта с достоверными датами релизов. Без такого плана компанию может постичь неудача, в результате чего инвесторы потеряют свои деньги.

С этой проблемой сталкиваются разнообразные компании: большие и маленькие, старые и новые, с финансированием и без. Во время недавнего обсуждения реализации Scrum"а компанией Google на лондонской конференции я решил узнать у аудитории, состоящей из 135 человек, кто из них использует Scrum? Я получил утвердительный ответ лишь от тридцати человек. Затем я поинтересовался, соответствует ли их процесс Nokia-стандарту итеративной разработки. Итеративная разработка - это ключевое положение Agile Manifest’а: «Постарайтесь предоставлять версии работающего программного обеспечения как можно чаще и раньше». В результате проведения ретроспектив с сотнями Scrum-команд в течение нескольких лет, Nokia выработала некоторые базовые требования к итеративной разработке:

Итерации должны иметь фиксированную длину и не превышать шести недель.

К концу каждой итерации код должен быть протестирован отделом качества (QA) и работать как следует.

Из тридцати человек, которые сказали, что работают по Scrum’y лишь половина подтвердила, что их команды придерживаются первого принципа Agile Manifest’а и соответствую Nokia-стандарту.

Затем я спросил их, придерживаются ли они Scrum-стандарта, разработанного Nokia:

У Scrum-команды должен быть один product owner и команда должна знать, кто это.

У Product owner’а должен быть один product backlog с историями и их оценками, выполненными командой.

У команды должна быть burndown-диаграмма, а сама команда должна знать свою производительность.

На протяжении спринта никто не должен вмешиваться в работу команды.

Из тридцати команд, внедряющих Scrum, только у трёх процесс разработки соответствовал стандартам Nokia. Я думаю, что только эти три команды получат дальнейшие инвестиции от венчурных капиталистов.

Основная ценность книги Хенрика состоит в том, что если вы будете следовать его советам, то у вас будет и product backlog, и оценки для product backlog’а, и burndown-диаграмма. Вы также будете знать производительность вашей команды и сможете использовать все наиболее важные практики высокоэффективных Scrum-команд. Вы пройдёте Nokia Scrum-тест, за что инвесторы оценят вас по достоинству. Если вы - начинающая компания, то, возможно, вы получите такие жизненно важные для вашего проекта финансовые вливания. Возможно вы - будущее разработки программного обеспечения, вы - создатель нового поколения программ, которые станут лидерами рынка.

Предисловие Майка Кона

И Scrum, и ХР (экстремальное программирование) требуют от команд завершения вполне осязаемого куска работы, который можно предоставить пользователю в конце каждой итерации. Эти итерации планируются таким образом, чтобы быть короткими и фиксированными по времени. Такая целенаправленность на выпуск рабочего кода за короткий промежуток времени означает только одно: в Scrum и ХР нет места теории. Agile-методологии не гонятся за красивыми UML моделями, выполненными при помощи специальных case-средств, за созданием детализированных спецификаций или написанием кода, который сойдёт на все случаи жизни. Вместо этого Scrum и ХР команды концентрируются на том, чтобы завершить необходимые задачи. Эти команды могут мириться с ошибками в ходе работы, но они понимают, что лучшее средство выявить эти ошибки - это перестать думать о софте на теоретическом уровне анализа и дизайна, и, закатав рукава, полностью посвятить себя созданию продукта.

Именно акцент на действии, а не на теории ярко выделяет эту книгу среди прочих. То, что Хенрик разделяет эти взгляды, видно с самых первых страниц книги. Он не предлагает нам длинное описание того, что такое Scrum; вместо этого он просто ссылается на необходимые веб-ресурсы. Первым делом Хенрик начинает с описания того, как его команда работает со своим product backlog"ом. Затем он проходит по всем элементам и практикам правильно поставленного agile-проекта. Без теоретизирования. Без справочных данных. Ничего этого не нужно: книга Хенрика - не философское объяснение, почему Scrum работает или почему мы должны делать так, а не иначе. Это описание того, как работает одна успешная agile-команда.

Хенрик предлагает набор избранных практик и описывает живые примеры, чтобы помочь нам понять, как использовать Scrum и ХР на передовой.

Предисловие - Эй! А Scrum-то работает!

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

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

Не хочеться говорить, что я удивлён, но… так и есть. После беглого знакомства с парой книг по теме, Scrum произвёл на меня хорошее впечатление, даже слишком хорошее, чтобы быть похожим на правду. Так что неудивительно, что я был настроен слегка скептически. Однако после года использования Scrum"а, я настолько впечатлён (и большинство людей в моих командах тоже), что, скорее всего, буду использовать Scrum во всех новых проектах, ну, разве что кроме случаев, когда есть веская причина не делать этого.

Как мы проводим Scrum-of-Scrums

Scrum-of-scrums - это регулярные встречи, цель которых - обсуждение различных вопросов между Scrum-мастерами.

Как-то мы работали над четырьмя продуктами. Над тремя из них работало по одной Scrum-команде, а над четвёртым - 25 человек, которые были разделены на несколько Scrum-команд. Это выглядело следующим образом:

У нас было два уровня Scrum-of-Scrums: «уровня продукта», который проводился с участием команд продукта Д, и «уровня компании» для участников всех команд.

Scrum-of-Scrums уровня продукта

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

Наша повестка дня имела следующий вид:

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

2. Любые другие проблемы, относящиеся к компетенции нескольких команд одновременно, которые нужно обсудить. Например, вопросы интеграции.

На самом деле повестка дня Scrum-of-Scrums не так уж и важна - важнее, чтобы эта встреча проводилась регулярно.

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

Из книги Прибыльный блог: создай, раскрути и заработай автора Литвин Евгений

Из книги автора

Как мы проводим демо Демонстрация спринта - очень важная часть Scrum’а, которую многие все же недооценивают. «Ой, а нам что, обязательно делать демо? Мы все равно ничего интересного не покажем!» «У нас нет времени на подготовку разных &%$# демо!» «У меня куча работы, не

Из книги автора

Как мы проводим ретроспективы Хотя основной формат немного варьируется, но в основном мы делаем так: Выделяем 1-3 часа, в зависимости от того насколько долгая ожидается дискуссия. Участвуют: product owner, вся команда и я собственной персоной. Располагаемся либо в отдельной

Из книги автора

Как мы сочетаем Scrum с XP То, что Scrum и XP (eXtreme Programming) могут быть эффективно объединены, не вызывает сомнений. Большинство рассуждений в интернете поддерживают это предположение, и я не хочу тратить время на дополнительные обоснования.Тем не менее, одну вещь я всё-таки должен

Из книги автора

Повышайте качество, включив тестировщиков в Scrum-команду О, я уже слышу эти возражения:«Но это же очевидно! Scrum-команды должны быть кросс-функциональными!»«В Scrum-команде не должно быть выделенных ролей! У нас не может быть человека, занимающегося только тестированием!»Я быПроводим интернет-семинары и обучающие курсы Этот вид заработка подходит для самых амбициозных и компетентных блогеров, профессионалов, гуру, экспертов в своей теме. Или для тех блогеров, которые незаметно для себя таковыми стали.Блогер может заработать деньги на

Название книги: Scrum и XP: Заметки с передовой

Дети часто боятся непонятного: работающую стиральную машину, гудящую трансформаторную будку, разобранную папину машину.
Пока родители не рассказывают, что это и как это работает.

Многие с опаской впервые садятся за руль. Пока инструктор не рассказывает про передачи.

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

В книге «Scrum и XP: Заметки с передовой» в роли мамы и инструктора выступает Хенрик Книберг – консультант компании Crisp в Стокгольме (www.crisp.se), который специализируется на Java и Agile-разработке.

Хенрик рассказывает нам, как работает интересующий нас механизм, с какими проблемами сталкивался он в своей работе, когда лучше проводить скрам-митинги, как понять, подходит ли эта команда для скрама? Что делать, если теоретически команда не подходит, и комната для совещаний в удобное время занята, при этом отказаться от Scrum – не предлагать!

Нет, Хенрик не дает нам советов и рецептов. Он рассказывает, КАК он справлялся со стихией Scrum.

Обратимся к предисловиям к книге:

«Командам необходимо знать основы Scrum"а. Как создать и оценить product backlog? Как получить из него sprint backlog? Как работать с burndown-диаграммой и вычислять производительность(velocity) своей команды? Книга Хенрика – это базовое руководство для начинающих, которое поможет командам перейти из состояния "мы пробуем Scrum" в состояние "мы успешно работаем по Scrum"у".»

«Именно акцент на действии, а не на теории ярко выделяет эту книгу среди прочих.
Хенрик предлагает набор избранных практик и описывает живые примеры, чтобы помочь нам понять, как использовать Scrum и XP на передовой.»

«По словам Кена Швебера, Scrum – это не методология, это фреймворк. А это значит, что Scrum не дает готовых рецептов, что делать в тех или иных случаях. Вот незадача!

Но у меня для вас есть хорошая новость: я расскажу, как именно я практикую Scrum... очень подробно и со всеми деталями. Однако, и без плохой новости не обойдётся: я расскажу всего лишь о том, как практикую Scrum я. Это значит, что вам не обязательно делать всё точно так же. На самом деле, в зависимости от ситуации, я и сам могу делать что-то по-другому. Достоинство Scrum"a и одновременно самый большой его недостаток в том, что его необходимо адаптировать к вашей конкретной ситуации.»

Итак, о чем же конкретно рассказывает Хенрик в своей книге?

Как его команда работает с product backlog"ом, как они готовятся к планированию спринта и как его планируют. О создании sprint backlog’а и проведении ежедневных Scrum’ов. Как обустроена комната команды, как проводится демо и ретроспектива.

Как организован отдых между спринтами и как команда Хенрика планирует релизы и составляет контракты с фиксированной стоимостью. Как получается сочетать Scrum с XP и как можно успешно управляеть несколькими Scrum-командами, даже если они являются географически распределёнными командами.

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

В главе «Соотношение спринтов и фаз приёмочного тестирования» Хенрик выделяет 2 подхода: Подход №1: "Не начинать новые истории, пока старые не будут готовы к реальному использованию", Подход №2: "Начинать реализовывать новые истории, но наивысшим приоритетом ставить доведение старых до ума" и Неправильный подход: "Клепать новые истории". Какой из подходов выбрать – решать вам.

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

Он просто рассказывает, как успешно с этим работать.

Русский перевод книги сделан энтузиастами из сообщества AgileUkraine, ПМами, разработчиками и тестировщиками, что втройне ценно, так как душа разработчика вложена не только в оригинал, но и в перевод

Annotation

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

Хенрик Книберг

Предисловие Джефа Сазерленда

Предисловие Майка Кона

Предисловие – Эй! А Scrum-то работает!

Вступление

Отказ от ответственности

Зачем я это написал

Так что же такое Scrum?

Как мы работаем с product backlog’ом

Дополнительные поля для user story

Как мы ориентируем product backlog на бизнес

Как мы готовимся к планированию спринта

Как мы планируем спринт

Почему без product owner’а не обойтись

Почему качество не обсуждается

Планирование спринта, которое никак не заканчивается

Распорядок встречи по планированию спринта

Определяем длину спринта

Определение цели спринта

Выбор историй, которые войдут в спринт

Как product owner может влиять на то, какие истории попадут в спринт?

Как команда принимает решение о том, какие истории включать в спринт?

Планирование, основанное на интуиции

Планирование, основанное на методе оценки производительности

Какую технику мы используем для планирования?

Почему мы используем учетные карточки

Критерий готовности

Оценка трудозатрат с помощью игры в planning poker

Уточнение описаний историй

Разбиение историй на более мелкие истории

Разбиение историй на задачи

Выбор времени и места для ежедневного Scum’а

Когда пора остановиться

Технические истории

Как мы используем систему учёта дефектов для ведения product backlog’а

Свершилось! Планирование спринта закончено!

Как мы доносим информацию о спринте до всех в компании

Как мы создаем sprint backlog

Формат sprint backlog’а

Как работает доска задач

Пример 1 - после первого ежедневного Scrum’а

Пример 2 - еще через пару дней

Тревожные сигналы на доске задач

Эй, как насчет отслеживания изменений?

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

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

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

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

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

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

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

Как мы обновляем доску задач

Как быть с опоздавшими

Как мы поступаем с теми, кто не знает, чем себя занять

Как мы проводим демо

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

Памятка по подготовке и проведению демо

Что делать с «недемонстрируемыми» вещами

Как мы проводим ретроспективы

Почему мы настаиваем на том, чтобы все команды проводили ретроспективы

Как мы проводим ретроспективы

Как учиться на чужих ошибках

Изменения. Быть или не быть

Типичные проблемы, которые обсуждают на ретроспективах

«Нам надо было больше времени потратить на разбиение историй на подзадачи»

«Очень часто беспокоят извне»

«Мы взяли огромный кусок работы, а закончили только половину»

«У нас в офисе бардак и очень шумно»

Отдых между спринтами

Как мы планируем релизы и составляем контракты с фиксированной стоимостью

Определяем свою приёмочную шкалу

Оцениваем наиболее важные истории

Прогнозируем производительность

Сводим всё в план релиза

Корректируем план релиза

Как мы сочетаем Scrum с XP

Парное программирование

Разработка через тестирование (TDD)

TDD и новый код

TDD и существующий код

Эволюционный дизайн

Непрерывная интеграция (Continuous integration)

Совместное владение кодом (Collective code ownership)

Информативное рабочее пространство

Стандарты кодирования

Устойчивый темп / энергичная работа

Как мы тестируем

Скорее всего, вам не избежать фазы приёмочного тестирования

Минимизируйте фазу приёмочного тестирования

Повышайте качество, включив тестировщиков в Scrum-команду

Тестировщик - это «последняя инстанция».

Чем занимается тестировщик, когда нечего тестировать?

Повышайте качество - делайте меньше за спринт!

Стоит ли делать приёмочное тестирование частью спринта?

Соотношение спринтов и фаз приёмочного тестирования

Подход №1: «Не начинать новые истории, пока старые не будут готовы к реальному использованию»

Подход №2: «Начинать реализовывать новые истории, но наивысшим приоритетом ставить доведение старых до ума»

Неправильный подход: «Клепать новые истории»

Не забывайте об ограничении системы

Возвращаясь к реальности

Как мы управляем несколькими Scrum-командами

Сколько сформировать команд

Виртуальные команды

Оптимальный размер команды

Синхронизировать спринты или нет?

Почему мы ввели роль «тимлида»

Как мы распределяем людей по командам

Нужны ли узкоспециализированные команды?

Подход №1: команды, специализирующиеся на компонентах

Подход №2: универсальные команды

Стоит ли изменять состав команды между спринтами?

Участники команды с частичной занятостью

Как мы проводим Scrum-of-Scrums

Scrum-of-Scrums уровня продукта

Scrum-of-Scrums уровня компании

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

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

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

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

Подход второй: Один product owner - несколько backlog"ов

Подход третий: Несколько product owner’ов - несколько backlog’ов

Параллельная работа с кодом

Ретроспектива для нескольких команд

Как мы управляем географически распределёнными командами

Оффшорная разработка

Члены команды, работающие дома

Памятка ScrumMaster’а

В начале спринта

Каждый день

В конце спринта

Хенрик Книберг

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

Как мы делаем Scrum

Максим Харченко умудрялся переводить даже на море. Спасибо Гипер.NET

Ярослав Гнатюк знает Хенрика лично.

Антон Марюхненко - самый молодой и перспективный.

Сергей Петров - самый старший и опытный.

Марина Кадочникова - наша единственная девушка-переводчица.

Лёша Солнцев,

инициатор и координатор первого украинского краудсорсингого проекта, Certified Scrum Master

P.S. Оригинал книги вы можете скачать по адресу http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

Предисловие Джефа Сазерленда

Максим Харченко умудрялся переводить даже на море. Спасибо Гипер. NET

Ярослав Гнатюк знает Хенрика лично.

Антон Марюхненко - самый молодой и перспективный.

Сергей Петров - самый старший и опытный.

Марина Кадочникова - наша единственная девушка-переводчица.

Лёша Солнцев,

инициатор и координатор первого украинского краудсорсингого проекта, Certified Scrum Master

P.S. Оригинал книги вы можете скачать по адресу http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

Предисловие Джефа Сазерленда

Итерации должны иметь фиксированную длину и не превышать шести недель.

К концу каждой итерации код должен быть протестирован отделом качества (QA) и работать как следует.

Затем я спросил их, придерживаются ли они Scrum-стандарта, разработанного Nokia:

У Scrum-команды должен быть один product owner и команда должна знать, кто это.

У Product owner’а должен быть один product backlog с историями и их оценками, выполненными командой.

У команды должна быть burndown-диаграмма, а сама команда должна знать свою производительность.

На протяжении спринта никто не должен вмешиваться в работу команды.

Предисловие Майка Кона

Предисловие - Эй! А Scrum-то работает!