Comments 12
Почему-то проблемы с методологиями везде на столько похожи что уже хочется сказать что зафакапить их - это в порядке вещей.
Вот и настало то время, когда можно писать статьи на Хабре и выступать на митингах о своем собственном процессном фреймворке, который решает все проблемы, имеющиеся в *Подставь сюда свой самый ненавистный процессный фреймворк*.
Одно время был бум архитектурных реализаций.
А теперь катится волна процессных фреймворков.
К статье вопросов нет. Наоборот, всячески поддерживаю, когда люди пытаются разобраться, а почему же у всех работает, а у них нет. Но я так и не получил ответа из вступления, а что же помешало автору в последующем пользоваться фреймворком, тем более, что успешный опыт у него был? Команда? Люди? И как исправлять-то причину?
Резюмируя: работало в команде, где:
хватало разрабов (отдельно FE и BE), QA, был отдельный дизайнер и девопс на команду
PO/BA великолепно описывал задачи в описанной статье нотации и подготавливал их заранее
митингов было настолько мало, насколько возможно
люди понимали зачем собираются
ретроспективы каждый раз улучшали процесс
соблюдался четкий тайминг
не работало в командах, где:
слишком много человек, где митинги затягивались, а половина присутствующих скучала
слишком мало человек, где недостаточно экспертизы и, прикрываясь T-Shaped, из разрабов делали фулстеков, которые и дизайн себе должны придумать, и протестировать, и задачи описать
люди не понимали зачем собираются, считали процессы элементом конроля, не видели пользы
на ретроспективах не пытались найти решения, назначать ответственных
митинги могли длиться долго и нудно
Собственно, это и помешало. Как с этим бороться при хороших данных в виде полноценной команды оптимального размера, в статье описано. В работе с людьми не думаю, что могут быть универсальные инструкции. Потому и во вступлении говорю, что у меня есть часть ответа.
спасибо что поделились опытом, но мне бы чуть попобольше контекста
PO/BA великолепно описывал задачи в описанной статье нотации и подготавливал их заранее
использовали ли вы цели спринта и формулировали ли критерии готовночти этих целей? если да, то поделись пожалуйста примерами цель-DoD-таска именно в связке интересно
митингов было настолько мало, насколько возможно
у нас в команде в 2-х недельный спринт на скрам активности 8-9 часов на скрам активности и каждый день 2-3 часа на митинги у части команды, а сколько у вас примерно часов уходит на общекомандные созвоны?
Отличные вопросы, спасибо!
использовали ли вы цели спринта и формулировали ли критерии готовночти этих целей? если да, то поделись пожалуйста примерами цель-DoD-таска именно в связке интересно
К целям спринта я лично отношусь скептически вопреки Scrum методолгии, потому как обычно спринт слишком малый промежуток, а команда может параллельно работать над несколькими целями. А вот в SAFe были цели на PI (Program Increment) - более длительный промежуток (4-5 спринтов). Они хорошо работали. Бизнес их приоритизировал во время планирования PI, а мы соответственно планировали задачи исходя из приоритета целей. Так у целей нет четкого срока закрытия - это может произойти как после первого спринта, так и по середине третьего, а команда может параллельно работать над разными целями внутри спринта. Для таких целей DoD довольно прозрачен - фича сделана и ей можно пользоваться. В обычном скраме цели больше отвлекают, по моему опыту.
у нас в команде в 2-х недельный спринт на скрам активности 8-9 часов на скрам активности и каждый день 2-3 часа на митинги у части команды, а сколько у вас примерно часов уходит на общекомандные созвоны?
На двухнедельный спринт общекомандных митингов (1ч планнинг, 1ч ретро, 1ч рефаймент, 15м*5дн=1ч15м) = 4ч15м. Если рефаймент не понадобился, то еще минус час. Митинги части команды сложно подсчитать, потому что тут очень много неизвестных переменных. То фронт общается с бэком по апи, то QA нашли багу и надо ее обсудить, то PO хочет прояснить как технически лучше решить проблему. Но все созвоны, которые частью команды, обычно полностью вас касаются и являются такой же важной работой, как писать код. Я в статье предлагаю минимизировать митинги, в которых люди успевают заскучать)
По моему опыту, самая главная проблема возникает из того, что людей все устраивает, они сидят делают свои задачи и не хотят смотреть по сторонам. У меня были люди, которые понимают зачем рестроспектива, но абсолютно в ней не участвуют, потому что "меня все устраивает, я не вижу/не считаю что-то проблемой"
Добиться этого можно, если внедрять процессы там, где они нужны и быть достаточно гибкими, чтобы адаптировать правила под себя, ведь agile переводится как “гибкий”.
Девушка, слово "agile" означает "проворный, шустрый, быстрый", а не "гибкий". Не верите? Откройте словарь и убедитесь сами.
А почему процессы не работают? Да потому что сама методология глубоко патологична. Те же ежедневные митинги нужны тимлиду или тому, кто их проводит, как форма контроля за работниками. По-сути, это форма микроменеджмента, и она не только отвлекает от работы, но и наносит психологический вред, вызывая стресс и тревожное расстройство у разработчиков. Наверняка у интравертов, как я сам, и вероятно у тех, кто в спектре. Никогда не задумывались о том, как подкашивает здоровье эта методология?
Лично я испытал на себе аджайл дважды и с тех пор держусь как можно дальше от команд, где практикуют аджайл. Не хочу болеть.
Девушка, слово "agile" означает "проворный, шустрый, быстрый", а не "гибкий". Не верите? Откройте словарь и убедитесь сами.
Одно из значений - таки "гибкий".
https://www.merriam-webster.com/dictionary/agile
2 : having a quick resourceful and adaptable character
// an agile mind
Те же ежедневные митинги нужны тимлиду или тому, кто их проводит, как форма контроля за работниками. По-сути, это форма микроменеджмента, и она не только отвлекает от работы, но и наносит психологический вред, вызывая стресс и тревожное расстройство у разработчиков.
Вот потому у Вас и не работает, что Вы так воспринимаете Agile, ИМХО.
Лично я испытал на себе аджайл дважды и с тех пор держусь как можно дальше от команд, где практикуют аджайл. Не хочу болеть.
Не болейте)
Почему у вас не работают agile процессы?