• 1. С чего начать?
• 2. Назначение задач и контроль хода выполнения
• 3. Анализ требований и управление изменениями
• 4. Управление рисками
• 5. План проекта
• 6. Документ "Техническое задание"
• 7. Планирование и документирование совещаний

Google Meet для лекций и семинаров: https://meet.google.com/hog-ybdm-sxi

1. С чего начать?¶

1.1 Первым шагом менеджер проекта должен создать себе задачу "Управление проектом".
Эта задача длится весь проект и предназначена для трекинга мелких и рутинных задач, как то: подготовка Vision, создание и назначение задач,
проверка результатов выполненных задач, ревизия плана работ, подготовка к совещаниям и т.д.

1.2 Работа над проектом начинается с формулировки Vision (Видение, с ударением на первый слог).

1.3 Менеджеру проекта необходимо разместить Vision в карточке проекта в redmine (Settings->Information->[Description]).

1.4 Следующим шагом менеджер проекта должен раздать участникам проекта задачи (Task) на анализ требований (см. разделы 2 и 3 ниже).

2. Назначение задач и контроль хода выполнения¶

2.1 В целях контроля хода выполнения всех видов проектных работ, а также учета времени, потраченного на их выполнение, используется трекер "Task".

2.2 Любая деятельность участника в рамках проекта, как то:

• анализ требований
• анализ рисков
• управление проектом
• разработка архитектуры
• кодирование
• тестирование
• документирование
• и т.д

осуществляется в процессе выполнения какой-либо задачи (трекер "Task"), в которой данный участник проекта является Исполнителем/Assignee.

2.3 Создание и назначение задач осуществляется участником проекта с ролью Manager в момент, когда задачу планируется начинать.
Не стоит создавать в редмайне все задачи из плана работ сразу, т.к план работ может меняться по ходу выполнения проекта, а правка иерархии
задач в редмайне далеко не столь проста, как в MS Project.
Статусы трекера "Task" и переходы между ними описаны в документе Роли в проекте, трекеры и статусы.

2.4 Постановка задачи должна соответствовать критериям SMART
Обязательно заполните поля Start Date/Дата начала, Due Date/Дата завершения, Estimated Time/Оценка трудозатрат и Description/Описание.

2.5 Исполнитель, получивший задачу, должен установить соответствующий статус задачи (см. Роли в проекте, трекеры и статусы ).

2.6 В процессе выполнения задачи исполнитель вносит в задачу фактические трудозатраты.
При завершении задачи Исполнитель устанавливает статус "Resolved", что является сигналом постановщику задачи на верификацию результатов.

2.7 Постановщик задачи производит приемку результатов и устанавливает либо статус "Closed", что соответствует принятой задаче, либо статус
"Feedback" с указанием замечаний в комментарии.

2.8 Процент выполненности задачи (% Done) рассчитывается автоматически на основании статуса.

2.9 Пример:
Два аналитика занимаются анализом требований к системе, и мы хотим разделить между ними работу следующим образом:
один будет составлять требования к роли "Админ", другой - к роли "Пользователь".
При этом, третий член команды (напр. Архитектор) будет активно участвовать в обсуждении этих требований с обоими аналитиками.

Для учета этих работ менеджер проекта может создать три задачи:
- для Аналитик 1 : задача "Анализ требований к роли "Админ"
- для Аналитик 2 : задача "Анализ требований к роли "Пользователь"
- для Архитектор : задача "Обсуждение требований с аналитиками"

Все трудозатраты на анализ требований и на их обсуждение аналитики и архитектор вносят на эти задачи (не на требования).

3. Анализ требований и управление изменениями¶

