Как поставить процесс разработки в компании, когда ты сам о современных методологиях ничего не знаешь…

Table of Contents:

• Дисклеймер
• Преследуемые цели
• Современные методологии разработки
  • Agile software development
  • Scrum
  • Kanban
• Артефакты Scrum
  • Product Backlog
  • Sprint Backlog
  • Sprint Burndown Chart
  • Инкремент Продукта
• Роли в Scrum
  • Product Owner
  • Scrum Master
  • Team (команда проекта)
• Процесс разработки Scrum
  • Планирование спринта
  • Ежедневный Скрам
  • Разработка
  • Обзор Спринта
  • Ретроспектива спринта
  • Другие виды активности scrum
• Классы обслуживания Kanban
• После всего выше сказанного, что хотим получить?
• Инструменты
  • Система labels
• Постановка задач
  • SMART
  • PURE
  • CLEAR
• Источники

Дисклеймер

Я не тратил годы (даже месяцы) на изучение гибких методологий.

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

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

Спойлер:

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

Преследуемые цели

• Сведение к минимуму бюрократии и регламентов

  Нежелание заводить какие-либо неудобные инструменты.

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

  Я заметил, что много кто ведет backlog в excel. Пока, первичный позыв, отказаться от этого и вести бэклог продукта в redmine, бэклог спринта в gitlab через milestone (посмотрим что из этого выйдет).

• Работа короткими циклами

  Здесь преследуются две цели:

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

    Даже с самым минимальным функционалом, главное, чтобы им можно было пользоваться.

    И в нашем случае, начать тестировать на реальном железе.

  • Ускорение процесса разработки и уменьшение трат личного мыслетоплева на планирование разработки. Так вся команда видит сроки, видит что успеваем, что не успеваем, разбирается почему.

• Понятие всей команды разработки о её целях

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

  Ведь когда знаешь, что в итоге должно получиться — это сильно помогает сфокусироваться.

Современные методологии разработки

Очень советую к просмотру:

Agile software development

Серия подходов к разработке программного обеспечения, опирающихся на использование динамичной, итеративной разработки (короткими 1-2 недельными циклами, спринтами).

Аджайл — теория, философия.

12 принципов, которые составляют Agile Methodology, можно поделить на 4 главные идеи:

1. Люди и взаимодействие важнее процессов и инструментов.
2. Работающий продукт важнее исчерпывающей документации.
3. Сотрудничество с клиентом важнее согласования условий контракта.
4. Готовность к изменениям важнее следования первоначальному плану.

Scrum

Скрам — это фреймворк, набор элементов, решений рабочего процесса.

Скрам — практика, правила, в которых описано что и в каком порядке необходимо делать.

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

Вся команда ответственна за результат — конкретного виноватого при провале никогда нет. Взаимная помощь и работа сообща внутри коллектива — один из столпов Скрама.

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

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

Kanban

Kanban ― это метод улучшения процессов разработки и часть agile-философии.

В его основе ― «Манифест гибкой разработки программного обеспечения».

Вы можете использовать все практики, часть практик или не использовать их вообще.

В Канбане нет строгого понятия, что есть Канбан, а что не есть Канбан.

Тоже есть принципы, но они более общие.

Базовые принципы, которые еще называют принципами управления изменениями:

1. Начните с того, что есть сейчас.
2. Договоритесь об эволюционном развитии.
3. Поощряйте развитие лидерства на всех уровнях.

Так как Канбан-метод живет в сервисной парадигме, он придерживается ее принципов:

1. Выясните потребности и ожидания заказчика, в нашем случае у нас просто есть ТЗ от заказчика, огромное, проработанное.
2. Управляйте работой, дайте людям организоваться вокруг нее.
3. Развивайте правила, чтобы улучшить показатели.

Сравнение Kanban и Scrum

Артефакты Scrum

Scrum подразумевает использование командой так называемых Артефактов.

Всего их три:

Product Backlog

Бэклог Продукта

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

