Перейти к содержанию

Конструирование системы. Часть 2 — Задачи

После того как мы описали систему, на листке или еще лучше в каком-нибудь инструменте типа вики, переходим к следующему этапу. На этапе постановки задач нам необходимо понять самое главное — идеальной, подходящей именно вам методологии не существует.

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

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

Начнём с терминологий:

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

 

В итоге мы получаем такую схему:

  • ПМ-ы получают технические задания (проекты) от заказчиков, и создают на основе них вехи (получив консультации от архитекторов и администраторов), т.е. промежуточные этапы внедрения.
  • ПМ-ы декомпозируют вехи на отдельные задачи в пределах своих компетенций, задача ПМ сводится к тому что учесть все нюансы вех, сервисов и исполнителей.
  • Исполнители при участии ПМ-ов определяются со временем исполнения задач (планирование), ПМ-ы при этом следят за корректностью времени и консультируют исполнителей по деталям задачи.
  • ПМ-ы планируют очередной спринт, складывая в беклог список задач требующих реализации, учитывая доступное время исполнителей, их особенности и принадлежности к сервисам.

назад

Опубликовано в рубрикеОбщее