MIKALAI ALIMENKOU | Agile анти-паттерны: 10 лет спустя

MIKALAI ALIMENKOU | Agile анти-паттерны: 10 лет спустя | Agile Rock Conference 2018

Рет қаралды 4,641

Күн бұрын

Вот уже более 10 лет Agile движение шагает по Украине и стучится практически в каждую компанию. Но приносят ли новые процессы, принципы и практики реальную практическую пользу? Получается ли изменить к лучшему команды, проекты, компании? Я в роли консультанта за эти 10 лет поработал с более чем 100 компаниями, поэтому повидал много хорошего и плохого. В данном докладе хочется пробежаться по основным проблемам, сложностям и анти-паттернам в переходе отечественных компаний на "Agile рельсы". Мы рассмотрим какие практики не очень хорошо приживаются, от чего страдает большинство команд, какие основные препятствия встречают на своем пути и как умудряются их обходить. Я надеюсь, доклад поможет зародиться множеству интересных дискуссий.

Пікірлер: 7

@annlega4322 6 жыл бұрын

Очень крутой доклад, много хороших мыслей озвучено, есть над чем подумать.

@mckros 6 жыл бұрын

Я лично говорил, что доклад ОК, и с выводами я согласен. Но по аргументации есть замечания. 1. 8:10. Определение проекта по PMBOK: Проект - это временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов. «Железный треугольник» это аллегория к работе с ограничениями проекта, но не его определение. 2. 17:05 - это не про аджайл - там есть свои ограничение, например в скраме фиксированные итерации и бюджет на неделю, но гибкий скоуп. Это про как раз про работу классического PM на классическом проекте - тут объясняют, что треугольник на самом деле не железный должен быть в реальности. 3. 25:50. Стори пойнты работают только при оценке способом сравнения для историй, нарезанных «вертикально», причём в стабильных кросс-функциональных командах. Они действительно не помогут оценивать специфические краткосрочные задачи - они для этого просто не предназначены. 4. 28:55. Спасибо за напоминание про статью Майка Кона. Я даже ссылочку ещё раз приведу www.mountaingoatsoftware.com/blog/why-i-dont-use-story-points-for-sprint-planning 5. 30:10. Одно из определений фокус-фактор = Реальная_производительность / Доступные_человеко-дни. И его значение сильно зависит от команды (фаза по Такману, например), индивидуальных особенностях человека, внешних условий и количества проектов (если есть переключения). Вряд ли его можно для всех указывать, как 0,64. Измерять лучше не расчётами, а замерять из опыта. 6. 32:10. Разве участие в митингах по улучшению эффективности работ (ретро), по улучшению качества описания задач (грумминг), по синхронизации (дейли скрам) - это вейст? Это такая же полезная работа, и она тоже приносит велью. Но как и любую другую ценность её тяжело измерить и продемонстрировать. Однако считать все разукрашенные (кроме жёлтых) работы потерями - это не верно и даже вредно для морального духа команды )) imho. 7. 33:30. Не понял как можно трекать оставшееся время - кто-то научился предсказывать будущее? )) Ну потратил ты день, предположил, что нужно ещё два, а в конце оказалось, что все 5. Откуда я мог это знать в конце первого дня? Трекать можно только время по факту, и на основе предварительной оценки делать какие-то прогнозы. Трекать оставшееся время - это какой-то оксюморон. Где прочитать про то, почему я не прав? 8. 42:20. Product Backlog не предназначен для планирования релизов. Зачем его ругать за это? Story mapping - yes! 9. 47:00. Summary is GREAT!

@Zuz666 6 жыл бұрын

Да, тоже вопрос 7 интересен.

@ssuhanov 5 жыл бұрын

Пункт 7 я понимаю так: делаете вы задачу и в конце дня видите, что на нее нужно еще 2 дня. Ставите, что осталось еще два дня. Остальные коллеги поступают похожим образом и на графике видно сколько дней еще осталось до выполнения скоупа спринта. На следующий день делаете эту же задачу и понимаете, что стало сложнее и появились новые нюансы. И делать еще 5 дней. Ставите этой задаче, что еще делать 5 дней. У коллег тоже может такое же быть. На графике тогда будет видно, что остаток трудозатрат на спринт увеличился (то, о чем Николай говорит в видео). Это помогает понять сколько реально осталось еще времени на скоуп задач. Ведь если сделать первоначальную оценку в 2 дня, то как отобразить, что задача оказалась сложнее и нужно потратить на нее 5-7-9 дней? А по методу, который озвучен в видео - вы будете постоянно видеть сколько "реально" (в кавычках, потому что по оценке на текущий момент, а не по оценке недельной давности) осталось времени на выполнение скоупа.