це все відволікає команду від спринта і дійсно важливої роботи що має формувати інкремент продукту.
Щоб лікувати таку проблему формується команда обслуговування (maintenance team) це не обовь’язкоао одні й тіж і не обов‘язково окремі люди, це може бути частина команди з фокус-фактором 0.3-0.5 або якщо потрібно, то, таки, окремі люди (чергові) зі зміною щотижнево.
обов’язково робити ретро чергових, бо якщо maintenance spent time зростає - потрібна увага людини що керує ресурсами розробки (тл, сто). З цього випливає що трекінг часу має бути структурований на продуктовий девелопмент, багфікс, обслуговування (work type, або окремий проект у вашому таск-трекері).
Щодо інкременту в якому нема багфіксу для користувачів - 100% проблема продукт овнера та приорітезації беклогу. Практично з усім погоджуюсь, що вже висловлено в коментах.
Про топ задачу - це якраз і є традиційний підхід. Пріоритизація і задача спринту якраз супер класика. Про кладовище задач - нікуди не дітись, якщо вони не несуть value то там їм і місце, до того моменту як не буде більш пріоритетних задач (тобто ніколи) або доки не переоціниться важливість цих задач
Щодо цінності задач із спринта для клієнта – ну ви же на плануванні визначили, що ось ці задачі будуть найбільш корисними з точки зору додавання цінності. І з вашим темпом це планування було максимально чотири дні тому! Я розумію, що пріоритет може змінитися і за більш короткий термін, але якщо там взагалі цінності немає, то це проблеми з плануванням.
Опять моё любимое - о семейных травмах присущих половине украинского ИТ. Очень часто у нас практикуют то, что называется за границей scrum-but, по нашему "скрам-но" (или есть еще версия скрам-бан). Макс, тот скрам который есть у людей в прошлом опыте работать не будет. Ты правильно говоришь что хороший результат, это не закрытые задачи в спринте. Результат спринта должен быть "инкремент". Как говорит гайд: "Инкремент это небольшой шаг в направлении целей продукта". Это именно то, о чем ты говоришь. В результате выкатить нужно что-то что улучшит продукт в итоге. А такая вещь как sprint goal по сути является направляющей к тому, какие задачи с беклога взять и в каком порядке работать. Т.е. грубо говоря, есть куча задач с приоритетом, продакт оунер говорит, мол, в текущей ситуации релиза на заграничный рынок есть набор проблем связанных со спамом среди нерелевантных откликов, дальше продакт в бэклоге поднимает в приоритете такие вот проблемы, а команда (заметь, по своему решению) выбирает с бэклога то, над чем они могут работать, и то, что они смогут гарантировать сделать за спринт. И вот когда они это сделают, сделают релиз, инкремент продукта решит конкретную проблему бизнеса (при этом можно увидеть что это достигнет цели спринта).
А по поводу стори поинтов, это вещь которая нужна исключительно внутри команды, чтобы команда вместе понимала смогут ли они закомититься на какие-то задачи или нет. Продакту должно быть в целом пофигу, главное что он получит от стори поинтов это в лучшем случае приблизительное понимание на сколько реально это сделать в ближайшее время. Но вообще это не его дело сколько там стори поинтов, а дело команды. А по поводу размера стори поинта, всё просто, в команде выбирается средняя из самых простых задач и отмечается как 1 поинт, т.е. одному разработчику оно сложнее, другому проще, но они договорились что это 1. Дальше задача в два раза сложнее будет 2, для обоих разработчиков, если они не согласны, что она в два раза сложнее, а например в 4, значит у них разное представление о том как её делать. Самое главное - если команда поставила стори поинты задаче, это значит что команда (т.е. каждый в ней) точно знает ЧТО нужно сделать (и как это проверить в конце) и КАК это сделать. И это показатель того, что они понимают на что подписываются когда берут задачу в спринт, что могут это сделать.
Сорри за лонг рид, но когда это всё воспринимается правильно, то результат работы команды очень заметный. А еще, что не менее важно, не всем и не всегда подходит скрам! Но, в большинстве случаев очень даже отлично подходит и если всё правильно делать, результат есть.
Макс а можеш надати більш детальний приклад, коли ви берете ціль на спринт яка потребує співпраці багатьох розробників та їх сінхронізації, і з якими проблемами ви стикалися ?
Не совсем понятна проблема с стори поинтами. Похоже на вопрос приоретизации именно для менеджера. Команда со своей стороны не всегда может понимать что важно, а что нет и как раз менеджер расставляет приоритеты что команде делать. Если задача на 5 минут но с меньшим приоритетом то люди заняты чем то более важным и логично что времени нет.
Если люди могут спонтанно взять и делать то что не приоритетно то похоже как раз у них проблема с загрузкой.
Стосовно "задача на 10 хв не попадає в спрінт, тому що є більш важливі задачі " - не зовсім зрозуміла проблема, якщо задача важлива, чому її потрібно відкладати? Якщо ні - навіщо її взагалі робити?
Чи це проблема гранулярності - типу задача на 10 хв і на 2 години - обидві важать 1 СП, тому ми беремо другу? В такому разі мабуть треба трохи передефайнити поняття 1 СП.
В нас деякі мінорні задачі виконуються як сабтаски для більш мажорних задач - флоу розробки не змінюється, а при тестуванні додається ще 1 аксептнс критерій
То спринт якоюсь мірою е захистом команди від перенавантаження, коли і цю таску треба зробити, і цю, і ту. Якщо бізнесу треба щось додати у спринт, можно викинути з нього якусь меньш важливу таску з тим же естімейтом як і задачу, яку треба добавити.
Набійльш за все люблю ваші роздуми на рахунок продакт менеджменту. Дякую за те, що ділитись знаннями!
-асістанс сапорту/маркетингу/аналітики
-реагування на інциденти
- хотфікси по тасочкам на 10хв
це все відволікає команду від спринта і дійсно важливої роботи що має формувати інкремент продукту.
Щоб лікувати таку проблему формується команда обслуговування (maintenance team) це не обовь’язкоао одні й тіж і не обов‘язково окремі люди, це може бути частина команди з фокус-фактором 0.3-0.5 або якщо потрібно, то, таки, окремі люди (чергові) зі зміною щотижнево.
обов’язково робити ретро чергових, бо якщо maintenance spent time зростає - потрібна увага людини що керує ресурсами розробки (тл, сто). З цього випливає що трекінг часу має бути структурований на продуктовий девелопмент, багфікс, обслуговування (work type, або окремий проект у вашому таск-трекері).
Щодо інкременту в якому нема багфіксу для користувачів - 100% проблема продукт овнера та приорітезації беклогу. Практично з усім погоджуюсь, що вже висловлено в коментах.
Про топ задачу - це якраз і є традиційний підхід. Пріоритизація і задача спринту якраз супер класика. Про кладовище задач - нікуди не дітись, якщо вони не несуть value то там їм і місце, до того моменту як не буде більш пріоритетних задач (тобто ніколи) або доки не переоціниться важливість цих задач
Очевидний висновок: ми не вміємо розробку. Дивлячись на результати останнього року я навіть не буду сперечатися. 🤯
Можливо варто глянути в бік feature driven development (як приклад https://youtu.be/pCShsesxRZA)
Щодо цінності задач із спринта для клієнта – ну ви же на плануванні визначили, що ось ці задачі будуть найбільш корисними з точки зору додавання цінності. І з вашим темпом це планування було максимально чотири дні тому! Я розумію, що пріоритет може змінитися і за більш короткий термін, але якщо там взагалі цінності немає, то це проблеми з плануванням.
Опять моё любимое - о семейных травмах присущих половине украинского ИТ. Очень часто у нас практикуют то, что называется за границей scrum-but, по нашему "скрам-но" (или есть еще версия скрам-бан). Макс, тот скрам который есть у людей в прошлом опыте работать не будет. Ты правильно говоришь что хороший результат, это не закрытые задачи в спринте. Результат спринта должен быть "инкремент". Как говорит гайд: "Инкремент это небольшой шаг в направлении целей продукта". Это именно то, о чем ты говоришь. В результате выкатить нужно что-то что улучшит продукт в итоге. А такая вещь как sprint goal по сути является направляющей к тому, какие задачи с беклога взять и в каком порядке работать. Т.е. грубо говоря, есть куча задач с приоритетом, продакт оунер говорит, мол, в текущей ситуации релиза на заграничный рынок есть набор проблем связанных со спамом среди нерелевантных откликов, дальше продакт в бэклоге поднимает в приоритете такие вот проблемы, а команда (заметь, по своему решению) выбирает с бэклога то, над чем они могут работать, и то, что они смогут гарантировать сделать за спринт. И вот когда они это сделают, сделают релиз, инкремент продукта решит конкретную проблему бизнеса (при этом можно увидеть что это достигнет цели спринта).
А по поводу стори поинтов, это вещь которая нужна исключительно внутри команды, чтобы команда вместе понимала смогут ли они закомититься на какие-то задачи или нет. Продакту должно быть в целом пофигу, главное что он получит от стори поинтов это в лучшем случае приблизительное понимание на сколько реально это сделать в ближайшее время. Но вообще это не его дело сколько там стори поинтов, а дело команды. А по поводу размера стори поинта, всё просто, в команде выбирается средняя из самых простых задач и отмечается как 1 поинт, т.е. одному разработчику оно сложнее, другому проще, но они договорились что это 1. Дальше задача в два раза сложнее будет 2, для обоих разработчиков, если они не согласны, что она в два раза сложнее, а например в 4, значит у них разное представление о том как её делать. Самое главное - если команда поставила стори поинты задаче, это значит что команда (т.е. каждый в ней) точно знает ЧТО нужно сделать (и как это проверить в конце) и КАК это сделать. И это показатель того, что они понимают на что подписываются когда берут задачу в спринт, что могут это сделать.
Сорри за лонг рид, но когда это всё воспринимается правильно, то результат работы команды очень заметный. А еще, что не менее важно, не всем и не всегда подходит скрам! Но, в большинстве случаев очень даже отлично подходит и если всё правильно делать, результат есть.
Макс а можеш надати більш детальний приклад, коли ви берете ціль на спринт яка потребує співпраці багатьох розробників та їх сінхронізації, і з якими проблемами ви стикалися ?
Не совсем понятна проблема с стори поинтами. Похоже на вопрос приоретизации именно для менеджера. Команда со своей стороны не всегда может понимать что важно, а что нет и как раз менеджер расставляет приоритеты что команде делать. Если задача на 5 минут но с меньшим приоритетом то люди заняты чем то более важным и логично что времени нет.
Если люди могут спонтанно взять и делать то что не приоритетно то похоже как раз у них проблема с загрузкой.
От це і проблема, що кожна задача повинна пройти через менеджера, щоб потрапити в спрінт) Думаю потрібен ще випуск, бо я не дуже добре пояснив це
Стосовно "задача на 10 хв не попадає в спрінт, тому що є більш важливі задачі " - не зовсім зрозуміла проблема, якщо задача важлива, чому її потрібно відкладати? Якщо ні - навіщо її взагалі робити?
Чи це проблема гранулярності - типу задача на 10 хв і на 2 години - обидві важать 1 СП, тому ми беремо другу? В такому разі мабуть треба трохи передефайнити поняття 1 СП.
В нас деякі мінорні задачі виконуються як сабтаски для більш мажорних задач - флоу розробки не змінюється, а при тестуванні додається ще 1 аксептнс критерій
Потрібно відкладати, тому що якщо зробити зараз є ризик не виконати інші задачі спринту. Боюсь це я погано пояснив, може іншим разом ще спробую
То спринт якоюсь мірою е захистом команди від перенавантаження, коли і цю таску треба зробити, і цю, і ту. Якщо бізнесу треба щось додати у спринт, можно викинути з нього якусь меньш важливу таску з тим же естімейтом як і задачу, яку треба добавити.