Хабрахабр

[Из песочницы] Workflow одного спринта agile команды разработки

Не буду претендовать на свежесть или уникальность, хотелось рассказать своими словами простой материал со стороны описания пользы понятий и действий. Бездумный карго-культ, который насаживают сверху редко приносит 100% пользу.

Когда левые люди ломятся напрямую мимо менеджера со своими просьбами сделать простенькую задачку. Возможно многие, кто пришел в IT сам, а не в студенческую пору через стажерство в крупной компании, познакомились с различными стилями управления командой, точнее с их отсутствием. Когда начальник начинает орать, принимая задачу, что он просил не это. Когда начальство начальства ставит задачу и срок сдачи, абсолютно игнорируя оценки разработчиков. Когда важная для разработки часть задачи, которую должен выполнить другой отдел запинывается под ковер. Когда вас заставляют ходить на все подряд совещания. и т.п.
Надеюсь текст будет полезен начинающим разработчикам, тем кто застрял в потоке рэндомных задач и процессов, или мелким командам без PM’а, когда на Тимлида спихнули все функции PM, кто хочет внести немного дисциплины в свой рабочий хаос. Когда менеджер начинает искать кто виноват, что срок выполнения задачи был превышен в 10 раз. И совсем не хотят читать тонну литературы.

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

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

Который не совсем спринт.
До начала спринта N самой разработки, часть команды занимается подготовительной работой: тестированием, одобрением, проработкой, визуализацией и т.п.
Смысл: Чтобы разработчики могли качественно выполнить поставленную задачу, достичь требуемых параметров или решить чью то проблему, до начала самой разработки следует: Спринт N-1: Подготовительный.

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

Выход: набор артефактов и данных, удовлетворяющих чек-листу Definition Of Ready.

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

Старт спринта N-1:

— набор входящих внешних условий, которые направляют разработку. OKR, KPI, Требования стейкхолдеров и т.п.

Цель спринта N.
В зависимости от входящих условий, куда разработке следует двигаться, каких параметров требуется достигнуть, кому и зачем помочь, формируется цель грядущего спринта разработки.
Смысл: цель спринта выступает как мотивация команде, объяснение смысла их деятельности, установка показателей.
При отсутствии: немотивированными кодерами в основном управляют с помощью кнута, мата, штрафов.

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

Управление backlog ограниченной частью команды.
Смысл: Каждый спринт проводится встреча ограниченным составом для чистки, базовой проработки, первичной оценки сложности и реализуемости, декомпозиции, приоритезации задач в backlog.
Выход: Список релевантных и выполнимых задач.
При отсутствии: Огромный список хотелок в backlog, который никто не читает, где задачи лежат забытые годами. Backlog grooming — митинг или постоянная деятельность.

Упрощается управление ресурсами.
Выход: backlog спринта N. Планирование спринта N-1 — митинг, на котором часть команды подготовки, на основе цели и scope грядущего спринта N выбирает, предварительно оценивает и приоритезирует задачи.
Смысл: деятельность по подготовке к спринту тоже требует некоторого порядка.

В этом случае эта деятельность производится в рамках разработки задач в спринте N. Разработка тестов
Зависит от стиля разработки и наличия тестировщиков в команде.
Смысл: стоит иметь готовые планы проверки работоспособности кода.
Предлагаю рассмотреть 2 варианта:
При отсутствии тестировщиков, есть вариант передачи создания тестов команде разработки. Одна из полезность в том, что разработка задачи заканчивается на разработчике, и уменьшает шанс возвращения готовой задачи от тестировщиков, когда разработчик уже переключился на выполнение другой задачи. По некоторым отзывам такой подход улучшает качество кода, написанного разработчиками.
При наличии тестировщиков, можно использовать подход, когда тесты пишутся до кода.

