Прочитайте все-таки, что такое Product Backlog refinement:
Желательно, чтобы элементы Бэклога Продукта, расположенные сверху, были более детализированными и понятными по сравнению с расположенными ниже элементами. Чем детальнее описание элементов Бэклога Продукта, тем точнее может быть их оценка. В свою очередь, чем ниже находятся элементы в Бэклоге Продукта, тем меньше они детализированы.
Детализация же элементов Бэклога Продукта, над которыми Команда Разработки будет работать во время следующего Спринта, предполагает, что каждый из элементов может быть потенциального готов в течение Спринта так, что не остается никакой другой работы, чтобы подготовить продукт к выпуску.
Обычно максимально детально прорабатываются истории на следующий спринт, достаточно детально на 2-3 спринта вперед, остальной хвост бэклога детально не прорабатывается.
Существует множество способов оценить пользовательские истории. Мы используем собственную методологию, чтобы оценить и проработать задачи перед тем, как писать код. Как мы до этого дошли и почему наш подход лучше, чем Planing Poker, читайте под катом.
И исправьте везде по тексту статьи Definition of Done (критерии готовности) на Acceptance criteria (критерии приемки). Критерии готовности (http://www.scrumguides.org/scrum-guide.html#artifact-transparency-done) описывают общие условия готовности любых элементов бэклога, а частные критерии готовности конкретной работы — это критерии приемки.
Как это совместить? — ведь любая инициатива по изменению приведёт к вводу новой терминологии, по сути означающей тоже самое.
Не любая инициатива, а именно что инициатива по изменению терминологии. Как это происходит в диалоге:
— Помогите нам внедрить Agile.
— Какие проблемы испытывает ваш бизнес?
— Что вы?! У нас все нормально.
— Хм… а зачем вам Agile?
— Мы хотим быть в современном тренде.
Иногда это формулируют более честно-цинично: «Как бы нам внедрить Agile так, чтобы ничего сильно не менять?»
А вот инициатива по изменению компании реально изменяет ее организационную структуру. К примеру, в старой структуре руководитель подразделения не только нанимал и увольнял разработчиков, но и ставил им задачи, то есть руководил центром затрат с собственным бюджетом. А в новой структуре, к примеру, у него остаются только сервисные задачи: нанимать, увольнять и развивать разработчиков — но конкретные задачи разработчикам ставят отныне представители от бизнеса (Product Owner, Business Owners), плюс еще и дают бывшему руководителю обратную связь о том, насколько хороших разработчиков он им поставляет в команды, то… какой новый красивый термин ни придумай (по сути я описал роль Chapter Lead из Spotify), но бывший руководитель не согласится с вами, что суть та же.
То есть культура организации есть подсистема более старшей системы. Но более старшая система есть подсистема какой-то более старшей системы…
Вряд ли можно изменить самую высшую систему, но на практике у нас полно примеров разных культур в организациях существующих в одной системе.
Конечно, подразделения внутри компаний не единообразны. Могут быть разные культуры внутри одного и того же подразделения. К примеру, объективные причины: разработчики — культура взаимодействия (сложность современных программных систем требует активной интеграции), а системные администраторы — культура контроля (нужно контролировать работоспособность большого количества систем). Это культурное различие создает проблемы при попытке выстроить сквозной процесс между различными функциональными отделами. Эту проблему по сути и пытается решить DevOps.
Компании? Среди компаний, занимающихся сходным бизнесом, вы почти всегда встретите один и тот же тип культуры. К примеру, сравните системные интеграторы и компании-разработчики тиражируемых программных продуктов — совершенно разные культуры. Это происходит как раз потому что у них сходное или различное окружение, как вы написали — «высшая система»: государство, отрасль, клиенты, география и т.п. Хотя бывают и исключения, это герои: внутри компании (подразделении) или даже внутри государства (компании) с доминирующими культурами контроля выстраивают оазис совершенно иной культуры.
В процитированном вами тексте нет утверждения, что нужно изменять систему сверху-вниз или что нужно изменять систему снизу-вверх. Там говорится только о том, что нужно — изменять систему, тогда и только тогда будет меняться корпоративная культура. С другой стороны, да, приведенные выше примеры говорят о том, что система может до определенного момента изменяться снизу-вверх.
Статья — это перевод оригинальной статьи консультантов Scaled Agile Inc. из описания фреймворка SAFe. Если интересует именно практика, то посмотрите мой доклад, на который есть ссылка в конце статьи. В этом докладе я рассказываю в том числе и про «давление», которое происходит на встрече: правда, я больше указыванию на давление на менеджмент со стороны исполнителей — хотя и обратное происходит.
Если не верите консультантом, то посмотрите другой доклад от Сбербанка:
По мне вы немного сгущаете краски. Если мы проходим стандартные стадии проектного управления, это еще не означает, что жизненный цикл разработки продукта у нас водопадный. В принципе, проектное управление не то же самое, что водопад, и проектное управление с Agile не противоречат друг другу. За несколькими исключениями. Во-первых, традиционно принято команды собирать под проекты, как следствие, многозадачность, когда люди работают в нескольких проектах одновременно, а в Agile нужны стабильные команды, которым мы даем проекты (можно несколько). Во-вторых, длительные многомиллионные (натыкаюсь и миллиардные) проекты и Agile несовместимы или «невыносимосовместимы». То есть идет смещение фокуса на продукт (услугу, сервис и т.п. ценность), а проект становится просто упаковкой работ в рамках развития продукта, сильно теряет такой сакральный смысл, как ранее в него вкладывали.
Все верно, но задачи по Кабан-доске могут двигаться только вперед. Это основа вытягивающей системы задач, вместо проталкивающей. Задача из столбца тестирования не возвращается обратно, вместо этого разработчики подключаются к этой задаче, переключаясь с задач в столбце разработка. Столбцы доски описывают стадию задачи, но не являются разграничением зон ответственности функциональных специалистов.
А так, да, чаще всего вначале внедряется, так называемый, прото-Канбан.
В задачи этой заметки, конечно, не входило рассмотрение всех вопросов теории Кабан.
2 день обучения был практически полностью посвящен разбору реальных примеров компаний, в которых работают участники тренинга. На том тренинге, где побывал я, в одной группе разбирался пример одной известной интернет-компании с участием самого генерального директора этой компании, а в другой группе — пример одного прогрессивного государственного ведомства. Примеры реальные и масштабные. По разумеющимся причинам приводить детальное описание этой части тренинга я не могу.
А про эффективность наглядных примеров как для детей, так и для профессионалов с 10 проектами за плечами, хорошо сын божий сказал:
Обычно максимально детально прорабатываются истории на следующий спринт, достаточно детально на 2-3 спринта вперед, остальной хвост бэклога детально не прорабатывается.
И исправьте везде по тексту статьи Definition of Done (критерии готовности) на Acceptance criteria (критерии приемки). Критерии готовности (http://www.scrumguides.org/scrum-guide.html#artifact-transparency-done) описывают общие условия готовности любых элементов бэклога, а частные критерии готовности конкретной работы — это критерии приемки.
— Помогите нам внедрить Agile.
— Какие проблемы испытывает ваш бизнес?
— Что вы?! У нас все нормально.
— Хм… а зачем вам Agile?
— Мы хотим быть в современном тренде.
Иногда это формулируют более честно-цинично: «Как бы нам внедрить Agile так, чтобы ничего сильно не менять?»
А вот инициатива по изменению компании реально изменяет ее организационную структуру. К примеру, в старой структуре руководитель подразделения не только нанимал и увольнял разработчиков, но и ставил им задачи, то есть руководил центром затрат с собственным бюджетом. А в новой структуре, к примеру, у него остаются только сервисные задачи: нанимать, увольнять и развивать разработчиков — но конкретные задачи разработчикам ставят отныне представители от бизнеса (Product Owner, Business Owners), плюс еще и дают бывшему руководителю обратную связь о том, насколько хороших разработчиков он им поставляет в команды, то… какой новый красивый термин ни придумай (по сути я описал роль Chapter Lead из Spotify), но бывший руководитель не согласится с вами, что суть та же.
Конечно, подразделения внутри компаний не единообразны. Могут быть разные культуры внутри одного и того же подразделения. К примеру, объективные причины: разработчики — культура взаимодействия (сложность современных программных систем требует активной интеграции), а системные администраторы — культура контроля (нужно контролировать работоспособность большого количества систем). Это культурное различие создает проблемы при попытке выстроить сквозной процесс между различными функциональными отделами. Эту проблему по сути и пытается решить DevOps.
Компании? Среди компаний, занимающихся сходным бизнесом, вы почти всегда встретите один и тот же тип культуры. К примеру, сравните системные интеграторы и компании-разработчики тиражируемых программных продуктов — совершенно разные культуры. Это происходит как раз потому что у них сходное или различное окружение, как вы написали — «высшая система»: государство, отрасль, клиенты, география и т.п. Хотя бывают и исключения, это герои: внутри компании (подразделении) или даже внутри государства (компании) с доминирующими культурами контроля выстраивают оазис совершенно иной культуры.
В процитированном вами тексте нет утверждения, что нужно изменять систему сверху-вниз или что нужно изменять систему снизу-вверх. Там говорится только о том, что нужно — изменять систему, тогда и только тогда будет меняться корпоративная культура. С другой стороны, да, приведенные выше примеры говорят о том, что система может до определенного момента изменяться снизу-вверх.
Если не верите консультантом, то посмотрите другой доклад от Сбербанка:
А так, да, чаще всего вначале внедряется, так называемый, прото-Канбан.
В задачи этой заметки, конечно, не входило рассмотрение всех вопросов теории Кабан.
А про эффективность наглядных примеров как для детей, так и для профессионалов с 10 проектами за плечами, хорошо сын божий сказал:;-)