Size: a a a

Agile, Scrum, Lean, Kanban, XP

2020 February 19

DK

Denis Kachnov in Agile, Scrum, Lean, Kanban, XP
Нервов уходит прилично
источник

JP

Jane Pavlova in Agile, Scrum, Lean, Kanban, XP
Denis Kachnov
Оценки конечно реалистичные! И дни и сроки оценивала(ет) команда. Риски отдельно. Скоуп фиксированный. Сроки и оценки с определенного момента тоже. В общем, классический РМБоКовский вариант "фикс всё" )
Ну это понятно, но вот признайся, если вы такое до этого не делали, то многое становится понятно только в процессе работы. Поэтому у меня вопрос к вашему SoW, что туда уходит и насколько он гибкий и растяжимый.
Сколько вы тратили на анализ, перед запуском в имплементацию?
источник

DK

Denis Kachnov in Agile, Scrum, Lean, Kanban, XP
Jane Pavlova
Ну это понятно, но вот признайся, если вы такое до этого не делали, то многое становится понятно только в процессе работы. Поэтому у меня вопрос к вашему SoW, что туда уходит и насколько он гибкий и растяжимый.
Сколько вы тратили на анализ, перед запуском в имплементацию?
Конечно мы такое делали. Это нормально работает на устоявшемся стеке, когда РЕАЛЬНО можно прикинуть оценку на реализацию типового кусочка компонента.
источник

JP

Jane Pavlova in Agile, Scrum, Lean, Kanban, XP
Denis Kachnov
Но да, реально кровавость и ж0па в том, что тчка принятия обязательств ооочень далеко от реального старта работы получается. И обещания на длииинный срок. Поэтому риски большие и нужно весьма ловко лавировать между "полноценной загрузкой команды без простоев" и "способностью выполнить нежданчики по SLA"
Простои - это разве плохо?
источник

DK

Denis Kachnov in Agile, Scrum, Lean, Kanban, XP
А на полностью с нуля - нафиг нафиг
источник

JP

Jane Pavlova in Agile, Scrum, Lean, Kanban, XP
Denis Kachnov
Конечно мы такое делали. Это нормально работает на устоявшемся стеке, когда РЕАЛЬНО можно прикинуть оценку на реализацию типового кусочка компонента.
Ага!…
источник

G

Gretchen in Agile, Scrum, Lean, Kanban, XP
Jane Pavlova
Если бы они были…в целом разброд и ролевая система, и деление респонсибилитей. Выручка, да. Я в нижнем левом углу, где у нас аджайл. Но спасибо за ответы, книжка реально интересная.
Может, не все так и плохо) 4-х месячный цикл бюджетирования при самоокупаемости - это позитивный знак, agile в действии) проблему "жёстких сроков" в контрактах поднять обязательно нужно, это прямо классическая ошибка сейлза, хотя изредка по-другому никак... И если вторая главная проблема только в систематических нЕдооценках (мин. на 4 мес вперед?), можно попробовать полечить по-простому, симптоматически. Для бюджетирования домножать на N (если отклонения оценок стабильные). если разброс отклонений большой, таки разбираться с выбросами, потом домножать. Одновременно со скрам/.../...-танцами копить историю и динамику собственной производительности, корректировать N. При хорошем раскладе танцы будут способствовать скорости, качеству и пр, и контракты/бюджеты параллельно страдать будут гораздо меньше.
источник

DK

Denis Kachnov in Agile, Scrum, Lean, Kanban, XP
Jane Pavlova
Простои - это разве плохо?
А как же!  Ресурс недозагружен, простаивает в убыток же.
источник

G

Gretchen in Agile, Scrum, Lean, Kanban, XP
Dmitry Nedvetskiy
Да, он садится, и в одно лицо, делает архитектуру, пару основных, важных элементов и документацию-заключение, будет это работать или нет и сколько оно в общем будет стоить
Странно делать архитектуру того, что в итоге работать не будет) По описанию похоже на гибрид концепции и экспертного заключения, это точно не PoC
источник

DK

Denis Kachnov in Agile, Scrum, Lean, Kanban, XP
Jane Pavlova
Ага!…
А если реально можно прикинуть и накрыть аналитикой, тогда ценность экспериемнтов снижается и оверхед на них уже не так выгоден.
И Скрам становится ну, таким, не лучшим вариантом ;)
источник

JP

