IT-Project Management

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

Archive for Март 2008

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

leave a comment »

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

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

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

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

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

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

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

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

Реклама

Written by Артур К.

Март 30, 2008 at 21:39

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

Tagged with

Phishing

leave a comment »

На днях делал доклад по этой теме (см. тему поста) для всех желающих в родном институте (СПбГПУ). Выкладываю презентацию, по которой делал доклад.

Ничего принципиально нового, но содержит интересные моменты. Выделяются типовые сценарии атак, рассматриваются приемы достижения целей, есть различные статистические данные, примеры phishing-сообщений и рекомендации по организации защиты.

Вот ссылка на сам доклад: Phishing_By_ArturK.

Written by Артур К.

Март 29, 2008 at 8:19

Переход от концепции к проектированию

with one comment

Любой проект начинается со стадии выработки концепции, когда определяются основные цели и требования проекта. Здесь же обычно проводится куча исследований предметной области. Чем лучше на стадии выработки концепции будет разобрана предметная область, тем легче пройдет проектирование.

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

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

А теперь проблема. Исследования протоколов коммутации проводились неоднократно. Они начались, как только стало понятно, что придется анализировать трафик. Были выделены и разобраны конкретные протоколы, порты, типы сообщений и т.д. (все вплоть до конкретных пакетов). А когда дело дошло до проектирования, мы застопорились на одной простой вещи, которая имела принципиальное значение для контроля коммутации: ни кто не смог ответить на вопрос: «Может ли вот этот конкретный тип устройств инициировать новый сеанс обмена данными?». Выяснилось, что ни в одном RFC или каком либо другом стандарте ответа на этот вопрос нет. Необходимо либо проконсультироваться с производителями этого типа устройств, либо взять это устройство и поэкспериментировать с ним два-три дня.

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

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

Written by Артур К.

Март 27, 2008 at 8:50

О пользе итеративной разработки

leave a comment »

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

Планирование 

Два аспекта процесса итеративной разработки, которые в разы облегчают составление календарного плана или любого другого графика работ:

  1. Каждая итерация подразумевает законченный и протестированный прототип разрабатываемой системы.
  2. Длительность итерации — это константа.

Если оба этих правила выполняются, то к завершению фазы проектирования можно составить довольно точный календарный план, который будет подробно описывать весь процесс реализации проекта вплоть до этапа сдачи. Конечно, все зависит от объемов работ и самого проекта, но, по крайней мере, точные сроки разработки спроектированных частей системы (+/- 2 итерации) можно высчитать без гадания на кофейной гуще.

Назначение заданий

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

Оценка результатов

Длительность итерации выбирается, как правило, небольшой — от нескольких дней до двух недель (редко месяц). За это время каждый член команды успевает выполнить ряд небольших, вполне конкретных задач. В конце каждой итерации мы имеем законченный «state». Вот и все, что нужно для оценки текущих результатов проекта. Обсуждая новый билд, новые функции и баги, результаты исследований и разработанные документы можно легко оценивать продуктивность работ, сверятся с планом или графиком, составлять отчеты и т.д.

Итого

У себя на работе я активно продвигаю идею итеративной разработки. Конечно, до UP еще пока далеко, но уже то, что есть на данный момент приносит свои плоды. Все описанные плюсы были мне далеко не очевидны, поскольку раньше я занимался разработкой и не думал о «всяких там планах и графиках». А вот, как выяснилось, итеративный процесс удобен не только с точки зрения development`а, но и с точки зрения management`а.

Written by Артур К.

Март 24, 2008 at 0:45

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

Tagged with