IT-Project Management

Фундаментальный труд, охватывающий сразу несколько аспектов разработки ПО. Я читал эту книгу довольно давно, перечитывал некоторые части много раз. Сразу оговорюсь, я читал 2-ое издание, но сейчас в продаже уже 3-е.

Первое, что я вынес для себя из этой книги – это представление о том, как должен выглядеть итеративный процесс разработки. В книге описывается UP. Причем описываются различные аспекты и виды работ: начиная от формирования первоначального видения проекта и описания use-case`ов, и заканчивая тестированием продукта.

В книге приведены наиболее распространенные шаблоны проектирования. Подробные описания и разъяснения, а также примеры применения шаблонов. И конечно же это отличный учебник по UML.

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

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

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

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

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

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

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

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

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

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

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