С утра плохо работается, так что напишу пока здесь, как и обещал. Довольно большой текст получился, поэтому оформлен в виде отдельного поста.

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

Проект

Проект - это некая задача (в случае разработки ПО - программа), которую надо разработать в рамках ТЗ в определенные сроки. Как правило проектом становится выигранный ранее тендер (для гос. сектора - только так). У проекта есть свой бюджет, свои ограничения и т.п. Над проектом работает проектная команда.

Проектная команда

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

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

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

Аналитики - это такие люди, которые переводят хотелки клиента на язык объектов фреймворка и приложения. Они формируют объектную модель, на основании ТЗ они формируют технические решения (ТР), которые уже максимально приближены к руководству для разработчиков. У нас есть ведущий аналитик и просто аналитик. Разница наверно лишь в степени ответственности и глубины знаний. Аналитики не пишут код, они являются прослойкой между мыслью заказчика и разработчиками.

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

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

Есть еще специалисты по внедрению, но они в процессе разработки не участвуют, так что про них я мало что знаю.

Документация

Скучный раздел. Что тут можно сказать, есть разного вида документы (самые интересные описаны выше). Сначала у заказчика подписывается ТЗ, на его основании формируются ТР, затем ФС. О большем я не в теме, знаю только, что есть еще разного рода документы, но этим ведают менеджеры.

Процесс разработки

В нашей компании введена система учета времени, одновременно являющаяся системой учета работ. Суть ее заключается в том, что в ней заводятся "инциденты" на какую либо задачу. Это может быть разработка функционала, исправление найденной ошибки, разработка документа, обучение и т.п. На каждый инцидент списывается время, затраченное на него, плюс указывается комментарий, что было сделано + номер коммита в TFS. Такой подход мотивирует на работу, так как сотрудник обязан списать все рабочее время в течении дня на какие-то конкретные инциденты. Все это отражается у менеджера, который потом делает выводы о твоей успешности и продуктивности.

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

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

Код

Разработка ведется Visual Studio, подключенной к Team Foundation Server. Таким образом, каждый видит, кто что изменял, плюс имеет постоянно последнюю версию приложения у себя локально. Каждый коммит изменений принято комментировать описанием инцидента, по которому эти изменения внесены. В таком случае проще сориентироваться, что это сделал и почему. В компании принят корпоративный стандарт стиля кода. Для C# используется CamelCase-style, причем в нашем проекте внедрен StyleCop - примочка к студии, контролирующая стилистику. Если какая-то переменная или метод выбиваются из этого стиля, то генерируется предупреждение. Строго за этим не следится, но если обнаруживаются расхождения, то следует их исправлять.

Совещания, обсуждения и прочие демагогии

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

Плюшки

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

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

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