Size: a a a

Agile, Scrum, Lean, Kanban, XP

2020 March 02

SG

Sergey Gospodchikov in Agile, Scrum, Lean, Kanban, XP
Vasya Pupkin
Речь шла о том, что вы не успели выполнить цель спринта, частично выполненая цель - это отсутствие цели. Соответственно при жестком тайминге вы не доставляете сейчас - готово будет через пару дней. Вы можете сделать деливери через пару дней как будет готов, уже в следующем спринте, но это обнуляет идею спринтов.
Артем это объяснил тем, что надо "учиться вспевать в срок".
Спринты это Спринты, деливери это деливери. Иногда они совпадают, иногда нет. Но я не буду спорить.
источник

SG

Sergey Gospodchikov in Agile, Scrum, Lean, Kanban, XP
Vasya Pupkin
эм почему они одинаковые? Другая команда вполне могла иначе в SP оценить трудоемкость тех же задач. ВЫрожденный (специально для понимания) пример - команда фронтенда оценит задачи довольно низко, а вот команда бэкендеров, умеющих фронт (фулстек, да) будет давать уже несколько большие оценки в тех же SP. Это я к тому что мне непонятен аргумент что SP одинаковые для разных команд.
SP это интегральная оценка в которую входят Сложность работы, Объем  работы и Неопределенность.  Например, оценка ручной разгрузки Камаза с песком будет одинаковой для любой команды. Согласен? Но да, разные команды  выполнят эту работу с разной скоростью. Это зависит и от опытности и от количества членов в команде.  В Скраме принято говорить про кросс-функциональную команду. Это значит, что вся работа попадающая в команду оценивается от начала и до конца и выполняется одной командой. Поэтому мы не используем раздельную оценку для фронтенда и бэкенда.  Это бессмысленно.
источник

ДШ

Данила Шалыгин in Agile, Scrum, Lean, Kanban, XP
Artyomst
Кто-нибудь встречал книги/статьи о работе product owner со скрам командой? (как доносить задачи до команды, какой уровень детализации, ведение порядка в беклоге и т п без информации о продаже продукта)
источник

SG

Sergey Gospodchikov in Agile, Scrum, Lean, Kanban, XP
Vasya Pupkin
Хорошее замечание. Тогда скажите, пожалуйста, на сколько спринтов вперед у вас оценен бэклог? Вырисовывается понимание - что _весь_ бэклог оценен и распланирован исходя из ритма команды, так?
Естественно он может пополняться, но если, например, мы взяли проект - вы, получается, делаете его декомпозицию сразу же - всего известного на момент старта, в противовес тому, что "давайте разложим и проценим 1-2 месяца работ, а вот это все - когда дело дойдет"?
Иными словами весь заявленный scope оценивается и декомпозируется сразу же, а поступающие запросы на изменения просто изменяют бэклог и также оцениваются по мере поступления, бэклог переприоретизируется и переразбивается на спринты (в соответствии с тем же ритмом команды)?
Я правильно идею уловил?
По моим наблюдениям (на НАШЕМ продукте) планирование бэклога на два Спринта вперед бессмысленно.  Ситуация меняется каждую неделю. Мы готовим задачи примерно за  неделю до Планирования. И даже в этом случае они тухнут иногда. Полная неопределенность. Хотя есть и дедлайновые истории, например, требования регулятора. Если мы говорим о проектной разработке, то там ситуация совсем другая. Ты понимаешь Скоуп на весь срок проекта, появляется возможность долгосрочного планирования. Потому смысл в Спринтах теряется.  не нужен там Аджайл как правило. Если вспомнить Сноудена с его фреймворком Кеневин, то мы почти в Хаосе и следующий шаг нам становится понятным только после того как мы сделаем предыдущий (НА НАШЕМ Продукте) .   Мы больше не знаем чем знаем, когда пробуем работать с какой-то гипотезой. Мы не знаем что у нас получится и в какой степени мы достигнем целей. В этом смысле теряется роль экспертов-аналитиков. Все меняется так быстро, что завтра их знания устаревают и они перестают быть экпертами.  В проектах мы знаем результат заранее, нужно лишь его достичь.
источник

S

Slava in Agile, Scrum, Lean, Kanban, XP
(в проектной деятельности чуть меньше хаоса, но все равно аналогично)
источник

S

Slava in Agile, Scrum, Lean, Kanban, XP
вопрос только  в том, она типовая или нет. если типовая - то можно один и тот же гант даже использовать ))
источник

ДШ

Данила Шалыгин in Agile, Scrum, Lean, Kanban, XP
Artyomst
Кто-нибудь встречал книги/статьи о работе product owner со скрам командой? (как доносить задачи до команды, какой уровень детализации, ведение порядка в беклоге и т п без информации о продаже продукта)
И особенно уделить внимание Negotiable из INVEST модели https://agileforall.com/new-to-agile-invest-in-good-user-stories/?highlight=invest
источник

SG

Sergey Gospodchikov in Agile, Scrum, Lean, Kanban, XP
Slava
(в проектной деятельности чуть меньше хаоса, но все равно аналогично)
В проектной деятельности мы больше знаем чем не знаем. В комплексном домене  все наоборот.  Я всегда привожу метафору с туманом. Мы видим  следующую веху и ставим цель дойти до нее. дальше мы ничего не видим - там туман.  Дойдя  до нашей вехи-цели мы модем понять куда идти дальше - мы видим следующую цель. В проектах мы видим на несколько целей дальше. В этом собственно и различие этих двух доменов.
источник

S

Slava in Agile, Scrum, Lean, Kanban, XP
Туман войны :)
источник

EK

Evgeniya Ko in Agile, Scrum, Lean, Kanban, XP
Sergey Gospodchikov
SP это интегральная оценка в которую входят Сложность работы, Объем  работы и Неопределенность.  Например, оценка ручной разгрузки Камаза с песком будет одинаковой для любой команды. Согласен? Но да, разные команды  выполнят эту работу с разной скоростью. Это зависит и от опытности и от количества членов в команде.  В Скраме принято говорить про кросс-функциональную команду. Это значит, что вся работа попадающая в команду оценивается от начала и до конца и выполняется одной командой. Поэтому мы не используем раздельную оценку для фронтенда и бэкенда.  Это бессмысленно.
Сергей, расскажите, пожалуйста, как происходит сопостовление SP в условных единцах с рабочим временем и временем спринта (в единицах - часы)? Не могу никак понять тонкость. Время спринта, условно 80 часов, рабочее время команды (условно) 400 часов и как понять, сколько SP может уложиться в это время? Может мое желание првиязать SP ко времени ошибочно, но как тогда понять, что команда не переоценила свои силы и наоборот?
источник

SG

Sergey Gospodchikov in Agile, Scrum, Lean, Kanban, XP
Evgeniya Ko
Сергей, расскажите, пожалуйста, как происходит сопостовление SP в условных единцах с рабочим временем и временем спринта (в единицах - часы)? Не могу никак понять тонкость. Время спринта, условно 80 часов, рабочее время команды (условно) 400 часов и как понять, сколько SP может уложиться в это время? Может мое желание првиязать SP ко времени ошибочно, но как тогда понять, что команда не переоценила свои силы и наоборот?
Команда либо сделает цель либо нет.  Она сама это решает. Нельзя привязать SP к часам. Там есть такая составляющая как Неопределенность. Чем выше оценка в SP тем больше  эта часть как правило.  Команда может закопаться в любой момент. Потому сопоставление SP и тем более предсказание на этой основе - хрень.  Как можно оценить. например, баг? Правильно НИКАК. Сколько багов будет после прошлого релиза?  Не знает этого никто ....
источник

SG

Sergey Gospodchikov in Agile, Scrum, Lean, Kanban, XP
Все решает команда.  Ты ей можешь только доверять или нет. Если Ты ей не доверяешь то швах ...
источник

S

Slava in Agile, Scrum, Lean, Kanban, XP
Изучение системы по методу чёрного ящика сводится к наблюдениям за ней и проведению экспериментов по изменению входных данных, при этом в ходе наблюдения над реакциями системы на внешние воздействия достигается определённый уровень знаний об исследуемом объекте, позволяющий осуществлять прогнозирование поведения «чёрного ящика» при любых заданных условиях.
источник

S

Slava in Agile, Scrum, Lean, Kanban, XP
Вот и вся наука когда для вас программисты - черный ящик ))
источник

MM

Max Mikhailov in Agile, Scrum, Lean, Kanban, XP
» позволяющий осуществлять прогнозирование поведения «чёрного ящика» при любых заданных условиях.

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

S

Slava in Agile, Scrum, Lean, Kanban, XP
только методы черного ящика и применяются, можно сказать что это "группа методов" ))
источник

EK

Evgeniya Ko in Agile, Scrum, Lean, Kanban, XP
Sergey Gospodchikov
Все решает команда.  Ты ей можешь только доверять или нет. Если Ты ей не доверяешь то швах ...
ТОгда зачем SP? Для помощи команде оценить свои силы? Условно, команда посмотрит на список задач без SP и им будет сложно понять берут они эту цель в спринт, а с SP проще? Не лишний ли это шаг, если по сути в момент принятия цели и происходит условная оценка?
источник

ТХ

Тимур Хайруллин in Agile, Scrum, Lean, Kanban, XP
Evgeniya Ko
Сергей, расскажите, пожалуйста, как происходит сопостовление SP в условных единцах с рабочим временем и временем спринта (в единицах - часы)? Не могу никак понять тонкость. Время спринта, условно 80 часов, рабочее время команды (условно) 400 часов и как понять, сколько SP может уложиться в это время? Может мое желание првиязать SP ко времени ошибочно, но как тогда понять, что команда не переоценила свои силы и наоборот?
Я тоже могу поделиться опытом=)
Моя команда со временем вышла на "свою" скорость из которой ей выходить совсем не хочется, ей комфортно. Сейчас у нас нет ни просадок, ни перегрузов.
Но к этому мы шли не так уж и быстро. Начали с 50ти, закончили 70тью.  Увеличение произошло по инициативе самой команды. Мол, "можем и больше сделать, что-то скучновато иногда становится". В итоге нарастили сначала на 10, потом еще на 10. Выше пробовали - не вышло, возник перегруз.
И Сергей верно сказал, что без доверия никуда. У нас команда верит менеджменту, менеджмент верит команде.
А еще есть важный момент: не пробовать сравнивать SP одной команды с SP другой. Они никак друг с другом не связаны
источник

S

Slava in Agile, Scrum, Lean, Kanban, XP
На самом деле сравнивать SP одного спринта с SP другого спринта тоже нельзя, они не связаны :)))
источник

S

Slava in Agile, Scrum, Lean, Kanban, XP
Потому что 1 SP != 1 SP
источник