История одного «успешного» проекта. Или как правильно работать по Скраму

Цель данной статьи — рассказать о моем опыте на последнем проекте, который потерпел фиаско. Проанализировать что стало причиной фейла и как нужно было поступать в той либо иной ситуации. За эталон возьмем Скрам и посмотрим, что он рекомендовал бы нам делать.

Долго думал на структурой изложения чтобы рассказать все в логичной и структурированой форме. Решил выбрать 4 измерения: Время, Артефакты, Роли, Политика.
Время — это разделы статьи. Они будут показывать как развивались события
Артефакты — это части Скрам процесса
Роли — это Роли в Скрам команде. Кто какую роль выполнял и его обязанности
Политика — это решения со стороны компании или заказчика которые влияли на судьбу проекта

Название проекта, компании и имена членов команды искажены из уважения к ним.
Компания вендор — Тяп Ляп Продакшн, Украина
Компания заказчик — Быстро и Дешево, Европа
Проект — Плати и Бери .Финансовый проект.
Команда — 1 ПМ. 1 Архитектор. 2 БА. 4 КУА. 1 ДЕВ ОПС. 1 ДБ. 8 ДЕВ.
Год тоже изменен чтобы невозможно было отследить проект по моему профилю.

В ролях:
1. Пикассо- Штатный дев, работает на проекте парт-тайм
2. Дали — Архитектор, работает удаленно из Польши.
3. Миро — Проджект Менеджер, уволен через 2 мес после моего прихода.
4. Джакометти — Штатный дев, работает фул-тайм удаленно.
5. Массон — Застафленный дев, позже станет лидом девов.
6. Пикабиа — Менеджер, нанятый Тяп Ляп Продакшн, но работает в офисе у Быстро и Дешево.
7. Беллмер — ДБА
8. Гатри — Продукт Овнер, друг директора Быстро и Дешево.
9. Клее — Застафленный дев. Обладает Скрам майндсетом. Пришел на 2м Спринте.
10. Берни — Мидл. дев. Постоянно не доволен. Пришел на 5м Спринте.
11. Дельво — Новый Проджект Менеджер, пришел на замену Миро.
12. Неш — Мидл. дев. Человек-троль. Пришел на 7м Спринте.
13. Бергнер — КУА Лид. Самый хитрый член команды. Пришел на 8м Спринте.
14. Танги — Мидл. дев. Идеальный член Скрам команды. Пришел на 8м Спринте.
15. Бекон — Девопс первого колена. Пришел на 8м Спринте, ушел через 3 мес.
16. Швиттерс — Мидл. дев. Самомотивирующийся. Пришел на 9м Спринте.
17. Фредди — Мидл. дев. Перфекционист. Пришел на 9м Спринте.

ИНТРО.
Интересы заказчика. У заказчика есть свой продукт, который его не устраивает по ряду причин: медленный процессинг данных, сложность в поддержке, сложность в добавлении функционала, длительное время интеграции со сторонними системами. Поэтому заказчик решил заказать новый похожий продукт Плати и Бери, который будет лишен всех этих недостатков.
Интересы компании Тяп Ляп Продакшн. Для компании это новый проект в сфере финансов. Для компании это первый сложный и длительный проект. Компания хочет добавить этот проект в портфолио успешных проектов. Компания хочет предлагать этот продукт другим клиентам и в будущем сделать из него свой собственный продукт. У компании нет опыта в аджайл разработке — поэтому ей тоже интересно зарекомендовать себя на рынке как аджайл софтваре провайдер.

НАЧАЛО. Лето — Октябрь 2005.
Начало проекта — лето 2005. На проект я пришел в Октябре 2005 поэтому про самое начало проекта расскажу со слов Проджект Менеджера. Летом Тяп Ляп Продакшн какимто образом договорился с Быстро и Дешево что они запилят продукт Плати и Бери. Как позже стало известно директор Тяп Ляп Продакшн хороший знакомый Быстро и Дешево, думаю это и стало причиной успеха. Потому как не понятно как компания Быстро и Дешево могла доверить продукт стоимостью около 2 млн евро вендору без опыта и без команды. ФЕЙЛ 1. ПРОДУКТ ДЕЛАЛСЯ ДЕШЕВО ПО ЗНАКОМСТВУ.
У компании есть в штате гениальный девелопер Пикассо, который имеет опыт в финансах и знает Яву. Эго берут парт-тайм на проект. Второй человек на проекте — это гениальный архитектор Дали. У него большое портфолио успешных проектов, сейчас работает в Польше. Берут на проект парт-тайм удаленно. Ну и 3й человек на проекте — это гениальный проджект менеджер Миро. У него большой опыт работы с кадрами и управлении проектами. И у него не простая задача — собрать команду. Берут в штат на фул-тайм. С этими 3мя гениями сюрреализма проект начинается и живет до Октября.

ЕСТИМЕЙТ. Октябрь — Ноябрь 2005.

Долго думала компания Тяп Ляп Продакшн брать меня или нет... В итоге взяли, видимо потому что горели сроки и я был дешевым и самым доступным. Мог выйти на работу хоть на след. день. На след. день я не вышел, но начал работать удаленно, получая 2 ЗП в 2х разных компаниях :)
Вначале был Хаос. Не было Скрам процессов, Скрам Мастера, Скрам команды. Не было даже беклога. Был только BRD документ, где в описательной форме на 81й странице было изложено видение заказчика нового продукта.
Моя первая задача была создать Космос. И я принялся творить :) Не имея опыта в Скраме я принялся делать как художник — так как видел. Выписал тезисно, в формате требований, все хотелки кастомера. Сгруппировал требования по Епикам и занес это все это в ексель (вышло 978 строк). Заняло у меня это 2 недели. Это был первый Артефакт на проекте. ФЕЙЛ 2. НЕ ПРАВИЛЬНО СОСТАВЛЕННЫЙ БЕКЛОГ. ВО ПЕРВЫХ ФОРМАТ ТРЕБОВАНИЯ НИКАК НЕ ПОДХОДИЛ К НАШЕМУ АДЖАЙЛ ПРОЕКТУ. ВО ВТОРЫХ НЕ БЫЛО РОЛЕЙ ПОЛЬЗОВАТЕЛЕЙ. В ТРЕТЬИХ НЕ БЫЛО ОЖИДАЕМОГО РЕЗУЛЬТАТА ОТ КАЖДОЙ СТОРИ. В ЧЕТВЕРТЫХ КАСТОМЕР НИКОИМ ОБРАЗОМ НЕ ПРИНИМАЛ В ЭТОМ УЧАСТИЯ.
Как раз ко времени создания беклога уже была первая команда их 3 девов: Все тот же парт-тайм Пикассо, штатный дев компании Джакометти, который почему-то работал из Одессы, новый синиор дев Массон, который тоже работал на удаленке.
Этой командой мы начали работать над нашим первым Артефактом — Беклогом. Первая задача была сделать естимейт беклога. Мы брали каждое требование (да, это не были Юзер Стори), декомпозировали его на таски и оценивали каждую таску в Стори поинтах. Требования, которые было вообще не понятно как делать получали оценку 50 либо 100 Стори Поинтов. Первую неделю это были митинги по скайпу, дальше всем стало в лом и оценки приходили ко мне от каждого дева отдельно. Я выводил среднее и заносил в финальную оценку. Оценки, которые расходились в естимейте больше чем на 2 стори обсуждались отдельно. Отдельно оценивался естимейт на анализ, дев и куа. Еще раз, куа команда никакого участия в оценке не принимала, потому как ее еще не было. ФЕЙЛ 3. ОЦЕНКА ДЕЛАЛАСЬ ОЧЕНЬ ДЕТАЛЬНО И ЗАНЯЛА МНОГО ВРЕМЕНИ. ОНА ПОТОМ ВСЕ РАВНО ПЕРЕСМАТРИВАЛАСЬ КАЖДЫЙ СПРИНТ. ЗАЧЕМ БЫЛО ТРАТИТЬ 2 НЕДЕЛИ НА ПРЕДВАРИТЕЛЬНУЮ ОЦЕНКУ НЕ ПОНЯТНО.
Также вызывает вопрос моего участия как Аналитика/Продукт Овнера в оценке, потому как моя роль была просто записывать оценки и сводить их воедино. Может быть мне стоило в это время хорошенько подготовится к первому Спринту и к его началу иметь уже запас Сторей, которые заапрувлены клиентом и которые понятно как делать...
Вся эта оценка заняла около 2х недель. Один Стори поинт был оценен в один рабочий день. В результате получили естимейт проекта для команды в 8 чел — 2 года.
Вся эта информация была передана Миро и через некоторое время мы получили ответ: 2 года для клиента дорого, нужно сделать за год. ФЕЙЛ 4 ПОЛИТИЧЕСКИЙ. НУЖНО УЧИТЫВАТЬ ОЦЕНКУ КОМАНДЫ, НЕЛЬЗЯ ПРОСТО ВЗЯТЬ И В 2 РАЗА УМЕНЬШИТЬ ЕСТИМЕЙТ, ТЕМ БОЛЕЕ ЧТО ОЦЕНКА БЫЛА ДОСТАТОЧНО ТОЧНОЙ!
Оценка на анализ и куа не была вообще учтена. Миро выкатил Релиз План с 2мя фазами и 6тью MVP. Фаза 1 (MVP1 — MVP4) включала требования которые хоть както понятно было делать, Фаза 2 (MVP5 — MVP6) — все остальное. MVP1 — это минимально работающий функционал, MVP2 — дабавляем кучу фич, MVP3 добавляем юай, MVP4 — продукт готов к продакшину. MVP1 должен был быть готов к Маю, т.е. у нас оставалось Ноябрь — Май = 5 мес. Фаза 1 должна была быть закончена ровно через год к Ноябрю.
Я не зря не упоминиаю о Спринтах и Ролях потому как их пока нет.

