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

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

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

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

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

Спринт 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 на продакшен сервер и доступ пользователям происходит уже в следующем спринте, чтобы потенциальные неполадки не вылезли в выходные.

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