Comments 17
По первому пункту, я ушел от абстрактных стори поинтов, и перешел на вульгарные, банальные человеко-дни (ну то есть сказал, что у нас поинт - это примерно то, что можно сделать за один день работы). Планировать оказалось намного проще - у нас спринты 2 недели, и мы установили примерную скорость в 8 поинтов за спринт (с учетом всяких митингов и прочего). Стало очень легко учитывать праздники, всякую дополнительную деятельность и т.п. Не то, чтобы "Ниуспе..." совсем исчезло, но ушло на уровень минимального шума.
Что касается срочных добавлений в спринт, если они совсем-совсем необходимы и их не дают положить в следующий спринт, я привлекаю к обсуждению Product Manager'а, и пусть он решает, что именно мы выкинем из спринта (поскольку добавлять без выкидывания чего-то другого я не позволяю никогда).
Со сторипоинтами одна проблема - никто не понимает, зачем они нужны. Поясню.
Когда мы пытаемся оценить большой проект, мы разбиваем его на фичи и истории, и истории оцениваем примерно на основе уже проработанных историй (без всякой привязки к командам и людям). Принимаем примерную скорость команд (опять же на основе опыта), получаем количество итераций, то есть срок проекта. Тут и применяются сторипоинты.
При взятии историй в спринт сторипоинты нужны только для определения скорости команды, чтобы менеджеру понять, сколько примерно итераций осталось для проработки фичи. Внутри же команды при оценке спринта логично пользоваться днями и часами.
То есть сторипоинты - наружу, человеко-часы - внутрь команды. Двойная бухгалтерия, так сказать:)))
Со сторипоинтами одна проблема - никто не понимает, зачем они нужны.
Есть подозрение что так происходит потому что между любыми исчисляемыми попугаями (каким бы способом они ни были получены) и рабочими часами/днями/неделями есть взаимно однозначное соответствие, таким образом непонятно зачем плодить сущности если можно просто оценивать в часах/днях/неделях) Чтобы подчеркнуть для заказчика неопределенность? Этого можно и другими средствами добиться
Не совсем согласен. Соответствие конечно же есть, но как только мы начинаем упоминать знакомые слова, типа "час, день, неделя", мозг начинает к этому привязываться, и вот были неопределенные 80 сторипоинтов, а стали вполне определенные 60 человеко-дней с иллюзией, что 30 человек сделают фичу за 2 дня. И да, это сложно объяснить заказчику, особенно когда он хочет тебя не понять и простить, а утопить.
Ну потому что заказчик это человек который рискует деньгами, ему не нужны никакие сторипоинты (которыми исполнитель пытается постелить себе соломку), ему нужно понимание когда у него будет результат. Представьте что вы квартиру покупаете чтобы жить и вам строители говорят «80 сторипоинтов». Хорошая новость в том что это не проблема а задача, для нее существуют хорошо известные решения, например буферы. Я же в итоге пришел к еще более простому варианту - прошу у исполнителей оценку для худшего случая, дату к которой невозможно опоздать. Это рождает свои проблемы, самая очевидная - закон Паркинсона, но с ними тоже есть понятные методы борьбы, в первую очередь - не иметь дел с безответственными раздолбаями)
Круто читать про реальный нерафинированный опыт других команд.
У нас ситуаци ситуация немного отличается от описанной. У нас нет ни pm-а ни явно выделенного тимлида, через которого проходила бы постановка задач. Поэтому у нас все спринты всегда выглядят так, как на скрине в статье.
В статье написано, что вы пользуетесь сторипоинтами для оценки задач. Подскажите, пожалуйста, вы переоцениваете соответствие типичных задач сторипоинтам? Или норму сторипоинтов на человека со временем?
Интересен ваш опыт, т.к. для оценок новых задач я ввел матрицу соответствия типичных задач сторипоинтам, но со временем мы стали делать задачи сильно быстрее, т.к. набили руку и теперь нам надо сделать или переоценку типичных задач или поменять вместимость сторипоинтов в человека.
Мы в какой-то момент посмотрели корреляцию между story-points и тем, сколько задача шла от входа до выхода - и не увидели корреляции (ну, почти). Поэтому, волевым решением оценку задач со всеми ритуалами отменили. Оставили пожелание нарезать подзадачи не больше чем на 1-3 дня (сабтаски создает сам разработчик). Поскольку статусы задач все-равно обсуждаются в дейли, и есть алерты на зависание задач без движения - хуже точно не стало. А пожалуй что и лучше: можно лишний час работать, а не играть в покер с числами фибоначчи...
Вы просто не для того применяете сторипоинты, я в ответе на первый комментарий пояснил, для чего они нужны. При оценке задач, уже принятых командой к выполнению, они бесполезны.
Я понял вашу стратегию: от задач вы получаете стори-поинты, из истории вы берете velocity команды, делите одно на другое - получаете дни. При этом, неявное допущение заключается в том, что существует корреляция между увеличением количества стори-поинтов и временем, которое команда затратит на их сжигание (иначе бы вы одно на другое не делили бы). Собственно, весь хоровод был затеян только для того, чтобы не вносить систематическую ошибку, оценивая сразу в человеко-днях (ибо работа всегда занимает все отведенное для нее время...). Введя промежуточную единицу оценки, мы надеемся что через исторические данные мы устраним систематическую погрешность, и получим хорошие и правильные человеко-дни на выходе.
В результате проверки на данных, которые были собраны на проекте, оказалось что корреляция между стори-поинтами и реальными сроками практически отсутствует. Если мы смотрим на картинку, где по одной координате отражается число стори-поинтов, а с другой - реальное число дней которое делалась задача - получается плоское распределение (бывает что задачу на 10 поинтов удается сжечь за день, а бывает что над задачей из 3 поинтов сидят неделю). После нескольких обсуждений на ретро, стало понятно что задачи не типовые, и оценки даются "по ощущениям". А пока ты задачу делать не начал, ощущения - довольно ненадежная штука...
По итогу, как я и написал - в команде стори-поинты отменены. Если попадается задача, которую мы раньше уже делали (или делали похожую) - тогда мы можем сразу дать оценку в днях или человеко-днях. Если же такого опыта нет - то увы, можем только гарантировать что будем нарезать на мелкие подзадачи в процессе чтобы был понятен прогресс.
Мне иногда кажется, что спринты, и вообще, все методология вокруг этого превратилась в нечто самодостаточное
К примеру, я считал, считаю и буду считать, что Agile - это исключительно принципы и ценности. Все. Как заповеди Моисея. Читай, думай и пользуйся. Все остальное - это ритуалы, или церкви, если так угодно. Попытки, и надо сказать, крайне удачные, на ровном месте создать огромную (и наверное рекордную) монетизацию. Но смысл нести туда деньги - мне не ясно. Так и с "методиками" и скрам-мастерами
Скрам - это хоть и методология, но суть не в том, что надо все делать, как написано в гайде. А в идеях, которые лежат под ним.
Не рассусоливая дальше, могу предложить простое решение - забить на успех спринта :) Суть ведь не в том, сикоко там в стори поинтах чего-то немеряли (это вообще смешно, что-то мерять, когда изначальная погрешность измерительного прибора где-то в районе 50%). Т.е. серьезно, меряем с такой "точностью", а потом чего-то считаем?
Суть в том, что ритуалы помогают (если ими пользоваться с умом):
Ограничивать давление со стороны заказчика (чувак, наша велосити 20 стори поинтов, а мы тут на этот спринт уже на 22 набрали - будем пахать как папа карло, и то не факт, что успеем). И ведь не поспоришь. Велосити!!!
При грамотном продакте реально делать полезные вещи. Но это большущая редкость. Обычно продакты просто "уйней" маются, заказывая фиг пойми что. Но реально шанс есть, главное помнить, что брать лучше то, чего понятно и точно надо, а остальное - потом. Посмотрите на демо, подумаете, покажете фокус группе. Может и передумаете
Ретроспектива - повод собраться и поговорить. Хотя это обычно редко выходит, но ... как по мне, если что-то идет не так - зачем ждать.А если демо прошло неудачно - и так стоит собраться и поговорить. Но опять же - во времена офисной работы можно было заказать пиццу и банально час ни о чем не думать
Планинг / рефайнмент - в реальности наверное самое полезное, так как можно задать "глупые" вопросы, которые окажутся не глупыми и задача будет сделана так как надо, а не так как думали изначально. Правда раньше такие встречи проходили по 5 раз в день в курилке, но кто ж эти времена помнит
Периодические "демо" дисциплинирует по принципу "песец подкрался незаметно", но зато небольшой
В основном я с автором согласен. По проблемам и по решениям. Спринты дают возможность лучше контролировать процесс, но только тем, кто делает свою работу. Кто нет - тем ничего не поможет
Ваша формулировка "забить на успех спринта" в моем исполнении звучала бы скорее так: "Назвать имеющийся результат спринта успехом". Ведь что главное в успехе? То что вы с заказчиком согласны считать результат таковым. Результат полезен для заказчика, и получен в разумные сроки (возможно чуть позже, чем хотелось).
В остальном же согласен почти по всем пунктам.
В последних 4 командах, мы быстро отходили от story point-ов в пользу оценки по дням, сейчас и вовсе отказывались от оценки задач и перешли на trunk based development + kanban. На этапе MVP проекта я стараюсь сделать gitflow + waterfall если это возможно, а после выхода релиза, на этапе развития и поддержке проекта tbd + kanban + value stream mapping правда моим приоритетом всегда является скорость доставки "ценности" на прод, но далеко не все считают это важным.
быстро отходили от story point-ов в пользу оценки по дням
Это внутри команды, или при оценке нового проекта целиком?
waterfall
А как релизите? С заказчиком не бывает проблем, как раз в статье описанных, типа "я не это имел ввиду"? Корректировка требований как происходит? В этом же главная беда waterfall.
Внутри команды, потому что story point особо ничего не показывают. Если их оценивать по "сложности" задачи, то эта сложность меняется в процессе, когда приходит понимание бизнеса + есть уже наработки по кодовой базе. И получается их надо переоценивать, а тогда теряется смысл всех графиков на их основе.
По поводу waterfall, есть процессы сбора требований, составления документации и согласования этого с заказчиком, плюсом он получает сроки и смету, а команда железный roadmap, в котором можно запланировать этапы интеграции разных частей разрабатываемого приложения. Так же у команды появляется "вижн" общая цель и мотивация. Обычно на сбор требований и планирование я выделю 1 месяц (2 месяца если еще и команду надо подобрать), а MVP в моем понимании это проект 6 месяцев максимум.
Не мучайтесь сами и не мучайтесь команду. Откажитесь от спринтов, они, в том виде как вы их используете, не несут вам пользы. Ну или изучите скрам, сходите на тренинг и наладьте процесс со спринтами.
Нет смысла засчитывать часть задачи в выполненные sp, вы таким образом лишает себя возможности корректно определить ёмкость спринта. В велосити засчитываются только завершенные задачи. Незаконченные возвращаются в бэклог и проходят цикл оценки и планирования по новой.
Успешный спринт это не когда все задачи завершены, а когда достигнута цель спринта и есть готовый к поставке инкремент.
Спринт это командная работа, если разработчик утащил задачку в норку и там её в одиночку грызёт, если у вас внутри задачи микроводопад, с последовательно анализом, разработкой, тестированием, вы что-то делаете не правильно. Если у вас большинство задач планируются к завершению в конце спринта, неудивительно, что часто не успеваете. Вы описываете причины, по которым не успеваете. Но скрам предлагает решения этих проблем. И это не те, которые описываете вы.
У вас не работает одна из вырванных из скрама практик. Ровно потому, что все остальные остались за бортом.
Неидеальный спринт