Как стать автором
Обновить
2
Карма
0
Рейтинг
Сергей Рогачев @rsn81

Agile Coach

  • Подписчики 2
  • Подписки 1

Как оценивать большие задачи

Прочитайте все-таки, что такое Product Backlog refinement:
Желательно, чтобы элементы Бэклога Продукта, расположенные сверху, были более  детализированными и понятными по сравнению с расположенными ниже элементами.  Чем детальнее описание элементов Бэклога Продукта, тем точнее может быть их оценка. В  свою очередь, чем ниже находятся элементы в Бэклоге Продукта, тем меньше они  детализированы.

Детализация же элементов Бэклога Продукта, над которыми Команда Разработки будет  работать во время следующего Спринта, предполагает, что каждый из элементов может  быть потенциального готов в течение Спринта так, что не остается никакой другой работы,  чтобы подготовить продукт к выпуску.
Обычно максимально детально прорабатываются истории на следующий спринт, достаточно детально на 2-3 спринта вперед, остальной хвост бэклога детально не прорабатывается.

Как оценивать большие задачи

Существует множество способов оценить пользовательские истории. Мы используем собственную методологию, чтобы оценить и проработать задачи перед тем, как писать код. Как мы до этого дошли и почему наш подход лучше, чем Planing Poker, читайте под катом.

Это же не агильно
Это не так. Посмотрите в Scrum Guide: Product Backlog refinement (http://www.scrumguides.org/scrum-guide.html#artifacts-productbacklog) — в статье вы описываете вашу реализацию этого процесса.

И исправьте везде по тексту статьи 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.

Компании? Среди компаний, занимающихся сходным бизнесом, вы почти всегда встретите один и тот же тип культуры. К примеру, сравните системные интеграторы и компании-разработчики тиражируемых программных продуктов — совершенно разные культуры. Это происходит как раз потому что у них сходное или различное окружение, как вы написали — «высшая система»: государство, отрасль, клиенты, география и т.п. Хотя бывают и исключения, это герои: внутри компании (подразделении) или даже внутри государства (компании) с доминирующими культурами контроля выстраивают оазис совершенно иной культуры.

В процитированном вами тексте нет утверждения, что нужно изменять систему сверху-вниз или что нужно изменять систему снизу-вверх. Там говорится только о том, что нужно — изменять систему, тогда и только тогда будет меняться корпоративная культура. С другой стороны, да, приведенные выше примеры говорят о том, что система может до определенного момента изменяться снизу-вверх.

PI-планирование в SAFe

Статья — это перевод оригинальной статьи консультантов Scaled Agile Inc. из описания фреймворка SAFe. Если интересует именно практика, то посмотрите мой доклад, на который есть ссылка в конце статьи. В этом докладе я рассказываю в том числе и про «давление», которое происходит на встрече: правда, я больше указыванию на давление на менеджмент со стороны исполнителей — хотя и обратное происходит.


Если не верите консультантом, то посмотрите другой доклад от Сбербанка:

Консалтинговые ИТ-проекты в стиле Agile?

По мне вы немного сгущаете краски. Если мы проходим стандартные стадии проектного управления, это еще не означает, что жизненный цикл разработки продукта у нас водопадный. В принципе, проектное управление не то же самое, что водопад, и проектное управление с Agile не противоречат друг другу. За несколькими исключениями. Во-первых, традиционно принято команды собирать под проекты, как следствие, многозадачность, когда люди работают в нескольких проектах одновременно, а в Agile нужны стабильные команды, которым мы даем проекты (можно несколько). Во-вторых, длительные многомиллионные (натыкаюсь и миллиардные) проекты и Agile несовместимы или «невыносимосовместимы». То есть идет смещение фокуса на продукт (услугу, сервис и т.п. ценность), а проект становится просто упаковкой работ в рамках развития продукта, сильно теряет такой сакральный смысл, как ранее в него вкладывали.

Консалтинговые ИТ-проекты в стиле Agile?

мы обворачиваем Agile с двух сторон waterfall-ом
Поясните это утверждение? Под водопадом вы подразумеваете последовательный процесс: бюджетирование, реализация и закрытие проекта?

Теория, игра и практика Канбан — Certified Kanban/Lean Training

Все верно, но задачи по Кабан-доске могут двигаться только вперед. Это основа вытягивающей системы задач, вместо проталкивающей. Задача из столбца тестирования не возвращается обратно, вместо этого разработчики подключаются к этой задаче, переключаясь с задач в столбце разработка. Столбцы доски описывают стадию задачи, но не являются разграничением зон ответственности функциональных специалистов.

А так, да, чаще всего вначале внедряется, так называемый, прото-Канбан.

В задачи этой заметки, конечно, не входило рассмотрение всех вопросов теории Кабан.

Теория, игра и практика Канбан — Certified Kanban/Lean Training

Просто не считаю это приемлемым.

Теория, игра и практика Канбан — Certified Kanban/Lean Training

2 день обучения был практически полностью посвящен разбору реальных примеров компаний, в которых работают участники тренинга. На том тренинге, где побывал я, в одной группе разбирался пример одной известной интернет-компании с участием самого генерального директора этой компании, а в другой группе — пример одного прогрессивного государственного ведомства. Примеры реальные и масштабные. По разумеющимся причинам приводить детальное описание этой части тренинга я не могу.

А про эффективность наглядных примеров как для детей, так и для профессионалов с 10 проектами за плечами, хорошо сын божий сказал:
В тот день, выйдя из дома, Иисус сидел у моря. И собралось к нему великое множество людей, так что он вошёл в лодку и сел, а весь народ стоял на берегу. И рассказывал им многое в наглядных примерах, говоря: "Вот, вышел сеятель сеять..." Тогда подошли к нему ученики и сказали: "Почему ты говоришь с ними наглядными примерами?" В ответ он сказал: "Вам дано понимать священные тайны небесного царства, а им не дано. Ибо тому, кто имеет, будет дано больше, и будет у него изобилие, а у того, кто не имеет, будет отнято даже то, что он имеет. Потому и говорю с ними наглядными примерами, что они, глядя, смотрят впустую, и, слыша, слышат впустую, и не постигают смысла. И на них исполняется пророчество Исаии, которое гласит: "Слыша, услышите, но не постигнете смысла, и, глядя, будете смотреть, но не увидите".
© От Матфея, стих 13
;-)

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность