Регламент разработки

Здравствуйте!
Пока работаешь один особо не задумывавшийся о организации своей работы как проектировавший, бизнес-аналитика и кодировщик.
Как только в разработку надо внедрить еще одного (2,3,4...) человека существует необходимость в синхронизации их деятельности. Я знаю, что для организации совместной деятельности нескольких человек используется специфическое программное обеспечение, которое координирует и обеспечивает коммуникации между членами команды разработки.
Опыт в команде есть но хотелось бы вывести его на качественно другой уровень. Поэтому думаю уместны следующие вопросы.
Как организовать деятельность небольшой (средней, большой) команды разработчиков? Как написать регламент (должностную инструкцию) каждому члену команды разработчиков? Как взаимодействовать с представителями заказчика (посредством какой документации)?
Пойдет все!!!
Статьи, ГОСТы, книги и личный опыт! Помогите пожалуйста!

0

Личный опыт, возможно некорректный. Но это так, как мы делаем.

При планировании работы все вместе проводим "мозговой штурм" задачи. Все аспекты, мнения и идеи обсуждаются открыто и подошедшие документируются. Затем вся эта красота делится на некие отдельные сущности-составляющие (интерфейсы, или модули, или вообще отдельные функции), оговаривается взаисодействие этих сущностей друг с другом (входные/выходные данные для функций, например), затем Большой Начальник (в пределах команды) раздаёт всем задачи, и все пишут свой код, отлаживая его в отдельных мелких программках. Возникают вопросы, сложности или другие заморочки - садимся и все вместе обсуждаем. Когда мелкие независимые подзадачи решены (всякие утилитарные функции и прочая мелочь) - берёмся за более крупные задачи, полагающиеся на эти мелочи. Потом, когда всё готово, вся эта красота собирается Большим Начальником воедино и коллективно тестируется на работоспособность. Когда кто-то обнаруживает косяк, - получает сникерс и описывает косяк: где и при каких обстоятельствах что ввёл, куда нажал и чем это всё закончилось. Составляется список косяков, мелкие косяки исправляются тут же, по крупным опять проводится всеобщий мозговой штурм и опять раздаются задачи. И так по кругу.

В итоге все занимаются всем и всё в курсе всего. Возможно, это абсолютно некорректно построено, но как умели

0

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

Рекомендую прочесть о ролях, выполняемых в процессе разработки. Как минимум, вот навскидку:
1. Менеджер проекта
2. Бизнес-аналитик
3. Системный аналитик
4. Архитектор
5. Проектировщик
6. Программист (девелопер)
7. Тестировщик
8. Технический писатель
9. Специалист по управлению конфигурациями и сборке проекта (configuration engineer)
9. Специалист по поддержке/внедрению

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

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

По моему личному опыту, самое лучшее "программное обеспечение" для координации и коммуникаций - это блокнот (нет, не Notepad, а тот самый блокнот, в котором пишут карандашом, ручкой или фломастером), чашечка кофе и круглый стол. Специальное ПО нужно, главным образом, для географически распределенных команд.
В любом случае, для хранения исходников (да и вообще любой долговременной документации по проекту) нужна система управления версиями - svn, git.... несть им числа, а также система отслеживания ошибок и запросов на изменения - bugzilla,, mantis.... также несть им числа. Для планирования нужен инструмент типа MS Project (ну, проджект для маленьких команд слишком тяжеловесен, но можно поискать и более простые аналоги - например, unix-образный Planner). В целом же, при выборе программных инструментов нужно учитывать сложившиеся корпоративные стандарты в компании (если таковые уже сложились, конечно....).

> Как организовать деятельность небольшой (средней, большой) команды разработчиков?

Гм. "Четыре основных правила менеджмента
1. Найти нужных людей.
2. Дать им ту работу, для которой они лучше всего подходят.
3. Не забывать о мотивации.
4. Помогать им сплотиться в одну команду и работать так дальше.
Все остальное — административная ерундистика."
(с) Том ДеМарко

Вот полезные книжки, почитай (все есть в электронном виде в Сети, гугл в помощь):

Архипенков Руководство командой разработчиков ПО.pdf
Архипенков Управление проектами.pdf
Берлинский Константин Набор серебряных пуль.pdf
Брукс Фредерик Мифический человеко-месяц.pdf
ДеМарко Том Deadline.pdf
ДеМарко Том Вальсируя с медведями.pdf
ДеМарко Том Человеческий фактор.pdf
Йордон Эдвард Смертельный марш.pdf
Орлов Технологии разработки ПО.pdf
Панкаж Джалота Управление программным проектом на практике.djvu
Рейнвотер Как пасти котов.djvu
Ройс Уолтер Управление проектами по созданию ПО.pdf
Фатрелл Управление программными проектами.djvu

А в остальном - практика научит. Хотя и шишек понабьешь порядочно. Опыт не приходит просто так. :-)

> Как написать регламент (должностную инструкцию) каждому члену команды разработчиков?

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

> Как взаимодействовать с представителями заказчика (посредством какой документации)?

Зависит от принятой технологии разработки ПО в компании. По любому, для разработки нужно хорошее Техническое задание прежде всего. ГОСТы групп 19, 34 (и, возможно, группы РВ 15) тут тебе помогут.
Если ты думаешь, что "взаимодействовать с представителями заказчика" у тебя получится посредством бумажек, то это ошибка. Нужно возможно теснее работать с представителями заказчика лично, стараясь вовлечь представителей заказчика в процесс разработки еще на самых ранних стадиях, чтобы не упустить те требования, которые являются ключевыми для заказчика, но - да! да! такое вполне возможно! - даже не отражены в официальных бумагах.

2