3.1 Требования документируются в редмайн в виде трекеров "Requirement" (см. например требование #2040) и создаются аналитиком в ходе выполнения задач(и) по анализу требований.
Статусы трекера "Requirement" и переходы между ними см. здесь
Каждое требование должно быть назначено участнику проекта с ролью Analyst, который будет отвечать за анализ и конечную формулировку требования.
Назначение осуществляется указанием участника в поле Assignee/Исполнитель.
Возможно и создание требований самим аналитиком, в этом случае он должен сам назначить их на себя.

3.2 Описание требования должно быть предельно конкретным и не допускать противоречивых толкований.
Например, следующее требование

Название: Логин
Описание: Нужно реализовать вход пользователя в систему

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

Название: Авторизация пользователя
Описание:
1. Неавторизованный пользователь может осуществить вход в систему через ссылку Login в правом верхнем углу экрана одним из нижеперечисленных способов:
1.1 путем ввода логина и пароля
1.2 авторизацией через социальную сеть Facebook
1.3 авторизацией через социальную сеть VK
2. В случае неуспешной авторизации (несуществующий логин или неверный пароль) форма ввода логина/пароля очищается, над формой выводится сообщение:
Неверный логин и/или пароль

см. также примеры требований в проекте project:pmdemo

3.3 В описании требований можно использовать plantUML с тем отличием, что вместо "@startuml" нужно использовать "{{plantuml(png)", а вместо "@enduml" - "}}".
см. пример в требовании #2040

3.4 ВАЖНО: Требования в статусе "Анализ завершен" переносятся в текст ТЗ в неизменном виде, поэтому если требования в ТЗ вы собираетесь описывать в форме юзкейзов
по кобурновской форме (как в шаблоне ТЗ), то используйте эту же форму для представления требований в редмайн.

3.5 В процессе идентификации и обсуждения требований необходимо выявить и задокументировать термины предметной области,
используемые в описании требований (см. например термины Visitor, System, role в описании требования #2040).

Redmine предоставляет очень простой способ создания опиcаний терминов: если в процессе написания текста требования мы видим,
что использованное слово является термином предметной области, это слово нужно взять в двойные квадратные скобки,
тогда после сохранения текста для выделенного квадратными скобками термина будет автоматически создана
(если она еще не была создана ранее) страница в Wiki, на которую можно тут же перейти и внести описание термина.

Для понимания текста обычно вполне достаточно сделать ссылкой на Wiki первое вхождение термина в текст.

Пример описания терминов см. здесь

Полное описание тегов для форматирования текста в redmine см. здесь

3.6 Также, для обсуждения требований можно использовать форум проекта.
Форум создается участником с ролью Manager (см. Settings->Forums)

3.7 Не стоит пытаться сделать "требования" подзадачами задачи "Анализ требований", как и наоборот, не стоит делать задачи по реализации требования его же подзадачами.
Во-первых, это бессмыслица, т.к "требование" - это артефакт (результат) процесса, но не сам процесс и не его часть.
Во-вторых, "требование" может быть связано с несколькими задачами. Например, в рамках одной задачи требование было
проанализировано, в рамках другой - реализовано, а в рамках третьей - протестировано.
Равно и наоборот, в рамках одной задачи может быть реализован компонент, учитывающий несколько различных требований.
Таким образом, связи между требованиями и задачами, в общем случае, имеют тип "многие-ко-многим", что нереализуемо в рамках иерархии задач.
Для связывания требований и задач лучше использовать двунаправленную ассоциацию, которая в redmine реализуется через "Related issues".
Например, в задаче #2048 мы видим ссылку на созданное в процессе выполнения этой задачи требование #2040,
а в требовании #2040 мы видим не только #2048, но и прочие связанные с этим требованием трекеры, например задачу #2056 по реализации UI для данного требования,
а также риск #2070, который оказал влияние на данное требование.

3.8 Не стоит создавать на "требования" отчеты о трудозатратах.
Во-первых, как было сказано выше, "требование" - это артефакт (результат) процесса, но не сам процесс, а трудозатраты возникают в процессе выполнения работ.
Для учета времени, потраченного на выполнение работ, должен использоваться трекер "Task" (см. пункт 2.1 и пример в пункте 2.9)
Во-вторых, требования могут быть в проанализированы на этапе ТЗ (версии 0.1) проекта, а реализованы на этапе Реализация (версия 1.0), а затем переделаны в версии 2.0.
Если вы свяжете с ними трудозатраты, например, на анализ требования, а затем перенесете требование в другую версию проекта (в которой предполагаете его реализовать или изменить),
то требование "переедет" в новую версию вместе со своими трудозатратами из прошлой версии, что неоправданно усложнит вам анализ трудозатрат по этапам проекта.

3.9 Управление изменениями

3.9.1 Требования, к реализации которых команда проекта уже приступила, получают статус "Implementation". Статус устанавливается менеджером.

3.9.2 Полностью реализованные требования получают статус "Implemented". Статус устанавливается менеджером.

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

3.9.3.1 Достаточно часто возникает необходимость внести незначительные изменения в процессе реализации, которые не оказывают существенного влияния на объемы и сроки работ.
В этом случае часто используют термин "уточнение" (vs. "изменение"), и описание требования просто корректируется без измененения статуса.

3.9.3.2 Более существенные изменения требуют специальных процедур, и здесь возможны два варианта развития событий:

- Команда еще не приступала к реализации требования (статус "Analysis Completed")
- Требование находится в процессе реализации или, что хуже, уже реализовано (статусы "Implementation" и "Implemented").

Очевидно, что второй вариант более сложен, т.к, в этом случае, часть уже выполненной работы точно придется переделывать, что чревато срывом сроков.

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

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

При необходимости согласования изменений с Заказчиком, возможен также перевод требования обратно в статус "Analysis".

Обычно, сама возможность изменения требований зафиксирована в проекте как риск еще на этапе Техническое задание (см. пример #2070 в проекте project:pmdemo).
Если этого не было сделано, но риск случается на этапе Реализация, то стоит добавить в проект этот риск с типом "Unexpected",
и зафиксировать в описании риска план устранения последствий (см. пункт 4.6 ниже).

3.9.4 Пример:
В проекте project:pmdemo имеется требование #2040 в статусе "Implementation".
Это требование было измененено по ходу реализации в результате срабатывания риска #2070, о чем имеется запись в описании риска.

4. Управление рисками¶

4.1 Риски документируются и обсуждаются командой проекта в редмайн в виде документов с трекером "Risk" (см. например риск #2070).

4.2 Статусы трекера "Risk" и переходы между ними описаны в Роли в проекте, трекеры и статусы.

4.3 См. также презентации лекций по анализу рисков

4.4 На этапе Техническое задание очень важно идентифицировать ключевые риски, т.к выбор стратегии управления риском и плана устранения последствий существенно влияет на бюджет и сроки выполнения проекта.
На этом этапе идентифицируются риски двух типов: "Known" и "Unknown".

4.5 На старте этапа Реализация все ранее идентифицированные риски находятся в статусе "Analysis completed" и в поле "Assignee"/"Исполнитель" указан участник проекта, ответственный за мониторинг состояния риска.
Задача ответственного состоит в отслеживании текущего состояния риска и своевременном информировании менеджера проекта о том, что риск произошел (пора включать план устранения последствий), либо об изменении жесткости риска.

4.6 При срабатывании риска ответственный устанавливает статус "Triggered".
Срабатывание риска подразумевает запуск на исполнение плана устранения последствий.
В графу "Состояние дел" вносится текущее положение дел с риском: какие не предусмотренные планом задачи пришлось создать,
какие требования были изменены или созданы (см. пример в риске #2070).
По окончании процесса устранения последствий риску устанавливается статус "Closed" и одновремено фиксируется реальное влияние риска на проект в поле "Actual Risk Impact".

4.6.1 NB Некоторые риски могут срабатывать несколько раз!
Если риск относится к этой категории, т.е ваши действия по устранению последствий не гарантируют, что риск не повторится еще раз до окончания текущей фазы проекта, то закрывать его, конечно не стоит.

4.7 На этапе Реализация могут происходить риски, которые не удалось предвосхитить на этапе "ТЗ" или до момента, когда риск проявил себя.
Эти риски вносятся в систему управления проектом по факту возникновения и имеют тип "Unexpected".
У таких рисков по определению не может быть действий по сдерживанию, но план устранения последствий должен быть определен в момент возникновения.

4.8 К концу проекта все риски находятся либо в статусе "Mitigated" (риск не произошел благодаря стратегии управления), либо в статусе "Closed" (риск все-таки произошел, прошел через статус "Triggered", и последствия устранены). У рисков в статусе "Closed" должно быть заполнено поле "Actual Risk Impact", отражающее объем работ в ч/часах, который пришлось выполнить ввиду срабатывания риска.

5. План проекта¶

5.1 План проекта разрабатывается в Microsoft Project или любом другом ПО, поддерживающим работу с Гантт диаграммами.
Например, ProjectLibre .

5.2 При разработке плана можно воспользоваться шаблоном для Microsoft Project, или для ProjectLibre .

5.3 План проекта в обязательном порядке содержит:
а) Все работы, выполненные по факту в процессе разработки ТЗ (для УИТП) или к моменту составления плана (для КРПО)
б) План дальнейших работ (план этапа Реализация для УИТП, или до конца семестра для КРПО)

5.4 У всех задач плана работ должны быть заполнены колонки Duration/Длительность и Work/Трудозатраты

5.5 Чтобы иметь возможность независимо редактировать поля Duration и Work задачи, нужно:
а) установить в 'Task Information'->[General] опцию 'Schedule Mode'='Auto Scheduled'
б) установить в 'Task Information'->[Advanced] опцию 'Task Type'='Fixed Work'
в) Можно установить эти опции по умолчанию для всех новых задач через меню 'File'->'Options'->[Schedule] (в шаблоне плана это уже сделано)

