новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts

3причины,почемуСпринтыполезны

Перевод статьи Дэвида Старра “3 reasons to sprint“.
Некоторые команды спрашивают, почему так важно заканчивать работу за Спринт. “Это искусственное ограничение моей работы.” – поясняют они. “Почему мы не можем потратить столько времени, сколько необходимо? Почему всё должно быть готово до завершения Спринта?» По моему опыту, эти разочарованные команды, скорее всего, хотят перейти от плохо внедренного Скрама к катастрофически реализованному Канбану и работе по системе “точно вовремя” (just-in-time).
Использование спринтов дает три преимущества, которых нет в системе “точно вовремя”.

Сфокусированность
Команды разработки, которые работают по системе “точно вовремя” (just-in-time), часто страдают от недостатка фокуса. Границы Спринт помогают разработчикам работать творчески. Другими словами, разработчики не должны беспокоиться о том, какую следующую задачу им необходимо взять, чтобы уменьшить cycle time.

Резерв времени
Резервное время – необходимый элемент всех инноваций. Успешные Скрам команды создают себе резерв времени, взяв немного меньший объем работы в Спринт. Когда разработчики работают в непрерывном потоке от задачи к задаче, буфер считается пустой тратой, и команды будут стремиться от него избавиться, что негативно скажется на инновациях.
Если резервного времени недостаточно, чтобы наращивать возможности команды (например, через автоматизацию или внедрение новых практик), то команда может начать стагнировать и со временем совсем перестанет развиваться.

Обязательные Инспекция и Адаптация
Когда команды прекращают придерживаться границ Спринта, они часто вскоре начинают пропускать те события Скрама, которые в первую очередь помогали им успешно работать: Планирование спринта, Обзор спринта и Ретроспективу Спринта. Каждое из этих событий предназначено для инспекции (анализа) и адаптации (улучшения). Когда мы перестаем их проводить, уже внедренные улучшения начинают исчезать.
События Скрама являются базовыми для развития и постоянного совершенствования команды. Без них моментально начнется ее ослабление.

Заключение
Я описал свои ТОП-3 причины использовать Спринты в работе команд, хотя их намного больше. Если вы задумываетесь о том, чтобы отказаться от Спринтов в пользу потоковой работы над задачами по принципу “точно вовремя”, не забудьте про составляющие инноваций, которые вы рискуете потерять: сфокусированность, резерв времени, инспекция и адаптация.


Примечание переводчиков
В результате выбора варианта перевода названия системы “just-in-time” между “точно в срок” и “точно вовремя” предпочтение отдано последнему.

Плюсануть
Поделиться
Отправить
Класснуть
Линкануть
Вотсапнуть
Запинить
Ещё по теме
Студент Unusual Concepts делится ценными советами по сдаче экзамена PSM и PSPO 1. Цена попытки — 200$, но лучше сходить на тренинг Unusual Concepts. Рекомендую! Выйдет в четыре раза дороже, но оно того стоит. 2. Внимательно и вдумчиво изучить scrum guide на английском (!) языке. Что угодно делайте, чтобы понять и запомнить всё, что там написано. Мне лично помогло рисовать mind maps. Кому-то помогает внимательно прочесть 3 раза. 3. Пройти open assessments на сайте scrum.org (open, product owner, developer). Nexus не надо. Здесь задача в том, чтобы понять логику того, кто эти тесты делал (эта же самая логика используется и в сертификационном экзамене). Проходить советую вдумчиво, читая то, что написано. Не советую тупо запоминать вопросы и ответы на них, т.к. хотя в экзамене и есть copy-paste из open assessment, их, во-первых, всего лишь около половины, а во-вторых, это вам только помешает понять суть. Из этих же соображений советую тренироваться по одной попытке на каждый open assessment и потом перерыв. Потом опять по одной на каждый и опять перерыв. Идеально, если чередовать с изучением scrum guide. Обязательно читаем результаты теста! Там годные комментарии к ответам. Добивайтесь устойчивого 100% результата. 4. Если у вас с английским языком проблемы — то советую подтянуть. Лучший способ, на мой взгляд, делать всё, что я тут описал, но со словарём. Добиваемся, чтобы весь scrum guide и все open assessments были понятны без словаря. Во время экзамена словарь держите под рукой — попадаются непонятные слова, но целиком полагаться на него не стоит (один товарищ пытался загонять все вопросы в он-лайн переводчик, и в результате получил 53% правильных ответов). 5. Сертификационный экзамен сдаётся на сайте scrum.org, где другой интерфейс, чем у тестовых экзаменов. Это может добавить мандража, если станет неожиданностью. Но существенных отличий там нет. Разве только можно закладки ставить. 6. Перед сдачей самого экзамена убеждаемся, что у нас есть час времени, когда точно никто не будет отвлекать и интернет точно не отвалится. Я перестраховывался 3g модемом, но, слава Богу, не пришлось. 7. Во время экзамена ни в коем случае не надо париться над сложными вопросами! Если вопрос сложный, то выбирайте то, что вам кажется верным, ставьте на вопрос закладку (bookmark) и идите дальше. Большинство вопросов (около 60 из 80), при условии что всё вышеописанное вами сделано добросовестно, вы отобъёте за 30 минут. Оставшиеся 30 минут можно потратить, чтобы внимательно и вдумчиво разобрать все закладки. У меня даже получалось в интернете поискать варианты в это время. 8. Не надо ставить закладку на все вопросы, в которых у вас есть сомнения. Ставьте закладку только там, где вы вообще не уверены. Иначе получится неприятная картинка, когда сначала вы закладки ставили на средне-сложные вопросы, а потом стали ставить только на очень сложные, и в результате под конец теста у вас не 20 закладок, а 40, и времени в обрез. 9. Помните — это экзамен. Не надо быть самоуверенным, а то завалить его проще простого. Но и мандражить сильно не надо. Просто тщательно подготовьтесь, и всё будет хорошо. Оригинал поста в Фейсбуке
Андрей Толмачев рассказывает, как разрешить взаимное недовольство Владельца Продукта и Команды Разработки.

