Подготовительный этап
Подготовительный этап начинается с формулирования целей и задач проекта. Это очень важный пункт, потому что главным критерием завершения проекта является достижение целей, установленных на проект.
После того, как цели сформированы, необходимо сформировать проектную команду Заказчика :
- Определить владельца продукта
- Определить бизнес-заказчиков
- Определить функциональных заказчиков
Неотъемлемой частью проекта является погружение проектной команды заказчика в информационное поле проекта: обучение стандартной функциональности программных продуктов, основополагающих для проекта, согласование терминов, используемых на проекте, проработка сценариев использования продуктов в смежных и похожих отраслях.
Составление устава проекта
Устав проекта определяет цели, задачи проекта, подход к его реализации, методологию, которая будет использоваться на проекте, состав ролей проектной команды со стороны заказчика и со стороны исполнителя, методы взаимодействия между заказчиком и исполнителем, кто принимает решение о приёме результата выполнения работы со стороны заказчика, определяет проектные риски и реакцию на их возникновение. В документ вносятся цели проекта и критерии определения достижения целей. Что будет, если цели не достигнуты.
Данный документ в последствии служит основой для принятия решений, а также разбора всех спорных ситуаций в части управления проектом.
Предпроектное обследование
Предпроектное обследование включает в себя опрос всех функциональных заказчиков, составление полного перечня функциональных требований, их группировку в различных разрезах и составление концепции проекта и плана его реализации. Данный документ даёт представление о рамках проекта, позволяет выделить из функциональных требований те, что соответствуют целям и задачам проекта, а также те, что будут способствовать его внедрению.
Концепция проекта включает в себя общее описание функционала будущей системы с указанием основных принципов взаимодействия между собой блоков и подсистем.
Концептуальный план укрупнённо описывает порядок разработки и внедрения функционала, а также подход к реализации того или иного функционала, запланированного на проекте. Концептуальный план также включает подход к запуску функционала разрабатываемой системы на всю компанию.
Возможна ситуация, когда на основании предпроектного обследования цели и задачи проекта подвергаются изменениям. В этом случае, обязательно внесение соответствующих изменений в устав проекта.
На основании собранных о компании и ее сотрудниках данных разрабатывается методология запуска проекта и его этапов. В данном документе приведён общий подход, от которого возможны отклонения в связи со спецификой каждого конкретного проекта.
Проектирование архитектуры
На данном этапе описывается АйТи ландшафт системы: в каких условиях будут функционировать система, на каком оборудовании, какое программное обеспечение будет взаимодействовать с разрабатываемой системой и требует интеграции с ней.Для разрабатываемой системы определяется серверное программное обеспечение и оборудование, на котором она будет функционировать
Определяется полный перечень программного обеспечения, с которым потребуется интеграция и взаимодействие.
Исходя из концептуального плана системы, функциональность разбивается на основные блоки с привязкой к программному обеспечению и платформе. Для каждого блока описывается основной модуль или модули, при помощи которых он будет реализован, связь между функциональными блоками в плане транспортировки информации.
Техническое задание включает в себя блок архитектуры, блок настройки готовой функциональности системы, а также описание способов технической реализации и параметров разрабатываемых новых модулей.
Техническое задание для каждого функционального блока, расходящегося по функциональности со стандартной задокументированной функциональностью системы, должно содержать контрольные примеры, по которым в дальнейшем можно будет проверить функциональность системы.
Весь проект разбивается на релизы длительностью не более четырёх месяцев, этапы длительностью не более месяца и подэтапы продолжительностью не более недели.
Первый Релиз разработки описывается детально. Последующие - укрупнённо, в достаточной детализации для определения сроков и стоимости их исполнения с погрешностью 15%.
С Заказчиком согласуется календарный план всего проекта по Релизам, а также детально первый Релиз с привязкой ко времени старта (предоставления всех исходных данных, подписания документов, внесения предоплаты).
Разработка и внутренняя приёмка
Идеальная, но довольно трудоемкая архитектура среды разработки состоит из трёх серверов.
Первый сервер - на котором производится разработка и первичное тестирование разработчиками и руководителем проекта.
Второй сервер служит для переноса протестированного функционала и тестирование его средствами заказчика. После приемки работы на втором сервере разработка переносится на продакшн сервер.
На продакшн сервере система уже функционирует и работает персонал Заказчика.
В случае, если система разрабатывается до ввода в эксплуатацию на всю компанию, допускается использование двух серверов: сервера разработки и сервера тестирования. Однако, на сервере тестирования в этом случае, должна быть финальная версия, которая в дальнейшем станет основой для переноса информации на продакшн сервер.
Разработка ведется по техническому заданию. Любые отступления от технического задания обязательно фиксируются в письменной форме и направляются Заказчику по каналу официальной переписки. Обязательно получить ответ также по официальному каналу, для того чтобы зафиксировать согласие на соответствующие изменения в Техническом задании. Также изменения фиксируется в регулярно составляемых отчетах о состоянии проекта. По завершении этапа все изменения вносятся в техническую документацию, описывающую данный этап.
В случае существенных отклонений от технического задания либо архитектуры проекта, они обязательно фиксируются в дополнительном соглашении, и работы проводятся только после подписания дополнительного соглашения со скорректированным техническим заданием по соответствующему блоку.
На протяжении всего проекта подписываются отчёты о состоянии проекта. Отчёт о состоянии проекта включает в себя описание работы, проделанной за последнюю неделю: какие значимые решения по проекту были приняты, какие задачи реализованы, находится ли разработка в рамках календарного плана, либо существуют отклонения от него. В случае отклонения от технического задания, указываются причины, по которым произошло отклонение и их технические детали. Отчет о состоянии проекта передается заказчику для подписания. Если в течение пяти дней заказчик никак не отреагировал, либо не внес корректировки в отчет о состоянии проекта, он считается согласованным и принятым.
После разработки каждого подэтапа длительностью неделя и меньше производится внутренняя приемка. На внутренней приемки руководитель проекта либо тимлид производят проверку разработанного функционала на соответствие функциональным требованиям, архитектуре, а также корректного исполнения контрольных примеров из технического задания
По факту проверки составляется отчёт о результатах проверки. Это внутренний документ, который служит для фиксации корректности разработки каждого этапа, фиксируется кто разрабатывал этап, кто проверял, какие отклонения были обнаружены и в какие сроки они будут устранены.
После получения корректного результата по каждому этапу, информация передается заказчику по официальному каналу коммуникации.
Результат прохождения подэтапов передается заказчику исключительно с информационной целью. Заказчик при этом не допускается к тестированию подэтапов на сервере тестирования.
Сдача этапов работ Заказчику
После прохождения всех подэтапов этапа и корректного тестирования всех контрольных примеров результат выполнения переносится на сервер тестирования, на котором есть возможность проверять функциональность Заказчику.
Руководитель проекта сообщает Заказчику о готовности этапа и возможности его сдачи. Назначается встреча, на которой руководитель проекта производит демонстрацию функциональности, полученной в результате разработки и передачу результата на тестирование Заказчиком. Определяется период тестирования, который потребуется для проверки системы. Важно, чтобы на встрече по сдаче этапа присутствовали функциональные заказчики, чьи требования реализовывались на этапе.
На встрече ведется протокол, в котором фиксируется отклонения от функциональности если таковые имеются.
Руководитель проекта контролирует проведение тестирования заказчиком в установленные им сроки. На дату окончания проведения тестирования руководитель проекта должен связаться с заказчиком и зафиксировать, что время на тестирование истекло, назначить очередную встречу для обсуждения результатов тестирования.
На встрече между исполнителем и заказчиком обсуждаются результаты тестирования этапа. Если отклонений, существенных для дальнейшей разработки, нет, производится подписания акта приема-передачи этапа и согласование календарного плана разработки следующего этапа.
Календарный план следующего этапа должен быть готов за неделю до сдачи или концу процесса тестирования предыдущего этапа.
Для того, чтобы календарный план был достаточно детализированы и точен, к моменту начала написания календарного плана должно быть готовое техническое задание по соответствующему этапу и всем его подэтапам.
Таким образом, написание технического задания по следующему этапу начинается в момент начала разработки предыдущего этапа.
Сдача этапов заказчику производится по накопительному сценарию. То есть проговаривается весь разработанный функционал системы, освежается его восприятие клиентом и детально проговаривается функциональность сдаваемого этапа. Таким образом, по результатам сдачи каждого этапа, у клиента должно сформироваться полное представление о всей функциональности системы разработанный к текущему моменту.
Завершение проекта
После того как все этапы проекта сданы, производится общая презентация результатов проекта на владельца продукта. Также презентуется план вовлечения и обучения всех ролей разработанной системы.
Если функциональность системы запускается в продакшн поэтапно, тогда в период сдачи каждого этапа производится обучение функциональных заказчиков, а также ролей участвующих в работе с функционалом сдаваемого этапа.
На этапе запуска проекта в продакшн или его части на территории заказчика находится руководитель проекта, который принимает участие в обучении сотрудников клиента и их поддержке в момент запуска системы.
Перенос на продакшн сервер производится до обучения, но после тестирования заказчиком этапа.
Результатом проекта является, в первую очередь, достижение целей, определённых на проект; во вторую очередь - выполнение всех функциональных требований, перечисленных в Техническом задании и отчет о состоянии проекта, содержащий отклонения от технического задания, а также описание дальнейшего развития системы, его слабых сторон и вариантов улучшения.
