[Из песочницы] Workflow одного спринта agile команды разработки
Не буду претендовать на свежесть или уникальность, хотелось рассказать своими словами простой материал со стороны описания пользы понятий и действий. Бездумный карго-культ, который насаживают сверху редко приносит 100% пользу.
Возможно многие, кто пришел в IT сам, а не в студенческую пору через стажерство в крупной компании, познакомились с различными стилями управления командой, точнее с их отсутствием. Когда левые люди ломятся напрямую мимо менеджера со своими просьбами сделать простенькую задачку. Когда начальство начальства ставит задачу и срок сдачи, абсолютно игнорируя оценки разработчиков. Когда начальник начинает орать, принимая задачу, что он просил не это. Когда вас заставляют ходить на все подряд совещания. Когда важная для разработки часть задачи, которую должен выполнить другой отдел запинывается под ковер. Когда менеджер начинает искать кто виноват, что срок выполнения задачи был превышен в 10 раз. и т.п.
Надеюсь текст будет полезен начинающим разработчикам, тем кто застрял в потоке рэндомных задач и процессов, или мелким командам без PM«а, когда на Тимлида спихнули все функции PM, кто хочет внести немного дисциплины в свой рабочий хаос. И совсем не хотят читать тонну литературы.
Если вы хотите спокойно разрабатывать, то вам нужно собраться, договориться и записать прозрачные правила взаимодействия друг с другом. Хотя бы самые базовые.
Любые процессы и договоренности должны составляться при участии всех заинтересованных лиц, а негативно влияющие процессы должны изничтожаться.
Хочу расписать пример базового workflow одного спринта. Со стороны пользы каждого элемента: какие действия выполняются, какие артефакты присутствуют, и зачем каждое из них нужно.
Спринт N-1: Подготовительный. Который не совсем спринт.
До начала спринта N самой разработки, часть команды занимается подготовительной работой: тестированием, одобрением, проработкой, визуализацией и т.п.
Смысл: Чтобы разработчики могли качественно выполнить поставленную задачу, достичь требуемых параметров или решить чью то проблему, до начала самой разработки следует:
а. тщательно проделать всю подготовительную работу,
б. уменьшить разночтение,
в. протестировать на пользователях или получить одобрение от стейкхолдеров,
г. создать детальную визуализацию.
Выход: набор артефактов и данных, удовлетворяющих чек-листу Definition Of Ready.
Если вы хотите улучшить взаимодействие между кодерами и всеми остальными прямыми участниками процесса разработки, то будет полезно ознакомить и разъяснить базовые функции и процессы всех участников. Среди кодеров хватает интровертов, которым не нравится, когда нарушают их процесс, но и они должны разбираться, как работают остальные, чтобы не получилось обратного эффекта. Начинаем:
Старт спринта N-1:
OKR, KPI, Требования стейкхолдеров и т.п. — набор входящих внешних условий, которые направляют разработку.
Цель спринта N.
В зависимости от входящих условий, куда разработке следует двигаться, каких параметров требуется достигнуть, кому и зачем помочь, формируется цель грядущего спринта разработки.
Смысл: цель спринта выступает как мотивация команде, объяснение смысла их деятельности, установка показателей.
При отсутствии: немотивированными кодерами в основном управляют с помощью кнута, мата, штрафов.
Любой команде нужна мотивация, чтобы разработка не превращалась в бесконечную череду бессмысленных задач, которые непонятно нужны ли кому то. Особенно в компаниях, где разработка не является основой бизнеса, часто возникает проблема, когда отдел не ценят, отчего у них падает самооценка и мотивация. Нужна прозрачная и понятная цель — помочь кому то решить проблему, повысить какие то параметры бизнеса, улучшить чью то жизнь. Даже в самой убогой компании хорошо иметь осознание смысла своей деятельности.
Backlog grooming — митинг или постоянная деятельность. Управление backlog ограниченной частью команды.
Смысл: Каждый спринт проводится встреча ограниченным составом для чистки, базовой проработки, первичной оценки сложности и реализуемости, декомпозиции, приоритезации задач в backlog.
Выход: Список релевантных и выполнимых задач.
При отсутствии: Огромный список хотелок в backlog, который никто не читает, где задачи лежат забытые годами.
Планирование спринта N-1 — митинг, на котором часть команды подготовки, на основе цели и scope грядущего спринта N выбирает, предварительно оценивает и приоритезирует задачи.
Смысл: деятельность по подготовке к спринту тоже требует некоторого порядка. Упрощается управление ресурсами.
Выход: backlog спринта N.
Разработка тестов
Зависит от стиля разработки и наличия тестировщиков в команде.
Смысл: стоит иметь готовые планы проверки работоспособности кода.
Предлагаю рассмотреть 2 варианта:
При отсутствии тестировщиков, есть вариант передачи создания тестов команде разработки. В этом случае эта деятельность производится в рамках разработки задач в спринте N. По некоторым отзывам такой подход улучшает качество кода, написанного разработчиками.
При наличии тестировщиков, можно использовать подход, когда тесты пишутся до кода. Одна из полезность в том, что разработка задачи заканчивается на разработчике, и уменьшает шанс возвращения готовой задачи от тестировщиков, когда разработчик уже переключился на выполнение другой задачи.
Проработка Use Case«ов — подробная проработка сценариев взаимодействий и результатов внутри задачи.
Смысл: описание сценариев взаимодействия задачи текстом или диаграммами улучшает понимание проблемы всеми заинтересованными сторонами. Дешевый по созданию выход может использоваться для создания тест-кейсов и прототипирования.
При отсутствии: низкая проработка ведет к расхождению понимания, что реально требуется от задачи, возможна потеря альтернативных вариантов использования.
Wireframing, mockuping и prototyping по большому счету являются одним итеративным процессом по проработке визуализации интерфейса, с последовательно увеличивающейся детализацией. Начиная с самого простого и дешевого варианта, происходит тестирование на пользователях/стейкхолдерах, соответствует ли предложенный вариант ожиданию по решению проблемы. Визуальное тестирование настолько полезно в уменьшении разночтения текстового описания и очень дешево, по сравнению с кодингом, что в компаниях с сильным дизайнерским и продуктовым лобби их начали выделять его в отдельную методологию со своими процессами, артефактами и расписанием.
Wireframing — черновая зарисовка элементов интерфейса. Ручкой на бумажке, либо в софте без особых изысков.
Смысл: быстрое и дешевое тестирование/одобрение заинтересованными сторонами выполняемой задачи. Дополнительная демонстрация визуализации резко улучшает восприятие, чем просто описательный текст.
При отсутствии: расхождение понимания, что реально создается. Повышение стоимости разработки.
При отсутствии одобрения: получайте документальное одобрение при разработке под стейкхолдера, для минимизации шанса «а я не это просил».
Выход: одобренный/протестированный черновой wireframe.
Mockuping — второй шаг проработки визуализации вашего интерфейса. Увеличение детализации.
Смысл и Отсутствие: аналогично с wireframing. Подготовка контента под верстку.
Выход: одобренный/протестированный mockup и верстка.
Prototyping — третий шаг проработки визуализации вашего интерфейса. К высокой детализации визуализации добавляется демонстрация имитации взаимодействия пользователей с продуктом.
Смысл и Отсутствие: аналогично с wireframing и mockuping.
Выход: имеем детальный прототип продукта и визуализацию взаимодействия. Плюс документальное одобрение стейкхолдерами или результат тестирования на пользователях.
DoReady = Definition of Ready — оговоренный командой разработки и предподготовки чек-лист условий, по которым будет проверяться: имеет ли проработка задач достаточный уровень, наличие всех требуемых артефактов, чтобы задача могла быть принята в разработку.
Смысл: наличие оговоренного всеми заинтересованными сторонами формального чек-листа улучшает понимание и взаимодействие внутри команды. Все знают, что и как надо сдать. Можно ткнуть носом в чеклист и послать доделывать нерадивых работников.
При отсутствии: «ой, я почти доделал, там на 95% выполнено». и… это никогда не будет доделано.
Имхо это самый главный артефакт, по разрешению базовых конфликтов между кодерами и всеми остальными. Сразу видно кто и как не доделал свою работу, что нарушил, и как это отразится на других. С прописанными правилами спорить намного сложнее, чем в случае, когда идет спор на основе мнений или давление авторитетом/должностью. Хотя модератор ПМ, который ткнет в нужный пункт всё равно полезен.
Передали всё дальше:
Спринт N. Начинаем разработку.
Старт спринта N:
Definition of Ready, Цель спринта, Список первично оцененных задач — условия (и артефакты), требуемые для начала спринта.
Планирование спринта N — митинг, на котором команда разработки, на основе цели и scope спринта N выбирает, оценивает, приоритезирует и декомпозирует задачи. В зависимости от средней скорости работы команды набирается определенный объем задач.
Смысл: основная встреча, на которой команда проверяет удовлетворительно ли проработаны задачи. Правильно ли они понимают поставленные задачи, критерии приемки. Разработчики финально оценивают стоимость задач.
При отсутствие: хаос, задачи будут ставиться в любое время, любыми непонятными людьми, даже посреди выполнения других задач.
Выход: backlog спринта N.
Замечание: в зависимости от скорости команды в спринт часто берут 70–80% задач под цель спринта, и 20–30% задач под баги, технический долг или внезапные критические задачи.
Декомпозиция и назначение задач — часто мини-митинг для команды разработки без лишних людей.
Смысл: команда с тимлидом декомпозирует задачи спринта на саб-таски сроком выполнения не более 1 дня (край 2). Саб-таски назначаются берутся разработчиками в зависимости от их специализации или предпочтений.
При отсутствии: от участия команды в процессе зависит будут ли разработчики получать интересные задачи, которые способствуют их развитию.
Выход: детализация backlog спринта N до 1 дневных саб-тасков.
Daily meeting — ежедневный короткий митинг команды разработки.
Смысл: каждый день разработчики должны синхронизироваться друг с другом: кто и что выполнил за предыдущий день, что планирует выполнять в текущий, и какие проблемы мешают выполнить задачу.
При отсутствии: никто не знает над чем работают другие, их проблемы с выполнением. Срываются сроки разработки.
Выход: прогресс фиксируется в burn down chart — графике выполнения задач.
Моё мнение, что один из основных смыслов в существовании ежедневных митингов, это внедрение дисциплины. В кодерах много интровертов, которые не хотят общаться, не хотят знать, чем занимаются другие, не хотят тратить время на митинги. Отсюда и правила проводить стоя, коротко.
На самом деле, если команда хорошо сработалась, качественно общается в чате и сразу делится любыми проблемами, то количество митингов можно сократить, перестроив встречи в постоянно идущий процесс. Но совсем отсекать не стоит.
Решение блокираторов — прямое продолжение 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% задачи. Разработчики не должны доделывать завершенные задачи после спринта, если задача четко не удовлетворяет чек-листу, то она не должна считаться принятой, и уходит на будущий спринт.
Review и демонстрация инкремента продукта — митинг, на котором разработчики демонстрируют заинтересованным лицам реализацию цели спринта.
Смысл: разработчики сами демонстрируют работоспособный новый инкремент продукта. PM/PO формально сверяет с критериями оценки задач и соответствие с DoD. Заинтересованные лица решают соответствует ли новый инкремент продукта Цели спринта.
При отсутствии: отсутствие формальной демонстрации и приемки выполненной работы уменьшает ценность критериев приемки, качество выполненной работы.
Выход: Работы команды завершена. Стейкхолдеры решают будет ли вообще следующий спринт.
Демонстрация самим разработчиком выполненной задачи полезнее и понятнее, чем безличное предоставлению нового функционала стейкхолдеру для саморазбора. И стейкхолдер видит, кто сделал для него работу, и разработчики видят для кого они решали проблему.
Сбор отзывов — продолжение Review митинга.
Смысл: наличие в одном месте всех заинтересованных сторон, команды и самого продукта позволяет провести неформальное общение, собрать идеи, предложения и т.п. Получить обратную связь на качество работы команды.
При отсутствии: выделенное формальное время уменьшает ненужные контакты между командой и стейкхолдерами в другое рабочее время.
Выход: новые данные, обратная связь.
Фидбеки вообще полезная штука, даже отзыв от стейкхолдеров на их опыт контактов с разработчиками. Повод для модификации процессов взаимодействия с внешними акторами. Улучшение отношений со стейкхолдерами текущими и будущими всегда можно эксплуатировать — заказы, бюджет, послабления и т.п.
Ретроспектива спринта N — митинг для команды разработки и PM/PO.
Смысл: обсуждение процессов и проблем команды за последний спринт, попытка изменить процессы работы для улучшение команды. Какие процессы были удачные, какие не принесли пользы или повредили, какие новые проблемы возникли и как их можно починить.
Выход: План процессного эксперимента. Процессы модифицируются на следующий спринт, чтобы оценить какие модификации полезны, а от каких стоит отказаться.
При отсутствии: насаждение процессов разработки команды сверху или их отсутствие снижает удобство работы команды, производительность и предсказуемость разработки.
Кроме банального обсуждения проблем и как их стоит решать, хочу обратить внимание на «План процессного эксперимента». Не стоит относиться к записанным процессам как вырубленным в камне — неизменным и постоянным. Добавляете новое — тестируйте, не понравилось — отсекайте.
Конец спринта N
Спринт N+1. Залить новый инкремент в продакшен
Смысл: по причине частого завершения спринта в конце рабочей недели deploy на продакшен сервер и доступ пользователям происходит уже в следующем спринте, чтобы потенциальные неполадки не вылезли в выходные.
Инкремент ушел на мониторинг параметров.
Заключение (TL; DR)
Если вы озаботитесь хотя бы некоторыми полезными вещами:
а. базовой дисциплиной
б. формированием оговоренных процессов взаимодействия друг с другом и смежниками
в. объяснением, чем и как занимаются смежники
г. гибкостью в управлению процессами
д. своевременным реагированием на возникающие проблемы
то они улучшат рабочий климат в команде разработке.
