IT-Project Management

IT-PM: Персональный блог об управлении IT-проектами

Мозговой штурм

leave a comment »

В нашем дружном коллективе разработчиков сложилась такая традиция: при проектировании наиболее сложных частей системы собирать группу из 2-5 разработчиков и устраивать мозговой штурм. На мой проект эта традиция распространилась в немного измененном виде. Поскольку разработка итеративная, проектирование новых модулей проводится раз в 2 недели (длинна итерации). На днях мне как раз предстоит очередной такой мозговой штурм. Все свои мысли по поводу стратегии (!) проведения этого мероприятия попытаюсь изложить ниже. А заодно и для себя все разложу, что называется, «по полочкам».

Итак, начать нужно вот с чего:

  • Четко обозначить границы проектирования.
  • Обозначить все интерфейсы с другими частями системы.
  • Просмотреть список требований на предмет того, что планируется учесть при проектировании. 
  • Обдумать и расписать обязанности проектируемых компонент.

Далее, в процессе обсуждения:

  • Не пытаться решить все проблемы одновременно: примерно через 10-30 минут можно составить список проблем, порожденных архитектурой, свойством системы, конкретным проектным решением и.т.д. Далее нужно брать по одному пункту из этого списка и решать только его. Все сразу продумать не получится. А если «штурмующие» начнут увлекаться, нужно сводить спор именно на ту проблему, которая решается в данный момент.
  • По каждой проблеме нужно рассмотреть как минимум 2 варианта решений. Лучше больше. Для каждого варианта обдумывать его преимущества и недостатки. А не порождает ли это решение новые проблемы? А не противоречит ли оно уже принятым решениям?
  • Если не получается принять решение в течение часа, то лучше сделать перерыв и переходить к следующему пункту. Можно будет вернуться к этой проблеме позже.
  • Скорее всего, часть проблем решить так и не получится. Причина в недостатке информации о проблеме. В таком случае решение по данному вопросу целесообразно отложить на следующую итерацию. В плане необходимо предусмотреть проведение исследований по данной проблеме.
    (Это кстати очень распространенная ситуация когда из-за недостатка знаний о предметной области принимается неверное решение, или ни одно из предложенных решений не кажется правильным. Мы с группой как-то потратили 3 часа, но так и не смогли придумать что-то стоящее. Про это я уже недавно писал тут.)
  • По поводу принятия решения… вопрос сложный. Тут могут быть варианты: либо решение принимается единогласно, либо принимается решение от наиболее компетентного в данной области проектировщика, либо в команде есть профессиональный архитектор, которые одобряет или отклоняет решения, либо какой-то другой вариант.

В завершении мозгового штурма:

  • Еще раз вернутся к списку проблем, и оценить все принятые/непринятые решения.
  • Самое время дать еще раз высказаться тем, кто категорически не согласен с тем или иным решением. (возможно, штурм будет продолжен)
  • Определить, кто задокументирует все принятые решения.
  • Отметить, какие требования будут реализованы каким компонентом.

Вроде все. Если что забыл, допишу позже.

Реклама

Written by Артур К.

Март 30, 2008 в 21:39

Опубликовано в Опыт управления

Tagged with

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: