PMsoop: Глава №13: Про среды

В ролях – Менеджер Проекта, Команда Проекта

Артефакты – спецификация сред проекта

Суть – Менеджер Проекта совместно с командой определяет среды, используемые в проекте, и составляет их спецификацию

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

Перечислю основные используемые среды:

- среда планирования и учёта задач

- среда разработки

- среда тестирования

- среда учёта дефектов и изменений

- среды запуска проекта

- среда хранения требований и других проектных документов

Все эти среды нужно определить и, желательно, задокументировать до начала разработки. Рассмотрим каждую из сред подробнее:

Среда планирования и учёта задач

Данная среда состоит из нескольких компонент, которые будут рассмотрены по отдельности:

1. Представление плана проекта

План Проекта – важный документ для всей команды проекта (наглядное представление последовательности задач), и, в некоторых случаях, для заказчика (следить за прогрессом). Хранить его надо в некотором доступном для заинтересованных лиц месте. Следует учесть, что ПП часто актуализируется и изменяется в ходе проекта – и узнавать об этих изменениях должны все участники проекта своевременно. Варианты реализации компонента могут быть разные, например:

- использовать MSP, рассылать новые версии адресно или «на всех», хранить файл ПП в shared папке

- использовать web-based систему планирования, например Jira

- вести планирование по рекомендациям Agile методики и использовать task board

Какой именно вариант подходит именно вам для данного проекта – решайте сами.

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

2. Доступность требований по каждой задаче из плана проекта для разработчиков

Кроме последовательности задач команде проекта, пожалуй, в первую очередь, нужно знать актуальные требования по каждой задаче. Часто для решения данной задачи просто рассылается «на всех» последняя версия требований, и разработка ведётся по ней. Если качество требований достойное, и есть чёткая привязка задач из ПП к разделам требований – можно делать и так. Только не стоит забывать о том, что требования уточняются и изменяются в процессе разработки, поэтому новая информация должна быть стразу доступна всем участникам проекта. Уточнения и изменения обычно приходят в виде электронной почты, или истории чата с Заказчиком, или записей по результатам аудио/живого общения с Заказчиком. Если эта новая информация сразу не добавляется в общую спецификацию требований, а просто передаётся разработчикам в том же виде – ждите возможных проблем. Если сначала работали по спецификации, а потом было еще 3 письма и пару указаний в устной форме – часто может получиться, что никто толком не знает, что именно и как надо сделать, и задачи выполняются с ошибками, требующими последующих исправлений. В общем, помните, что требования должны быть доступны в одном и том же месте в актуальной форме. Рекомендуемые варианты реализаци:

- работать по спецификации и обновлять саму спецификацию по каждому изменению и уточнению требований; для этого в команде рекомендуется иметь выделенного аналитика

- работать в среде Sharepoint с привязкой требований к плану проекта в MSP – аналогично следующему пункту

- хранить требования в issue tracking системе, например Jira, в виде задач; уточнения и изменения добавлять в виде комментариев к задаче (что удобно ещё и тем, что видна история изменений); а ещё к такой системе можно дать доступ Заказчика чтобы он сам мог видеть актуальные требования и их уточнять – улучшает качество понимания в команде проекта; а ещё такая система наиболее наглядна и удобна в использовании для разработчиков; а ещё лучше всего «стыкуется» с другими задачами этой же среды и других сред, т.к. есть плагины для диаграммы Ганта, file sharing, SVN etc.

- работать по Agile–методике, выяснять/уточнять требования на регулярных собраниях команды проекта с Заказчиком (работает только в случае отличной доступности Заказчика)

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

3. Учёт выполненных и текущих задач

Смысл думаю понятен, а вот варианты реализации могут быть различными:

- Менеджер Проекта «ручками» актуализирует ПП

- Команда отчитывается в MSP (через MSP сервер), прогресс виден на диаграмме Ганта