Дешевый по созданию выход может использоваться для создания тест-кейсов и прототипирования.
При отсутствии: низкая проработка ведет к расхождению понимания, что реально требуется от задачи, возможна потеря альтернативных вариантов использования. Проработка Use Case’ов — подробная проработка сценариев взаимодействий и результатов внутри задачи.
Смысл: описание сценариев взаимодействия задачи текстом или диаграммами улучшает понимание проблемы всеми заинтересованными сторонами.

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

Ручкой на бумажке, либо в софте без особых изысков.
Смысл: быстрое и дешевое тестирование/одобрение заинтересованными сторонами выполняемой задачи. Wireframing — черновая зарисовка элементов интерфейса. Повышение стоимости разработки.
При отсутствии одобрения: получайте документальное одобрение при разработке под стейкхолдера, для минимизации шанса “а я не это просил”.
Выход: одобренный/протестированный черновой wireframe. Дополнительная демонстрация визуализации резко улучшает восприятие, чем просто описательный текст.
При отсутствии: расхождение понимания, что реально создается.

Увеличение детализации.
Смысл и Отсутствие: аналогично с wireframing. Mockuping — второй шаг проработки визуализации вашего интерфейса. Подготовка контента под верстку.
Выход: одобренный/протестированный mockup и верстка.

К высокой детализации визуализации добавляется демонстрация имитации взаимодействия пользователей с продуктом.
Смысл и Отсутствие: аналогично с wireframing и mockuping.
Выход: имеем детальный прототип продукта и визуализацию взаимодействия. Prototyping — третий шаг проработки визуализации вашего интерфейса. Плюс документальное одобрение стейкхолдерами или результат тестирования на пользователях.

Все знают, что и как надо сдать. DoReady = Definition of Ready — оговоренный командой разработки и предподготовки чек-лист условий, по которым будет проверяться: имеет ли проработка задач достаточный уровень, наличие всех требуемых артефактов, чтобы задача могла быть принята в разработку.
Смысл: наличие оговоренного всеми заинтересованными сторонами формального чек-листа улучшает понимание и взаимодействие внутри команды. и… это никогда не будет доделано. Можно ткнуть носом в чеклист и послать доделывать нерадивых работников.
При отсутствии: “ой, я почти доделал, там на 95% выполнено”.

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

Передали всё дальше:

Начинаем разработку. Спринт N.

Старт спринта N:

Definition of Ready, Цель спринта, Список первично оцененных задач — условия (и артефакты), требуемые для начала спринта.

В зависимости от средней скорости работы команды набирается определенный объем задач.
Смысл: основная встреча, на которой команда проверяет удовлетворительно ли проработаны задачи. Планирование спринта N — митинг, на котором команда разработки, на основе цели и scope спринта N выбирает, оценивает, приоритезирует и декомпозирует задачи. Разработчики финально оценивают стоимость задач.
При отсутствие: хаос, задачи будут ставиться в любое время, любыми непонятными людьми, даже посреди выполнения других задач.
Выход: backlog спринта N.
Замечание: в зависимости от скорости команды в спринт часто берут 70-80% задач под цель спринта, и 20-30% задач под баги, технический долг или внезапные критические задачи. Правильно ли они понимают поставленные задачи, критерии приемки.

Саб-таски назначаются берутся разработчиками в зависимости от их специализации или предпочтений.
При отсутствии: от участия команды в процессе зависит будут ли разработчики получать интересные задачи, которые способствуют их развитию.
Выход: детализация backlog спринта N до 1 дневных саб-тасков. Декомпозиция и назначение задач — часто мини-митинг для команды разработки без лишних людей.
Смысл: команда с тимлидом декомпозирует задачи спринта на саб-таски сроком выполнения не более 1 дня (край 2).

Срываются сроки разработки.
Выход: прогресс фиксируется в burn down chart — графике выполнения задач. Daily meeting — ежедневный короткий митинг команды разработки.
Смысл: каждый день разработчики должны синхронизироваться друг с другом: кто и что выполнил за предыдущий день, что планирует выполнять в текущий, и какие проблемы мешают выполнить задачу.
При отсутствии: никто не знает над чем работают другие, их проблемы с выполнением.

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