Даже смысла писать нету что было сделано не правильно — все было сделано не правильно. Как нужно было делать правильно см. ниже.

! Оценка проекта по Скраму. Есть несколько способов. 1. Использовать исторические данные (Historical Data), т.е. опыт команды на прошлых проектах. 2. Подождать и увидеть (Wait and See), т.е. запилить 3 спринта и на основе этой велосити сделать оценку всего беклога. 3. Слепая Оценка (Blind Estimation). В нашем случае подходил только последний вариант, про него немного детальнее.
Слепая Оценка состоит из таких частей:
1. Оценить продукт беклог
2. Декомпозировать шаблонную сторю
3. Аппроксимация стори поинтов в часы
4. Оценить велосити команды
Важно! Эта техника предусматривает что после нескольких спринтов когда будут уже реальные данные велосити команды и точная оценка шаблонной стори, оценка по методу Blind Estimation идет в мусорник и заменяется реальными данными.
ФЕЙЛ 5. НАША ИЗНАЧАЛЬНАЯ ОЦЕНКА НИКОГДА НЕ ПЕРЕСМАТРИВАЛАСЬ НА ПРОТЯЖЕНИИ ПРОЕКТА.

Шаг 1. Оценка беклога.
Выбираем из всего беклога штук 5 шаблонных Сторей размером в 2 стори поинта. Сравниваем оставшиеся Стори как больше-меньше с нашими шаблонными Сторями и проставляем оценку всем Сторям в беклоге. Для оценки лучше использовать ряд Фибоначи 1,2,3,5,8,13...
Шаг 2. Декомпозируем шаблонную сторю.
Дальше грумим и декомпозируем на Таски наши шаблонные стори. Оценка Тасок делается в Часах, используя тот же ряд Фибоначи. Оценка больше 13 часов недопустима — в этом случае Таска дробится на несколько.
Шаг 3. Апроксимируем стори поинты в часы.
Напомню, все шаблонные Стори у нас по 2 Стори Поинта.
Сторя 1 займет у нас 14 часов
Сторя 2 — 22 часа
Сторя 3 — 20 часов
Сторя 4 — 18 часов
Сторя 5 — 16 часов
Среднее время на сторю — 18 часов. 18 часов на 2 стори поинта = 9 часов на Стори Поинт. Херовастенькая оценка, выходит одна Сторя будет занимать у нас больше одного рабочего дня. Но для оценки это пофигу, поэтому идем дальше.
Шаг 4. Оценка велосити команды.
Каждый член прикидывает сколько чистого времени он может тратить на написание кода. Например, наш Пикассо, так как он работает парт-тайм на проекте может тратить, допустим, 4 часа в день. Другой дев может, посидев в ФБ, почитав новости и сходив 2 раза на обед может тратить в день 5 часов. Третий, более сознательный 6 часов, и т.д. Каждый дает свое максимальное и минимальное время. Для нашего кейса с 3мя девами и 2х недельным спринтом (10 рабочих дней) это бы выглядело так: Пикассо — 4(3) * 10 = 30-40 часов. Дев 1 — 5(4) * 10 = 40-50. Дев 2 — 6(7) * 10 = 60-70.
Среднее время команды выглядит так: 43-53 часа за спринт.
Чтобы получить велосити команды делим время команды на 9 часов (среднее время на сторю). 43-53/9 = 4 — 5. Результат, наша супер команда сможет бернить 4-5 Стори Поинтов за Спринт.
Чтобы получить общее время проекта просто делим общее кол-во стори поинтов в беклоге (допустим 200) на нашу велосити. 200/4-5=50-40. Выходит нашей супер команде чтобы запилить такой проект нужно будет 40 Спринтов при лучших раскладах и 50 Спринтов — при худших.

Еще не все. Теперь нужно приоритезировать наш беклог, чтобы понимать какие Стори пилить в начале и какой спринт будет первым. Нам поможет техника The Big Wall.
Пишем Стори на карточках. Находим большую стену и клеим на нее карточки. Стори располагаем в таком порядке с лева на право: Стори в 1 Стори Поинт — вертикальная линия — Стори в 2 Стори Поинта — вертикальная линия — и т.д. Должно получится так, чтобы Стори с одинаковой оценкой были в своих отдельных колонках. Зовем стейкхолдеров либо кастомера и просим расставить Стори по вертикали так, чтобы вверху были самые приоритетные Стори, внизу — с наименьшим приоритетом.
Итого, в первые Спринты идут Стори с низкой оценкой и высокой важностью, Стори с высокой оценкой и высокой важностью — кандидаты на ближайшие груминг сессии. Стори с низкой оценкой и низкой важностью идут в конец беклога, оставшиеся Стори с низким приоритетом и высокой оценкой идут еще ниже. Внимание! Эта техника не заменяет Релиз План, но это уже другая история...

ПЕРВЫЙ СПРИНТ. Ноябрь 2005.
Перед тем как продолжим, не лишним будет рассказать еще об одном персонаже. Чтобы понять его важность, расскажу немного о самом заказчике. Быстро и Дешево состоит из 40-50 сотрудников и имеет такую структуру:

-2 директора
—1 внешний Продукт Овнер
—1 начальник опсов
---10ток опсов
---3 админа
—1 архитектор
---3 ДБАшника
—1 начальник по работе с клиентами
---10ток сапорт спецов
—10ток всякого менеджмента

Отсюда видно, что заниматься новым продуктом некому. Вот Бысто и Дешево и решила нанять специально обученного менеджера для управлением проектом со своей стороны. Этим человеком стал гениальный Пикабиа, почему гениальный я расскажу дальше. Пикабиа был нанят компанией Тяп Ляп Продакшн, оформлен в штат к Быстро и Дешево и отправлен туда к ним на релокейт. Он уже активно «работал» по поему приходу на проект.
Итак, мы начинаем наш первый Спринт. Длинна спринта была выбрана стандартная — 2 недели. ФЕЙЛ 5. ДЛИННА СПРИНТА ДОЛЖНА ВЫБИРАТСЯ ИСХОДЯ ИЗ СПЕЦИФИКИ ПРОЕКТА.
О том как выбрать длинну спринта я расскажу ниже.
Входные данные такие: Скрам ролей нет, с Продукт Овнером связи нет, 3 девелопера, 2 из которых работают на удаленке, 1 в офисе но на парт-тайм. 1 калека-аналитик. 2 менеджера, один ТАМ — другой ТУТ. Из Беклога ни одна Сторя не находится в статусе Реди — не может быть взята в Спринт. Вопрос — ЧЕМ занять команду?.. Выход нашел гениальный Пикабиа — у нас есть архитектура, у нас есть критически важное требование — перформанс, давайте сделаем ПОК и покажем что наша система соответствует требуемому быстродействию.
Тут же появился ДБА на фул тайм — Беллмер, человек крайне интересный, о нем чуть позже.
Я засетапил Дейли Скрам митинги, напилил тасок в ISM (Redmine) и мы начали работать: девы пилили ПОК, ДБА создавал тестовую базу под ПОК, я занимался грумингом тасок. К середине спринта мы определились с Ролями:
1. Скрам Команда: 3 дева, 1 аналитик, 1 ДБА. (Команда будет расти, Тяп Ляп Продакшн активно нанимает людей)
2. Скрам Мастером стал Миро.
3. Продукт Овнером стал продукт овнер Быстро и Дешево.
ФЕЙЛ 6. РОЛИ В КОМАНДЕ НЕ ДОЛЖНЫ ВЫБИРАТСЯ СЛУЧАЙНЫМ ОБРАЗОМ. ЭТО ОДНА ИЗ ВАЖНЕЙШИХ ЧАСТЕЙ В СКРАМЕ.
О том как застафить правильную Скрам команду я расскажу ниже.
Роли не подходили потому что:
1. Скрам команда. Ни одного человека с опытом в Скраме, люди сидят в разных местах. Не все участники командные игроки и не всем близки ценности Скрам.
2. Миро — имеет отличные менеджерские качества, единственный человек, который понимает что такое Скрам. Был бы отличным Скрам Мастером если бы его не уволили через 2 месяца. По сути он даже толком не успел поработать с командой.
3. Продукт Овнер — человек далекий от Скрама, с майндсетом вотерфольных проектов. Тяжело доступен, не участвует в жизни команды, не менеджит беклог, ему не интересны Спринт Ревью.
О Продукт Овнере нужно сказать пару слов. Продукт Овнер по имени Гатри — это человек в возрасте, близкий друг одного из основателей Быстро и Дешево. Имеет коллосальный опыт в домене продукта, это он написал BRD документ.
О ролях в Скраме я напишу ниже.