Т.е. фактически это полноценная карта развития продукта, редактируемая с учетом изменений, пожеланий и изменений в процессе разработки.

Epic - эпик, самая крупная состовляющая backlog. Огромная часть функционала.

Story - стори, сторисы. Эпики делятся на стори. Более мелкая часть функционала, но она еще не является задачей, которую можно назначить.

Sprint Backlog

Бэклог спринта

Спринт — рабочий цикл. Бэклог спринта — список задач на данный конкретный цикл, т.е. что будет сделано в эти 1-4 недели для создания/улучшения продукта. Для каждого цикла создается новый бэклог.

Sprint Burndown Chart

Диаграмма сгорания задач — диаграмма, показывающая количество сделанной и оставшейся работы. Не является артефактом фреймворка Scrum.

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

Существуют разные виды диаграммы:

• диаграмма сгорания работ для спринта — показывает, сколько уже задач сделано и сколько ещё остаётся сделать в текущем спринте.
• диаграмма сгорания работ для выпуска проекта — показывает, сколько уже задач сделано и сколько ещё остаётся сделать до выпуска продукта (обычно строится на базе нескольких спринтов).

Инкремент Продукта

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

Для примера, в нашем случае, это могут быть release notes.

Роли в Scrum

В скрам роли:

• Product Owner
• Scrum Master
• Team

Product Owner

Один человек, который полностью отвечает за результат — это Владелец продута (Product Manager / Product Owner). Важно понять, что этот человек — не руководитель и не начальник. Но именно он определяет конечную цель, ставит задачи перед командой, корректирует курс разработки. Его роль можно обозначить как Тимлид (Team Leader) — он ведет проект от начала и до конца, он знает, какой результат нужен клиенту. Для того, чтобы направить команду в нужное русло Владелец продута создает Бэклог продукта.

В наших реалиях, выделить Product Owner невозможно.

Проще выделить ведущих продукт и главного среди них, благо данная иерархия легко просматривается.

Они же и будут заниматься переводом эпиков/сторей из беклога продукта в задачи.

Scrum Master

• следит за корректным применением принципов Agile и процессов (ритуалов) Scrum
• организует работу команды и обеспечивает её всем необходимым
• защищает команду, несёт ответственность за её эффективность
• только один человек.

Очень сложная роль. В классическом project management есть Руководитель проекта. В Scrum такая роль не предусмотрена. Лучшим синонимом роли Scrum Master будет “администратор”. Скрам Мастер организовывает работу команды проекта, но не вмешивается в её работу.

• Скрам мастер не назначает людей на задачи – это делает сама команда;
• Мастер не заставляет людей делать работу – это ответственность команды;
• Мастер не указывает Product Owner какие требования он должен написать – это работа владельца продукта.

Тем не менее, если скрам-процесс проходит с нарушениями (кто-либо из команды опаздывает на daily-meeting), то мастер должен вмешаться и исправить ситуацию.

Team (команда проекта)

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

Команда отвечает за разработку продукта итерациями (спринтами). Команда определяет самостоятельно:

• продолжительность спринта
• емкость (capacity) команды
• размер её фокус фактора (коэффициент слаженности)
• трудоемкость требований, которые будут реализованы в спринте
• очередность выполнения задач и много другое.

Команда НЕ принимает решений:

• какие требования являются приоритетными – это делает Product Owner.

Процесс разработки Scrum

Планирование спринта

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

Ежедневный Скрам

Каждый день проводятся 15-минутные встречи, на которых команда оценивает, как продвигается работа и синхронизирует планы на ближайшие сутки. Такая «планерка» нужна, чтобы каждый член команды понимал, куда будет двигаться разработка продукта на ближайшие 24-часа. Совещание принято не затягивать более 15 минут.

Разработка

Разработка — это непосредственно сам процесс создания продукта в текущем спринте. Результатом должен стать инкремент продукта

Обзор Спринта