Решение блокираторов — прямое продолжение daily meeting.
Смысл: после того как разработчики озвучили проблемы с реализацией задач, проходит обсуждение задач, которые команда может решить внутри, тогда она уходит к участникам, а блокираторы с внешним решением уходят к PM.
При отсутствии: проблемы с реализацией должны решаться сообща, максимально быстро, чтобы никто искусственно не затягивал прогресс.

Когда интроверты сбежали по своим углам, вот тут уже можно обсудить проблемы и варианты их решения.

Commits/Code Review — верификация кода другими членами команды.
Смысл: 1-2 других члена команды должны посмотреть новый код и одобрить качество, стиль и т.п.
При отсутствии: повышение количества ошибок в коде, низкое качество и стиль.

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

Deploy to Development server/пред демонстрация — залить код на девелоперское окружение/сервер.
Смысл: любую реализацию задачи можно залить на девелоперское окружение и пригласить заинтересованных лиц для тестирования и предварительного одобрения выполненной работы.
При отсутствии: на финальном демо спринта можно попасть в неудобное положение продемонстрировав неработающую или неправильную реализацию.
Выход: неформальное одобрение выполненной задачи.

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

Все знают, что является критерием выполненной задачи, а что нет.
При отсутствии: без четких критериев появляется “доработка” задач после попыток сдать их. Definition of Done — аналогично с Definition of Ready, это чек-лист принципов, по которым PM/PO принимает выполненные задачи.
Смысл: создается командой разработки совместно с PM/PO для предсказуемости параметров принятия работы. Либо задачи остаются недоделанными до финальных требований.

Хорошо уменьшает количество спорных моментов.
Не дает PM/PO внаглую давить должностью. Документальное соглашение, по которым PM/PO принимает задачу и её критерии, одобренное обеими сторонами. Разработчики не должны доделывать завершенные задачи после спринта, если задача четко не удовлетворяет чек-листу, то она не должна считаться принятой, и уходит на будущий спринт. Отсекает “выполненные” на 95% задачи.

PM/PO формально сверяет с критериями оценки задач и соответствие с DoD. Review и демонстрация инкремента продукта — митинг, на котором разработчики демонстрируют заинтересованным лицам реализацию цели спринта.
Смысл: разработчики сами демонстрируют работоспособный новый инкремент продукта. Стейкхолдеры решают будет ли вообще следующий спринт. Заинтересованные лица решают соответствует ли новый инкремент продукта Цели спринта.
При отсутствии: отсутствие формальной демонстрации и приемки выполненной работы уменьшает ценность критериев приемки, качество выполненной работы.
Выход: Работы команды завершена.

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

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

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

Какие процессы были удачные, какие не принесли пользы или повредили, какие новые проблемы возникли и как их можно починить.
Выход: План процессного эксперимента. Ретроспектива спринта N — митинг для команды разработки и PM/PO.
Смысл: обсуждение процессов и проблем команды за последний спринт, попытка изменить процессы работы для улучшение команды. Процессы модифицируются на следующий спринт, чтобы оценить какие модификации полезны, а от каких стоит отказаться.
При отсутствии: насаждение процессов разработки команды сверху или их отсутствие снижает удобство работы команды, производительность и предсказуемость разработки.

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

Конец спринта N

Спринт N+1. Залить новый инкремент в продакшен
Смысл: по причине частого завершения спринта в конце рабочей недели deploy на продакшен сервер и доступ пользователям происходит уже в следующем спринте, чтобы потенциальные неполадки не вылезли в выходные.

Инкремент ушел на мониторинг параметров.

Заключение (TL;DR)

Если вы озаботитесь хотя бы некоторыми полезными вещами:

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

то они улучшат рабочий климат в команде разработке.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть