Сообщений в теме: 7

[YuP]

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

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

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

А вот какой подход использовать для организации стадии исследований и разработки макетов?

[Green]

Размер имеет значение!


Нет! Это не про то, что вы подумали, а про размер компании. Процессы - это механизм снижения производственных издержек в крупной компании. Я читал, что предел для трехуровневой системы управления (директор, руководитель подразделения, руководитель группы) составляет примерно 200 сотрудников. В более крупных компаниях количество управленческих уровней должно расти с ростом количества подчиненных.

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

Если в Вашем случае речь не идет о налаживании процессов в масштабах крупной компании, то лучше ориентироваться не на сертифицированный по международным стандартам процесс, а на набор зарекомендовавших себя практик (best practices). Их легко выделить в отдельную задачу, легко написать инструкцию, легко начать применять на пилотном проекте и легко объяснить другим выгоду от его использования.

Самый простой вариант - собраться проектной командой (или ПМ-ами и ведущими специалистами проектов) и решить, какие именно приемы наиболее полезны (зарекомендовали себя в других проектах, в которых принимали участие участники ). Если прием или практика получает большинство голосов (или по другому принципу), то назначают ответственного, кто должен описать набор шагов по применению практики (как это было в его случае). После этого практика или прием применяется в проекте на протяжении 3-х месяцев. Если по истечению этого времени практика приживается, ее вносят в реестр практик и она становится обязательной для всех проектов. Если нет, то от нее отказываются. За один раз лучше не пробовать применить более 3 практик.

Улучшение процессов - это не разовая операция (как многие пытаются это представить). Это постоянный процесс, при чем кто-то должен за него отвечать (драйвить, проводить регулярные собрания, обсуждения, отслеживать результаты и т.п.).

Если же Вам непременно нужен какой-то описанный процесс, то, на мой взгляд, может подойти методика MSF (microsoft solution framework). В настоящий момент уже имеются два варианта процесса - классический, построенный на ролях и документации, и облегченный (т.н. agile MSF). К продуктам компании Майкрософт он отношения не имеет, а может быть реализован на для любого проекта на любой технологии. Но для поддержки своего процесса Майкрософт выпустила тул - Team foundation server, позволяющий координировать работу и задачи проектной команды на базе шаблонов процесса MSF. Можете попробовать работать с ним.

[YuP]

Спасибо за столь подробный ответ.

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

Хотя.. наверное все-таки по другому не получится поступить. Попробуем обобщить удачный опыт собственных прошлых разработок.

Еще раз спасибо.

[Green]

Очень интересная задача. Как-то сам для себя собирал все в кучу, что бы при 20% усилий было 80% улучшений. Получилось примерно следующее.

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

Практика "разработка":
- коллективное обсуждение технологических решений (тот, кто принимает решение, должен хотя бы обосновать - почему он принял именно такое решение);
- тоже самое и про архитектурные решения - лучше всего организовать что-то типа защиты;
- применение юнит-тестирования;
- применение ревью кода (хотя бы раз в неделю, на два часа разработчик садятся с продвинутым разработчиком и рассказывает, что и как он напрограммировал, выслушивает мнение и замечания)

Практика "тестирование":
- это можно взять на моем сайте из моего доклада на РИТ2007

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

Практика "Коллектив":
- проведение еженедельных семинаров, подготовленных силами проектной группы, по любой профессиональной теме или по проекту
- периодические вылазки всей компанией (в кино, "на шашлыки" и т.п. - кстати, можно и в рабочее время, если нет большой загрузки)

Может быть еще что-то. Писал по памяти, мог что-нибудь и упустить.

[yamayka80]

Практика "тестирование":
- это можно взять на моем сайте из моего доклада на РИТ2007

Дайте ссылку, пожалуйста.

[Green]

Практика "тестирование":
- это можно взять на моем сайте из моего доклада на РИТ2007

Дайте ссылку, пожалуйста.

Силь ву пле, в подписи.

[yamayka80]

Силь ву пле, в подписи.

Виновата, сразу не заметила

Спасибо!

[nata_mish]

не знаю, на сколько еще актуален вопрос, но попробую ответить.
Раз с самого начала все требования у вас не ясны и приходится изначально много анализировать, чтобы понять, то не стоит ли вам попробовать методологию Agile? которкие итерации (недели 2), для которых определяется скоуп (определенный набор требований), разрабатывается и тестируется.. и так каждую итерацию.. Такой подход не будет требовать от вас всецелого единовременного анализа.