Эта статья в основном поможет вам понять весь процесс гибкой разработки Scrum, начиная с определения и цели Scrum, agile-манифеста, ролей людей в Scrum, процесса разработки Scrum и 12 принципов Agile.
1. Определение и цель Scrum
Scrum — это основа для разработки и обслуживания сложных продуктов, это постепенный, итеративный процесс разработки, цель которого — сделать разработчиков такими же быстрыми и увлеченными, как игра в невежество, благодаря командной работе, повысить эффективность работы. Создавать ценность для компании за счет эффективного взаимодействия команды.
Во-вторых, гибкая декларация
На самом деле до публикации Agile Manifesto уже существовало и использовалось множество agile-практик, таких как: Scrum, XP, KanBan и т.д. Agile Manifesto был опубликован, потому что эти практики продвигают agile-разработку индивидуально, а не как консорциум, без единого набора рекомендаций. Итак, 17 agile-сооснователей решили опубликовать Agile-манифест, чтобы совместно продвигать движение agile-разработки по всему миру. Вот 4 предложения из Agile Manifesto:
3. Роли персонала в Scrum
3 персонажа
Люди в Scrum делятся на 3 роли: Владелец Продукта, Scrum Master и Команда Разработки (Команда).
- Владелец продукта: определить все функции продукта, определить содержание и дату выпуска продукта, нести ответственность за ввод и вывод продукта, определить приоритеты функций, которые необходимо разработать в соответствии с изменениями рынка, разумно скорректировать функции продукта и последовательность итераций, утвердить или отклонить доставку итераций.
- ScrumMaster: ScrumMaster не является руководителем проекта, у него нет права назначать задачи, нет права оценивать, нет права отдавать приказы, он направляет членов проектной команды, чтобы они выполняли действия в соответствии с принципами и методами Scrum, руководит команда, чтобы завершить практику Scrum и отразить ее ценность, устранить трудности, с которыми сталкивается команда, убедиться, что команда компетентна в своей работе, и поддерживать эффективную производительность, заставить команду работать в тесном контакте, заставить команду работать индивидуально выполнять несколько функций и защищать команду от нежелательных внешних воздействий.
- Команда разработчиков: классическая команда состоит из 5-9 человек, в состав команды входят программисты, тестировщики, дизайнеры пользовательского интерфейса и т. д. Взаимоотношения в команде должны быть закреплены в итерации, функции отдельных лиц могут быть скорректированы в начале новой итерации. , Команда Самоорганизованная и управляемая (самоорганизованная, самоуправляемая), все члены команды работают полный рабочий день.
В-четвертых, процесс разработки Scrum
(картинка взята из интернета)
В отличие от водопадной модели, которая делит процесс разработки на требования, дизайн, кодирование, тестирование и т. д., Scrum делит весь процесс разработки на несколько итераций (называемых спринтами, спринтами), обычно длящихся от 2 до 4 недель, наиболее распространенными из которых являются 2 недели. . Scrum фокусируется не на завершении процесса за определенный период времени, а на всех необходимых частях процесса, которые необходимо завершить за этот период времени. Требования, дизайн, кодирование, тестирование, ввод в эксплуатацию должны быть выполнены за одну итерацию, и каждая итерация должна производить работающее программное обеспечение.
4.1 Пять встреч
Весь процесс разработки Scrum делится на пять конференций:
1) Совещание по отработке невыполненных работ
Совещание по планированию итерации проводится за 3 дня до начала собрания, в нем должны участвовать Владелец Продукта и Скрам-мастер, а также должны участвовать ключевые разработчики или архитекторы, время контролируется от 30 минут до 1 часа.
Владелец продукта описывает набор пользовательских историй, которые команда хочет реализовать на следующей итерации, и описывает их присутствующим членам команды в порядке реализации Скрам-мастер и присутствующие участники анализируют пользовательские истории и четко указывают выделяет области, которые, по мнению команды, требования неясны, и Владелец Продукта фиксирует это на месте. После встречи Скрам-мастер и архитектор, а также присутствующие участники анализируют, какие технические задачи необходимо включить в пользовательскую историю Сначала скрам-мастер устанавливает подзадачи, чтобы команда могла более точно оценить баллы задачи во время совещания по планированию итерации.
В конце собрания владелец продукта гарантирует, что проблемы, поднятые командой, могут быть решены до начала собрания по планированию итерации.Если команда находит области, которые необходимо усилить или улучшить, у владельца продукта остается два три дня, чтобы укрепиться, в то время как в центре внимания собрания. Не тратьте время на совещании по планированию итерации, занимаясь этим.
2) Спринт планирования встречи
Владелец Продукта формирует Бэклог Продукта. Список характеристик продукта — это набор детализированных требований, которые должны быть описаны с точки зрения ценности для клиента и расставлены по приоритетам.
Скрам-мастер созывает соответствующий персонал для проведения собрания по планированию итерации.Планирование итерации проводится в первый день каждой итерации, чтобы выбрать невыполненную работу этой итерации и оценить рабочую нагрузку этой итерации.
Владелец продукта объясняет наиболее важные функции продукта одну за другой, а команда разработчиков совместно оценивает рабочую нагрузку, необходимую для невыполненной работы, пока рабочая нагрузка этой итерации не достигнет насыщения. Владелец продукта участвует в обсуждении и отвечает на вопросы, связанные с требованиями, но не вмешивается в результаты оценки. Члены команды забирают задание (или распределяют его по согласованию с руководителем группы), и выполняют задание самостоятельно или с другими, время встречи контролируется в пределах 1-2 часов.
3) Ежедневное стендап-совещание
Команда использует ежедневные стендап-совещания, чтобы сообщить о прогрессе.Через 15 минут команда разработчиков использует диаграмму выгорания, чтобы показать общий прогресс; если нет особой причины и нет изменений во время итерации, команда участники должны ответить на следующие 3 вопроса на ежедневном стендап-совещании:
- что ты делал вчера?
- Что ты собираешься сегодня делать?
- Вам нужно иметь место, чтобы помочь вам?
Это обязательства членов команды друг перед другом.
4) Ретроспективная встреча
Команда представляет результаты итеративной работы владельцу продукта, который дает комментарии и отзывы. Оценивайте завершение задачи с точки зрения того, может ли пользовательская история быть успешно реализована. Вся команда должна участвовать, скрам-мастер, владелец продукта, команда и, возможно, клиент в течение 1-2 часов.
5) Ретроспективная встреча
Проводите короткие сеансы размышлений после каждой итерации, чтобы резюмировать, что прошло хорошо, а что нет. Хорошие сохраняются, плохие отбрасываются. На совещании пришли к выводу: что делать, что продолжать, на чем остановиться, в целом контролировалось в течение 15-30 минут.
Scrum - это набор процессов разработки и тип Agile. Реализация в основном зависит от людей, подчеркивая, что она самоорганизуется и движется самостоятельно. Только постоянно и тщательно испытывая ее в практических приложениях, мы можем понять истинное значение Scrum. и эффективно использовать Scrum.
4.2 12 Принципы
Ниже приведены принципы гибкой разработки 12. Эти принципы 12 служат руководящими принципами гибкой разработки для процесса разработки программного обеспечения, а также объясняют манифест гибкой разработки с практической значимостью. Я надеюсь, что вы внимательно изучите его на практике.
Мы следуем этим рекомендациям:
- Нашей высшей целью является удовлетворение наших клиентов за счет своевременной и непрерывной поставки ценного программного обеспечения.
- Приветствуются изменения требований даже на поздних стадиях разработки проекта. Чтобы эффективно использовать изменения спроса, чтобы помочь клиентам получить конкурентное преимущество.
- Непрерывно доставляйте полезное программное обеспечение с циклами от недель до месяцев, чем короче, тем лучше.
- Во время проекта деловые люди и разработчики должны работать вместе.
- Уметь мотивировать проектных людей, предоставлять им необходимые условия и поддержку и доверять им выполнение работы.
- Самый эффективный метод общения как внутри команд, так и между ними — беседа лицом к лицу.
- Доступное программное обеспечение является основным индикатором прогресса.
- Гибкие процессы способствуют устойчивому развитию. Стороны проекта, разработчики и пользователи должны иметь возможность поддерживать постоянную и стабильную скорость выполнения.
- Усовершенствование технологий и постоянное совершенствование дизайна повысят маневренность.
- Быть кратким означает максимально сократить ненужную работу. Это искусство.
- Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами.
- Команды регулярно размышляют о том, как они могут быть более эффективными, и соответствующим образом корректируют свое поведение.
Автор: Свен красавчик
Источник: Технологический институт CreditEase.