Несколько слов о ДБА. Человек старой закалки из банковской сферы. Устал от жизненной суеты и привык делать все по спецификации или если таковой нет — по четким указаниям начальника. Вопросов к работе у него никогда не было. Есть четкая задача — делаю, задача не четкая либо ее нет — жду четкую задачу. Жизненный подход абсолютно верный, но слабо подходящий к аджайл разработке.

! Как выбрать длительность Спринта

Длительность спринта зависит от 3х факторов: Длительность проекта, Кастомера и Скрам Команды.
1. Длительность проекта. Напомню что результатом каждого Спринта является рабочий продукт, который оценивается заказчиком и предоставляется фидбек. Если длительность проекта 1 год и спринты по 1 мес, то вы получите фидбек 12 раз. Если проект на 3 мес и спринты по 1 мес, то фидбек вы получите 3 раза, чего явно не достаточно. Вообще конечно чем чаще фидбек от заказчика тем лучше, но мы упираемся во второй фактор.
2. Кастомер. При оценке кастомера нужно учесть следующее: Насколько доступер Продукт Овнер и Стейкхолдеры, культура компании и ее знакомство со Скрамом, Регуляторные ограничения (аудит, соотв. безопасности и т.д.). Так вот если Продукт Овнер очень занят и заказчику вообще пофигу что делается по Спринтам (как в нашем случае) — нет смысла им показывать Спринт Демо каждые 2 недели и ждать фидбека. Или если это банк и чтобы задеплоить какойто код нужно пройти 9 кругов ада по аудиту — не очень хочется делать это часто.
3. Скрам Команда. Допустим с 2мя первыми факторам проблем нет — проект средней длительности (пол года), заказчик готов рвать и метать, тогда мы упремся в 3й фактор. При оценке Скрам Команды нужно учесть следуещее: Опыт команды в Скраме, навыки инжениринга (TDD, Pair Programming, Continuous Integration, etc.), умение декомпозировать таски. Если команда новая или не умеет работать по Скраму (как в нашем случае) — нет смысла ожидать от нее рабочего продукта через неделю или две.
Только после того как учтены все факторы можно выбрать длинну спринта таким образом чтобы это не афектило клиента, команду и вы были уверенны что двигаетесь в правильном направлении, вовремя получая фидбек от заказчика. Идеальная длительность Спринта — 2 недели, к ней нужно стремится, обучая клиента и команду Скраму.

! Как застафить Скрам команду

Для начала немного теории. По теории Брюса Такмана существует 4 стадии развития команды: Формирование -> Конфликт -> Нормализация -> Перформанс. На стадии Формирования команда учится работать вместе, выявляет кто есть кто и определяются лидер(ы). На стадии Конфликта — проявляются межличностные конфликты, начинается слаженная работа. На стадии Нормализации команда уже начинает показывать результат, члены команды доверяют друг другу, каждый знает что делает. Перформанс — это уже стадия максимально доверия, никто не боится попросить о помощи или показать слабость, все проблемы решаются командно. Работа идет потоком без задержек. Максимальная производительность команды.
Для команды в стадии Перформанс, каждый новый человек возвращает команду в стадию Формирования, и команда должна уметь быстро вернутся обратно в стадию Перформанса. Велосити всей команды падает с каждым новым членом команды. Для того чтобы команда сумела быстро вернутся к стадии Перформанса нужно выбрать правильного человека. Идеальный член Скрам Команды должен соответствовать таким качествам:
— Ему должны быть близки ценности Скрама
— Готов к изменениям
— Гибкий
— Скромный
— Командный игрок
— Быстро обучается новому
— Иметь все необходимые технические скилы для работы
Кроме того, Скрам Команда должна быть готова помочь новому члену интегрироваться — обучить своей культуре работы и ценностям, предоставить ответы на все технические вопросы.
Сейчас я понимаю что несколько членов нашей команды так и не смогли интегрироваться, хотя начинали проект почти с самого начала.

! Роли в Скраме
Скрам Мастер.
Тренер: помогает команде следовать Скрам процессу и постоянно совершенствоватся в нем. Кроме того, помогает новому Продукт Овнеру понять и исполнять его роли на проекте.
Защищает команду от внешних воздействий и помогает сконцентрироваться на работе.
Устраняет все проблемы для эффективной работы команды.

Продукт Овнер
Управляет экономикой проекта: постоянно находит компромис между скоупом, сроками, качеством и бюджетом
Учавствует в планировании Спринтов: определяет цель Спринта.
Грумит Беклог: добавляет, приоритезирует, уточняет Стори.
Определяет Аксептанс Критерии и апрувит их.
Взаимодействует со Скрам Командой: контролиует как разрабатывается функционал и помогает Скрам Команде понять что нужно делать. Это помогает в дальнейшем избежать тиканья пальцев.
Взаимодействует со стейкхолдерами: собирает и синтезирует требования.
Должен обладать такими качествами: иметь знания в бизнес домене, уметь работать с людьми, не боятся принимать решения, быть доступным и принимать ответственность за продукт

Член Команды
Открыт к чемуто новому
Готов самосовершенствоваьтся и помогать в этом другим
Командный игрок
Имеет уважение в команде
Скромный

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

ПЕРВЫЙ СПРИНТ. ПРОДОЛЖЕНИЕ. СПРИНТ БЕКЛОГ
Напомню что Сторей на 1й Спринт беклога у нас не было и команда занималась ПОКом по перформансу. В течении 1го спринта я занимался кларификацией требований, написанием сторей и документацией сего добра на вики портале Быстро и Дешево. Хочу отметить что ни о каких аксептанс критериях речь не шла. ФЕЙЛ 7. ПИШЕШЬ СТОРИ ПИШИ И АКСЕПТАНС КРИТЕРИИ, СРАЗУ АПРУВЬ ИХ У ЗАКАЗЧИКА.
О том как писать юзер-стори я напишу ниже.
В начале проекта общение с заказчиком было очень формальным — бизнес вопросы задавались через Гатри, технические вопросы — через Пикабиа. Кроме того, общение с Продукт Овнером Гатри велось через ексельник с вопросами. Если мне что-то было не понятно — я должен был создать вопрос в екселе и ждать ответа. Быстро и Дешево жили вотерфольным майндсетом и предполагали что ели проект уже идет пол года, то анализ уже должен был быть сделан и осталось только время на разработку. ФЕЙЛ 8. ЖИВОЕ ОБЩЕНИЕ СО СТЕЙКХОЛДЕРАМИ И ПРОДУКТ ОВНЕРОМ ОБЯЗАТЕЛЬНЫ В АДЖАЙЛЕ. Я сразу понимал что это будет, как минимум, тормозить процесс сбора требований, но к каким критическим последствиям это приведет не осознавал. В конце концов нам таки удалось выйти на живых стейкхолдеров через пол года с приходом нового Поджект Менеджера, но об этом позже.
К концу первого Спринта у нас уже был Беклог с разбивкой по МВП и приоритезацией low-medium-high. Моя задача была расписать хай приорити Стори и прогрумить их с командой, задача команды — задевелопить Стори и уложится в естимейт. О том какой бенефит принесет каждая Стори кастомеру никто не думал. Сейчас я понимаю что если бы я думал о пользе каждой Стори — я бы писал их по другому.

Спринт Беклог.
В Спринт Беклог попадали Стори, которые были хот как-то понятны. Спринт, вместо того чтобы иметь какую-то цель, приносить бенефит клиенту и быть работоспособным, включал работу которую можно было хоть как-то сделать. Так мы жили почти год. ФЕЙЛ 9. КАЖДЫЙ СПРИНТ ДОЛЖЕН ПРИНОСТИТЬ БЕНЕФИТ, А НЕ ВКЛЮЧАТЬ ТОЛЬКО ПОНЯТНЫЕ ТАСКИ.
От том как правильно составлять Спринт читайте ниже.

[16.02.18]

! Из чего состоит Спринт в Скраме

