Эта публикация вдохновлена одной из многочисленных презентаций о том, как планировать спринт в разработке, коих за свою жизнь я видел очень немало. И все они похожи одна на другую, как однояйцевые близнецы - всегда очень красивые рисунки и выверенный текст типа «тут у нас аналитика, вот разработка и тестирование, двухнедельный спринт, в конце спринта все задачи закрыты, руководство в восторге, заказчик счастлив». Я же хотел бы показать реальность такой, какая она есть.
Пройдемся по совершенно обычным для каждого тимлида проблемам, и способам их решения. Начнем с самой распространённой.
Меня зовут Султанов, и я тимлид (тяжелый вздох). Стараюсь завершать все задачи по спринту в срок. Иногда даже получается. А еще у меня есть канал, где можно обсудить эту и другие статьи. Подписывайтесь, там интересно.
1. Ниуспе…
Никогда не видел, чтобы на презентациях завершенные спринты выглядели вот так:
В идеале конечно надо всё успевать, но положа руку на сердце (а другую на библию конституцию), признайтесь, какой процент спринтов полностью выполняется? Хорошо, если ответ будет "около 50%"). В остальных же спринтах хоть что-то, да не успеваем. Что делать?
Стандартные решения – просто перенести на следующий спринт и доделать, закрыть и доделать в фоновом режиме, закрыть как есть и занести в техдолг. Все эти способы по тем или иным причинам не очень хорошие.
Решение:
Пересчитать историю, и зачесть команде столько сторипоинтов, насколько команда наработала, после сделать инъекцию в бэклог, куда внести остаток от спринта отдельной историей с остаточной оценкой и высшим приоритетом, и делать в следующем спринте уже её до победного. Недостаток этого решения очевиден – зачем точно оценивать истории, зачем спешить, если мы всегда можем взять время и доделать в следующем спринте. В этом случае неплохо применить к команде некие штрафы, например за каждый подобный случай лишать части премии назначать штрафные баллы, и устраивать соревнования команд.
2. Проблемы у конкретного разработчика
Разработчик – зверь хитрый и изворотливый. Это только кажется, что они все такие самостоятельные и проактивные, на самом деле они, как и все люди, очень разные.
Конечно, есть подход «не работай с мудаками», да вот только он совершенно не масштабируемый. Набрать 10 супергероев на суперинтересный и общественно значимый проект – можно. Набрать 100 супергероев на скучное банковское легаси – очень навряд ли. Так что работа с мудаками – это и есть самая настоящая будня тимлида особенно когда он сам мудак.
2.1 Прямой обман
Надо сказать, случай и правда довольно редкий, так как за него в итоге всё равно прилетит. Но потом. Поэтому можно перевести небольшую задачу в «сделано», зная, что лид сейчас занят и не проверит, и уйти в отпуск, а там как-нибудь отмажемся…
2.2 Разработчик перестал работать
Обычно случается после долгих праздников, отпусков, отмечания свадеб и прочих перерывов в работе. Ну и при выгорании, конечно же. Именно тут возникают очень интересные истории с такими «невероятной сложности плавающими» багами, которые «делались» полспринта, и в итоге решались за 2 минуты при ближайшем рассмотрении.
Решение:
Подобные случаи в начале моего тимлидского пути и научили меня никому не верить на слово, и просить показать, что сделано. Регулярно, раз в пару дней. Это приучает разработчиков к добросовестности и к тому, что лид всё равно не отстанет. Беда наступает, когда лид перестает всё контролировать сам – просто не успевает. Тогда лучше всего организовывать перекрестный код-ревью, а лиду показывать уже более-менее готовый функционал.
3. Конфликт
Как внутри команды, так и с заказчиком (его представителем, продукт-овнером и т.п.). Обычно выглядит как куча комментариев (и комментариев к комментариям) с постепенным повышением накала, вплоть до перехода к личным оскорблениям.
Бывает, что кто-то из команды очень хочет попробовать какую-то технологию, для проекта не нужную, и начинает её лоббировать. Случается, что включает её самостоятельно, огребает проблем и потом не знает, как их решать, что не сильно радует остальных.
Иногда не сходятся во мнениях представитель заказчика и техлид, что приводит к отсутствию согласования и срыву спринта, так как нельзя завершить историю без согласования представителем заказчика.
Решение:
Обычно конфликт заканчивается волевым решением ответственного, и именно для этого очень неплохо четко распределять зоны ответственности заранее. Если не получилось – можно прямо в ходе конфликта, только письменно с оповещением всей команды, и дальнейшими встречами один на один со сторонами, чтобы предотвратить намеренный саботаж решения или уничижение «проигравшей» стороны.
4. Мы тестировали-тестировали, да не вытестировали
Встречается регулярно при недостатке времени на тестирование и попытке закрыть историю до конца спринта. Думаю, всем понятно, что не до конца протестированное решение включать в релиз нельзя.
Решение:
Описано вот тут. А изловить такую ситуацию можно, затребовав с тестировщиков письменные результаты тестов. Они будут упираться (работа с документами всегда скучна), но даже мимолетного взгляда на план тестирования и результаты будет достаточно, чтобы задать ряд увесистых вопросов. Ну и заодно зафейлить сроки по истории.
5. Заказчик на дэмо: я не это имел ввиду
Этих слов боятся все, особенно менеджмент, потому что слова эти значат почти наверняка срыв сроков по проекту и уменьшение премиальной части. На этапе произнесения сделать уже ничего нельзя, история скорее всего уходит на помойку в стол, и начинается этап уточнения требований. Считать ли это проблемами спринта (ведь по сути история сделана, и сделана в срок) – ученые спорят.
Решение:
Работать с заказчиком не только на дэмо, но и в течении спринта, периодически уточняя, не изменились ли его требования. Помогает не всегда просто потому, что заказчик, с которым можно работать, и заказчик, принимающий работу – далеко не всегда одно и то же лицо. Но надо же хоть что-то делать.
6. Включи в текущий спринт очень срочную задачу сверх плана!
Случается не часто, но регулярно, обычно связана с багами на проде или прям срочными требованиями очень высокого руководства заказчика, про которые все, включая представителей этого самого заказчика, дружно забыли. Срывает все сроки, сносит крыши и башни, вызывает переработки, а потом лежит никому не нужное полтора месяца, потому что «ждем релизного окна».
Решение:
Запрет на включение в спринт любых задач, кроме запланированных. Всё, что прилетает сверху, снизу, сбоку, включается в бэклог будущих спринтов с высшим приоритетом. Помимо создания спокойной атмосферы в команде, это решение еще и здорово охлаждает горячие головы людей, старающихся понравиться заказчику, одобряя любые его требования и бросающихся немедленно их исполнить.
И вот теперь, ознакомившись с этим далеко не исчерпывающим перечнем проблем каждого спринта, вы перестанете задавать вопросы типа:
Комментарии (14)
jvsg6
08.04.2024 15:44Круто читать про реальный нерафинированный опыт других команд.
У нас ситуаци ситуация немного отличается от описанной. У нас нет ни pm-а ни явно выделенного тимлида, через которого проходила бы постановка задач. Поэтому у нас все спринты всегда выглядят так, как на скрине в статье.
В статье написано, что вы пользуетесь сторипоинтами для оценки задач. Подскажите, пожалуйста, вы переоцениваете соответствие типичных задач сторипоинтам? Или норму сторипоинтов на человека со временем?
Интересен ваш опыт, т.к. для оценок новых задач я ввел матрицу соответствия типичных задач сторипоинтам, но со временем мы стали делать задачи сильно быстрее, т.к. набили руку и теперь нам надо сделать или переоценку типичных задач или поменять вместимость сторипоинтов в человека.
Trihlorid Автор
08.04.2024 15:44Вообще переоценку положено делать раз в квартал, но у нас происходит примерно раз в год.
ruomserg
08.04.2024 15:44+3Мы в какой-то момент посмотрели корреляцию между story-points и тем, сколько задача шла от входа до выхода - и не увидели корреляции (ну, почти). Поэтому, волевым решением оценку задач со всеми ритуалами отменили. Оставили пожелание нарезать подзадачи не больше чем на 1-3 дня (сабтаски создает сам разработчик). Поскольку статусы задач все-равно обсуждаются в дейли, и есть алерты на зависание задач без движения - хуже точно не стало. А пожалуй что и лучше: можно лишний час работать, а не играть в покер с числами фибоначчи...
Trihlorid Автор
08.04.2024 15:44Вы просто не для того применяете сторипоинты, я в ответе на первый комментарий пояснил, для чего они нужны. При оценке задач, уже принятых командой к выполнению, они бесполезны.
ruomserg
08.04.2024 15:44Я понял вашу стратегию: от задач вы получаете стори-поинты, из истории вы берете velocity команды, делите одно на другое - получаете дни. При этом, неявное допущение заключается в том, что существует корреляция между увеличением количества стори-поинтов и временем, которое команда затратит на их сжигание (иначе бы вы одно на другое не делили бы). Собственно, весь хоровод был затеян только для того, чтобы не вносить систематическую ошибку, оценивая сразу в человеко-днях (ибо работа всегда занимает все отведенное для нее время...). Введя промежуточную единицу оценки, мы надеемся что через исторические данные мы устраним систематическую погрешность, и получим хорошие и правильные человеко-дни на выходе.
В результате проверки на данных, которые были собраны на проекте, оказалось что корреляция между стори-поинтами и реальными сроками практически отсутствует. Если мы смотрим на картинку, где по одной координате отражается число стори-поинтов, а с другой - реальное число дней которое делалась задача - получается плоское распределение (бывает что задачу на 10 поинтов удается сжечь за день, а бывает что над задачей из 3 поинтов сидят неделю). После нескольких обсуждений на ретро, стало понятно что задачи не типовые, и оценки даются "по ощущениям". А пока ты задачу делать не начал, ощущения - довольно ненадежная штука...
По итогу, как я и написал - в команде стори-поинты отменены. Если попадается задача, которую мы раньше уже делали (или делали похожую) - тогда мы можем сразу дать оценку в днях или человеко-днях. Если же такого опыта нет - то увы, можем только гарантировать что будем нарезать на мелкие подзадачи в процессе чтобы был понятен прогресс.
Batalmv
08.04.2024 15:44+4Мне иногда кажется, что спринты, и вообще, все методология вокруг этого превратилась в нечто самодостаточное
К примеру, я считал, считаю и буду считать, что Agile - это исключительно принципы и ценности. Все. Как заповеди Моисея. Читай, думай и пользуйся. Все остальное - это ритуалы, или церкви, если так угодно. Попытки, и надо сказать, крайне удачные, на ровном месте создать огромную (и наверное рекордную) монетизацию. Но смысл нести туда деньги - мне не ясно. Так и с "методиками" и скрам-мастерами
Скрам - это хоть и методология, но суть не в том, что надо все делать, как написано в гайде. А в идеях, которые лежат под ним.
Не рассусоливая дальше, могу предложить простое решение - забить на успех спринта :) Суть ведь не в том, сикоко там в стори поинтах чего-то немеряли (это вообще смешно, что-то мерять, когда изначальная погрешность измерительного прибора где-то в районе 50%). Т.е. серьезно, меряем с такой "точностью", а потом чего-то считаем?
Суть в том, что ритуалы помогают (если ими пользоваться с умом):
Ограничивать давление со стороны заказчика (чувак, наша велосити 20 стори поинтов, а мы тут на этот спринт уже на 22 набрали - будем пахать как папа карло, и то не факт, что успеем). И ведь не поспоришь. Велосити!!!
При грамотном продакте реально делать полезные вещи. Но это большущая редкость. Обычно продакты просто "уйней" маются, заказывая фиг пойми что. Но реально шанс есть, главное помнить, что брать лучше то, чего понятно и точно надо, а остальное - потом. Посмотрите на демо, подумаете, покажете фокус группе. Может и передумаете
Ретроспектива - повод собраться и поговорить. Хотя это обычно редко выходит, но ... как по мне, если что-то идет не так - зачем ждать.А если демо прошло неудачно - и так стоит собраться и поговорить. Но опять же - во времена офисной работы можно было заказать пиццу и банально час ни о чем не думать
Планинг / рефайнмент - в реальности наверное самое полезное, так как можно задать "глупые" вопросы, которые окажутся не глупыми и задача будет сделана так как надо, а не так как думали изначально. Правда раньше такие встречи проходили по 5 раз в день в курилке, но кто ж эти времена помнит
Периодические "демо" дисциплинирует по принципу "песец подкрался незаметно", но зато небольшой
В основном я с автором согласен. По проблемам и по решениям. Спринты дают возможность лучше контролировать процесс, но только тем, кто делает свою работу. Кто нет - тем ничего не поможет
sshikov
08.04.2024 15:44Ваша формулировка "забить на успех спринта" в моем исполнении звучала бы скорее так: "Назвать имеющийся результат спринта успехом". Ведь что главное в успехе? То что вы с заказчиком согласны считать результат таковым. Результат полезен для заказчика, и получен в разумные сроки (возможно чуть позже, чем хотелось).
В остальном же согласен почти по всем пунктам.
Gariks
08.04.2024 15:44+1В последних 4 командах, мы быстро отходили от story point-ов в пользу оценки по дням, сейчас и вовсе отказывались от оценки задач и перешли на trunk based development + kanban. На этапе MVP проекта я стараюсь сделать gitflow + waterfall если это возможно, а после выхода релиза, на этапе развития и поддержке проекта tbd + kanban + value stream mapping правда моим приоритетом всегда является скорость доставки "ценности" на прод, но далеко не все считают это важным.
Trihlorid Автор
08.04.2024 15:44быстро отходили от story point-ов в пользу оценки по дням
Это внутри команды, или при оценке нового проекта целиком?
waterfall
А как релизите? С заказчиком не бывает проблем, как раз в статье описанных, типа "я не это имел ввиду"? Корректировка требований как происходит? В этом же главная беда waterfall.
Gariks
08.04.2024 15:44Внутри команды, потому что story point особо ничего не показывают. Если их оценивать по "сложности" задачи, то эта сложность меняется в процессе, когда приходит понимание бизнеса + есть уже наработки по кодовой базе. И получается их надо переоценивать, а тогда теряется смысл всех графиков на их основе.
По поводу waterfall, есть процессы сбора требований, составления документации и согласования этого с заказчиком, плюсом он получает сроки и смету, а команда железный roadmap, в котором можно запланировать этапы интеграции разных частей разрабатываемого приложения. Так же у команды появляется "вижн" общая цель и мотивация. Обычно на сбор требований и планирование я выделю 1 месяц (2 месяца если еще и команду надо подобрать), а MVP в моем понимании это проект 6 месяцев максимум.
StepEv
08.04.2024 15:44Не мучайтесь сами и не мучайтесь команду. Откажитесь от спринтов, они, в том виде как вы их используете, не несут вам пользы. Ну или изучите скрам, сходите на тренинг и наладьте процесс со спринтами.
Нет смысла засчитывать часть задачи в выполненные sp, вы таким образом лишает себя возможности корректно определить ёмкость спринта. В велосити засчитываются только завершенные задачи. Незаконченные возвращаются в бэклог и проходят цикл оценки и планирования по новой.
Успешный спринт это не когда все задачи завершены, а когда достигнута цель спринта и есть готовый к поставке инкремент.
Спринт это командная работа, если разработчик утащил задачку в норку и там её в одиночку грызёт, если у вас внутри задачи микроводопад, с последовательно анализом, разработкой, тестированием, вы что-то делаете не правильно. Если у вас большинство задач планируются к завершению в конце спринта, неудивительно, что часто не успеваете. Вы описываете причины, по которым не успеваете. Но скрам предлагает решения этих проблем. И это не те, которые описываете вы.
У вас не работает одна из вырванных из скрама практик. Ровно потому, что все остальные остались за бортом.
hoack
По первому пункту, я ушел от абстрактных стори поинтов, и перешел на вульгарные, банальные человеко-дни (ну то есть сказал, что у нас поинт - это примерно то, что можно сделать за один день работы). Планировать оказалось намного проще - у нас спринты 2 недели, и мы установили примерную скорость в 8 поинтов за спринт (с учетом всяких митингов и прочего). Стало очень легко учитывать праздники, всякую дополнительную деятельность и т.п. Не то, чтобы "Ниуспе..." совсем исчезло, но ушло на уровень минимального шума.
Что касается срочных добавлений в спринт, если они совсем-совсем необходимы и их не дают положить в следующий спринт, я привлекаю к обсуждению Product Manager'а, и пусть он решает, что именно мы выкинем из спринта (поскольку добавлять без выкидывания чего-то другого я не позволяю никогда).
Trihlorid Автор
Со сторипоинтами одна проблема - никто не понимает, зачем они нужны. Поясню.
Когда мы пытаемся оценить большой проект, мы разбиваем его на фичи и истории, и истории оцениваем примерно на основе уже проработанных историй (без всякой привязки к командам и людям). Принимаем примерную скорость команд (опять же на основе опыта), получаем количество итераций, то есть срок проекта. Тут и применяются сторипоинты.
При взятии историй в спринт сторипоинты нужны только для определения скорости команды, чтобы менеджеру понять, сколько примерно итераций осталось для проработки фичи. Внутри же команды при оценке спринта логично пользоваться днями и часами.
То есть сторипоинты - наружу, человеко-часы - внутрь команды. Двойная бухгалтерия, так сказать:)))
ruslan_sverchkov
Есть подозрение что так происходит потому что между любыми исчисляемыми попугаями (каким бы способом они ни были получены) и рабочими часами/днями/неделями есть взаимно однозначное соответствие, таким образом непонятно зачем плодить сущности если можно просто оценивать в часах/днях/неделях) Чтобы подчеркнуть для заказчика неопределенность? Этого можно и другими средствами добиться