Обзор спринта — это открытая презентация перед всеми заинтересованными лицами — командой разработки, пользователями, другими сотрудниками компании. Демонстрация включает в себя не только рассказы или презентации — на обзоре спринта обязательно должен быть Инкремент продукта (кто забыл — промежуточный релиз, который команда создала/улучшила за спринт).

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

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

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

Update спустя 2 недели:

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

Другие виды активности scrum

1. Можно проводить сессии с целью уменьшения bus фактора и вопросом “А какие бы задачи еще были бы тебе интересны”.

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

2. При наличии времени можно не каждый спринт проводить из бэклога.

   Можно проводить спринты с целью закрывать техдолг.

3. Так же некоторые спринты можно проводить для рефакторинга.

Классы обслуживания Kanban

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

Рассмотрим влияние стоимости задержки и соответствующий класс обслуживания на примерах:

1. Ускоренный класс – неотложная скорая помощь-реанимация. Едет по выделенной полосе. Нет времени откладывать решение проблемы. Нужно как можно скорее.
2. Класс с фиксированной датой – стоимость задержки резко возрастает после определенного периода.
3. Стандартный класс – стоимость задержки растет пропорционально времени. Если делаем сразу, получаем прибыль сразу. Если делаем долго, получаем прибыль долго.
4. Нематериальный класс – делаем, но явной прибыли эта работа не несет, стоимость задержки растет медленно. Например, уборка в доме. Можно и не убираться регулярно, но через пол года придется делать генеральную уборку.

После всего выше сказанного, что хотим получить?

Для себя хочется взять что-то между Kanban и Scrum.

Взять спринты, часть принципов, артефакты и процессы от Scrum.

От Kanban вид доски (настройть лейблы для этого), часть принципов и классы обслуживания, т.к. фиксированный спринт не совсем приемлем для нашей компании.

Из scrum возьмем:

• Спринты

  На две недели. Задачи будем собирать в спринт командой (стремимся к самоорганизующейся команде).

• Planning poker

  Пока без карт и подобного, просто будем растить компетенцию в оценке задач, оценивать будем временем.

• Retro

  В конце спринта, на пару часов смотрим, что как прошло.

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

  Надо ответить на 3 вопроса:

  • Что мы делали хорошо в спринте?
  • Что делали плохо?
  • Что сделать чтобы стало лучше?

• Возможно, если дело встанет на поток, daily затащим. По началу воздержимся.

  Надо ответить на вопросы:

  • Что делал вчера?
  • Что будешь делать сегодня?
  • Что тебе мешает/блокирует?
• Backlog и продукта и спринта.
• Общую терминологию (эпики, стори, таски, процессы, артефакты).

Из Kanban хочется взять:

• Классы обслуживания (измененные сильно)
• Возможность вносить в спринт задачи в процессе спринта
• Ориентированность на рост лидерства среди сотрудников

Инструменты

Камень преткновения в нашей компании.

Т.к. заинтересованными лицами в затаскивании какой-либо методологии разработки являются разработчики/аналитики, есть часть “хотелок” без которых не хочется обходится.

К ним относится:

• Спринты и непосредственно issue, и проекты должны быть связанны.

• Беклог продукта делится на две части.

  Первая - беклог состоящий из эпиков/сторей виден руководству, согласовывается с ним и в инструменте более удобном для них. В нашем случае это Redmine.

  Вторая - беклог состоящий из задач виден только разработчикам и сортируется и приоритезируется через лейблы. И т.е. задачи в беклог спринта “перетаскиваются” из беклога продукта явно.

В связи с этим:

• Backlog продукта ведем в Redmine.

  Именно его видит руководство, и согласовывает его.

  За актуализирование этого бэклога отвечают ведущие разработчики, аналитики.

• Backlog задач для спринтов ведем в milestione Backlog в Gitlab.

  В milestone можно сортировать задачи проектам, так что должно быть удобно

• Сами спринты ведем в milestione Gitlab

  Gitlab в milestone показывает задачи только для проектов, в которые ты добавлен, что здорово.