Какую работу может включать в себя Спринт:
1. Стори — функциональность, которая приносит бенефит пользователю системы.
2. Спайк — активность, ограниченная во времени, которая необходима чтобы разобраться в сложной или не известной функциональности, изучить новую систему, разобраться в непонятной Сторе.
3. Технический долг — работа необходимая чтобы закрыть косяки в плохом дизайне системы, архитектурные таски и все что напрямую не относится к функциональности.
4. Баги — документация багов, апдейт юнит-тестов, проверка и закрытие бага.
5. Аварии — фикс проблем, связанных с окружением — упал сервер с билдом, билд не билдится и т.д.
6. Прочие обязанности — соблюдение корпоративных стандартов по безопасности, документированию и т.д. — в больший компаниях это, кстати, занимает очень много времени. Посещение корпоративных митингов и других активностей. Скрам митинги — 3 вей чаты, планинг, груминг, дейли скрам, ретро.

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

[20.02.2018]
СПРИНТ ПЛАННИНГ.

Спринт планнинг у нас по началу занимал часа 3-4, чего с натяжкой хватало чтобы прогрумить и разбить на части все Стори — кандидаты в Спринт. Прослеживалась четкая тенденция на уменьшение этого, и так недостающего, времени. Через год наши Спринт планинг митинги сократились до 1 часа. Как результат — все меньше и меньше Сторей были расписаны и декомпозированы на таски. А у меня оставалось все меньше времени на написание Сторей, их приоритезацию и апрув со стейкхолдерами. Одна из Основных задач аналитика/продакт овнера — это своевременно подавать боеприпасы стрелкам. С этой задачей я справился плохо, не сумев в самом начале проекта наладить своевременную подачу боеприпасов на передовую. Считаю причиной тому следующее: слабая коммуникация с Продакт овнером в начале проекта, отсутствие Стори груммингов на протяжении спринта, слабая проработка Сторей на Спринт планнинге. Со временем ситуация только усугублялась, мы так и не сумели за весь проект организовать своевременный грумминг Сторей. ФЕЙЛ 10. ЕСЛИ ВНАЧАЛЕ ПРОЕКТА, КОГДА ЕЩЕ ЕСТЬ ВРЕМЯ, НЕ НАЧАТЬ ГРУМИТЬ СТОРИ В НЕОБХОДИМОМ КОЛИЧЕСТВЕ — ПОТОМ ДОГНАТЬ БУДЕТ ОЧЕНЬ ТЯЖЕЛО.

Еще одна наша проблема — мы не определяли цель спринта — наиболее критичный функционал, который обязательно должен быть завершен (MMF Minimum Marketable Feature). Например, целью Спринта может быть Сторя позволяющая юзеру секьюрно залогинится на портал. Связанные Стори такие как смена пароля либо учетных данных — это опциональные Стори, отсутствие которых не повлияет на основной функционал. ФЕЙЛ 11. В НАЧАЛЕ ПРОЕКТА МЫ ДЕЛАЛИ САМЫЕ ПРОСТЫЕ СТОРИ, КОТ. МОГЛИ ХОТЬ КАК-ТО ЗАГРУМИТЬ. НУЖНО НАЧИНАТЬ СО СТОРЕЙ С НАИБОЛЬШИМ РИСКОМ.

Тут я хочу отвлечься и сказать пару слов о зависимости рискованости/сложности Стори от номера Спринта, в каком эта Сторя будет имплементироватся. Эта зависимости обратно пропорциональна — чем более рисковая Сторя, тем проще ее делать в первых Спринтах. Есть такая теория — Окно Возможности (Mitch Lacey): в начале проекта, когда люди еще мотивированны и бюджет не проеден, мы имеем больше возможностей и времени на комплексные таски. Команда может потратить больше времени на груминг Стори, кастомер будет иметь больше времени предоставить детали, меньше импакт изменить реализацию Стори, и т. д. Со временем проекта это окно становится все меньше и соотв. пропадает возможность пропихнуть в это окно комплексные Стори.

ДЕЙЛИ СКРАМ или СТЕНДАП

Наши Стендапы мы по началу проводили сидя и по скайпу, можно было продолжать сидеть в фейсбуке не отвлекаясь на стендап. Это была вынужденная мера, потому как 2 человека работало удаленно — Джакометти и Дали. Новый ПМ пришел и навел порядок — теперь все стояли кружком вокруг ноутбука со скайпом, что было, в принципе, сносно. Но время шло и команда росла. При размере команды 5 девов, 2 куа и 1 девопс митинги проходили на удивление эффективно. Но время шло и команда росла, через год команда насчитывала уже 12 девов+дба, 4 куа, 2 аналитика, 1 ПМ. При таком размере команды тяжело было держать митинг в фокусе и уложится в 30 мин.
Первый год проекта я был фасилитатором Стендапа и считал это обязаностью аналитика, но позднее эту роль взял на себя Клее и у него это получалось лучше чем у меня.ФЕЙЛ 12. СТЕНДАП ДОЛЖЕН ПРОВОДИТЬ ТЕХ. ЧЕЛ. КОТОРЫЙ ИМЕЕТ АВТОРИТЕТ СРЕДИ ДЕВЕЛОПЕРОВ. ( ЛИБО СКРАМ МАСТЕР). НО НИКАК НЕ АНАЛИТИК. Вместо коротких ответов на 3 вопроса Скрама, митинги превращались в архитектурные батлы между Пикассо и Джакометти. Тут отмечу что наш архитектор Дали на митинги являлся все реже и реже, и споры по архитектуре задавались ему по почте. В итоге через год он полностью пропал из проекта и архитектурить начали Пикассо и Джакометти. ФЕЙЛ 13. ОТСУТСТВИЕ АРХИТЕКТОРА НА ПРОЕКТЕ ВЛЕЧЕТ ЗА СОБОЙ КАТАСТРОФИЧЕСКИЕ ПОСЛЕДСТВИЯ. ДВА АРХИТЕКТОРА НА ПРОЕКТЕ ЭТО КОНЕЦ ПРОЕКТА.
В конце концов митинги превратились просто в какойто непонятный и бессмысленный обычай. Все попытки ПМа договорится с командой и объяснить важность Стендапа ни к чему не привели. Вывод: Стендап — это не просто митинг с целью обсудить рабочие моменты — это четко структурированый митинг с конеретными вопросами и ответами ограниченный по времени. Если команду не научить правильно проводить Стендап — он превратится в рудимент, который не только не приносит пользу но и демотивирует команду.

Небольшое отступление — пару слов о Клее.
Клее пришел к нам в команду на 2м Спринте. Он сразуже вписался в команду так как соответствовал всем критериям идельного члена Скрам Команды — см. раздел «Член Команды» выше. Клее «болел» за Скрам на нашем проекте и именно он подтолкнул меня на мысль что что-то в нашем процессе идет не так. Он в дальнейшем взял на себя роль фасилитатора Дейли Скрам митингов. Если бы все члены команды были с таким же майндсетом как у Клее, может проект закончился бы подругому...

[22.02.2018]

! Релиз Планнинг
По сути, релиз планинг — это тоже самое что планировать вело путешествие — составлять вело маршрут. Вело маршрут это и есть Релиз план. Допустим, у вас задача доехать из Киева в Краков.
Расстояние, которое вы проезжаете в день — это Часы затраченные на Стори.
Дорожные указатели за которыми вы следите и уверены что едите в нужном направлении — Дейли Скрамы, Спринт Ревью и Ретроспективы.
Пройденный путь — это Велосити команды.
Скорость с которой вы движетесь — это Берндаун чарт.
До Кракова 800км, в день вы планируете проехать приблизительно 100 км, значит до Кракова вы доедите за 8 дней. Вроде бы все просто — вот и весь план. Но вас в дороге может застать дождь или технические проблемы. В этот день вы сможете проехать лишь 50 км — велосити падает в 2 раза. На след. день вам нужно ехать в 1.5 раза быстрее чтобы выровнять велосити и уложится в 8 дней. Кроме того, вы можете сбится с дороги и поехать не в ту сторону, чтобы этого не случилось вы постоянно следите за знаками — дейли Скрам, Спринт Ревью и Ретроспектива. Чтобы контролировать вашу скорость и не опоздать — вы используете берндаун чарт, который показывает сколько км из общего пути вам осталось проехать.
Релиз план предусматривает постоянный контроль скорости разработки и возможностей команды. Со временем команда приобретает больша опыта и повышает свою велосити (как велосипедист с опытом может проехать 150км в день), соответственно релиз план должен учитывать эти факторы и быть постоянно «живым».

