Team Agile Scrume

Team - команда программистов, менеджеров, тестировщиков и продукт менеджеров, решающая общую цель.
Заказчик - тот кто оплачивает разработку и ставит общие требования к функционалу. Обычно их много: продукт-owner, отдел продаж, отдел тех.поддержки, клиенты, маркетологи. В простейшем случае ставят задачи поровну.
Product Owner - тот кто знает приоритет всех задач и общие принципы продукта он формирует все задачи на ближайший спринт несет ответственность за увеличение продаж. Понимает все фичи модули и возможности и задачи из бек лога. Может выполнять функции скрам менеджера.
Fеature Owner - постановщик, тот кто пробил новую возможность или модуль и лучше всех знает как он должен работать и выглядеть, это могут быть или сотрудники или клиенты задачи решаются только после обсуждения с Fеature Owner'ом.
Спринт (итерация) - период на который составляется план историй и задач которые клеятся на доску, у нас 1 неделя.
Новая Версия - 4 итерации, в конце проводится презентация и ретроспектива. В конце итерации готовый дистр выкладывается на сайт, проводится рассылка новости и на сайт новостью. Новая версия выкладывается не позже 10 числа.
Планирование новой версии - долгосрочное планирование. Release planning должен быть в тикетной системе (джире) или в crm. Создает владелец продукта. Оценку времени по фичам делает команда. После выпуска версии релиз архивируется, нерешенные задачи переносятся в следующий беклог. Новые задачи и фичи планируются на через 1-2 мес всегда. Одна версия фичи, следующая баги и т.д. Если беклог и версию нельзя четко сформулировать, прописываем вектор развития продукта на ближайшие итерации и берем задачи соответствующие вектору например: вектор повышения стабильности.
Ежедневный SCRUM (митинг) - 10-30 мин совещание обычно с 11-00 до 15-00, но всегда в одно время. Мы выбрали в 15-00. Вопросы: что сделал, что буду делать, есть ли проблемы, и как улучшить. Нельзя вступать в длинные дискуссии, только отдельно после скрама. Скрам проводится всегда в одно и тоже время не ждем опоздавших или занятых. Стоя, по желанию кто то сидя.
SCRUM мастер - помогает команде самоорганизовываться, следит за соблюдением правил, проводит SCRUM митинги, проводит ретроспективы и презентации, решает спорные и тупиковые вопросы, решает конфликты. Часто совместитель с другой должностью(но не программист).
День Знаний - один день в месяц когда все читают книги или тематические статьи.
Product Backlog (Беклог продукта) - план итерации, приоритезированный список задач, которые взялись делать разработчики. Сюда можно включать инфраструктурные задачи. Может меняться по ходу итерации по составу иногда, но не по суммарному колву дней задач. Наш беклог в отличии от scrum может содержать и разные задачи, а не только фичи.
Диаграмма сгорания - BurnDown идеальный и реальный график решения задач во времени
Демонстрация (презентация) - проводится в конце спринта или версии, показывают насколько лучше стал продукт, участвуют маркетологи,продажники,поддержка,клиенты(можно по ютуб потом посмотреть).
Ретроспектива - проводится в конце спринта, анализ как можно улучшить процесс, но не искать виноватых. Составляется план улучшения процесса.
Критерий готовности - Definition of Done Описание и чеклист определяющий что фича готова, формулируется Владелецем продута и членами команды.\\(Работает, Тестится, автотесты работают и тд) мы не используем, тк пропагандируем прием задачи постановщиком.
Alarm task - критикал задача возникшая во время итерации не входящая в беклог(не висящая на доске).

Обычно в пн, снимаются все задачи с доски и итерация планируется заново.
Для первичных стадий продукта можно не снимать нетронутые задачи.
Владелец продукта и команда планируют беклог.
Суммарное время задач разработчика не должно превышать идеальную производительность*коэффициент. То есть коэф идеального дня к реальному.
Коэффициент начальный 0.5 - значит не более 2.5 задачи на 1 разработчика, можно прописывать индивидуальный каждому в строке.
Длина задачи может быть 0, 0.5, 1. Мелкие можно объединять. Если длина больше 1, то надо декомпозировать.
Все запланированные задачи клеятся магнитами на доску на выбранного исполнителя, доска доступна всем.
В отличии от обычного scrum у нас меньше демократии, так как есть специализации, тимлид вместе с скрам менеджером может назначать задачу, любой может возразить и попросить задачу себе, если ему очень интересна она.
Доска задач - обязательно физическая доска с бумажными наклейками или карточки с магнитами. Висит на видном месте. За доску отвечает скрам-мастер. Карточки может двигать только скрам-мастер или с его разрешения и в его присутствии исполнитель. Митинги проводятся возле доски. Доска актуализируется только во время скрама. Доска должна выглядеть опрятно, имена и сетку обновляем маркером время от времени.

