Sunday, November 26, 2006

Жизнеобеспечение проекта. Часть 3.

Про обещанного аналитика, и еще про технолога.

Предыдущие части: Часть 1 (введение), Часть 2 (про службу поддержки).

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

Кликните по картинке для увеличения

Аналитик анализирует новый требующийся функционал (check function overview) и возможные технические проблемы проекта (check possible bug), выявленные пользователями и службой поддержки. Т.е. неформализованную информацию из Help Desk. На основе этого он составляет технические задания (technical project) для разработчиков. ТЗ, как и вся информация по проекту, складывается в Wiki. Задания разработчикам записываются в Bug Tracking со ссылками на источник задания в Help Desk и на ТЗ в Wiki.

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

  • Если в проекте есть закрепление модулей за разработчиками, то роль аналитика заканчивается на принятии решения, в какой модуль проекта будет встраиваться новый функционал. Это возможно, когда за каждый модуль отвечает
    • один разработчик,
    • команда, возглавляемая ведущим разработчиком (который принимает решения по реализации функционала внутри модуля),
    • команда, сама принимающая решения (например Agile team).
  • Если же в проекте нет явного закрепления модулей за разработчиками, то аналитик пишет детальное ТЗ для конкретных разработчиков, с детализацией вплоть до интерфейсов классов.
  • Если для реализации нового функционала принимается решение использовать новые технологии или появляется область задач, ранее в проекте не реализовывавшаяся, то на аналитике лежат задачи по сбору информации по нововведению и по обеспечению разработчиков справочными материалами и рекомендациями к реализации.

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

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

    Кликните по картинке для увеличения

    Технолог – главный специалист в своей предметной области (subject area). Он работает на неформализованном уровне проекта. Всю информацию, которая требуется для решения конкретной задачи технолог кладет в Wiki и ставит на нее ссылку из Ticket-а Help Desk.

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

    В следующей части - Project Manager.

    В начало


    technorati tags: ,

    5 comments:

    Anonymous said...

    Ну и диаграммы юзкейсов! Чесслово понять что-то сложно. А вот чего я действительно НЕ ПОНЯЛ, так это как может быть generalization от check possible bug к possible bug!!! Что такое possible bug вообще? Это СУЩНОСТЬ?

    Elena Makurochkina said...

    Уважаемый Anonymous, «possible bug» - это возможный баг (проблема) приложения. Собственно ведение проблем, возникающих у пользователя, это основное предназначение Help Desk-а. Подробнее о «первой линии» взаимодействия с пользователями было описано во 2-й части Жизнеобеспечения проекта. Основная же роль аналитика в использовании Help Desk-а – проверка возможных багов (а возможные они потому, что тех поддержка, которая ведет взаимодействие с пользователем, не может точно сказать баг это или нет) и выдача решений по багам. Т.ч. собственно «check possible bug» (проверка возможных багов) и «possible bug solution» (решение по багам) относятся к обобщенному варианту использования «possible bug».

    Anonymous said...

    Хм, варианты использования, суть именованные цели эктора по отношению к scope. Не понятна мне физика обощенного варианта использования "Possible bug". Или он назван не верно, или не верно выделен этот самый обощенный ВИ, или "одно из трех" :-). Да и ваше пояснение, говорит о том, что по сути Possibble bug -- это больше сущность, а оннюдь не цель эктора. Исходя из этого и возникает непонимание, насколько корректно такое наследование, с т.з. логики использования ВИ. Интересно увидеть сценарий этого обощенного ВИ ...

    Anonymous said...

    В дополнение ... все-таки думаю это некорректное наследование. Да и не понятно, что является "видимым для эктора" результатом ВИ «check possible bug»? Название характеризует скорее процесс чем результат. Да и «check possible bug» + «possible bug solution» больше похоже на функциональную декомпозицию. Думаю более корректным было бы просто определение ВИ как "resolve problem", суть которого, что аналитик все равно "вступает в игру" при невозможности решения техсаппортом проблемы. И дает либо workaround, либо признает это багом и готовит shange request. Что-то в этом духе. И диаграмма бы стала гораздо проще и семантика сохранена. Думаю, что это справедливо и для других диаграмм.

    Anonymous said...

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