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

Команды могут быть эффективными и без формальных процессов

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

В дополнение к ситуации «на все руки мастер»-а программисты берут на себя инициативу и создают функциональность которая не является обязательной, но о которой попросили некоторые пользователи или клиент. Это происходит когда программист знает о нуждах пользователей и знает рутинные задачи которые можно автоматизировать. Когда такого рода изменения приводят пользователей в состояние счастья, программиста начинают признавать как гения, он пишет софт полезный людям и организации, который не требует работы с их стороны. Такой прекрасный вид работ для программиста, без давления сверху, определённых ожиданий пользователей, и высоко ценимый.

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

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

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

Интересно заметить что команды которые не имеют формального процесса как правило довольны ситуацией!

Команды производящие успешный софтверный продукт гордятся своими успехами. Известность и широкое признание означает что программисты высоко уважаемы в организации. Уважаемы за исключением случаем когда проекты проваливаются.

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

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

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

Эта проблема появляется когда знания необходимые для определения нужного поведения ПО не существует в организации. Программисты знают как программировать, но они не знакомы с ежедневными проблемами людей в бизнес которых они теперь вовлечены. Так в один день «мастер на все руки» находит себя на зыбкой почве. Он провел много времени изучая нужды небольшой группы людей и если новый проект требует понимания совершенно других отраслей, другого бизнеса, ему уже необходимо достаточно много времени чтобы изучить тонкости новой сферы.

Source: Applied Software Project Management, By Jennifer Greene, Andrew Stellman