Как проводить скрам: практическое руководство

В современной ИТ-индустрии концепция Agile стала довольно популярной. Все говорят. Почти все ИТ-компании приняли тот или иной уровень гибкости.

Канва процесса Scrum — визуальная парадигма

Под эгидой гибкой разработки также существует множество методов, включая экстремальное программирование (XP), Scrum, Crystal Methods, адаптивную разработку программного обеспечения (ASD), разработку, управляемую функциями (FDD), разработку динамических систем (DSDM) и облегченную разработку. RUP, разработка через тестирование (TDD) и многое другое. Среди многих гибких методов разработки более популярным является внедрение Scrum.

Зонтик гибкого метода

Agile или водопад? См. рисунки

В последнем отчете Standish Group были рассмотрены проекты, которые они изучали в период с 2013 по 2017 год. За этот период времени общее распределение успехов, проблем и неудач показано ниже для Agile и водопада, при этом Agile-проекты имеют примерно в 2 раза больше шансов на успех, и на 1/3 меньше вероятность отказа.

(Источник: vitalitychicago.com —  сравнение показателей успешности проектов Waterfall и Agile )

Водопад против Agile, что лучше?

В этой статье в основном рассказывается о понимании Scrum, процессе внедрения Scrum и изменениях, внесенных внедрением Scrum, а также объясняется, что такое работающий Scrum.

Что такое Скрам?

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

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

Почему Scrum потерпел неудачу в некоторых компаниях

Скрам имеет большое значение. Однако в некоторых компаниях сложно внедрить Scrum. Некоторые люди говорят, что Scrum не оказывает существенного влияния на их организацию. Почему у них такой результат? Основными причинами могут быть:

  • Agile быстрее  — у проектной команды нет правильного понимания Agile. Он просто думает, что agility — это быстро, то есть догоняет прогресс, и может быть свободен от каких-либо системных ограничений.
  • Agile быстрее, или нам нужно работать сверхурочно  — я слышал, что некоторым компаниям приходится разрабатывать новую функцию. Из-за внедрения scrum проектная команда вынуждена работать сверхурочно, а задачи разработки продолжительностью 2 недели и более будут выпущены в течение одной недели. Внедрение Scrum означает, что проектная команда работает сверхурочно, что приводит к «страху» в гибкости проектной команды;
  • Бэклог продукта плохо поддерживается  — PO не может быть квалифицирован для работы, не может разделить эффективные пользовательские истории, или разделение пользовательской истории нецелесообразно, не может реализовать разработку инкрементного поколения;
  • Проблема формирования команды  — у Scrum высокий спрос на самоорганизующиеся команды, но многие члены команды считают, что они не соответствуют стандартам самоорганизации;
  • Отсутствие Agile-культуры  — Scrum выступает за прозрачность работы, завершение проекта в режиме реального времени и признание задач каждого человека. Доска спринта и диаграмма выгорания проекта беспрепятственны, и многим людям это не нравится;
  • Осмотр и адаптация не на месте  — в процессе итерации проблема не может быть обнаружена вовремя, или проблема найдена, и проблема не может быть решена эффективно, что вызывает разочарование проектной команды. и многое другое.

Если знание Scrum застряло только в:

«Утром у меня есть идея, днем ​​она будет реализована, а ночью она будет онлайн».

Это неуместно. На мой взгляд, Scrum определенно ценен. К основным функциям Scrum относятся:

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

Однако внедрение Scrum не означает, что на него не распространяются правила и ограничения проекта. Итак, какова правильная поза для внедрения Scrum?

Шаги по внедрению Scrum

1. Назначьте заказ на покупку

PO — это владелец продукта, то есть роль, а PO — единственный владелец списка дел продукта управления. Конечно, в некоторых компаниях ПО как организация уже существует — например, наша компания реализовала ПО как организацию при внедрении Scrum.

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

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

2. Сформируйте команду разработчиков

Команда является реализатором продукта и несет ответственность за предоставление потенциального Отгружаемого приращения и «завершенного» приращения продукта в конце каждого Спринта.

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

Размер команды должен составлять от 5 до 9 человек.

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

3. Выберите Скрам-мастера

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

4. Поддерживайте бэклог продукта

Бэклог продукта — это набор всех элементов невыполненной работы, основанный на стратегии компании и видении продукта. PO сортирует все элементы в невыполненной работе продукта в соответствии с порядком приоритета в соответствии с бизнес-ценностями и формирует список приоритетных элементов. Бэклог  продукта может служить «дорожной картой» разработки продукта. Чтобы понять контекст продукта, лучшим справочным материалом являются элементы невыполненной работы.

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

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

5. Agile Estimation с использованием Story Point

Относительно гибкая оценка обычно выполняется при планировании спринта или корректировке во время спринта, а невыполненная работа продукта оценивается командой вместе с ответственным за фактическую работу по разработке и тестированию.

Чтобы планирование спринта было более эффективным на практике, PO и Scrum Master сделают приблизительную оценку перед собранием по планированию спринта. Им нужно задать такие вопросы, как:

  • Посмотрите, выполним ли план спринта?
  • Достаточно ли информации для решения этих вопросов?
  • Разумно ли разделить элемент невыполненной работы по продукту?

