SCRUM в процессе WEB разработки « проф’SAIUZ

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

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

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

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

МЕТОДОЛОГИИ УПРАВЛЕНИЯ IT ПРОЕКТАМИ

Когда команда воссоздаст всю картину спринта, то у нее появится хороший набор данных перед следующим этапом — «Генерация идей». Эти три слова необходимо написать на флипчарте или борде, и команда по кругу делится своими чувствами, которые соответствуют этим словам. Лучше не использовать это упражнение часто, так как можно выплеснуть много негативных эмоций. Прежде всего, можно разбить ретро на несколько этапов и применять на каждом этапе различные техники для организации групповой работы с командой. Теперь давайте перейдем непосредственно к проведению ретро.

При гибком подходе на протяжении всего проекта вы можете менять какие-то моменты, адаптируясь к обстоятельствам — внешним или рыночным. Не заботятся о том, чтобы вся команда разделяла видение продукта — зачем он создается и в чем его суть. Не опираются на принципы и ценности Agile, игнорируют принципы Scrum — работают только с процессной частью фреймворка. Например, когда в команде нет открытости и коллеги неохотно делятся информацией — тогда у каждого накапливается свой субъективный опыт. Основная метрика для измерения скорости работы команды — velocity.

Всего над электронным журналом мы работали несколько спринтов. После этого заказчик решил, что существующей функциональности достаточно — поэтому мы поставили разработку этого инструмента на паузу и сместили ФОКУС на конструктор расписания. Такие короткие спринты позволяют команде быть максимально гибкой и часто корректировать свои планы. Короткие спринты провоцируют больше обратной связи и релизов. А это обеспечивает гарантию, что команда работает в правильном направлении.

Понятно, не взял, но через полгода кто-то другой — взял, успешно «вошла в айти», теперь «статечна людина, член суспільства, депутат палати лордів». Давайте уже честно признаемся, что говорим заказчику «работаем по SCRUM», чтобы ему было спокойнее, а сами работаем по системе гибридный ЛеЩуР, где ЛеЩуР — лебедь, щука и рак. Вместе с тем, то же XP среди меня и моих коллег породило интерес, скорее, к инженерным практикам (юнит тесты, CI, рефакторинг). А вот как на инструмент именно управления проектом на него смотрели, как на экзотику, так как прекрасно понимали, что предлагаемая XP модель ну никак не натягивается на реалии аутсорса начала 2000х.

Бэклог

В результате вы будете двигаться итерациями «вслепую», не инспектируя и не адаптируясь. Адаптация — изменение курса на основе обратной связи, полученной https://deveducation.com/ в процессе инспекции. Прозрачность — работа, которая выполняется, видна всем стейкхолдерам. Процесс тоже должен быть известен и понятен каждому.

• Поэтому перед разработкой системы для Академии мы организовали совместный тренинг с ребятами из Scrum Ukraine.
• На практике вся сложность сводится к тому, чтобы научить разработчиков и других специалистов следовать этой самой методологии в работе.
• Он говорит, что устраивает, а что нет, какие аспекты можно улучшить.
• На каждой сессии пленнинг покера, BA/PO выбирает подготовленные истории из этого списка и обсуждает с командой.

Scrum — фреймворк, который подходит для работы над проектами с высокой степенью неопределенности. Сейчас Елена работает Program Manager в DXC Luxoft, и скоро в Laba стартует ее курс о Scrum. Нам она рассказала, в чем специфика работы по Scrum и в каких проектах лучше выбрать другой подход. Как и любой другой документ, бэклог имеет определенные критерии, которые должны быть соблюдены для успешной работы. Эти же критерии описывают то, какая информация должна быть указана, как она должна быть структурирована и кто отвечает за это. Вам, как клиенту, при разработке собственного программного продукта придется создавать бэклог для успешной разработки по современным стандартам.

Фэйл 3: Работа по привычным схемам

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

И это дает колоссальную эффективность затраченных ресурсов, времени и усилий. Необходимо договариваться с заказчиком о включении в sprint backlog технических историй и методологических часов. Для нас ретроспектива бэклог это является вторым по значимости мероприятием в Scrum после планирования спринта. Sprint demo — демонстрация результатов заказчику. Разработчики по очереди демонстрируют новые функции вживую на реальных данных.

Схематическая структура Jira для управления бэклогом

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

Как измерять результаты работы команды

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

Джефф Сазерленд рекомендует малочисленные группы — около семи человек. Он приводит данные, что если группа состоит из более чем девяти человек, то скорость ее работы падает. Затем нужно собрать «Команду», в которую войдут люди, непосредственно выполняющие работу. Они должны обладать навыками и знаниями, которые помогут воплотить идею владельца продукта в жизнь. Важными характеристиками Scrum является ее гибкость и ориентированность на клиента, так как она предполагает его (клиента) непосредственное участие в процессе работы.

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

SCRUM

Когда я обучаю людей этой методике, я часто рассказываю о своем многолетнем опыте занятий японским боевым искусством айкидо». Автор отмечает, что создавая свою методологию, он, прежде всего, смотрел на то, как работают успешные команды, а не слушал то, что они говорят. Предоставляет понятные и тестируемые требования команде. User Story (пользовательская история) — короткая формулировка намерения пользователя и что продукт должен сделать для него.