Гибкая методология Scrum

За что мы любим scrum?

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

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

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

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

Чтобы изучить Scrum с помощью Jira Software, прочитайте это руководство.

Введение

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

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

Что же такое продукт и продуктовый подход? Продукт – это не товар и не услуга в общем смысле. Продукт – это то, за что готовы платить ваши клиенты. Так, продукт компании BMW, это не средство передвижения, это драйв, удовольствие за рулем, статус и безопасность.

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

Разработка любого продукт имеет свой жизненный цикл, который можно свести к следующим этапам:

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

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

Но не все знают, что получили развитие эти методы с Пути Тойоты — Dao Toyota.

Dao toyota, lean и kanban

Помимо принципов ведения бизнеса, в Toyota сформировали основные виды потерь. К потерям относится все, что не создает ценности для продукта:

Для максимальной эффективности выстраивания рабочего процесса и устранения потерь в Toyota используется метод Kanban и Lean бережливое производство. Сначала подробнее рассмотрим Lean.

Производственная система Toyota TPS представляет собой уникальный подход к производству. Именно она породила движение за бережливое производство, которое (вместе с концепцией шести сигм) стало одной из доминирующих тенденций в разработке. Однако есть мнение, что несмотря на схожесть TPS и Lean, первое – это путь конкретной компании, а Lean production – набор методов и инструментов, которые базируются на философии Toyota, но могут быть реализованы на других производствах.

Сам термин «Бережливое производство» был введен Джоном Крафчиком в 1988 г. в рамках его работы в Международной автомобильной программе Массачусетского технологического институту. Исследования Крафчика в области бережливого производство были использованы Деймсом Вомеком и Дэниелем Джонсом в книге «Бережливое производство:

Таким образом, Lean — это не методология, так как в ней нет набора готовых инструментов. Это часть философии эффективной разработки, которая вышла из философии Toyota и впоследствии стала частью философии Agile. Lean бережливое производство призвано бороться со всеми видами потерь. В основе данной философии лежат принцип вытягивания и принцип «точно в срок» (Just in Time).

Принцип вытягивания производства предполагает производство продукта только на основании требований заказчика в строго необходимом количестве. Часто для инициации процесса производства служит карточка Kanban.

Принцип «точно в срок» (Just in time) предполагает, что система планирования и организации работы компании построена так, что все необходимые элементы поступают в производственный процесс в нужный момент и в необходимом количестве. Также этот принцип предполагает бездефектное производство, так как брак может сломать всю четкую систему планирования.

К Lean бережливому производству можно отнести следующие методы организации труда и разработки:

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

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

Слово Kanban имеет японское происхождение и переводится как «рекламный щит, вывеска».

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

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

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

Простой пример реализации доски Kanban представлен ниже. В общем случае каждый столбик является отдельным этапом жизненного цикла разработки.

Основные принципы:

Из этих принципов можно сформулировать и ограничения метода:

Версия продукта (релизность)

Это отправная точка нашего пути. План выпуска релизов формируется в предшествующем текущему году.

Версии мы ведём в формате гг.нн, где гг — год, нн — номер версии. Например, первый релиз 2020 года будет под номером 20.1, затем 20.2, 20.3 и т. д. Такой формат очень удобен, во-первых, для ведения историчности, во-вторых, для планирования задач в разрезе года.

Согласно плану выпуска в backlog Jira SM заводит версии:

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

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

Как бы то ни было, мы взяли и держим планку вот уже более 2 лет по количеству разрабатываемых релизов одновременно — 3 штуки.

Груминг

Обрастаем фактурой. Теперь у нас есть списки версий и Epic’и с BR:

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

Так сложилось исторически, что у каждой BR есть направление в большую сторону одной из функциональных команд. Соответственно, ещё на стадии заведения BR в backlog, из первичного описания, у нас складывается представление, к какой функциональной области, а равно к какой команде в большей степени относится BR. SM такой команды автоматически становится драйвером всех оргпроцессов и коммуникаций.

Оценивая задачи с командой, SM собирает свой бэклог, наполняя историями. Свой бэклог SM формирует через создание спринтов в Jira. Как говорил ранее, в главе описания процесса формирования бэклога: «Оставив «жмых» более чем из сотни задач, стали распределять по командам, там же, в бэклоге, путём создания новых спринтов с припиской Backlog.

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

Команда разработчиков scrum

На команды Scrum ложится вся основная работа. Они специалисты по принципам сбалансированной разработки. Самые успешные команды сплочены, находятся в одном месте и обычно состоят из 5–7 участников. Чтобы определить размер команды, можно обратиться к известному «правилу двух пицц», которое сформулировал глава Amazon Джефф Безос (в команде должно быть столько участников, чтобы им хватало двух пицц).

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

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

Мини-справочник scrum

Scrum

(скрам) – схватка, гибкий метод управления проектами. Термин пришел из игры рэгби.

