Agile и Scrum на пальцах / О ГИБКИХ методологиях разработки ПО понятным языком

Понимание гибких методологий Agile, производное от английского слова "гибкий", относится к методологиям, разработанным для быстрой адаптации к внешним факторам. Эти подходы направлены на предоставление готового к использованию продукта в установленные сроки, удовлетворяя потребности клиентов с помощью итеративных процессов. В отличие от жестких методологий, agile позволяет командам разработчиков работать слаженно и регулярно предоставлять функциональное программное обеспечение.

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

Гибкие методологии, семейство подходов и принципов для разработки программного обеспечения, были официально задокументированы в 2011 году на горнолыжном курорте. Манифест включает в себя четыре основные идеи: люди важнее процессов и инструментов; рабочие продукты важнее подробной документации; сотрудничество с клиентами важнее переговоров по контракту; и реагирование на изменения, а не следование плану. Эти ключевые концепции формируют основу для различных гибких методов, таких как экстремальное программирование (XP), функционально-ориентированная разработка (FDD), Scrum и Kanban.

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

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

Понимание невыполненной работы, эпопей и историй Список невыполненных работ - это список задач, необходимых для завершения разработки продукта. Он состоит не только из задач, но и из более крупных объектов, называемых epic, — больших блоков функциональности, которые могут быть выполнены в течение цикла разработки. Например, при создании социальной сети эпопеей может быть "профиль пользователя" или "платформа B2B". Эти эпопеи разбиты на более мелкие части, известные как истории.

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

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

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

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

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

Процесс проверки результатов спринта В конце каждого спринтерского цикла (одна или две недели) проводится этап проверки, на котором функциональные элементы демонстрируются заинтересованным сторонам. Это касается только полностью закрытых историй; незавершенные автоматически переносятся в следующий спринт. Цель состоит не только в демонстрации, но и в совершенствовании процессов путем проведения дополнительных совещаний, посвященных совершенствованию после проверки.

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

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

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

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

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

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

Ограничения Scrum для больших команд Увеличение размера команды может улучшить общую атмосферу, но Scrum не подходит для больших команд. Другие методологии лучше подходят для масштабных проектов с сотнями разработчиков. Классический Scrum лучше всего работает с 5-9 разработчиками и следует неформальному "правилу двух пицц" - если ваша команда не может приготовить две пиццы, пришло время либо изменить методологию, либо разделиться на более мелкие группы, используя синхронизированные Scrum—процессы.

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