После того как мы описали систему, на листке или еще лучше в каком-нибудь инструменте типа вики, переходим к следующему этапу. На этапе постановки задач нам необходимо понять самое главное — идеальной, подходящей именно вам методологии не существует.
Вам необходимо вооружившись головой и здравомыслием выбрать какие инструменты подходят наиболее всего для решения поставленных задач, и при необходимости доработать их. Представленный ниже способ будет вам возможной отправной точкой на этом пути.
Небольшое отступление, тут мы будем рассматривать «итеративную проектную деятельность», т.е. деятельность в основе которой лежит реализация проектов итерациями. Проекты мы будем разбивать на вехи, а в вехи будем складывать наши задачи. Дополнительно мы будем собирать спринты из общего стека задач, раскладывая их на исполнителей, которые на протяжении спринта будут решать их.
Начнём с терминологий:
- Заказчик — лицо и/или группа лиц, нуждающихся в реализации какого либо функционала.
- Проектный-Менеджер — лицо или группа лиц, осуществляющих деятельность по менеджменту портфеля проектов, и ответственные за реализацию оных.
- Архитектор — человек, занимающийся созданием/модификацией архитектуры сервисов системы и консультирующий проект-менеджеров о её текущих возможностях, выступая в качестве источника знаний о текущем состоянии системы.
- Администратор — лицо и/или группа лиц, занимающийся обслуживанием парка серверов.
- Проект — функционал или набор функциональных возможностей, нуждающийся в реализации.
- Веха — контрольная точка в реализации проектов, содержащая в себе описание и список задач необходимый для её реализации, а так же при необходимости фиксированную дату завершения.
- Задача — инструкция (набор инструкций), которые необходимо реализовать, в какой-либо части системы. Стоит отметить, что задачи должны быть атомарными и не могут включать в себя несколько частей системы (сервисов).
- Сервис — изолированная часть системы, с определённым списком возможных исполнителей(сервисная команда) и ответственным за его стабильную работу человеком (владельцем), направленная на реализацию какого-либо действия (микро-сервис), набор однотипных действий (сервис) или группу разнородных действий (макро-сервис).
- Исполнитель — лицо или группа лиц(команда), ответственных за выполнение поставленных задач.
- Команда — группа лиц, ответственных за работоспособность определённых частей системы и осуществляющая её сопровождение.
- Декомпозиция — процесс дробления вех проектов на задачи и задач на подзадачи, в результате которого поставленные задачи станут атомарными и привязанными к конкретным сервисам, и понятным для исполнителей описанием.
- Планирование — процесс определения времени, необходимый для реализации задач. В обычном случае применяется планирование-покером, как самый простой и более честный вариант.
- Планирование-Покером — вариант планирования, при котором по очередной задаче участники планирования кладут карточки со временем рубашкой вверх, а проект-менеджер выбирает средний показатель. (в случае если показатели сильно разнятся, проводится беседа, определяющая в чём загвоздка).
- Планирование-Спринта — процесс распределения задач на исполнителей, с учетом их привязки к сервисам, ограничением времени и срочности.
(границы времени исполнителя заданы из времени рабочего дня , за вычетом времени планирований и встреч, перемноженный на количество дней спринта) - Спринт — итерация жизненного цикла системы, с заданным не меняющимся временем и строго заданным количеством задач по результатам планирования.
- Статус задачи — довольно индивидуальная тема, но можно выделить основные, используемые в большинстве систем:
1. Беклог — список задач попавших в спринт, но еще не взятых в работу.
2. В работе — список задач выполняющихся в текущий момент.
(обычно для последующего перехода «в тестирование», необходимо создать «пул-реквест» и получить «апрув» от команды сервиса)
3. В тестировании — задача находится на проверке в отделе тестирования
(да да, ручное приёмочное-тестирование еще долго останется актуальным)
4. Выполнена — задача прошедшая тестирование переходит в статус «выполнена», иначе она возвращается «в работу»
(обычно статус «выполнена» может установить только тестирующий, также на этом шаге «пул-реквест» сливается в основную ветку сервиса) - «Пул-Реквест» по задаче — запрос на внесение изменений из одной ветки в другую (например в основную — для выгрузки на бой).
(применяется в случае использования командой системы контроля версий) - «Апрув» «пул-реквеста» по задаче — принятие решения по задаче другими исполнителями(командой). Комментирование сомнительных/опасных моментов, и финальное [Не]Согласие с данным решением
(в случае если решение задачи получило апрув от команды, но провалилось на тестировании, то после исправления она снова попадает в тестирование только после получения нового апрува). - Важность задачи — довольно индивидуальная тема, но можно выделить 4 основных (матрица Эйзенхауэра):
1. Важно-Срочно (первоочередная)
3. НеВажно-Срочно (очередная)
2. Важно-НеСрочно (простая)
4. НеВажно-НеСрочно (возможная)
В итоге мы получаем такую схему:
- ПМ-ы получают технические задания (проекты) от заказчиков, и создают на основе них вехи (получив консультации от архитекторов и администраторов), т.е. промежуточные этапы внедрения.
- ПМ-ы декомпозируют вехи на отдельные задачи в пределах своих компетенций, работа ПМ сводится к тому, чтобы учесть все нюансы вех, сервисов и исполнителей.
- Исполнители, при участии ПМ-ов определяются со временем исполнения задач (планирование), ПМ-ы при этом следят за корректностью времени и консультируют исполнителей по деталям задачи.
- ПМ-ы планируют очередной спринт, складывая в беклог список задач требующих реализации, учитывая доступное время исполнителей, их особенности и принадлежности к сервисам.
Дополнительно, рассмотрим еще набор возможных терминов, вводящих некоторые ограничения, преимущественно полезных для больших объемов систем:
- Продукт — часть системы/совокупность частей системы объединённая в выделенную её часть, с выделенным ответственным со стороны заказчиков владельцем и командой исполнителей.
- Владелец-продукта — представитель со стороны заказчика, коммутирующий с ПМ, радеет за текущее состояние продукта, его актуальность и возможности.
(частный случай ПМ, но не управляет командой а корректирует её направление/курс) - Продуктовая-команда — выделенная часть исполнителей, необходимая для реализации задач какого-либо продукта.