Введение
Цель - рассказать про процессы с точки зрения управления проектами, моделирования бизнес-процессов и возможностей применения этих знаний для улучшения качества работы (в контексте разработки ПО).
Процесс - совокупность взаимосвязанных или взаимодействующих видов деятельности, преобразующих входы в выходы.
Уровень 0. Что-то происходит
При многократном выполнении похожих задач формируется опыт (что нужно делать, как не нужно делать) и алгоритм (последовательность действий для достижения поставленной задачи).
Появляется человек со знаниями. Он пытается делать каждый раз опираясь на опыт прошлого, иногда делиться опытом и делегировать.
Когда другому человеку нужно начать делать аналогичные задачи, то он начинает спрашивать у “эксперта”, анализирует результат работы по прошлым задачам.
Уровень 0. Проблемы
В какой-то момент подход становиться недостаточно расширяемым:
- Много времени нужно, чтобы объяснить новому человеку
- Тяжело и долго проверить, что всё сделано так, как нужно
Появляется желание процесс формализовать.
Уровень 1. Текстовое описание
Первым шагом по улучшения процесс является описание процесса. Зачем:
- Описание становится документацией, упрощает передачу знаний
- Описание процесса можно сравнивать с реально происходящим процессов и находить места, где не по плану выполняется работа
Пример процесса
Опишем абстрактный контекст в рамках которого будет существовать процесс.
Представим, что есть некая компания, которая занимается разработкой своего ПО. В ней сформировалась подходы к работе. В какой-то момент один из её участников решил составить описание процесса:
- Инициируется создание нового проекта
- Пишется код с реализацией требований
- По мере реализации происходят уточнения требований
- После того, как код будет готов, начинается тестирование
- Создаются и чинятся дефекты
- После закрытия всех дефектов проект отдаётся тех. писам.
Уровень 2. Ролевая модель в процессе
Следующим значимым улучшением описания процесса является добавление ролей:
- Роли дают возможность понять, что требуется от каждого члена процесса
- Роли фиксируют ответственность за людьми
Выделение ролей
- Роли могут наследоваться от общеизвестных описаний и регламентов (PMBoK)
- В сложных процессах роли очень сильно видоизменяются и лучше создавать роли под конкретные процессы
- Роль в процессе != роль в компании
- Роли нужно декомпозировать и можно комбинировать
- Описание роли упрощает понимание требований к ней
Выделим роли
Вернёмся к изначальному процессу и ролям. Если упростить, то можно дать такие определения ролям:
- Аналитик. Определят требования и ограничения к функциональности.
- Ответственный за функциональность. Управляет жизненным циклом функционала от момента получения требований от аналитика, до предоставления готового результата техническим писателям, поддержке.
- Разработчик. Пишет код для реализации поставленных задач.
- QA. Проверяют, что реализация соответствует требованиям.
Визуализация ролей
@startuml
|Аналитик|
|Ответственный|
|Разработчик|
|QA|
|Аналитик|
start
:Сформировать требования;
:Создать задачу;
|Ответственный|
:Изучить требования;
:Запросить уточнения;
|Аналитик|
:Уточнить требования;
|Ответственный|
:Сформировать требования к демо;
|Разработчик|
:Подготовить демо;
|Ответственный|
:Показывает демо, собирает фидбек;
|Аналитик|
:Даёт фидбек про демо;
|Ответственный|
:Фиормирует итоговые требования;
|Разработчик|
:Реализовывает функциональность;
|QA|
:Валидирует решение;
:Фиксирует дефекты;
|Разработчик|
:Исправляет дефекты;
|Ответственный|
:Утверждает итоговое решение;
:Передаёт решение другим командам;
stop
@endumlУровень 3. Артефакты
Каждый шаг процесса имеет свои входы и выходы. Они являются частью процесса. Формализация артефактов даёт ряд плюсов:
- Знание о том, какой output ожидается, упрощает ответ на вопрос “что нужно сделать”
- Требования к input позволяет “требовать” от исполнителя прошлого шага все необходимые данные
Среди артефактов:
- Описание требований и ограничений функциональности, который описывает аналитик
- Задачи, которые формирует разработчик при декомпозиции
- Описание дефектов
- Результаты еженедельных митингов
Визуализация с артефактами
@startuml
|Аналитик|
|Ответственный|
|Разработчик|
|QA|
|Аналитик|
start
:Сформировать требования;
:Создать задачу;
-[#green]-> Требования к функциональности;
|Ответственный|
:Изучить требования;
:Запросить уточнения;
-[#green]-> Список вопросов к требованиям;
|Аналитик|
:Уточнить требования;
-[#green]-> Требования к функциональности;
|Ответственный|
:Сформировать требования к демо;
-[#green]-> Список задач для реализации;
|Разработчик|
:Подготовить демо;
|Ответственный|
:Показывает демо, собирает фидбек;
-[#green]-> Демо новой функциональности;
|Аналитик|
:Даёт фидбек про демо;
-[#green]-> Список запросов на изменения;
|Ответственный|
:Фиормирует итоговые требования;
-[#green]-> Список задач для реализации;
|Разработчик|
:Реализовывает функциональность;
|QA|
:Валидирует решение;
:Фиксирует дефекты;
-[#green]-> Описание дефектов;
|Разработчик|
:Исправляет дефекты;
|Ответственный|
:Утверждает итоговое решение;
:Передаёт решение другим командам;
stop
@endumlВнесение изменений в процесс
Представим, что процесс уже запущен, но вдруг приходит новое требование: новая функциональность должна сразу покрываться автоматическими тестами. Реализацией автоматических тестов должен заниматься разработчик из специальной команды.
При обсуждении изменений в процессах выделяют термины “as is” и “to be”: процесс до изменений и после. Их сравнение позволяет:
- Увидеть насколько больше шагов нужно делать
- Увидеть как меняется положение каждой роли и корректировать требования к квалификации
- Увидеть новые переходы между ролями и понять какие новые формы и шаблоны коммуникации нужны
Процесс to be
|Ответственный|
:Сформировать итоговые требования;
:Запросить список сцнариев
для автотестов;
-[#green]-> Итоговые требования к функциональности;
|QA|
:Подготовить тест-кейсы;
-[#green]-> Список тест-кейсов;
|Test dev|
:Подготовить авто-тесты;
-[#green]-> Отчёт о создании авто-тестов;
|Разработчик|
:Реализовывает
функциональность;Уровень 4. Оценка процесса
Если процесс описан, то его можно оценить. Есть много систем оценивания, среди которых и ГОСТ 33020. Он определяет набор атрибутов процесс, например:
- Атрибут управления осуществлением
- Атрибут определения процесса
- Атрибут инновации процесса
Атрибут управления осуществлением
- Определены цели процесса
- Осуществление процесса планируется, и проводится его мониторинг
- Осуществление процесса регулируется для соответствия планам
- Определены роли и полномочия в рамках процесса
- Определены источники информации, необходимые для осуществления процесса
Анализируемый процесс имеет цель (реализовать функциональность), он планируется и мониторится. В процессе выделены роли и определены источники информации, а значит процесс можно назвать управляемым.
Атрибут определения процесса
- Определен стандартный процесс
- Определены последовательность и взаимодействие стандартного процесса с другими процессами
- Определены компетентности и роли, необходимые для осуществления процесса
- Определены инфраструктура и рабочая среда, необходимые для осуществления процесса;
Атрибут инновации процесса
- Определены цели улучшения процесса
- Проанализированы причины вариаций при осуществлении процесса
- Проанализированы возможности применения инноваций и стандартных практик
- Установлена реализация стратегии для достижения целей улучшения процесса
Не все требования атрибутов должны достигаться процессом. У компании может не стоять за цель инновация определённых процессов, если их устраивает текущее положение дел.