В первой части статьи см.Часть 1 мы обсудили преимущества организации процессов производства ИТ-продуктов в виде ИТ-сервисов, взаимодействующих на базе платформы.
Рассмотрели возможную структуру первого важного сервиса: «Учет требований к ИТ-Продукту». Определили, что его результат должен представлять собой сложную структуру описания Требований к целевой Информационной системе (далее ИС), максимально приспособленной к организации на ее основе активностей по их реализации.
Следующим шагом в рамкам платформы набор Требований должен передаваться в сервис «Организация производства ИТ-Продукта», где им предстоит воплотиться в функциональность готового ИТ-продукта.
IV Организация производства ИТ-Продукта
Итак, за основу организации работ по реализации Продукта мы приняли концепцию переработки Требований в итоговый функционал, который можно идентифицировать и измерить в целевом ИТ-продукте.
1. Сервис учета работ в производстве ИТ-Продукта
Поскольку наиболее распространенный подход разработки ИТ-Продуктов - итеративный, то и мы работы будем организовать в виде набора периодически повторяемых специфических активностей. Принято выполнять итерацию в четыре фазы: 1) Планирование – 2) Выполнение – 3) Проверка (фиксация отклонений) – 4) Анализ (корректировка).
Но вернемся на шаг назад, поскольку мы оставили без внимания момент организации работ стадии формирования самого Требования, а ведь они тоже являются процессом производства ИТ-продукта. Это не совсем изолированный этап, ведь во время работ в итерации, реализующей Требования может понадобиться их изменить, дополнить или полностью заместить на другие. А при Agile подходе и вовсе большая часть Требований рекомендуется генерировать уже на этапе реализации.
Понятно, что, например, Задача на формирование Требования отличается по своим параметрам, от Задач на их реализацию. Как минимум она связана с Требованием. В итоге, для одного Требования может существовать множество разнообразных задач. Например, на создание, на изменение, а также на реализацию, тестирование, включение в сборку и т.п. см. Рис.4.
Задачи производственной активности других типов (реализация, тестирование и прочие) можно организовывать подобным же образом. Исходя из этого следует, что большая часть Задач характеризуется обобщенными (генерализованными) свойствами (дата создания, планируемое время исполнения и т.д.), но каждый уникальный тип может иметь свой собственный расширенный набор свойств. Например: задачи на разработку могут ссылаться на компонент ИТ-продукта или версию сборки и прочее см.Рис.4.
Задачи чаще всего хоть и не имеют разветвленную иерархическую структуру, но требуют логической связанности. Например, задание на создание в целевом продукте функциональной возможности должна детализироваться задачами на реализацию программного кода, тестирования полученного результата, включения в сборку и т.д.
2. Организация работ с использованием итерационного метода
Но вернемся снова к организации работ по производству ИТ-продукта посредством итеративного подхода. Очевидно, что необходимо учитывать в системе сами Итерации, и работы организовывать уже в их разрезе.
Важно зафиксировать, что часть работ может выполняется вне итерационной парадигмы, например: предпроектное обследование, работы стадии проектирования, активности внедрения готового продукта и прочие. Итеративный же подход, в нашем случае, обеспечивает организацию работ по реализации проектного решения в целевой системе, поэтапно, разбивая его на составные, обозримые части (Итерации) см.Рис.5.
Это позволяет в ходе выполнения каждой итерации обеспечить приращение лишь части заложенных возможностей системы, отобранных из общего объема, и дает возможность постепенно, шаг за шагом анализировать как сам создаваемый ИТ-Продукт, так и процесс его производства, внося коррективы и купируя отклонения.
На практике для этого в актуальную (текущую) Итерацию, на этапе ее планирования, добавляют Задачи, на воплощение Требования (возможности). Далее, раскладывают каждую из них, создавая подчиненные задачи уже на их техническую реализацию. Отдельно можно включать в Итерацию задачи, несвязанные с Требованиями, например, на решения технических и инфраструктурных проблем см.Рис.6.
Следующий аспект. Согласно большинству методологий Итерации должны укладываться в строго отведенное время. Чаще всего придерживаются фиксированного периода выполнения, например, 2 недели, 4 недели и т.д. Но такой подход зачастую вызывает массу проблем, при планировании. Как определить время, которое понадобится для реализации не просто частной задачи, но и их совокупности в виде Возможности (функциональности), связанной с Требованием? Или зайдя, с другой стороны, сколько Требований взять на Итерацию, чтобы не просрочить их воплощение или не простаивать, быстро решив все задачи?
Например, фреймворк Scrum рекомендует организовывать работу в ограниченные сроки итерации (Спринта) и заканчивать ее независимо от того, всё ли успели сделать или нет. А Kanban методология предполагает выполнение всех задач, взятых на итерацию, не зависимо от того на сколько отклонились от первоначального плана-графика.
При использовании первого подхода часто возникает сумятица в объемах получаемого результата (функциональности) и постоянное ее дробление между итерациями, что значительно снижает качество анализа и возможность корректировки. А при втором, происходит затягивание работ по реализации Требований, чему попустительствует отсутствие жестких рамок. Во-втором случае итерацию проще прекратить, чем просто закончить.
Для лучшего понимания, каким путем идти, заглянем в суть подходов. Их отличия продиктованы способом организации работ: Scrum - проталкивающая, а Kanban – вытягивающая. То есть в первом случае выполнение одних работ инициирует начало следующих, а во втором одна высокоуровневая работа требует создания и выполнения цепочки более мелких, детальных работ. Второй подход, очевидно, больше подходит для предложенного нами варианта формирования активностей в Итерации – на основании Требования-возможности. Но это не означат, что мы должны безрассудно следовать всем нюансам методологии, мы все-таки строим свой процесс, используя лучшие практики.
Если отказаться от строгого соблюдения сроков Итерации, в угоду гарантированной реализации Требований-возможностей целевой системы, то мы должны решить вопрос: как бороться с проблемой затягивания сроков? Эта боль скорее решается при помощи менеджмента, чем посредством возможности ИТ-сервиса.
Сами Итерации должны учитываться в разрезе Проекта по созданию целевого ИТ-продукта.
Проект в данном случае объединяет все активности, связанные с получением конкретного результата в заданный период времени. Это может быть ИТ-продукт, отдельные модули Информационной системы, MVP, интегрируемое решение и прочее. У проекта чаще всего есть свой Заказчик.
Исходя из этой концепции можно Задачи, не требующие реализации в парадигме итерационного подхода, объединить в отдельные Итерации (в одно повторение), посвященные выполнению определенного шага этапа производства. Например «предпроектное обследование», «проектирование» и т.п. Это позволит унифицировать общую схему работы.
3. Поддержка жизненного цикла Задачи в процессе ее реализации
Каждая Задача характеризуются набором устойчивых состояний, определяющихся моделью ЖЦ, организованного для каждого типа по-разному. Например, Задача-возможность (по Требованию), при выполнении всех подчиненных задач на разработку, должна переходить на фазу тестирования. Это достигается конфигурированием статусной модели возможных переходов состояний уникальной для каждого типа Задач.
Так при создании новой задачи ей присваивается статус «Создана». В момент принятия задачи в работу исполнителем, ее статус меняется, например, на «В Работе». По текущему статусу можно определить на каком этапе ЖЦ, она находится см.Рис.7. и управлять исполнением.
При выполнении активностей по Задаче, каждый исполнитель формирует отчет с указанием времени выполнения и описания процесса см.Рис.4. Когда задача реализована в полном объеме, ее состояние меняется, в соответствии со статусной моделью, например, на «Выполнена».
Как упоминалось выше, если все задачи на реализацию требования перешли в статус «Выполнена», то объединяющая их Задача-возможность (связанная с Требованием) переходит в статус «на Тестирование». Это событие дает QA-специалисту сигнал, что он должен взять «В работу», связанную задачу на тестирование реализованной возможности. Этот сигнал, может формироваться без использования визуальных досок (Kanban или Scrum), обеспечивая бесшовный процесс организации производства.
В результате работы инженеров по качеству могут создаваться новые задачи на исправление ошибок и отклонений от требований. Иногда, могут появляться задачи и на доработку Требований по реализованным в продукте возможностям, отличающимся от требований, но оказавшимся комплементарными.
Когда по Задаче-возможности реализован весь комплекс работ, само Требование-основание задачи можно считать реализованным. А следовательно, в сервис «Учет требований к ИТ-Продукту», необходимо передать сигнал о продвижении связанного Требования по ЖЦ и смены его статуса на - «Реализовано».
Весь механизм обеспечения ЖЦ Задач, тянет на еще один сервис.
Поскольку каждая итерация должна завершаться стадией анализа, то результаты должны быть зарегистрированы в виде фактов положительных и отрицательных тенденций в самом ИТ-продукте и процессе выполнения работ в Итерации. На основании этих фактов должны быть выставлены задания на следующую Итерацию, по организации работ закрепления положительных тенденций и нивелирования отрицательных.
Результатом Итерации должна (в идеале) стать Сборка ИТ-продукта с ограниченными возможностями см.Рис.8.
4. Поддержка жизненного цикла Требования в процессе его реализации
Таким образом, складывается производственный конвейер.
Сформированное в сервисе «Учет требований к ИТ-Продукту» Требование в виде контекста было передано в разработку, в сервис «Организация производства ИТ-Продукта». Там были организованы работы по его реализации и обеспечению качества, с предоставлением обратной связи о стадии прохождения его ЖЦ.
5. Развитие платформы
Для тех, кто привык работать в классической проектной парадигме, может использоваться сервис, представляющий набор требований с типом: «Продукт», Компонент», «Возможность», в виде работ диаграммы Ганта, отражающей в том числе фиксацию их исполнения см. Рис.9.
Набор сервисов может и должен расширяться. Каждый сервис, не подходящий для конкретной команды , может быть заменен на наиболее комплементарный.
Модель организации взаимодействия самих сервисов - это отдельная большая тема и в рамках данной статьи не обсуждается.