Условия задачи

Представьте такую ситуацию. Вы — новый Скрам-мастер. Ваша Команда Разработки состоит из системного аналитика, двух разработчиков и двух специалистов по тестированию. Длина Спринта — две недели. Команда работает со сложной системой на старой платформе, поэтому для каждого элемента Бэклога Продукта аналитика, разработка и тестирование попадают в отдельные Спринты. В течение последнего Спринта Команда не успела сделать работу, взятую в Спринт, поэтому на Ретро Владелец Продукта допытывается, кто чем занимался в течение Спринта. Владелец Продукта жалуется, что Команда работает очень медленно. Члены Команды жалуются, что бизнес контролирует и микроменеджит их. Как разрешить взаимное недовольство Владельца Продукта и Команды Разработки? Давайте разбираться.

Что происходит

Для каждого элемента Бэклога Продукта аналитика, разработка и тестирование попадают в отдельные Спринты — это означает, что элемент будет готов к выпуску только через три Спринта. В таком случае истинная длина Спринта равна шести неделям — это больше, чем допускает Руководство по Скраму.
Максимальная продолжительность Спринта — один календарный месяц. При большем сроке планирования возможны изменения целей, увеличение сложности и рост рисков.
Руководство по Скраму Когда Команда редко поставляет готовый Инкремент, то редко получает обратную связь от стейкхолдеров и клиентов. В результате:
  • возрастает риск сделать не то, что надо. Способность реагировать на изменения падает;
  • стабильность процесса падает, прогнозировать работу сложно. Например, тестирование выявляет дефекты через недели после разработки. Баги обнаруживаются поздно, поэтому объём «поддержки» будет меняться от Спринта к Спринту;
  • рабочий процесс перестаёт быть прозрачным.
По этим причинам Команда Разработки теряет доверие Владельца Продукта и стейкхолдеров, следовательно, давление возрастает и начинаются конфликты.

Решение

Скрам-мастер не может решить проблему самостоятельно, но может помочь своей Команде следующим образом:
  • объяснить описанную выше системную динамику и её вредные последствия. Скрам-команда должна понимать, что правило Скрама про Done Increment каждый Спринт — это естественное системное решение их проблемы;
  • помочь сформулировать или пересмотреть минимальный DoD, который может быть выполнен в течение Спринта и который обеспечит готовность Инкремента к релизу;
  • научить Команду Разработки правильно декомпозировать элементы Бэклога. Небольшие элементы в Бэклоге Продукта способствуют ранней поставке, оптимизации ценности Продукта и улучшению потока работы;
  • помочь договориться взять в следующий Спринт хотя бы один небольшой элемент Бэклога, но довести его до состояния Done;
  • визуализировать поток работы. Прозрачность — залог успеха;
  • устранить простои в работе. Для этого Скрам-мастер обучает Команду хорошим инженерным практикам, например, общему владению кодом, стимулирует развитие T-shaped или E-shaped людей в Команде, заключает командные соглашения;
  • объяснить Владельцу Продукта, что причина задержек — технический долг и убедить его выплатить.
Используйте Ретроспективу, чтобы найти лучшие решения по устранению препятствий. Помните, что эти решения — эксперименты, не факт, что они принесут ожидаемый эффект. Поэтому инспектируйте результаты прошлых решений и адаптируйте решения на следующих Ретроспективах.

Итоги

Готовый Инкремент в конце Спринта — это важнейшие правило Скрама, которое помогает избежать роста рисков, потери предсказуемости и гибкости. Описанные причинно-следственные связи полезно знать, чтобы понимать, почему Скрам требует соответствующий DoD, готовый к релизу Инкремент каждый Спринт. Следующие действия могут помочь в достижении этой цели:
  • декомпозиция работы на небольшие PBI;
  • визуализация потока работы в Спринте и поиск основных узких мест;
  • устранение «простоев» работы с помощью командных соглашений, хороших инженерных практик и развития T-shaped или Е-shaped людей;
  • планомерная ликвидация технического долга.
Комментарии
Сергей Медведев, 26 апреля 2017

Коллеги, по поводу фразы
"Успешные Скрам команды создают себе резерв времени, взяв немного меньший объем работы в Спринт."
На сколько меньший ? как проконтролировать, чтобы чересчур меньший не получился ? а если будут злоупотреблять ?