5.6 См. также презентации лекций по планированию

6. Документ "Техническое задание"¶

6.1 Документ "Техническое задание" разрабатывается на основе шаблона в формате DOCX (MS Word).

6.2 Требования, собранные на этапе Техническое задание, переносятся в текст документа "Техническое задание" в неизменном виде.

6.3 Хорошей практикой является систематический подход к именованию файлов документов.
Например, имя файла Название проекта.Техническое задание.docx заведомо лучше, чем Мой ТЗ.docx.

При необходимости версионировать файлы, например, в случае отправки Заказчику через email, имя файла
Название проекта.Техническое задание-1.0.5.docx заведомо работает лучше, чем Мой ТЗ.новый.docx или Мой ТЗ.последний.docx.

6.4 Итоговый документ размещается в хранилище "Документы" вашего проекта в redmine.

7. Планирование и документирование совещаний¶

7.1 Для планирования и документирования совещаний используется трекер "Meeting".

7.2 Статусы трекера "Meeting" и переходы между статусами см. здесь

7.3 При создании совещания в поле "Description" вносится повестка (краткий список тем для обсуждения).

7.4 При закрытии совещания (статус "Closed") в поле "Description" под повесткой документируются результаты (принятые решения по пунктам повестки).
Не стоит недооценивать важность документирования результатов.
Во-первых, через пару недель вы сами забудете половину принятых ранее решений.
Во-вторых, документирование позволяет ознакомиться с принятыми решениями тем членам команды, которые не смогли принять участие в совещании.
В-третьих, даже краткое текстовое описание способно значительно уменьшить влияние основной проблемы вербальной коммуникации: когда двое "договорились", но каждый понял по-своему.

7.5 Время, потраченное участниками совещания, вносится в трекер "Meeting" так же, как это делается в задачах.

7.6 Примеры документирования совещаний см. в project:pmdemo : #2052, #3880