Страница 3 из 8

Мы используем два подхода к разработке: классический водопад (с план-графиком и MSProject), и модный сейчас Agile (который мы используем уже 3 года).
Все проекты ведутся единым «проектным офисом» - в каждом проекте участвуют методологи, архитектор, разработчики, внедренцы, все специалисты различного профиля, которые в этом проекте могут понадобится. Работу по проекту координирует РП (руководитель проекта), а все преокты в целом – РПО (руководитель проектного офиса). Мы знаем кто, когда, чем занят, когда освобождается, и когда мы можем или не можем взять проект определенного типа.
Чуть ниже – таблица, которая примерно дает понять, в каких случаях какая методика применима. Есть несколько условий, которые мы соблюдаем в любом случае.

 

ВЕДЕНИЕ ПРОЕКТА  

  • Документирование требований и задач. Все фиксируем письменно.
  • Документирование хода проекта. Еженедельные статус-отчеты, протоколы встреч, актуализация плана.
  • Постоянное участие архитектора - следит за качеством кода, оптимальностью решений, соответствием того, что делают программисты, первоначальной задумке.
  • Постоянное участие методолога - следит за тем, чтобы все остальные поняли задачи бизнеса и решали их (а не "кодили всякие интересные штуки").
  • Управление проектом - это важная, регулярная, постоянная работа.

  • ТЕХНОЛОГИИ  

    • Продуманная архитектура, максимальное использование типового функционала
    • Высокий уровень разработки (оптимальный быстрый и чистый код)
    • Обновляемость (решения должны быть настолько обновляемыми, насколько это возможно)
    • Внутреннее тестирование

    • ВЗАИМОДЕЙСТВИЕ  

      • Команда проекта должна говорить на человеческом языке
      • Необходимо руководить не только собой, но и заказчиком
      • Заказчика необходимо вовлекать в проект с начала и до конца
Мы собрали несколько важных критериев — конечно, их больше. Но это то, на что мы всегда обращаем внимание, перед тем как предложить заказчику подход к разработке.
AGILE
Есть общее понимание требуемого результата (концепции, задач решаемых ИС), но сформулировать его детально – невозможно
Требования могут меняться в ходе проекта, и это нормально (проект должен это учитывать)
Бюджет на проект в целом – не выделен. Нужно распределять оплаты по периодам, и постоянно видеть результат каждой оплаты.
Заказчику нужно видеть хоть какие-то результаты как можно быстрее и чаще
Заказчик не может гарантировать скорость реакции со своей стороны в ходе всего проекта. Возможны задержки, вызванные текущими делами: выставками, командировками ЛПР, и так далее


 

WATERFALL
Цели проекта полностью известны. Можно написать единое большое ТЗ – на весь проект.
Зафиксированные требования не меняются, или меняются незначительно.
Необходимо сразу понять бюджет, согласовать его на всех уровнях компании, утвердить и придерживаться
У проекта есть контрольные точки и этапы. Этого достаточно.
Со стороны заказчика выделен РП, который занимается проектом как основной работой. Он постоянно доступен, решает проектные задачи, обеспечивает быструю реакцию, и на время проекта никуда не уезжает.