главе 8

команда использовала пять «почему», чтобы узнать больше о рабочих процессах. В дальнейшем список выглядел так:

1. Команда получает запрос от пользователя.

2. Менеджер проекта намечает функции на следующий трехмесячный релиз.

3. Команда собирает функцию.

4. Команда тестирует функцию.

5. Менеджер проекта проверяет прохождение тестирования.

6. Менеджер проекта планирует показ демоверсии высшему руководству.

7. Если топ-менеджер хочет, чтобы команда внесла изменения, то руководитель проекта проводит анализ влияния изменений, функция возвращается в пункт 1 и по порядку двигается к пункту 8.

8. Функция выполнена и включена в следующий релиз.

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

Мы будем менять канбан-доску, чтобы представить это нагляднее, добавляя колонки «комментарии менеджера» для тех функций, которые ожидают старшие менеджеры в демоверсии.

Рис. 9.3. Эта канбан-доска представляет более точную картину того, как протекает проект

Теперь у нас есть более точная визуализация рабочего процесса в команде. Если на канбан-доске видно все течение релиза, то проблема становится очевидной. Рабочие элементы накапливаются в столбце «приемка руководством» и хранятся там до окончания релиза, как показано на рисунке 9.4.

Рис.

9.4. Когда вы используете канбан-доску для визуализации рабочего процесса, проблемы, возникающие из-за неравномерности, легче обнаружить

А как насчет рабочих элементов, которые были отнесены к будущему релизу в связи с доработками, которые инициированы менеджерами? Мы особенно заботимся о таких элементах, потому что из-за них некоторые пользователи ушли к конкурентам.

Рис. 9.5. Канбан-доска делает потери более очевидными, когда вы видите, что в течение рабочего процесса они встречаются несколько раз

По некоторым из элементов работа уже началась и должна продолжаться. Когда рабочие элементы требуют доработки уже после проверки менеджером, они возвращаются в начало процесса. Давайте убедимся, что они представлены на канбан-доске, – мы добавим столбец в начале пути, назовем его «На доработку» и передвинем стикеры влево (ставим маленькую точку на каждом стикере, чтобы сразу обнаружить, если они попадутся во второй раз).

Это довольно хорошая визуализация процесса, которому следует команда. Теперь мы можем точно видеть, что не так с проектом и почему ситуация ухудшалась. Некоторые члены команды, наверное, догадывались, что происходит, но теперь это ясно любому, кто смотрит на доску. И еще важнее, что это объективное свидетельство того, что способ, которым старшие менеджеры проводят обзор функций, – это основная причина проблем со сроками.

<< | >>
Источник: Эндрю Стеллман, Дженнифер Грин. Постигая Agile. Ценности, принципы, методологии. 2015

Еще по теме главе 8:

  1. Введение к главе
  2. Введение к главе
  3. Введение к главе
  4. Введение к главе
  5. Введение к главе
  6. Введение к главе
  7. Введение к главе
  8. Введение к главе
  9. Введение к главе
  10. Введение к главе
  11. Главе 18
  12. Выводы по главе 1
  13. Выводы по главе 2
  14. Выводы по главе 3
  15. Выводы по главе 4