Jane Pavlova in Agile, Scrum, Lean, Kanban, XP
Gretchen
Может, не все так и плохо) 4-х месячный цикл бюджетирования при самоокупаемости - это позитивный знак, agile в действии) проблему "жёстких сроков" в контрактах поднять обязательно нужно, это прямо классическая ошибка сейлза, хотя изредка по-другому никак... И если вторая главная проблема только в систематических нЕдооценках (мин. на 4 мес вперед?), можно попробовать полечить по-простому, симптоматически. Для бюджетирования домножать на N (если отклонения оценок стабильные). если разброс отклонений большой, таки разбираться с выбросами, потом домножать. Одновременно со скрам/.../...-танцами копить историю и динамику собственной производительности, корректировать N. При хорошем раскладе танцы будут способствовать скорости, качеству и пр, и контракты/бюджеты параллельно страдать будут гораздо меньше.
источник

DN

Dmitry Nedvetskiy in Agile, Scrum, Lean, Kanban, XP
Gretchen
Странно делать архитектуру того, что в итоге работать не будет) По описанию похоже на гибрид концепции и экспертного заключения, это точно не PoC
Правда скорее всего, как всегда по середине, так как он говрил, что от пресейла к пресейлу задание может варьироваться.
источник

DK

Denis Kachnov in Agile, Scrum, Lean, Kanban, XP
Jane Pavlova
Ага!…
А вот когда "нужен новый продукт. На чем будем делать бэк? Томкат? Нафиг Томкат, вот есть ХХХ , он прикольный! И сделаем вебсокеты для оперативного обновления данных вместо обычного HTTP API!"
Тогда хрен оценишь заранее )
источник

DN

Dmitry Nedvetskiy in Agile, Scrum, Lean, Kanban, XP
Кому-то просто аналитику на каких технологиях лучше делать, кому-то архитектуру, кому-то PoC
источник

JP

Jane Pavlova in Agile, Scrum, Lean, Kanban, XP
Denis Kachnov
А вот когда "нужен новый продукт. На чем будем делать бэк? Томкат? Нафиг Томкат, вот есть ХХХ , он прикольный! И сделаем вебсокеты для оперативного обновления данных вместо обычного HTTP API!"
Тогда хрен оценишь заранее )
Ну это если брать только реализацию, а если мы еще и гипотезы продуктовые хотим тестировать.
источник

DK

Denis Kachnov in Agile, Scrum, Lean, Kanban, XP
Jane Pavlova
Ну это если брать только реализацию, а если мы еще и гипотезы продуктовые хотим тестировать.
Ага. Это еще только сама реализация. А гипотезы вообще отдельная тема. Вот там эксперименты рулят.
источник

DN

Dmitry Nedvetskiy in Agile, Scrum, Lean, Kanban, XP
Gretchen
Может, не все так и плохо) 4-х месячный цикл бюджетирования при самоокупаемости - это позитивный знак, agile в действии) проблему "жёстких сроков" в контрактах поднять обязательно нужно, это прямо классическая ошибка сейлза, хотя изредка по-другому никак... И если вторая главная проблема только в систематических нЕдооценках (мин. на 4 мес вперед?), можно попробовать полечить по-простому, симптоматически. Для бюджетирования домножать на N (если отклонения оценок стабильные). если разброс отклонений большой, таки разбираться с выбросами, потом домножать. Одновременно со скрам/.../...-танцами копить историю и динамику собственной производительности, корректировать N. При хорошем раскладе танцы будут способствовать скорости, качеству и пр, и контракты/бюджеты параллельно страдать будут гораздо меньше.
Про "домножать" сразу вспомнил термин - Каста-передастов
источник

DN

Dmitry Nedvetskiy in Agile, Scrum, Lean, Kanban, XP
Gretchen
Ни в коем случае не принимайте на личный счет 😁

Просто по дороге домой как раз слушай "Джедайские техники" Дорофееева, там где он пару раз упоминал этот термин
источник

DK

Denis Kachnov in Agile, Scrum, Lean, Kanban, XP
Dmitry Nedvetskiy
Про "домножать" сразу вспомнил термин - Каста-передастов
Ну введите на этапе оценки коррекцию. Чеклист для учета всех нужных работ и/или опору на предыдущие данные по реальной трудоемкости.

Будете не домножать, а ..., ну или домножать не итог а отдельные слагаемые ))
источник

DN

Dmitry Nedvetskiy in Agile, Scrum, Lean, Kanban, XP
Про целый пласт менеджеров, которые только принимают, домножают и предают дальше, если не устроила оценка, возвращают, только уже с делением)))
источник