- То же можно сделать через Jira с правильными плагинами

- Task board для Agile

4. Учёт реальных трудозатрат команды проекта

Непосредственно связано с предыдущим компонентом. Типичные варианты реализации:

- команда проекта пишет ежедневные отчёты (из которых МП потом ручками собирает данные и актуализирует ПП, применимо только для небольших проектов и команд)

- трудозатраты и прогресс отчитываются в MSP/Jira/etc

- трудозатраты вообще можно не учитывать т.к. Заказчик оплачивает всё рабочее время, а прогресс по задачам отмечает МП в виде процентов

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

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

5. Среда хранения документов проекта

В рамках данного компонента речь идёт о доступном для всех участников проектной команды (и иногда Заказчика) месте хранения публичных документов проекта. Таких ак, например, спецификация требований (ТЗ), спецификация сред, концепция архитектуры проекта, мокапы дизайна проекта и т.п. Варианты возможной реализации:

- shared folder (file hosting)

- использовать Sharepoint либо Jira с нужными плагинами

- SVN

Среда разработки

Основными компонентами данной среды являются:

1. ПО разработчиков

Имеется ввиду набор софта, который должен быть установлен на ПК разработчика для нормального ведения разработки. Если в проекте задействовано несколько технологий – набор софта для каждой технологии может быть разным. Выяснить, что планируется использовать можно на собрании с разработчиками исходя из принятой концепции архитектуры (собственно, в концепции этот момент может быть уже определён). По результату обсуждения принятые решения дописываем в спецификацию сред. А разработчиков отправляем устанавливать нужный софт, если это ещё не сделано.

2. Хранение и контроль версий

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

- какой программой пользуемся

- где она будет установлена, параметры доступа

- правила наименований, определения «веток» и фиксации версий

Результаты добавляем в спецификацию сред. Даём задачу ответственному персоналу на установку и настройку всего что нужно.

В некоторых случаях среда хранения и контроля версий может быть определена Заказчиком – тогда просто добавляем нужную информацию в спецификацию сред.

3. Среда «сборки» проекта

Необходимо определить где будет происходить «сборка» (компиляция) всего проекта и необходимое для этого ПО. В крупных проектах для этой цели может выделяться отдельный сервер. В небольших проектах где используется одна технология сборка может выполняться на ПК одного из разработчиков. В любом случае этот момент стоит определить и зафиксировать спецификации сред.

Среда тестирования

По-хорошему, среда тестирования должна эмулировать среду типичного пользователя проекта. Даже если в проекте для тестирования сайта достаточно Smoke tests & Monkey testing – нужно использовать наиболее распространённые браузеры, а не то что нравится тестировщику. Компоненты среды тестирования:

1. Эмуляция типичного пользователя

Например для простого сайта – браузеры через которые тестируем сайт. Для исполняемого приложения – ПК должен соответствовать некоторому «среднему» уровню (который должен быть определён в нефункциональных требованиях) плюс на нём должно быть установлено «типичная» ОС и набор программ. В общем, речь идёт про создание условий приближённых к условиям типичных пользователей готового продукта. В некоторых случаях эти условия детально определены в требованиях проекта, но такое встречается редко. В большинстве случаев эти условия можно определить исходя из понимания проекта и здравого смысла. Для этого МП может собрать тестировщиков проекта и обсудить с ними доступные варианты. Принятые решения (или соответствующий раздел из требований) добавляем в спецификацию сред.

Заметка – часто для эмуляции среды пользователя используют виртуальные машины. В таком случае в спецификации сред не забудьте указать, где и как они хранятся и параметры доступа к ним.

2. Специальное ПО

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

Среда учёта дефектов и изменений

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

- Sharepoint + MSP

- Jira + плагины