СПРИНТ РЕВЬЮ
Спринт ревью проводил я по заранее подготовленному скрипту. Скрипт включал в себя список функционала, который мы показывает клиенту. Первые полгода проекта функционал показывался на листике, тоесть не было вообще никакого работающего функционала енд ту енд. Я показывал диаграмму из елементов системы и говорил — то что зеленое — работает, серое — в процессе разработки. Ни о каком фидбеке заказчика говорить и не приходилось. ФЕЙЛ 14. СПРИНТ ДЕМО ВСЕГДА ДОЛЖЕН ЗАКАНЧИВАТСЯ ФИДБЕКОМ ЗАКАЗЧИКА И АКСЕПТАНСОМ ПРОДЕЛАННОЙ РАБОТЫ.
Кроме того, как я уже говорил, аксептанс критериев у нас не было и готовая Сторя в следующем Спринте могла оказатся не готовой. ФЕЙЛ 15. ГОТОВАЯ СТОРЯ ДОЛЖНА БЫТЬ ПОДТВЕРЖДЕНА АКСЕПТАНС КРИТЕРИЯМИ И ТЕСТАМИ.
Как убедится что Сторя готова я напишу ниже.

! Спринт ревью в Скраме
Длительность ревью или демо должна выбираться в зависимости от длительности Спринта. Спринт 1 неделя — 30 — 60 мин, 2 недели — 60 — 90, 4 недели — 120 — 240 мин.
Спринт ревью состоит из подготовки и самой демонстрации.
1. Подготовка к ревью.
Подготовить такую информацию:
— Цель Спринта
— Список Стори, которые команда планировала завершить
— Стори, которые команда завершила
— Стори, которые команда не успела закончить
— Ключевые решения, принятые в течении Спринта — архитектурные, рыночные, новые требования, ...
— Проектные метрики — покрытие кодом и т.д.
— Демонстрация проделанной работы, скрипт
— Ревью приоритетов на след Спринт

Подготовка к ревью не должна занимать много времени и отвлекать команду от основной работы. В идеальном случае, Спринт ревью должен быть PlugandPlay, но часто необходимо подготовить окружение, прогнать тесты, подготовить тестовые данные и т.д.

2. Демонстрация Спринта.
Участники Спринт ревью: Продакт Овнер, Команда, Скрам Мастер, заказчик и иногда менеджмент.
Функционал показывает команда, именно команда а не аналитик или продакт овнер. В идеальном варианте функционал проверяет непосредственно заказчик своими руками. Большой плюс если деплоймент функционала является часть демонстрации. По завершении демонстрации заказчик сразу аксептит Стори или предлагает что нужно изменить/улучшить. Важно, чтобы заказчик сразу же аксептил и давал свой фидбек — это должно быть частью демо. После демо нужно оставить время 30 мин на неформальное общение команды и заказчика.

Зачем нужен Спринт ревью:
— Строит доверие между заказчиком и командой
— Помогает убедится что проект движется в верном направлении
— Выявляет скрытые риски и требования
— Дает возможность получить обратную связь от клиента

Если совсем коротко, Спринт Ревью выглядит так: Планируем -> Показываем -> Документируем решения во время показа -> Получаем аксептанс.

[19.03.18]
РЕТРОСПЕКТИВА
Как мы проводили ретро.
Ретро проводил ПМ без особого понимания как это делать. У нас не было четкого плана, понимания важности ретро и результат ретро был не очевиден. Ретро в начале мы проводили в правильное время — сразу после Спринт демо, позже оно стало переносится на любое удобное ПМу время. Ближе к концу проекта ретро уже проводилось раз в несколько Спринтов.

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

При росте команды ретро потихоньку превращались в балаган. Я постоянно жаловался на то, что у нас нет нормальных процессов, Клее жаловался, что нет Скрама и на жизнь в целом, Пикассо и Джакометти вступали в архитектурные батлы. Остальная команда жаловалась на плохо расписанные Стори. В таком хаосе тяжело было найти суть и выделить екшн поинты для улучшения. Команда на ретро только еще больше демотивировалась, в конце концов необходимость в Рето просто отпала, мы ходили туда уже просто как на курилку.

Поначалу я думал что вся проблема в ПМе, который не мог заменеджить процесс, но сейчас, с оглядкой назад, я могу выделить такие причины:
1. Команда не понимала важности ретро и ей никто ее не объяснил
2. Команда не видела результат екшн поинтов прошлых ретро
3. Команда не знала как проводить ретро
4. Очень большая команда — 15 чел

! Ретроспектива в Скраме.
Цель ретро — постоянное улучшение команды — как работать более ефективно, повысить велосити и качество кода.
Если команда постоянно не совершенствуется — она распадается. Это, кстати, и случилось в нашем случае.

Ретро состоит из планирования и самого проведения.
Планирование ретро.
1. Коммуникация. Каждый член команды должен понимать ожидания от ретро. Для этого необходимо слать агенду заранее, она включает в себя: о чем митинг, почему это важно, какую пользу она принесет команде, как будет распределено время митинга, какой конечный результат.
2. Подготовка митинга. Убрать стулья, повесить копию Берндаун чарта, список выполненых сторей, цель спринта, заметки прошлой ретро, повесить доску с колонками, либо 3 доски — что прошло хорошо, что нужно улучшить, недовольства.
3. Повесить на виду основные правила ретро:
— Уважай соседа
— Не перебивай
— Убрать ноутбуки и моб телефоны
— Длинные дискусии переносить на после
— Проговорить все услышанное чтобы убедится что все поняли
— Что сказано на ретро за пределы ретро не уходит
4. Строго следить за планом и регламентом. Присекать все попытки кого либо перетянуть одеяло на себя.

Проведение ретро.
По очереди:
1. Все пожелания и замечания пишутся на доске в 3 х колонках (3х досках) участниками ретро: хорошо, улучшить, не понравилось.
2. Убираем дубликаты.
3. Ставим приоритеты. Хороший метод приоритезации — выдать всем по 100$ и позволить тратить их на пункты.
4. Выбрать приоритетные пункты и убедится что все понимают о чем они.
5. Проголосовать брать ли на улучшение приоритетные пункты.
6. Ели пункт не берется на улучшение — задокументировать этот факт.
7. Если пункт берется на улучшение — выбрать ответственного человека и назначить временные рамки.
8. Засетапить отдельный митинг для обсуждения результатов улучшений.

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

[23.02.2018]

! Готова ли Сторя?
Готовность Стори определяется критериями готовности — Definition of Done.
Критерии готовности определяются командой в зависимости от специфики проекта. Наилучшая техника определения критериев готовности — это брейншторм митинг.
Типичные критерии готовности Стори:
1. Аксептанс критерии (тесты) определены и пройдены
2. Весь код, включая тесты, залит в репозиторий и билдится
3. Все юнит тесты пройдены
4. Функциональные тесты пройдены
5. Файл помощи сгенерирован

Важнейшим пуктом здесь являются Аксептанс Критерии. Аксептанс критерии (тесты) раскрывают детали Стори и определяют ожидания заказчика от Стори. Аксептанс критерии могут писатся самим заказчиком, аналитиком/овнером либо скрам командой. Хороший метод проверить все ли тесты написаны — задать такие вопросы:

— Что еще нужно знать девам об этой Стори
— Какие допущения о Стори я сделал и не записал
— Есть ли еще кейсы в которых Стори может вести себя по другому
— Что может пойти не так в этой Стори

Definition of Done так же определяется для Спринта, например:
— Бекап Продукта проапдейчен
— Перформанс тесты пройдены
— Диаграммы классов, архитектуры, пакетов проапдейчены
— Все баги закрыты либо перенесены
— Покрытие кодом больше 80% юнит тестов

Definition of Done для Релиза:
— Инсталяционные пакеты созданы
— Мониторинг тулза подключена
— Админ гайд в актуальном состоянии
— Траблшутинг гайд в актуальном состоянии
— Дизастер план готов
— Все тестовые окружения работают
— Стресс тестирование пройдено
— Заявленый перформанс
— Соблюдены все требования по безопасности
— Дизастер рекавери план проверен

[26.02.2018]

! Эффективный Дейли Скрам
Симптомы плохого Дейли Скрама:
— Частое углубление в детали
— Члены команды постоянно опаздывают
— Невнимательность на митинге
— Статус репортиься долго, расплывчато и не по сути
— Митинги часто превышают 15мин

Проводить эффективный Стендап, как оказалось, не совсем просто. Несколько советов эффективного Дейли Стендапа:

1. Выбрать такое время митинга, которое подходит всем членам Скрам команды. Это должно быть утренне время когда все уже на работе.
2. Начинать митинг всегда в одно и тоже время. Опоздавших можно мотивировать различными способами — поговорить отдельно, пристыдить при всей команде, финансово. Какой метод мотивации — решать вам.
3. Заканчивать митинг всегда вовремя (через 15мин), избегать чересчур детальных статусов, обсуждений не по теме, и т.д. Чтобы команда привыкла с ритму митинга, повторять ежедневно мантру: «Рад всех сегодня видеть, мы собрались чтобы ответить на 3 вопроса — Что вы сделали вчера, Что вы будете делать сегодня, Что вам мешает закончить таску.» Со временем команда привыкнет к ритму и будет проще собирать статус. Лучше чтобы команда стояла в кругу и репортила статус друг другу а не Скрам Мастеру.
4. Присекать все попытки перебивать. Хорошая техника использовать «говорящий предмет». Тот кто держит предмет — говорит, остальные — слушают. Или любую другую технику, подходящую вашей команде.
5. Присекать все попытки брожений и углублений в детали. Обычно брожения начинаются с вопроса «Что я делал вчера» и говорят о том, что человек не подготовился. Дальше это может перерасти в углубление в детали, часто не по сути. Метод пресечения таких разговоров — попытаться припарковать вопрос и обсудить его сразу же после митинга, отпустив всех остальных участников митинга.
6. Выявлять скрытые проблемы а не проводить менеджмент статус. Цель Статус митинга — способствовать тесному сотрудничеству команды и выявить все возможные проблемы, которые могут встать на пути к Цели Спринта.

