Здравствуйте, <Аноним>, Вы писали:

А>Стоит задача упорядочить процесс разработки программного обеспечения.
А>Проблема в том, каждый месяц заказчики предлагают новые идеи которые надо реализовать (эта ситуация будет продолжаться и в будущем, такова специфика работы). В результате на данный момент разработка программного обеспечения сводится к тому что 3 программиста пишут код и один руководитель распределяет обязанности. Код не документируется, не применяются системы тестирования, нет единого стиля кодирования, программисты имеют чрезвычайно поверхностное представление о ООП и дизайне. В добавок предстоит набор на работу студентов, которые не имеют серьезного опыта работы.
А>Все это необходимо разрулить.
А>На данный момент предполагаю предпринять следующие меры:
А>0) выработать общий стиль кодирования
А>1) обязательное документирование нового кода, и постепенное документирование старого
А>2) ознакомить людей с design pattern-ами, и потребовать чтобы постепенно сотрудники осваивали их
А>3) периодически проверять как сотрудники применяют pattern-ы
А>4) важные модули разрабатывать самому

А>По вашему мнению какие меры надо предпринять для улучшения ситуации, как поставлен процесс у вас?

А>P.S. Пожалуйста не предлагайте вариант всех разогнать и набрать супер спецов и и ввести RUP.

ИМХО.

Лирическое отступление.

Есть два подхода к облагораживанию парка. Первый — это поставить заборы, расставить указатели, перекопать протоптанные тропинки и сделать красивые аллеи. Второй — это заасфальтировать уже существующие тропинки и поставить вдоль них урны и лавочки. В первом случае вам может не хватить времени и денег, а тропинки всё равно появятся. Вполне вероятно, вам будет достаточно второго, причём сделать из него первый будет уже гораздо проще...

Вступление.

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

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

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

План действий.

1. Создание артефакактов

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

— Требования. В данном наборе документов нужно перечислить задачи, которые вам ставит заказчик, и для каждой задачи кратко описать основные требования заказчика (функциональные). В данном разделе можно создать небольшой документ, в котором описать основные нефункциональные требования.
— Архитектура проекта. Здесь нужно описать общее видение проекта, сделать грубую функциональную модель, описать основные технологические принципы построения программного обеспечения и технологии, которые предполагается применять.
— Технический проект. Здесь рекомендуется описать основные сервисные составляющие системы (написанные вами библиотеки, постоянно используемые технологические приёмы, сервисные классы и т.п.). Данный документ можно проработать достаточно глубоко, поскольку использоваться он будет как справочник. Также можно даже попробовать средства автодокументирования кода для создания чего-то вроде help-а, потому что этот документ будет использоваться дальше как справочник.
— Модель процесса разработки. Этот документ достаточно простой — здесь нужно кратко описать, какие процессы у вас в разработки задействованы и какие данные поступают на вход этих процессов, а какие на выход. Например, вы указываете процесс "формирование требований". На входе этого процесса у вас есть устные пожелания заказчика, а на выходе документ "Требования". Также, например, можно описать что разрабатывается в модуле и в какой последовательности (например, сначала модель предметной области, потом структура БД, хранимые процедуры, параллельно модель классов, далее кодирование классов, интерфейсы, тестирование отдельных классов, общая сборка и тестирование, деплоймент...). Причём желательно описать это достаточно кратко (можно хоть в Visio нарисовать прямоугольничками), но должно быть чётко указано, что поступает на вход каждого процесса, а что из него выходит (документы, устные сведения, код и т.п.). Это даст вам возможность отслеживать, какой модуль на какой стадии находится, а также возможность осуществлять минимальное планирование. Кстати, не обязательно все этапы должны быть пройдены всегда — в некоторых случаях часть процесса может быть пропущена. Главное здесь, чтобы разработчик знал, что он получит в качестве условий задачи и что должен породить (передать дальше).

2. Формирование операционной среды

Под операционной средой я понимаю ту инфраструктуру, которая обеспечит разработчику всё необходимое для того, чтобы он работал и не отвлекался. Сюда входит:
— среда(ы) разработки (если есть возможность, то лучше свести всё к одной среде);
— средства поддержки версионности и совместного использования кода (как пример — SourceSafe). Здесь, кстати, надо хранить и все документы;
— средства обеспечения отказоустойчивости разработки (систему резервного копирования и восстановления операционной среды)

Кстати, резервное копирование очень простая и важная штука... Она позволяет ощутить устойчивость. На первых порах можно остановиться хотя бы на 3-х вещах: backup дисков на машинах разработчиков (например, Norton Ghost), автоматизированный backup БД и автоматизированный Backup исходников кода системы и документов (например, бэкапить базы SourceSafe при помощи утилиты Backup32 — в ZIP, а потом на другой винт, CD или DVD)

3. Структурирование команды

Здесь сложно чего-то говорить не зная вашей специфики, но всё же... Если есть возможность, то я бы советовал разделить разработчиков "горизонтально" по специализации. Т.е. кто-то в основном занимается БД, кто-то в основном пишет интерфейсы, кто-то классы предметной области, кто-то системную и коммуникационную часть и т.д. Жёсткой специализации делать не нужно — теряете взаимозаменяемость, но вот мягкая даёт следующие преимущества:
— появление в команде явных технологических лидеров-экспертов по направлениям;
— появление "контрактных" отношений (СУБД-шник придумывает документы типа описания заказа на структуры данных и процедуры, писатель классов предметной области договаривается "документально" с интерфейсником и т.п.). Таким образом появляется потребность создавать артефакты более низкого уровня, нежели "архитектура" и "техпроект", что само по себе хорошо. Почему? Потому что при дальнейшем приближении к артефактам той или иной методологии люди уже не будут задумываться — что им писать, а будут только изучать "в каком формате" им это делать, а это уже несоизмеримо легче.
— более простое управление вновь прибывшими в команду разработчиками. Каждый специалист может брать шефтсво над вновь прибывшим, если тот также принимается на специализированную должность или над той частью обучения и контроля новичка, которая находится в ведении специалиста.
— повышение ответственности каждого конкретного специалиста за содеянное своими руками, поскольку теперь из-за него могут замедлится коллеги и пострадать целый проект. Это даст более ответственное отношение к срокам и качеству кода, а также халтура будет видна лучше.

4. Фиксация окружения

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

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

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

5. Формирование процедур управления

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

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

Также можно ввести устную беседу с каждым разработчиком по вечерам, выясняя, что он сделал и что собирается делать автра. Только не надо вводить всякой отчётности типа документов "что я сделал за день". Почему не надо — я уже писал где-то в форуме "о работе". Если нужно — найду ссылку.

--
Вот, вкратце такой набор мер. Думаю, что у вас на это может уйти несколько месяцев (от 2-х до 4-х). В результате вы не только сможете получить некоторое упорядочивание в своём проекте, но и подготовите почву для дальнейшего применения более тяжёлых методик (если это будет необходимо). Также за это время вы поймёте, что вам действительно нужно (какая методика), сможете приучить своих людей к структурированному, а не хаотичному, ведению проекта и увидите многие слабые места.


Если я не прав, то старшие товарищи меня поправят.