Product Owner (продакт оунэр) – владелец продукта, связующее звено между заказчиком и командой разработки. Самая главная ответственность Product Owner – это создание и контроль Product Backlog.

Основные обязанности и ответственность Product Owner при управлении Product Backlog:

Scrum Team

(скрам тим) – собирательный образ команды, состоящей из Development Team, Scrum Master и Product Owner. Команда полностью самодостаточна и не зависит от внешних специалистов или заказчиков.

Scrum Master (скрам мастер) – арбитр, который организует и проводит совещания, следит за соблюдением всех принципов скрама, разрешает противоречия и защищает команду от отвлекающих факторов, проводит фасилитацию митингов, отвечает за учет, хранение и выдачу SCRUM-инвентаря. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса.

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

Development Team (дэвэлопмэнт тим) – команда разработки, кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д. Размер команды составляет от 5 до 9 человек (5 оптимально).

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

Stakeholders (стэкхолдэрс) – дословно акционеры, лица, которые инициируют проект (бизнес-заказчики), которым скрам-проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review).

Модели разработки. agile

Параллельно с внедрением различных методологий в производстве, развивается процесс разработки программного обеспечения. Предпосылки для внедрения принципов проект-менеджмента в процесс разработки ПО зародились в конце 60х — начале 70-х годов 20 века в связи с резким увеличением производительности ЭВМ при значительном снижении его стоимости.

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

Формируется жизненный цикл разработки ПО, который в общем виде можно представить так:

Методология разработки может быть жесткой (или традиционной), например, по каскадной модели, или гибкой.

Каскадная модель (waterfall) была представлена доктором У. Ройсом ещё в 1970 году. В его основе лежит логическая последовательность шагов, которые должна быть предприняты на протяжении жизненного цикла разработки ПО. Каждый этап согласовывается компетентными сотрудниками, документируется и передаётся дальше.

Недостатки

• Не все проекты можно выполнять по такой методологии. Для госзаказов, к примеру, Scrum многие специалисты считают неприменимой.
• Отсутствие фиксированных бюджета и срока (имеется ввиду не спринт, а в целом время, нужное для получения готового продукта) на выполнение также осложняет заключение юридических договоров.
• Немотивированная или низкоквалифицированная команда не сможет работать эффективно. А далеко не все сотрудники отличаются самоорганизованностью. Это же может повысить затраты на подбор и отбор кадров.
• С некомпетентностью можно столкнуться и при подборе специалистов на роль Scrum-мастера. Сейчас очень много людей, имеющих на руках сертификат о том, что они прошли обучение. При этом далеко не всегда эти люди действительно являются профессионалами и могут организовывать деятельность команды.

Дэйв Томас, один из авторов Манифеста, считает, что Agile-методологии так и не получили воплощения. Вместо этого были придуманы наборы жёстких правил (как в Scrum), а слово «Agile» превратилось в бессмысленный маркетинговый термин.

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

Платформа

Преимущества scrum

Спринты

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

После взятия в достаточном объёме задач и историй для 2 недель спринт запускается

В приведённом примере отображены дробления историй: (Часть 2), (Часть 3). В бэклоге лежит ещё по парочке «Частей» в будущие спринты.

Согласно ЖЦ доски, исполнитель проводит задачи через все циклы: Нужно сделать → Разработка → Тестирование → Выполнено.

Что касается цикла тестирования: на старте спринта тестировщики берут разработанные задачи в соответствующем статусе «Тестирование». Окей, а как быть с задачами, которые к концу спринта будут только разработаны? Здесь мы идём по двум сценариям:

1. Если функциональность не затрагивает монолит, да даже если и затрагивает, но разработчик на 100% уверен в своём результате и находит поддержку тестировщика, то выходим на показ и тестим на горячую.
2. Если дорабатывалось что-то глобальное, то тестирование переносим на следующий спринт.

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

Процесс ведения спринта описан ранее. Остановлюсь на ещё одном инструменте в Jira, который использую в рабочем процессе и который будет полезен тем, кто держит руку на пульсе — Отчёт по спринту.

А именно — диаграмма погашения. Диаграмма отражает текущую ситуацию команд с задачами. Любые отклонения — сигнал к действию.

Наша адаптация гибкой методологии Scrum оказалась настолько гибка, что в каждый описанный выше шаг мы можем вносить корректировки согласно потребностям существующих и стартующих процессов производства. В то же время нам удаётся придерживаться вектора философии Agile и достигать синергии внутри проекта, команды и каждого из нас 24/7.

Я описал адаптацию Scrum к нашим процессам, но настоятельно рекомендую ознакомиться с первоисточником, возможно, пройти курсы и понять, как лучше интегрировать фреймворк у себя. Быть может, вам зайдёт чистый Scrum, без адаптаций? Пробуйте!

На этом всё. Ну а мы пошли засучивать рукава, брать маркеры, рисовать, генерировать и воплощать в цифру самые крутые вещи 🙂