3 вопроса на Дейли Скрам митинге:
— Что я делал вчера
— Что я буду делать сегодня
— Какие проблемы у меня возникли

Возможен еще один дополниельный 4й вопрос — Насколько я оцениваю риски не достигнуть цели Спринта. Это может помочь выявить скрытые риски, о которых может быть неудобно говорить команде в течении Дейли Скрама. Как пример — архитектурная бага, которая напрямую не связана с функционалом текущего Спринта. Или девелопер стесняется сказать что работа над Таской займет больше времени и тянет до последнего.

[28.03.2018]
МВП 1
МВП 1 был запланирован на Май. Т.е. мы имели 7 мес. чтобы показать первый работающий продукт. При том что полную команду мы собрали только в апреле. В январе, на Спринте 5 к нам в команду пришел мидл дев Берни. Человек уникальный и очень похож характером на меня — ему вечно все не нравилось. Мне тоже все не нравилось, но я был на позиции человека, который должен был все заменеджить, поэтому мне постоянно приходилось успокаивать Берни. Берни постоянно требовал для себя детальные таски, чем превращал наши Спринт Планинг митинги в ад. В начале было очень тяжко — уходило масса времени на Берни — описания таски не дашь — будет куча фона что непонятно как делать, дашь описание — его всегда мало либо оно не понятно написано. Но я таки понял, как работать с таким характером — давать полную ответственность за свою часть функционала. В итоге Берни занялся отдельным куском функционала под присмотром лида, и жить стало чуть полегче.

Берни еще раз дал понять, что Стори грумятся плохо и девелоперам, по сути, не ясно что делать в начале Спринта. Я начал эскалировать проблему ПМу, а он в свою очередь СЕО.

А проблема заключалась в том, что Продукт Овнер Гатри у нас был bottle neck’ом. Все коммуникации шли через него, и мы не имели прямого доступа к стейкхолдерам. Много вопросов оставалось открытыми и это не позволяло нам нормально грумить Стори и переводить их в статус Реди. Чтобы девы не простаивали, работу и функционал придумывали на лету. Очень часто у нас складывалось впечатление что продукт мы делаем не для заказчика, а для себя — как хотели, так и делали, безо всякого ревью со стороны заказчика. ФЕЙЛ 16. ЕСЛИ ТЫ ЗАКАЗЧИК НИКОГДА ПОЛНОСТЬЮ НЕ ДОВЕРЯЙ ВЕНДОРУ. Это был основной и главный фейл всей нашей разработки, как с нашей стороны, так и со стороны заказчика.

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

Случилось это в конце Января, на Спринте 6. Миро уже к тому времени собрал почти всю команду, Дельво только оставалось ее формально нанять, плюс найти еще одного аналитика и девопса. Тяп Ляп Продакшн только недавно наняла Дельво на работу, и поработав немного на другом проекте он был переведен к нам как лучший ПМ в штате. По началу Дельво мне понравился, пока он входил в курс дела и сдавал дела по прошлому проекту, его было не видно и не слышно. У нас была уникальная возможность самоорганизоваться как команда и поработать несколько спринтов без лишнего менеджмента. Я выполнял роль как Продукт Овнера так и Скрам Мастера. Можно сказать, что это было золотое время нашего проекта, но длилось это всего пару месяцев до начала Мая. Перед релизом МВП 1 Дельво вошел в курс дела, полностью освободился от прошлого проекта и принялся нам «помагать». У него была не простая задача — он отвечал за выдачу МВП 1, не принимав никакого участия в ее разработке. И вместо того, чтобы переложить ответственность на команду, с неплохой велосити на тот момент, он принялся разбиратся во всем сам, предлагать какието решения по реализации, улучшению процессов, в общем «помагать» всеми силами. Собственно, это был один из основных его косяков, и то я думаю это связано с банальным непониманием специфики работы по Скраму. Учитывая, что ни у кого из нас его не было — назовем это спецификой его работы. Но, благодаря стараниям Дельво, я не только получил прямой доступ к стейкхолдерам, я мог ездить в командировки на сайт к заказчику. О Дельво я еще не раз буду упоминать по ходу рассказа, потому как его решения были судьбоносными для проекта.

[29.03.2018]
В конце февраля на Спринт 7 к нам пришел мидл дев Неш. Человек-троль — так могу охарактеризовать его одним словом. Был моим основным конкурентом по шуточкам, подколам и троллингом сотрудников. Именно Неш опустил велосити команды больше всех, потому как входил в ритм команды медленно и с шуточками. Зато, в отличии от Берни, брал таски в работу с минимальным описанием и задавал минимум вопросов и по сути. После вхождения в ритм команды требовал к себе минимально внимания.

Команда росла быстрым темпом и в начале марта команда пополнилась мидл девом, КУА лидом и Девопсом. Внимание! Обращаю ваше внимание что КУА как единица появилась на проекте только спустя 5 месяцев фактического начала проекта, на 8м Спринте девелопмента!

КУА лид Бергнер разу же столкнулся с проблемой большого количества готового функционала, на который ему нужно было написать авто тесты. Документации на функционал не было, описания Сторей были посредственные, аксептанс критериев не было — это просто кошмар для тестировщика. Нужно отдать должное Бергнеру, он взял все в свои руки и по крупицам начал собирать аксептанс критерии. Наличие КУА добавило нам еще одну проблему — теперь нужно было не только писать код без багов, но и ранее написанный код должен был пройти тесты задним числом. Это было просто нереально сделать, так как нужно было бернить текущие Стори. Как результат — поначалу тестеры у нас были как формальность, для галочки — никто на них не обращал внимания. Только через пол года, к МВП 3, тестеры сумели догнать девелопмент (тогда уже КУА команда насчитывала 4 чел.). ФЕЙЛ 17. ТЕСТЕРЫ ДОЛЖНЫ ПРИСУТСТВОВАТЬ С САМОГО НАЧАЛА ПРОЕКТА ЧТОБЫ ИМЕТЬ ВОЗМОЖНОСТЬ ДРАЙВИТЬ ДЕВЕЛОПМЕНТ К ЛУЧШЕМУ КАЧЕСТВУ. Если охарактеризовать Бергнера одним словом — то это будет хитрый лис. Он был настолько хитрым, что умудрялся договорится со всеми — с клиентом, с ПМом, с СЕО, с командой, с аналитиком и даже с Пикассо (который мало кому нравился). Это было потрясающе — его любили все и для каждого у него были истории.

Мидл дев Танги влился в команду как сметана в борщ. Практически никак не зааффектив велосити команды, он сразу же начал бернить Таски. При этом требуя к себе минимального внимания. Для меня он — идеальный девелопер и член Скрам команды. К сожалению, он покинул нашу звездную команду через пол года, уехав на релокейт в Европу. Он был просто слишком хорош для нас...

Девопс Бекон оказался самым умным из нас, и поняв в какую компанию и какой проект он пришел — уволился сразу же после окончания испытательного срока, через 3 мес. За это время он успел настроить окружение под четким руководством архитектора Дали, который на тот момент еще принимал активное участие в проекте. Благодаря Бекону я пересел с винды на мак, за что ему очень признателен!

В конце марта, на Спринте 9 мы закончили формировать команду девелоперов. На работу вышло еще 2 мидл. девелопера. Первым из девов пришел Швиттерс. Как и Танги, он сразу же включился в работу и начал бернить Таски. Чем интересен Швиттерс, так это тем, что он постоянно был мотивирован работать и продержался дольше всех на проекте. Бывали времена, когда вся команда, в том числе и я, теряла мотивацию к работе, но Швиттерс все также продолжал бернить. В чем секрет такого перформанса для меня до сих пор загадка.

Через неделю после Швиттерса пришел Фредди. Самый молодой член нашей команды, но самый эффективый и амбициозный. Он умудрялся бернить в 2 раза больше Стори Поинтов чем все остальные. И это при том, что он был перфекционистом и писал без говно кода. Перфекционизм Фредди раздражал много кого в нашей команде, но в большей степени Пикассо, который привык делать быстро, а потом думать и рефакторить. Вообще, качество нашего кода было совершенно биполярно, часть команды делала быстро и с говнокодом и багами, часть медленно, но красиво. Единого подхода к разработке не было, так как команда была поделена между 3мя лидами, каждый со своим отдельным видением прекрасного (об этом детальнее я напишу позже). Наш Фредди уже через пол года стал синиором, а через год я его уже номинировал на роль лида. ПМ Дельво проигнорировал лидерские стремления Фредди и Фредди ушел с проекта проработав чуть больше года.

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

