13 Comments
Jun 5, 2022Liked by Max Ischenko

Набійльш за все люблю ваші роздуми на рахунок продакт менеджменту. Дякую за те, що ділитись знаннями!

Expand full comment
May 24, 2022Liked by Max Ischenko

-асістанс сапорту/маркетингу/аналітики

-реагування на інциденти

- хотфікси по тасочкам на 10хв

це все відволікає команду від спринта і дійсно важливої роботи що має формувати інкремент продукту.

Щоб лікувати таку проблему формується команда обслуговування (maintenance team) це не обовь’язкоао одні й тіж і не обов‘язково окремі люди, це може бути частина команди з фокус-фактором 0.3-0.5 або якщо потрібно, то, таки, окремі люди (чергові) зі зміною щотижнево.

обов’язково робити ретро чергових, бо якщо maintenance spent time зростає - потрібна увага людини що керує ресурсами розробки (тл, сто). З цього випливає що трекінг часу має бути структурований на продуктовий девелопмент, багфікс, обслуговування (work type, або окремий проект у вашому таск-трекері).

Щодо інкременту в якому нема багфіксу для користувачів - 100% проблема продукт овнера та приорітезації беклогу. Практично з усім погоджуюсь, що вже висловлено в коментах.

Expand full comment

Про топ задачу - це якраз і є традиційний підхід. Пріоритизація і задача спринту якраз супер класика. Про кладовище задач - нікуди не дітись, якщо вони не несуть value то там їм і місце, до того моменту як не буде більш пріоритетних задач (тобто ніколи) або доки не переоціниться важливість цих задач

Expand full comment

Щодо цінності задач із спринта для клієнта – ну ви же на плануванні визначили, що ось ці задачі будуть найбільш корисними з точки зору додавання цінності. І з вашим темпом це планування було максимально чотири дні тому! Я розумію, що пріоритет може змінитися і за більш короткий термін, але якщо там взагалі цінності немає, то це проблеми з плануванням.

Expand full comment
May 13, 2022·edited May 13, 2022

Опять моё любимое - о семейных травмах присущих половине украинского ИТ. Очень часто у нас практикуют то, что называется за границей scrum-but, по нашему "скрам-но" (или есть еще версия скрам-бан). Макс, тот скрам который есть у людей в прошлом опыте работать не будет. Ты правильно говоришь что хороший результат, это не закрытые задачи в спринте. Результат спринта должен быть "инкремент". Как говорит гайд: "Инкремент это небольшой шаг в направлении целей продукта". Это именно то, о чем ты говоришь. В результате выкатить нужно что-то что улучшит продукт в итоге. А такая вещь как sprint goal по сути является направляющей к тому, какие задачи с беклога взять и в каком порядке работать. Т.е. грубо говоря, есть куча задач с приоритетом, продакт оунер говорит, мол, в текущей ситуации релиза на заграничный рынок есть набор проблем связанных со спамом среди нерелевантных откликов, дальше продакт в бэклоге поднимает в приоритете такие вот проблемы, а команда (заметь, по своему решению) выбирает с бэклога то, над чем они могут работать, и то, что они смогут гарантировать сделать за спринт. И вот когда они это сделают, сделают релиз, инкремент продукта решит конкретную проблему бизнеса (при этом можно увидеть что это достигнет цели спринта).

А по поводу стори поинтов, это вещь которая нужна исключительно внутри команды, чтобы команда вместе понимала смогут ли они закомититься на какие-то задачи или нет. Продакту должно быть в целом пофигу, главное что он получит от стори поинтов это в лучшем случае приблизительное понимание на сколько реально это сделать в ближайшее время. Но вообще это не его дело сколько там стори поинтов, а дело команды. А по поводу размера стори поинта, всё просто, в команде выбирается средняя из самых простых задач и отмечается как 1 поинт, т.е. одному разработчику оно сложнее, другому проще, но они договорились что это 1. Дальше задача в два раза сложнее будет 2, для обоих разработчиков, если они не согласны, что она в два раза сложнее, а например в 4, значит у них разное представление о том как её делать. Самое главное - если команда поставила стори поинты задаче, это значит что команда (т.е. каждый в ней) точно знает ЧТО нужно сделать (и как это проверить в конце) и КАК это сделать. И это показатель того, что они понимают на что подписываются когда берут задачу в спринт, что могут это сделать.

Сорри за лонг рид, но когда это всё воспринимается правильно, то результат работы команды очень заметный. А еще, что не менее важно, не всем и не всегда подходит скрам! Но, в большинстве случаев очень даже отлично подходит и если всё правильно делать, результат есть.

Expand full comment

Макс а можеш надати більш детальний приклад, коли ви берете ціль на спринт яка потребує співпраці багатьох розробників та їх сінхронізації, і з якими проблемами ви стикалися ?

Expand full comment

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

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

Expand full comment
May 12, 2022·edited May 12, 2022

Стосовно "задача на 10 хв не попадає в спрінт, тому що є більш важливі задачі " - не зовсім зрозуміла проблема, якщо задача важлива, чому її потрібно відкладати? Якщо ні - навіщо її взагалі робити?

Чи це проблема гранулярності - типу задача на 10 хв і на 2 години - обидві важать 1 СП, тому ми беремо другу? В такому разі мабуть треба трохи передефайнити поняття 1 СП.

В нас деякі мінорні задачі виконуються як сабтаски для більш мажорних задач - флоу розробки не змінюється, а при тестуванні додається ще 1 аксептнс критерій

Expand full comment