Наша доска отличается

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

• Проводится от 11-00 до 15-00 независимо от наличия сотрудников всегда в одно и тоже время. (постоянное время выбирает команда).
• Проводится каждый день.
• Срок проведения - 5-15 минут, кроме старта в пн.
• Перед скрамом скрам менеджеру рекомендуется сообщать сотрудникам, что скрам через 5 минут, чтобы успели закоммититься и освежить память и подготовиться. Или звонит будильник за 5 минут до.
• Собираются все программисты тестировщики и скрам менеджер.
• Проводится стоя, при желании можно сесть.
• По очереди, скрам-менеджером берет текущий лист задачи сотрудника и читает команде, что это за задача. Задаются 3 вопроса: что сделал, что начнешь сегодня, что тебе мешает, вопрос всегда произносится.
• Если задача не сделана - переносится на следующий день - листок сдвигается вправо, если это третий день, то точно есть проблемы надо помогать.
• Если задача сделана, она переносится в Done или в Test если колонка Test используется тестировщиком.
• Стараемся не делать никаких длинных обсуждений. Все обсуждения после скрама.
• Никакой строгой отчетности. Никакой критики и оценочных суждений. Никаких подшучиваний. Никого не ругаем. Все без напряга. За ошибки не ругают, а думают и помогают их избежать. За этим следит скрам-менеджер.
• Если есть проблемы - это проблемы процесса и обсуждаем как процесс изменить, договариваемся кто кому поможет.
• Во время скрама запрет на использование средств коммуникаций: телефонов, планшетов, компов.
• Удаленные сотрудники обязательно присутствуют на скраме через скайп, кроме студентов.

Скрам менеджер формирует отчет в вики или лучше на соседнюю доску.

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

День знаний проводится минимум один раз в месяц и является неотъемлемой частью Carbon Agile.
Читать: день знаний

Пользователи ПО лучший контролер и управленец.
Выкладываем на сайт в автоматическом режиме, колво задача, статистика решений, тексты коммитов-ChangeLog, лучших разработчиков, документацию внутренних принципов разработки и devops.

Рекомендуемый состав:
Одна команда, одна скрам доска, 5-9 разработчиков, если больше, то делим на команды.
В команде:

• 1-2 гуру из них один технический тимлид
• 3-4 ведущих программистов и программистов
• 1-2 новичков

Члены команды выбираются и нанимаются под тимлида, тимлид или гуру обязательно участвует в конечном собеседовании. В команде должны быть специалисты разной квалификации и разных амбиций, и звезды-ученые и линейные и инженеры(дельцы) и иногда экстроверт-полуcейлез https://habrahabr.ru/post/336248/
Мы против опенспейс, лучшую эффективность добились с 1-4 человек в кабинете, часто гуру работает 1 в кабинете.
Уровни джуниор→разработчик→профи→иногда-гуру.
Переход происходит по времени в среднем 3-5 лет между уровнями при чтении книг и увлеченности можно быстрее.
Работать с интересом и азартом, но без напряжения без пинков, без штрафов, с упором на творчество и технические вызовы.
Тот кто работает за деньги тоже очень крут и создает надежность проекту.

Технолог производства не реже раз в квартал проверяет работу команды по всем принципам opencarbon и соблюдения правил скрам и выборочно работу программистов и код.

Геймификация это хорошо.
Геймификация возможна только если есть лицо с обязанностью ее поддерживать.
Геймификация должна быть очень простой и понятной, возможно по аналогии с MMORPG играми.
Например: Маг Охотник Чернокнижник Шаман Монах Рыцарь, уровни скила от 1 до 70 повышения за достижения и обучение.
Рейтинги различные и по скилам и по объемам и по лояльности. Визуализация ачивок на стене или на компе. Разные виды цветных ачивок.
Ачивки за достижения, за книги, за блоги, за доки, пуш ночью - ночной дозор, многокоммитов-многостаночник, многочасов-суперемен, помощь поддержке, помощь пользователю, помощь коллегам и тд. Может быть карбаксы для покупок в офис, но не всем нравится, или для участия в лотерее. За особые достижения выдаются амулеты.

Читать: Жизненный цикл программ