вiд „митця”: https://******.it/2018/03/23/agile-vs-waterfall/

Итого, перефразируя пословицу: «Раз в год и скрам может выстрелить»

"Бывали времена, когда вся команда, в том числе и я, теряла мотивацию к работе"©
Можно чуть подробнее ? (Симбиоз описан настолько аппетитно, что кажется, что потеря мотивации к работе просто нереальна..)

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

ооо, батенька. А как вы думаете продаются аджайл проекты? :)

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

Приблизительно как ремонт в квартире делать. Посчитали материалы, посчитали работу, прикинули смету, вышло, скажем 10к грн. Вы соглашаетесь. По ходу ремонта вы забыли про новую люстру, повесить ее это плюс 100грн. Не хватило шпаклевки — плюс 1000грн и т.д. В итоге сумма может вырасти в разы.
А может и наоборот, вам срочно нужно заехать потому что с прошлой квартиры уже выгоняют. Ремонт в большой комнате отменяется — это минус 3к грн.

ээ. кэп, это вы?

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

ах это. ну так предметно возразить можете?
и насчет опыта — я хоть и не коуч, но кушаю это аджайл уже с десяток лет

так вы только подвердили мое «громкое заявление»:

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

вы постоянно переходите на личности. это все аджайл апологеты такие или есть адекватные?

1. на вопрос вы так и не ответили: сначала я услышал сарказм, потом хамство (тыканье, указывание чем мне надо заниматься и тп)
2. Что в моей изначальной фразе указывало на серьезность утверждения? нежели выражение «вотерфол галимый»
3. я возможно и одиозный, но вы просто банальный хам (впрочем, вам по профессии положено)

Чтобы получить велосити команды делим время команды на 9 часов (среднее время на сторю). 43-53/7 = 6 — 7

 Делим время на 9, а пишем в формуле 7. Вопрос: «Какая из трех черепашек пиздит». Что-то не сходятся формулы

Спасибо! Исправил, мой завтык

серьезно думаете что успех проекта зависит от скрама или какой другой модной фишки?

Честно, я хз от чего зависит успех проекта :)

В основном не от этого, Лурий)

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

ЕСТИМЕЙТ. Октябрь — Ноябрь 2005.
Продолжение следует....

Долго думала компания Тяп Ляп Продакшн брать меня или нет... В итоге взяли, видимо потому что горели сроки и я был дешевым и самым доступным. Мог выйти на работу хоть на след. день. На след. день я не вышел, но начал работать удаленно, получая 2 ЗП в 2х разных компаниях :)
Вначале был Хаос. Не было Скрам процессов, Скрам Мастера, Скрам команды. Не было даже беклога. Был только BRD документ, где в описательной форме на 81й странице было изложено видение заказчика нового продукта.
Моя первая задача была создать Космос. И я принялся творить :) Не имея опыта в Скраме я принялся делать как художник — так как видел. Выписал тезисно, в формате требований, все хотелки кастомера. Сгруппировал требования по Епикам и занес это все это в ексель (вышло 978 строк). Заняло у меня это 2 недели. Это был первый Артефакт на проекте. ФЕЙЛ 2. НЕ ПРАВИЛЬНО СОСТАВЛЕННЫЙ БЕКЛОГ. ВО ПЕРВЫХ ФОРМАТ ТРЕБОВАНИЯ НИКАК НЕ ПОДХОДИЛ К НАШЕМУ АДЖАЙЛ ПРОЕКТУ. ВО ВТОРЫХ НЕ БЫЛО РОЛЕЙ ПОЛЬЗОВАТЕЛЕЙ. В ТРЕТЬИХ НЕ БЫЛО ОЖИДАЕМОГО РЕЗУЛЬТАТА ОТ КАЖДОЙ СТОРИ. В ЧЕТВЕРТЫХ КАСТОМЕР НИКОИМ ОБРАЗОМ НЕ ПРИНИМАЛ В ЭТОМ УЧАСТИЯ.
Как раз ко времени создания беклога уже была первая команда их 3 девов и одного куашника: Все тот же парт-тайм Пикассо, штатный дев компании Джакометти, который почему-то работал из Одессы, новый синиор дев Бретон и куа лид Шагал.
Этой командой (кроме Шагала, он участия пока никакого не принимал, изучал BRD) мы начали работать над нашим первым Артефактом — Беклогом. Первая задача была сделать естимейт беклога. Мы брали каждое требование (да, это не были Юзер Стори), декомпозировали его на таски и оценивали каждую таску в Стори поинтах. Требования, которые было вообще не понятно как делать получали оценку 50 либо 100 Стори Поинтов. Первую неделю это были митинги по скайпу, дальше всем стало в лом и оценки приходили ко мне от каждого дева отдельно. Я выводил среднее и заносил в финальную оценку. Оценки, которые расходились в естимейте больше чем на 2 стори обсуждались отдельно. Отдельно оценивался естимейт на анализ, дев и куа. Еще раз, Шагал никакого участия в оценке не принимал, оценки ставились девами вместо него. На пол пути нашей оценки к команде присоединился еще один синиор дев Массон. И мы закончили уже в 5тиром. ФЕЙЛ 3. ОЦЕНКА ДЕЛАЛАСЬ ОЧЕНЬ ДЕТАЛЬНО И ЗАНЯЛА МНОГО ВРЕМЕНИ. ОНА ПОТОМ ВСЕ РАВНО ПЕРЕСМАТРИВАЛАСЬ КАЖДЫЙ СПРИНТ. ЗАЧЕМ БЫЛО ТРАТИТЬ 2 НЕДЕЛИ НА ПРЕДВАРИТЕЛЬНУЮ ОЦЕНКУ НЕ ПОНЯТНО.
Также вызывает вопрос моего участия как Аналитика/Продукт Овнера в оценке, потому как моя роль была просто записывать оценки и сводить их воедино. Может быть мне стоило в это время хорошенько подготовится к первому Спринту и к его началу иметь уже запас Сторей, которые заапрувлены клиентом и которые понятно как делать...
Вся эта оценка заняла около 2х недель. Один Стори поинт был оценен в один рабочий день. В результате получили естимейт проекта для команды в 4 чел — 2 года.
Вся эта информация была передана Миро и через некоторое время мы получили ответ: 2 года для клиента дорого, нужно сделать за год. ФЕЙЛ 4 ПОЛИТИЧЕСКИЙ. НУЖНО УЧИТЫВАТЬ ОЦЕНКУ КОМАНДЫ, НЕЛЬЗЯ ПРОСТО ВЗЯТЬ И В 2 РАЗА УМЕНЬШИТЬ ЕСТИМЕЙТ, ТЕМ БОЛЕЕ ЧТО ОЦЕНКА БЫЛА ДОСТАТОЧНО ТОЧНОЙ!
Оценка на анализ и куа не была вообще учтена. Миро выкатил Релиз План с 2мя фазами и 6тью MVP. Фаза 1 (MVP1 — MVP4) включала требования которые хоть както понятно было делать, Фаза 2 (MVP5 — MVP6) — все остальное. MVP1 — это минимально работающий функционал, MVP2 — дабавляем кучу фич, MVP3 добавляем юай, MVP4 — продукт готов к продакшину. MVP1 должен был быть готов к Маю, т.е. у нас оставалось Ноябрь — Май = 5 мес. Фаза 1 должна была быть закончена ровно через год к Ноябрю.
Я не зря не упоминиаю о Спринтах и Ролях потому как их пока нет.

Даже смысла писать нету что было сделано не правильно — все было сделано не правильно. Как нужно было делать правильно см. ниже.

Оценка проекта по Скраму. Есть несколько способов. 1. Использовать исторические данные (Historical Data), т.е. опыт команды на прошлых проектах. 2. Подождать и увидеть (Wait and See), т.е. запилить 3 спринта и на основе этой велосити сделать оценку всего беклога. 3. Слепая Оценка (Blind Estimation). В нашем случае подходил только последний вариант, про него немного детальнее.
Слепая Оценка состоит из таких частей:
1. Оценить продукт беклог
2. Декомпозировать шаблонную сторю
3. Аппроксимация стори поинтов в часы
4. Оценить велосити команды
Важно! Эта техника предусматривает что после нескольких спринтов когда будут уже реальные данные велосити команды и точная оценка шаблонной стори, оценка по методу Blind Estimation идет в мусорник и заменяется реальными данными.
ФЕЙЛ 5. НАША ИЗНАЧАЛЬНАЯ ОЦЕНКА НИКОГДА НЕ ПЕРЕСМАТРИВАЛАСЬ НА ПРОТЯЖЕНИИ ПРОЕКТА.

