Как правильно делать проекты

Posted on января 18, 2008
Filed Under Microsoft, SharePoint, Разное

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

Вроде бы какие вопросы? Берем любой процесс (MSF, RUP, XP, …) следуем ему и все. Все этапы проекта описаны, артефакты тоже. В крайнем случае (или наоборот в первую очередь) берем 34 ГОСТ (например ТЗ) и смотрим какие документы должны быть и что в них должно содержаться.

Но где вы видели такую идеальную картину? Большинство средних и мелких фирм используют "доморощенные" процессы, поэтому вопрос "минимального набора" все-таки достаточно актуален.

На мой взгляд для разработки ПО такой список выглядит так:

Краткое описание бизнес-процессов (можно назвать основными бизнес-требованиями и бизнес-сценариями). Например в нотации BPMN.
Краткое ТЗ с основными функциями системы.
Верхнеуровневое описание архитектуры. Например в нотации UML 2.1
Хороший код. (Ибо зачастую это практически единственное, чему можно доверять). Соответственно постоянный рефакторинг, очень здорово если модульные тесты, комментируем все не очевидные моменты (но их должно быть как можно меньше). Используем средство построения документации по коду.

А для успешности проекта я бы в этот список добавил еще вот это:

Устав проекта (как приложение к договору с описанием проектной команды, способов эскалации вопросов и т.д.)
Методика тестирования (приемки) на стороне заказчика
Подписание всех ключевых документов с заказчиком
Использован протоколов встреч
Вовлечение бизнес-пользователей
Быстрый прототип и feedback

Это насчет управленческих подходов. А теперь немного технологического взгляда

MS совсем недавно (16.01) опубликовал очень хороший документ — SharePoint Products and Technologies White Paper: Implementing Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0 Solutions. Спасибо за наводку SharePointBuzz. Всего около 30 страниц на английском, но они стоят того чтобы их почитать.

Приведу цитату из документа:

In the last couple of months, several of our leading partners asked us for comprehensive guidelines on SharePoint Products and Technologies development, to enable them to better estimate the required effort as well as manage the new server. The aspects they wanted clear answers on are:

How to manage team development in MOSS large projects?

How to deploy content and code between development and production environments?

How to develop towards deployment in a remote hosted environment?

How to enable developers to participate in several projects at the same time?

This document outlines a methodology for team SharePoint development, customization and content authoring that aims at accelerating implementation and mitigates production risks.

To form the methodology, the document reviews implementation scenarios, tools and development environment.