Управление проектами - статьи

         

Планирование реализации требований


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

  • Определите размер итерации

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

  • Определите объем занятости в человеко-часах на каждую итерацию

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

    4 часа в день * 2 недели * 5 дней * 2 разработчика =
    80 человеко-часов на итерацию

    Поспешу заверить, что это не так уж мало, как может показаться

  • Планируйте время на выполнение каждого требования



    Такие оценки следует доверить разработчику - он лучше всех представляет, сколько времени может потребоваться на реализацию каждого требования. Не спланировав время на выполнение требований, невозможно спланировать итерацию
  • Фиксируйте время, на самом деле потраченное на реализацию каждого из требований

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

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


    1. Список лиц, утверждающих и согласовывающих документ;
    2. Общее описание документа и его предназначения;
    3. Описание ролей участников процесса (Заказчик, разработчик). Стоит описать, какие решения принимает каждый из участников и общий характер взаимодействия участников;
    4. Пошаговый порядок взаимодействия участников процесса;
    5. Перечень разрабатываемых артефактов.


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

    Результатом процесса должны стать утвержденные требования к системе, с указанием планируемых трудозатрат, с расставленными приоритетами и распределенные по итерациям.
  • Определите список заинтересованных лиц для каждого проекта

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

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



    Если версии не доходят до заинтересованных лиц, нет смысла в их частом выпуске
  • Добейтесь участия в процессе всех заинтересованных лиц

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

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

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

    В вышеуказанной инструкции опишите, что должно выполняться в следующих случаях:


    1. Сокращено время проектной занятости группы разработки на текущую итерацию
    2. Заказчик изменяет приоритет требований
    3. Заказчик изменяет состав требований


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

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

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

    Направления улучшения данного процесса:


    1. Ввести более или менее формальную процедуру оценивания заказчиком продукта.
    2. Фиксировать отзывы заказчика о продукте
    3. Определить, как будет учитываться время на организацию работы, выяснение деталей реализации, совещания и т.д.



    Содержание раздела