When the development team conducts an estimation, it is recommended to abandon the traditional method (i.e. how many hour to be assigned to the task) and use agile estimation approach by using the story point – the Fibonacci number (1, 2, 3, 5, 8, 13, 21…) Form to evaluate the effort required for the implementation of an item.

At the time of the estimation, the team needs to first identify an backlog item which might be in user story form as a reference for the estimation. In addition, it is important to note that when the single story point of the assessment is greater than 21, the user story needs to be split again, and the single user story point is no more than 8 is the ideal state.

Agile Estimation Method

6. Sprint planning meeting

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

Цикл спринта обычно фиксирован, в основном от 2 до 4 недель. Команда начинает с пользовательской истории с наивысшим приоритетом в списке задач продукта, чтобы увидеть, сколько можно сделать за спринт.

Если команда уже провела несколько спринтов, со ссылкой на:

  • «Очки истории», завершенные в предыдущих итерациях,
  • Команда может оценить приблизительные баллы для этой итерации.
  • «Очки истории» эквивалентны скорости команды.

Скрам-мастер и команда должны стремиться увеличивать это число в каждой итерации спринта.

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

7. Ежедневная встреча

Ежедневные стендапы — это источник жизненной силы для Scrum. Обычно в число участников входят PO, Scrum Master и команда. Команда общается внутри компании в фиксированном месте и в фиксированное время каждый день. Время  обычно утреннее, продолжительность не более 15 минут, и стоя. Скрам-мастер задает  членам команды следующие вопросы:

  • Что ты делал вчера?
  • Какую работу вы планируете делать сегодня?
  • Что такое препятствия и препятствия?

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

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

Скрам-мастер отвечает за устранение препятствий, с которыми сталкиваются члены команды.

8. Отслеживайте ход проекта с помощью доски задач Scrum

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

Некоторые команды хорошо умеют использовать сторонние инструменты для использования электронной Scrum-доски, такие как Visual Paradigm или Jira; некоторые команды с удовольствием используют большие автономные физические доски.

Независимо от того, используете ли вы электронную доску Scrum или физическую доску, столбцы Kanban обычно состоят из трех частей: списка дел, текущих задач и завершенных задач. По мере продвижения итерации команда будет ежедневно обновлять вопрос в соответствующей колонке Scrum Kanban.

Доска задач Scrum — визуальная парадигма

9. Отслеживание прогресса с помощью графиков выгорания

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

用燃尽图跟踪进度

10. Демонстрация продукта

Обзор Scrum и ретроспективная встреча — визуальная парадигма

Демонстрационный раздел Руководства по Scrum называется Sprint Review Meeting, в котором говорится, что он должен включать демонстрацию работы, проделанной командой разработчиков, и ответы на вопросы об инкременте продукта. Встреча обычно проводится перед выпуском этой итерации. Самая важная работа этой встречи — проверка сценариев реализации пользовательских историй с принятием оценок по каждому завершенному элементу для выполнения определения «готово».

Участником этой встречи может стать любой, не только PO, Scrum Master и команда, но и заинтересованные стороны, бизнес и менеджеры, и даже клиенты.

Это открытая встреча, участником которой может стать каждый, не только PO, Scrum Master и команда, но и заинтересованные стороны, бизнес и менеджеры, и даже клиенты.

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

11. Ретроспектива спринта

Ретроспективное собрание спринта обычно проводится на второй день после окончания этого спринта.

На ретроспективном собрании спринта следует тщательно рассмотреть следующие вопросы:

  • Что удалось улучшить;
  • Почему так случилось?
  • Почему мы проигнорировали это в то время;
  • Как можно ускорить работу.

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

  • Нет абсолютно правильного, неправильного и беспокойства,
  • Поощряйте технические столкновения;
  • Не может включать обсуждение личных нападок;
  • Сопротивляйтесь людям в цветных очках, чтобы видеть людей,
  • Направляйте всех к рациональному обсуждению;
  • Мужественно принимайте вызовы других,
  • Принимать собственные несовершенства.
  • Ответственность за собственные процессы и результаты,
  • мозговой штурм и поиск решений проблем. Это очень важно.

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

После завершения последнего спринта начните вводить новую итерацию спринта.

Резюме

Scrum  представляет собой комбинацию 3355. Основные концепции фреймворка Scrum можно просто запомнить как 3.3.5.5 следующим образом:

3 роли

3 артефакта

  • Резерв продукта
  • Бэклог  спринта — Список дел спринта
  • Увеличение продукта — возможное увеличение количества поставляемого продукта

5 событий

5 значений

  • Открыть
  • Уважать
  • Храбрость
  • Фокус
  • Обязательство

Цели 3355 стоят за тремя столпами Scrum.

  • Прозрачный
  • осмотр
  • Приспособление

Определение «Готово» (DoD) достигается путем выполнения 3 столпов с помощью 5 событий команды  Scrum .

Фреймворк Scrum 3355

Leave a Reply

Ваш адрес email не будет опубликован.