17.04.2017

Разработка ПО. Устав проекта

Блог: разработка ПО. Устав проекта

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


Общее описание

Чтобы понять смысл устава проекта, представьте, что в ходе работы поменялась часть штата со стороны ИТ-компании. Поднимаются типовые вопросы: кому и с чем звонить, адреса серверов, правила работы с репозиторием и трекером, какой компилятор использовать, можно ли выпускать релизы по выходным и т.д. Хороший проектный устав отвечает на большинство из них, идеальный - на все. И вы, и клиент экономите время, а вероятность ошибок значительно снижается.


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


Сложнее когда к проекту привлекаются третьи лица. Нужно детально описать их часть работ и зону ответственности. Перечень также должен присутствовать в плане проекта. Что нужно зафиксировать? Порядок действий и ответственных за прогон регресс-тестов, выкладку релиза на основные сервера. В каком виде ведущий разработчик передает релиз? Как заказчик развертывает решения, на каких серверах, тестирует ли он его?


Самые важные моменты дублируйте в договоре:

  • сотрудники с обеих сторон несущие ответственность за свои области разработки;
  • официальные контакты и способы обмена информацией;
  • список работ и ответственностей, которые несет заказчик.

О пользе устава можно судить по одному небольшому примеру: тщательно подготовленный документ исключает попадание в релиз версии программного обеспечения, не прошедшей полноценное тестирование.


Содержание

Что, помимо лиц, участвующих в проекте со стороны клиента и разработчика, их контактов, пула задач и ответственности должен содержать устав?


  • Способы коммуникаций между сторонами и внутри команд: почта, чаты, трекеры, репозитории документов.
  • В явном виде перечисленные работы, которые делает заказчик: составляет документацию, принимает решения (опять-таки, какие?), пишет часть кода, проводит тестирование, деплой, отрабатывает аварийные сценарии, вводит решение в опытную эксплуатацию и так далее — как договоритесь.
  • Схему передачи документов, релизов, исходных текстов.
  • Описание аппаратных и программных ресурсов: серверов, репозиториев, баг трекеров.
  • Данные о нахождении проектной документации и структуре хранилища.
  • Карту ресурсов со всей необходимой информацией.
  • Используемые технологии и инструменты (библиотеки, инструменты для сборки, версии языков и т.п..
  • Планы релизов, их развертывания, тестирования, согласования выкладки с заказчиком.
  • Другие правила работы.

В устав включают также принятые схемы работы.


С репозиториями:

  • работа с ветками кода (в какой разрабатывается версия, а где — замороженный код релиза), их создание и объединение;
  • выкладка релизов и их версий на тестовые, отладочные и боевые сервера;
  • список разработчиков, отвечающих за ревью кода и слияние веток.

С баг трекером:

  • логика маршрутизации задач;
  • маршрутизация по типам и темам задач;
  • ответственные сотрудники (кто распределяет задачи, кто отвечает за отдельные компоненты или подпроекты и пр.).

Цель

Устав — источник взаимопонимания с заказчиком и его командой, легкого вхождения новых сотрудников в проект и ответа на вопрос «кто виноват, что делать?».


Автор

Первые наброски устава предоставляются сотрудниками проектного офиса в качестве одного из типовых документов.


В целом он пишется менеджером проекта, но к отдельным его частям привлекают:

  • ведущего разработчика или архитектора;
  • ведущего сотрудника по линии devops;
  • аккаунта, ответственного за связь с клиентом;
  • ответственного со стороны заказчика.

Написать документ нужно до старта проекта или на этапе его запуска, что будет значительно хуже. Согласование должно быть официальным, при этом устав допускает незначительные корректировки и доработки в ходе проекта, но обязательным требованием будет доносить изменения до всей команды. Устав может меняться, но должен всегда содержать актуальные и верные сведения.