• Для формирования Kanban досок используем лейблы, подробнее см. Система labels.

Система labels

В связи с этим придуманна система лейблов, для более удобного поиска/приоритизации.

Статус задачи:

• Назначена = Todo
• В процессе выполнения = In progress
• На ревью = Review
• Тестируется = Testing
• Отклонена = Reject (тот кто ревьюил или тестировал отклонил реквест на доработку)
• Выполнена = Done
• Обсуждение = Discussion (переехал сюда спустя две недели из лейблов “класс задач”)

Приоритет задачи:

• M – задачи и требования, которые имеют самый высокий приоритет и должны быть первоочередно применимы к продукту в первую очередь. Без них релиз не будет выполнен (это must).
• S – важные требования, но не с самой высокой приоритетностью. Обычно они не имеют решающего значения, но все равно обязательны к исполнению (это should).
• C – требования и задачи, желательные для релиза (это could).
• W – наименее критичные требования, их можно проигнорировать или перенести до следующих релизов (это would).
• U - не назначен (undefined)

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

Спустя две недели: Начали приоритизировать не только Backlog, но и Technical Debt.

Класс задачи:

• Тех Долг
• Ошибка (Bug)
• Новый функционал
• Добавление/обновление существующего функционала
• Обсуждение

Область задачи (категория):

• CI
• Инфраструктура
• Docs
• Build systems
• Hardware
• Tests
• и тд, эти постоянно расширяться будут

Постановка задач

Для постановки задач руководствоваться будем следующими критериями правильности целей: SMART, PURE и CLEAR (может не всеми всегда, но будем стараться).

SMART

Вероятно, многие слышали про критерий SMART

S = Specific = Определенна, специализированна, четкая.

Цели должны быть обозначенными в виде четких результатов.

M = Measurable = Измерима

Цели должны быть измеримыми в конкретных показателях.

A = Achievable = Достижима

Поставленные цели должны быть достижимыми.

R = Realistic = Реалистична

Цели должны быть реалистичными, то есть достижимыми конкретными исполнителями.

T = Time-bound = Ограничена по времени

Цели должны быть реализуемыми в установленное время.

В качестве примера: “Я хочу машину” - цель не очень хорошая. Если ваш начальник поставит вам такую задачу, то шансы не попасть в его ожидания - чуть больше чем 100%.

“Я хочу синий BMW X5 с двигателем 3.0 л к 15 сентября. Бюджет есть, машины в наличии тоже есть.” - вот это уже гораздо лучше, да.

Но есть еще два критерия для целей, про которые часто забывают / не знают, но которые также полезно использовать: PURE и CLEAR.

PURE

P = Positively Stated = Позитивно сформулирована

U = Understood = Понята (не понятна, а понята)

R = Relevant = Уместна (например, связана с более глобальной целью)

E = Ethical = Этична (не приносит вред вам, близким и другим людям

CLEAR

C = Challenging = Содержит вызов (иначе может быть не так интересно)

L = Legal = Легальна (помним про уголовный и административный кодексы)

E = Environmentally Sound = Не вредит экологии (и вашему окружению)

A = Agreed = Согласована (не навязана)

R = Recorded = Записана (как говаривал легендарный CEO компании IBM Лу Герстнер: “People don’t do what you expect. They do what you inspect.” = “Люди делают не то, что вы ожидаете, а то, что вы проверяете”)

Источники

Agile/Scrum для начинающих. Что такое гибкая методология?

Digital словарь: Что значат эти термины? (дополняется)

Scrum термины

Scrum: 12 терминов, которые нужно запомнить

Planning Poker: как сделать процесс постановки задач максимально прозрачным и четким

Умное целеполагание (SMART goalsetting)

https://www.youtube.com/watch?v=cDvZaXzQezs&t=157s

https://scrumtrek.ru/blog/kanban/1360/chto-takoe-kanban-metod-maksimalno-korotko/