43
Рисунок 5. Схема процесса реализации проекта в веб -
студии «Айбраш» после внедрения методологии Скрам
Как можно увидеть из рисунка 5, в зависимости от перечня задач в
журнале продукта (бэклога продукта) все проекты дополнительно
разбиваются на релизы. Для каждого релиза создается своя команда
разработчиков, которая отвечает за тот или иной функционал. Все работы
осуществляются итерационно и на выходе проверяются тестером. При
дополнительно внедряются скрам - мастер и владелец продукта, которые
непосредственно взаимодействуют с командой разработчиков. Данная схема
описывает общие изменения в процессе реализации продукта.
2.4. Анализ управления проектом на инвестиционной фазе
Рассмотрим более подробно, какие изменения планируется реализовать
в рамках рассматриваемого проекта на инвестиционной фазе.
1. Управление коммуникациями.
Коммуникации в организации после внедрения проекта будут
осуществляться в рамках ежедневных митингов, на которых команда проекта
будет обсуждать насущные проблемы и варианты решения тех или иных
задач. Также в рамках методологии Скрам будут проводиться обзоры
спринтов и ретроспективы, где каждый из участников сможет поделиться
своими переживаниями и опасениями по тому или иному проекту.
Предполагается создание самоорганизующей команды по проектам, внутри
которых будет проходить ежедневные обсуждения задач. В рамках одного
проекта за результат работы будет отвечать вся команда разработчиков . а не
конкретно один человек, что мотивирует исполнителей обсуждать задачи
совместно и по возможности делиться опытом.
2. Управление командой проекта
Командообразование в рамках данного проекта будет проходить в
44
несколько этапов. Причем, чтобы команда работала с максимальной отдачей,
она должна находиться в стадии «Функционирование». Таким образом, на
начальном этапе проекта основной задачей скрам-мастера является
способствование наискорейшему переходу команды в нужную стадию
(таблица 3).
Таблица 3
Этапы формирование команды в Scrum
Этап
Быстрый переход
Средний переход
Долгий переход
Формирование
0-ый спринт
2-ой спринт
2-ой спринт
Бурление
1-ый спринт
4-ый спринт
6-ой спринт
Нормализация
1-ый спринт
6-ой спринт
10-ый спринт
Функционирование
2-ой спринт
8-ой спринт
16-ый спринт
Расформирование
Завершение проекта
Рекомендуется на начальных этапах работы на проекте познакомить
участников проектной команды с помощью совместных внерабочих
мероприятий и, если участники обладают достаточной мобильностью, то
поработать совместно в рамках первых двух основных спринтов. Не
рекомендуется использовать данную технику в рамках нулевой итерации,
чтобы участники проектной команды могли в первую очередь узнать своих
коллег с профессиональной точки зрения и понять какими навыками
обладает каждый, а потом устанавливать неформальные контакты.
Для команды, которая раньше никогда не работала с гибкими
методологиями, полезно проведение обучающих игр, которые позволят
познакомиться с основными ценностями и принципами работы значительно
быстрее, чем чтение гайдов и мануалов.
Наиболее популярные обучающие игры по гибким методологиям:
- Скрамчасы - участники выбирают картинки и слова, которыми можно
наиболее точно описать позиции Скрамманифеста;
- Scrumble- настольная игра, имитирующая процессы разработки в
рамках Scrum;
- битва ретроспектив - дает представление о том, как можно и нужно
45
проводить ретроспективы и другие.
3. Управлением сроками и содержанием проекта.
Управление сроками будет осуществляться посредством организации
деятельности на основе спринтов. Рекомендованный размер спринта
составляет две недели. По желанию команды длительность спринта может
быть сокращена до недели.
Из списка функций системы (беклог продукта), составленного в рамках
нулевого спринта, выбираются функции в порядке важности для клиента,
декомпозируются на более мелкие задачи и включаются в беклог спринта.
При выборе задач на спринт участвует вся команда, которая оценивает свои
возможности и скорость работы, с учетом отпусков и болезней сотрудников.
Для того чтобы понять насколько трудоемка та или иная история
пользователей, будет использована методика покер-планирования. В
процессе покер-планирования участники будут оценивать сложность истории
пользователя относительно эталонной задачи в сторипоинтах. Покер-
планирование длится несколько раундов, в процессе которых проходит
обсуждение и уточнение деталей. Для понимания того какой объем работ
был выполнен, какие задачи находятся на какой стадии и что еще осталось
сделать применяют практики визуального менеджмента. В данном случае
под практиками визуального менеджмента подразумевают использование
доски. Доска разделяется на столбцы соответствующие этапам работы над
любой задачей, и на нее помещаются стикеры с историями пользователей. По
мере работы над задачей стикер перемещается в соответствующий столбец
(рисунок 6).
46
Рисунок 6. Доска для визуализации работы над задачами
4. Управление качеством проекта.
Управление качеством будет осуществляться с помощью
применения практики коллективного владения кодом и осуществления
инспекции после реализации каждой задачи. Практика коллективного
владения кодом распространяется внутри определенной группы
специалистов, разделяя между собой ответственность. Коллективное
владение кодом означает, что каждый человек, который изменяет код,
должен после внесения всех изменений закомпилировать его и проверить,
что данная версия программы работает корректно. Также разработчик
должен иметь представление обо всех программных модулях, имеющихся в
системе, и зависимостях между ними. Аналогичный подход
распространяется и на аналитиков, которые в случае модификации отчетов
или диаграмм с описанием системы, обязаны проверить не противоречит ли
их изменение остальным компонентам системы и не является ли данное
изменение дублированием уже сделанной ранее работы.
Практика инспекций подразумевает проверку кода и интерфейсов
разработчиками самостоятельно, до начала тестирования специалистами по
тестированию. Инспекции являются надежным и мощным инструментом,
47
повышающим качество разрабатываемого программного продукта и
снижающим затраты на последующую переработку программного продукта.
Скрам-мастеру необходимо выстроить в команде культуру инспекций, дав
понять ее участникам, что проверка сама по себе является не средством
оценки персональных знаний и навыков разработчика, а способом выявления
проблемных мест в коде.
При инспекциях возможно использование метрик, отражающих
наиболее проблемные места в коде, например, количество ошибок на сто
строк кода, это позволяет, понять при доработке каких программных
модулей нужно быть особенно внимательным, и выявить «узкие места».
Тем не менее, применение практики инспекций не означает отказ от
полноценного тестирования, а является дополнительным инструментом
верификации качества программного продукта.
Немаловажным является построение иерархической структуры
работ, в котором отражается поэтапное внедрение методологии Скрам в
деятельность организации. Построим иерархическую структуру работ
(таблица 4).
Таблица 4
Иерархическая структура работ
Название задачи
Длительност
ь
Начало
Окончание
Старт проекта
1. Комплексная диагностика
состояния организации
3дня
Пн. 8.05.20
Ср. 10.05.20
2. Выявление основных проблем
в
проектной деятельности
организации
2дня
10.05.20
11.05.20
3. Формулировка направлений
совершенствования проектной
деятельности
1 день
12.05.20
12.05.20
4. Реализация проекта
48 дней
Пн 15.05.20
Ср 19.07.20
4.1 Подготовка к трансформации
4 дня
Пн 15.05.20
Чт 18.05.20
4.1.1 Проведение тренинга по
основам Скрама с деловыми играми
3 дня
Пн 15.05.20
Ср 20.05.20
4.1.2 Проведение обучение скрам-
мастеров
4 ч
Чт 18.05.20
Чт 18.05.20
48
4.1.3 Проведение обучения
владельцев продуктов
4 ч
Чт 18.05.20
Чт 18.05.20
4.2. Старт первого спринта с
командами
4 дня
Чт 18.05.20
Вт 23.05.20
4.2. 1. Проведение планирования
спринта и разбиение юзер-стори на
задачи
2 дня
Чт 18.05.20
Пт 19.05.20
4.2.2 Проведение покер-
планирования для оценки юзер
стори
3 ч
Пн 22.05.20
Пн 22.05.20
4.2.3 Отработка механизма
эскалации проблем
1 день
Пн 22.05.20
Вт 23.05.20
4.2.4.Отработка механизма
синхронизации деятельности команд
1 день
Ср 24.05.20
Ср 24.05.20
4.3. Завершение первого
«калибровочного» спринта
1 день
Чт 25.05.20
Чт 25.05.20
4.3.1 Проведение демонстрации и
получение обратной связи
2 ч
Чт 25.05.20
Чт 25.05.20
4.3.2 Проведение ретроспективы
3 ч
Чт 25.05.20
Чт 25.05.20
4.3.3 Определение скорости работы
команды эмпирическим путем
3 дней
Чт 25.05.20
Пн 29.05.20
4.4. Старт второго спринта
2 дня
Вт 30.05.20
Ср 31.05.20
4.4.1 Планирование и старт второго
спринта
1 день
Чт 01.06.20
Чт 01.06.20
4.4.2. Тренинг и мастер-класс по
практикам экстремального
программирования
4 дня
Пт 02.06.20
Ср 07.06.20
4.5 Завершение второго спринта
8 дней
Чт 08.06.20
Пн 19.06.20
4.5.1 Изучение практики
инструментов бережливого
производства
4 дня
Чт 08.06.20
Вт 13.06.20
4.5.2 Проведение демонстрации
1 ч
Ср 14.06.20
Ср 14.06.20
4.5.3 Проведение ретроспективы с
применением инструментов
бережливого производства
8 ч
Чт 15.06.20
Чт 15.06.20
4.5.3.1 Разбор причин опоздания по
несделанным задачам
2 ч
Пт 16.06.20
Пт 16.06.20
4.5.3.2 «5 почему» по каждому
дефекту
1 день
Пн 19.06.20
Пн 19.06.20
4.6 Старт третьего спринта
9 дней
Вт 20.06.20
Пт 30.06.20
4.6.1. Планирование и старт
третьего спринта
1 день
Вт 20.06.20
Вт 20.06.20
4.6.2 Проведения тренинга по
приемочным тестам
2 дя
Ср 21.06.20
Чт 22.06.20
4.6.3 Внедрение модульных и
приемочных тестов
6 дней
Пт 23.06.20
Пт 30.06.20
4.7 Завершение третьего спринта
8 дней
Пн 03.07.20
Ср 12.07.20
4.7.1 Демонстрация спринта
1 ч
Пн 03.07.20
Пн 03.07.20
4.7.2 Внедрение основ
статистического управления
качеством
7 дней
Вт 04.07.20
Ср 12.07.20
4.7.2.1 Статистика по дефектам
2 дня
Вт 04.07.20
Ср 05.07.20
4.7.2.2 Диаграмма Парето по
модулям
3 дня
Ср 05.07.20
Пт 07.07.20
4.7.2.3 Контрольные карты Шухарта
2 дня
Пт 07.07.20
Пн 10.07.20
4.8 Планирование и старт пятого
спринта
2 дня
Пн 10.07.20
Вт 11.07.20
49
4.8.1 Проведение анализа
выполнения задач по диаграмме
сгорания релиза
1 день
Вт 11.07.20
Вт 11.07.20
4.8.2 Проведение тренинга по
канбан для членов команды
2 дня
Ср 12.07.20
Чт 13.07.20
4.9 Завершение пятого спринта
4 дня
Пт 14.07.20
Ср 19.07.20
4.9.1 Демонстрация релиза продукта
1 ч
Пт 14.07.20
Пт 14.07.20
4.9.2 Проведение ретроспективы по
окончанию релиза
2 ч
Пт 14.07.20
Пт 14.07.20
4.9.3 Сбор обратной связи от
команды проекта
3 дня
Пн 20.07.20
Ср 19.07.20
5. Завершение проекта
4 дня
Вт 15.12.20
Пт 18.12.15
5.1 Анализ изменений
4 дня
Чт 20.07.20
Вт 25.07.20
5.2 Архивация полученных знаний
5 дня
Ср 26.07.20
Вт 01.08.20
5.3 Подведение итогов и закрытие
проекта
3 дня
Вт 02.08.20
Чт 04.08.20
Все планируемые изменения так или иначе ведут за собой ряд рисков и
барьеров, которые необходимо заранее предусмотреть. Их минимизация
связана с эффективной деятельностью руководства предприятия. Поэтому
следующим этапом необходимо проанализировать возможные риски,
которые могут оказать влияние на проект. Анализ рисков компании и
проекта, позволяет организации оценить и выявить проектные риски,
уменьшить угрозы и воспользоваться преимуществами. Так как данный
проект можно считать организационным, то он направлен только на
внутреннюю среду предприятия и следовательно, достаточно слабо
подвержен внешним рискам.
Цель управления рисками состоит в том, чтобы: 1) в идеале избежать
возникновения проблем или 2) минимизировать возможный ущерб для
проекта, если избежать проблемы не представляется возможным.
Выделяются несколько сдерживающих проблем и барьеров, которые
необходимо учесть при реализации такого проекта внедрения (таблица 5).
Таблица 5
Основные проблемы возникающие при внедрении Скрам
№
Область
Описание
1
Процесс
В команде недостаточно смелости для качественного изменения
процесса
Длина спринта увеличивается в его ходе или часто меняется
Непостоянный ритм разработки с паузами между спринтами
Нет списка проблем и систематической работы над их устранением
50
2
Продукт
Видение продукта, цели релизов и спринтов не донесены до всех
членов команды
Цели итераций не корректируются на основании обратной связи от
рынка
Видение продукта, цели релизов и спринтов не донесены до всех
членов команды
Беклог продукта содержит большие истории (размером в
полспринта), команда не умеет разбивать их на более мелкие
3
Технологи
и
Отсутствие или слабое использование инженерных практик (CI,
CodeReview, Refactoring, TDD, etc.)
Работы по тестированию не включены в один спринт с разработкой
Тестирование не автоматизировано
4
Роли
Владелец Продукта недоступен по ходу спринта.
Владельца Продукта не построены на основе стратегии обучения
и бизнес-ценности, Владелец продукта не дает обратную связь
команде
Нет выделенного Скрам-Мастера или он меняется каждый спринт,
У Скрам-Мастера недостаточно социальных навыков (softskills) для
работы с людьми. Скрам-Мастер «по-совместительству” выполняет
роль.
Члены команды имеют глубокую специализацию и слабое
представление о работе своих коллег. Состав команды изменяется
по ходу спринта
Планиров
ан
ие
Дейли митинги проходят несистематично и/или с опозданиям
Технические и бизнес-решение обсуждаются в ходе Дейли,
затягивая этот митинг более чем на 15 минут
Нет формальной оценки «успешных» и «не успешных» спринтов
Демонстрации проходят без подготовки, нет структуры встречи
Часть из рассматриваемых рисков можно решить с помощью наборов
инструментов. А именно :
- проведение мотивационных тренингов для сотрудников;
-демонстрация и визуализация поддержки руководства;
-демонстрация примеров успешных практик по управлению проектами;
-создание новых перспектив карьерного роста для сотрудников;
-поддержание интереса в работе;
- донесение до сотрудников важности командной работы;
- развитие способностей и обмен знаниями внутри организации.
Выводы по главе 2
Предполагается, что в скором будущем при соблюдении всех
требований методологии Скрам организация будет реализовывать проекты на
высоком профессиональном уровне и будет иметь возможность, в случае
51
возникновения простоев максимально быстро и без потерь реагировать и
принимать меры по ликвидации данных ситуаций, что станет свидетельством
жизнеспособности предприятия и гарантом надежного сотрудничества
заказчикам. Веб - студия сможет в индивидуальном порядке подходить к
проработке требований каждого заказчика, учитывая и удовлетворяя его
желания. Тем самым относительно молодая компания сможет привлечь
большее количество клиентов.
Результатами, которые планируется достичь, используя
Scrumявляются:
1) прозрачность процесса, ежедневное отображение хода
выполнения работ за счет внедрения корпоративной системы управления
проектами с компонентом Скрам В этой системе предусмотрено
использование инструмента Скрам - доска (доска движения задач,
поставленных конкретным разработчикам, на которой в режиме реального
времени отображаются статусы выполнения всех находящихся в разработке
задач);
2) предсказуемость сдачи промежуточных и финального
результатов. Поскольку длительность каждого спринта фиксирована,
заказчик и исполнитель знают даты получения промежуточных результатов
работ, что позволяет контролировать ход выполнения работ по проекту.
повышение качества продукта: лучшее соответствие ожиданиям
пользователей, уменьшение количества ошибок, за счёт их раннего
обнаружения. Заказчик включен в непосредственно сам процесс разработки,
участвует в планировании спринтов, в приемке промежуточных результатов,
вместе с командой разработчиков определяет приоритетность выполнения
задач.
3) увеличение продуктивности за счёт полного использования
потенциал командной работы и фокусировки на производительности
команды, а не на индивидуальной продуктивности;
4) самоорганизация команды повысила мотивацию и обеспечила
52
обратную связь для корректировки процесса, что значительно уменьшило
нагрузку на менеджмент;
5) упрощение вхождения в команду новых игроков за счёт ясности
процесса, общей процессной терминологии, а также создания почвы
взаимного обучения в виде ретроспектив и стенд-апов (регулярных встреч и
обсуждений).