Оба эти варианта позволяют удобное управление задачами разработки и разделение задач на разработку, устранение дефектов и реализацию изменений. Также оба варианта позволяют тестировщикам (или Заказчику) регистрировать дефекты и новые задачи, а разработчикам отчитываться о текущем прогрессе и завершении. И там и там есть возможности комментирования, куча статусов для отображения возможного состояния задачи (new, assigned, needs information, duplicate, fixed, closed, withdrawn). В общем – рекомендую.

Если планирование и учёт задач ведётся в среде, не рассчитанной на регистрацию дефектов и запросов на изменения – значит, для регистрации дефектов и изменений понадобится выделенная среда. Суть такой среды – с одной стороны тестировщики регистрируют дефекты, с другой стороны разработчики отчитываются про исправления. Подробнее отправлю в Гугл по запросам bug tracking или issue tracking. Простым вариантом, кстати, но только для внутреннего пользования, является всё тот же task board. Минус в том что Заказчику его показывать трудно.

Принятое решение по среде учёта дефектов и изменений следует внести в спецификацию сред.

Среды запуска проекта

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

1. Среда запуска для разработки

При разработке после «сборки» проекта обычно есть необходимость запустить собранную версию и проверить реализованный функционал. Делают это сами разработчики. Для проекта по разработке небольшого сайта эта среда может представлять собой Apache поднятый на ПК одного из разработчиков. Для проекта по созданию исполняемого приложения – сам ПК разработчика. Для крупных проектов это может быть несколько различных сред на разных серверах. Иногда (часто) среда запуска для разработчиков может совпадать со средой «сборки» проекта.

Определить параметры среды Менеджер Проекта может на собрании с разработчиками. В некоторых случаях среда может быть определена Заказчиком. В любом случае принятое решение описываем в спецификации сред, даже если это «запуск на ПК Васи».

2. Среда запуска для тестирования

Тестирование рекомендуется выполнять в среде запуска отличной от среды запуска для разработчиков. Причина проста – разработчики «собирают» новые версии значительно чаще, чем выпускают версию для тестировщиков, а внезапные изменения в тестируемой версии затрудняют тестирование.

Важным моментом при определении среды запуска для тестирования является необходимость учесть перспективу нагрузочного тестирования, если оно необходимо. Грубо говоря, выбранная среда запуска должна позволять нагрузить приложение согласно ТЗ.

Среду запуска для тестирования рекомендуется определять на собрании с разработчиками и тестировщиками вместе. В некоторых случаях среда может быть определена/предоставлена Заказчиком. В других случаях среда запуска для тестирования может быть описана в разделе «среды тестирования». Но в любом случае принятое решение должно быть описано в спецификации сред.

3. Среда запуска для показа Заказчику

Думаю, тут всё понятно. Речь идёт о среде, в которой будем «сдавать» готовые версии Заказчику. Часто она совпадает либо со средой запуска для тестирования, либо со средой запуска готового проекта.

4. Среда запуска готового проекта

Наконец, важно определить параметры среды, в которой будет работать готовое приложение, и сделать это надо до старта разработки – так как именно от параметров этой среды зависит подбор параметров всех остальных сред запуска приложения. В идеале, все среды должны быть одинаковы, но такое возможно достаточно редко вследствие частых ограничений по ресурсам. В идеале, требования к среде запуска должны быть определены в ТЗ. Но даже в таком случае всё равно стоит их скопировать в спецификацию сред.

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

- наглядность представления информации; меньше шансов что кто-то что-то забудет

- доступность всей информации по средам в одном месте, удобство внесения изменений, если они вдруг появятся (такое бывает – например, Заказчик захочет увеличить пиковую нагрузку сайта со 100 до 1000 одновременных пользователей что повлечёт за собой изменений требований к среде запуска готового проекта)

- удобство при вводе в проект новых участников

Если в проекте есть документ, описывающий архитектуру приложения – спецификацию сред можно включить в этот документ. Либо приложить к спецификации требований. Либо оставить как отдельный документ. Но, в любом случае, спецификацию сред стоит написать