Шаг 1. Оценка беклога.
Выбираем из всего беклога штук 5 шаблонных Сторей размером в 2 стори поинта. Сравниваем оставшиеся Стори как больше-меньше с нашими шаблонными Сторями и проставляем оценку всем Сторям в беклоге. Для оценки лучше использовать ряд Фибоначи 1,2,3,5,8,13...
Шаг 2. Декомпозируем шаблонную сторю.
Дальше грумим и декомпозируем на Таски наши шаблонные стори. Оценка Тасок делается в Часах, используя тот же ряд Фибоначи. Оценка больше 13 часов недопустима — в этом случае Таска дробится на несколько.
Шаг 3. Апроксимируем стори поинты в часы.
Напомню, все шаблонные Стори у нас по 2 Стори Поинта.
Сторя 1 займет у нас 14 часов
Сторя 2 — 22 часа
Сторя 3 — 20 часов
Сторя 4 — 18 часов
Сторя 5 — 16 часов
Среднее время на сторю — 18 часов. 18 часов на 2 стори поинта = 9 часов на Стори Поинт. Херовастенькая оценка, выходит одна Сторя будет занимать у нас больше одного рабочего дня. Но для оценки это пофигу, поэтому идем дальше.
Шаг 4. Оценка велосити команды.
Каждый член прикидывает сколько чистого времени он может тратить на написание кода. Например, наш Пикассо, так как он работает парт-тайм на проекте может тратить, допустим, 4 часа в день. Другой дев может, посидев в ФБ, почитав новости и сходив 2 раза на обед может тратить в день 5 часов. Третий, более сознательный 6 часов, и т.д. Каждый дает свое максимальное и минимальное время. Для нашего кейса с 3мя девами и 2х недельным спринтом (10 рабочих дней) это бы выглядело так: Пикассо — 4(3) * 10 = 30-40 часов. Дев 1 — 5(4) * 10 = 40-50. Дев 2 — 6(7) * 10 = 60-70.
Среднее время команды выглядит так: 43-53 часа за спринт.
Чтобы получить велосити команды делим время команды на 9 часов (среднее время на сторю). 43-53/7 = 6 — 7. Результат, наша супер команда сможет бернить 6-7 Стори Поинтов за Спринт.
Чтобы получить общее время проекта просто делим общее кол-во стори поинтов в беклоге (допустим 200) на нашу велосити. 200/6-7=33-28. Выходит нашей супер команде чтобы запилить такой проект нужно будет 28 Спринтов при лучших раскладах и 33 Спринта — при худших.

Еще не все. Теперь нужно приоритезировать наш беклог, чтобы понимать какие Стори пилить в начале и какой спринт будет первым. Нам поможет техника The Big Wall.
Пишем Стори на карточках. Находим большую стену и клеим на нее карточки. Стори располагаем в таком порядке с лева на право: Стори в 1 Стори Поинт — вертикальная линия — Стори в 2 Стори Поинта — вертикальная линия — и т.д. Должно получится так, чтобы Стори с одинаковой оценкой были в своих отдельных колонках. Зовем стейкхолдеров либо кастомера и просим расставить Стори по вертикали так, чтобы вверху были самые приоритетные Стори, внизу — с наименьшим приоритетом.
Итого, в первые Спринты идут Стори с низкой оценкой и высокой важностью, Стори с высокой оценкой и высокой важностью — кандидаты на ближайшие груминг сессии. Стори с низкой оценкой и низкой важностью идут в конец беклога, оставшиеся Стори с низким приоритетом и высокой оценкой идут еще ниже. Внимание! Эта техника не заменяет Релиз План, но это уже другая история...

ПЕРВЫЙ СПРИНТ. Ноябрь 2005.
Продолжение следует...

В принципе, нет повода оценивать то, что ещё не определенио. Это означает, пока таски (это необязательно «юзер сториз») бэклога не сформулированы детально так, чтобы разработчик мог сесть и начать их делать — такие таски рано оценивать.

В итоге, когда таски прописаны подобающим образом (либо непрописаны, но кодерки более-менее знают, как их реализовывать) + достаточно точно сформулированы «акцэптэнс-критерии», такое уже можно оценивать.

И вот такая оценка, уже будет довольно-таки точна. Кроме того, такую оценку можно сделать довольно быстро. Cкажем (из опыта на проектах), можно в течении 2-3-х часов более-менее точно оценить таски бэклога на следующие полгода, для команды из 4-5 чел.

Предварительная оценка нужно чтобы знать сколько $ просить у клиента

Предварительная оценка нужно чтобы знать сколько $ просить у клиента

А как оценивать, если неясно ни что делать, ни как делать?

Я ведь написал: «когда таски прописаны подобающим образом (либо непрописаны, но кодерки более-менее знают, как их реализовывать) + достаточно точно сформулированы „акцэптэнс-критерии“, такое уже можно оценивать».
И после такого описания тасков — уже действительно можно разбираться и с деньгами/оплатой.

Скажем, из моего примера выше: «в течении 2-3-х часов более-менее точно оценить таски бэклога на следующие полгода, для команды из 4-5 чел» — речь идёт о том, что команде из 4 чела выделяют 3500 часов на следующие полгода (это часы, которые будут оплачены заказчиком с определённой стоимостью). И в течении 2-3 часов, команда набирает тасков на эти полгода (и заказчик с этим объёмом работ соглашается).
Но это работает, только если таски прописаны достаточно детально и команда в курсе, как их делать. А если не детально или непонятно — такой таск не оценивается, т.к. себе дороже...

То есть, предлагаешь такой проект сразу отдавать конкурентам?

Если заказчик настаивает, чтобы ему сделали эстимэйт без детального описания работ — пускай идёт к конкурентам.

От такого заказчика будут лишъ проблемы, неуплаты и судебные тяжбы (бесперспективные).

Я когда-то научился такому трюку, когда с арабами работал, если в сторе ничего нет или херня какая-то — ставишь ей эстимейт 100 дней или 800 часов. Заказчик такой — ООО, надо бы прояснить ))) Но ты прав, заказчик конфликтный и с ним была просто туча проблем. Наша проблема в том что сейлзы, менеджеры и прочие уже наобещали и продали.

Если вообще неясно что делать то есть такая тема MVP за 3 дня.

так команды же тоже не было, кем велоситить?

! Просьба удалить мой коммент выше. Это копия основной статьи!

Спойлер: убийца заказчик

А где же скрам мастер?

Съели, но кадры остались в режиссёрской версии

Что это за сериал, что тут обсуждать? Писали бы сразу все, или не писали бы вообще.

И нет сисястых тёлок, и ружжё на стене не висит

Там много персонажей... Был и face seller со стороны заказчика, и молодые гномы-интерны...

и долго вы так из себя собираетесь выдавливать по капле? )

Миро, Пикассо и Дали в контексте разработки — очень меткая аналогия.

Зареєстрований 27 квітня 2014

Сидел Иван ... то есть Iurii на печи 3+ года, насмотрелся на высеры с итальянского домена и решил что он ничем не хуже.

Хороший БА должен уметь четко и однозначно описывать ситуации.

Девелоперов было 6-10 в разные периоды, единственный эпик фейл — жадность заказчика. Сначала это проявлялось во впихивании в BRD всего, до чего доходила фантазия, потом — жадность платить сверх оговоренного, когда поняли, что за эти деньги они конфету не получат. По сути требовали параллельной разработки хардкод поддержки платёжных систем и волшебного агностик интерфейса, который должен работать с абстракциями. Если верить удивлению заказчика по поводу такой параллельной разработки под конец спектакля, то накосячил ещё продакт овнер. И сильно так накосячил.

ПыСы: команда была заебись. Лучшая из всех на моей памяти.

Да Макс, спасибо, я это учту в дальнейшем рассказе :)

1. Успешным проект делает не процесс, а кодерки.
— как-то работал я в одном проекте, где был вполне функционирующий аджайл, около-100% покрытие юнит-тестами, порядка пары сотен одних лишь кодерков на проекте. Тем не менее, из проекта вышел эпик-фейл, когда после 3-х лет пиляний проект закрыли и выбросили на помойку. (потом, по слухам, забрали с помойки, отмыли, открыли снова и даже допилили до релиза, в сильно-урезанном виде и через 4 года после первоначального плана).
— а в другой компании проекты были без аджайла, без бэклога, без юнит-тестов, с двумя десятками кодерков (на все проекты) — но компания была лидером в своей области (написание бл/гуёв для медоборудования).

2. «гениальный архитектор Дали», «сейчас работает в Польше» — нет ли тут противоречия?

Цель статьи поделится опытом а не кого-либо обосрать, хотя очень хочется :)

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

Но ведь заказчик платит за человеко-часы?

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

Подписаться на комментарии