Коллеги, в данной публикации хотелось бы рассмотреть некоторые принципы современной организации процесса разработки, в большей степени присущие современным гибким (Agile) методологиям, чем «водопаду».
Возможно, в публикации будет некоторый акцент на критике, но не стоит на ней зацикливаться. Скорее, это некий обзор: каждый из подходов имеет свои плюсы и минусы.
Данный пост является продолжением предыдущих публикаций (часть 1, часть 2).
Есть некоторые вопросы по поводу распределения полномочий в управлении проектами и процессе разработки таких у ролей, как аналитики, руководители проектов, архитекторы, разработчики.
Вот некоторые тезисы-вопросы, которыми я хотел бы поделиться:
1. Аналитики создают модель предметной области в своих терминах, разработчики ее кодируют в своих.
Нужно, чтобы кто-то «наводил мосты» между первыми и вторыми.
Эти люди — архитекторы, причем видов архитекторов нужно как минимум три:
— архитектор системы в целом (системный архитектор, system architect);
— архитектор программного обеспечения (программный архитектор, software architect);
— архитектор баз данных (DB architect).
2. Во времена «водопада» аналитики, руководители проектов, архитекторы вырастали из линейных специалистов и руководителей профильных подразделений, лучшие становились постановщиками задач.
Но — и это крайне важно — все эти люди оставались профильными специалистами и руководителями, т.е. занимались реальной работой и знали, в чем она состоит.
Например, начальник отдела (или главный инженер) мог по совместительству занимать должность руководителя проекта (проекта, а не проектов, как современные PM).
3. В текущую эпоху доминирования гибких (Agile) технологий, хотя это с ними и не напрямую связано, преобладает такой подход:
3.1. Аналитиками становятся те, кто не смог стать разработчиком, но на аналитиков они и не учились (а где сейчас на них учат? — наверное учат, но процесс только пошел, а текущему подходу уже лет 10-15 как).
3.2. Разработчикам отвели роль «дешевых кодеров», соответственно, они или не могут по своим качествам заниматься аналитикой, или их до нее не допускают;
3.3. И вот тут то и нужны те самые архитекторы, о которых я писал выше. Архитекторы должны соединить между собой первых и вторых, т.к. те не могут сделать это самостоятельно, в соответствии с определенной им ролью и качеством подобранных кадров.
4. Итак, самое интересное — а где эти архитекторы?
Как поясняют знающие люди, домининирующая модель разработки выбрана, исходя из удешевления процесса разработки, именно поэтому используются дешевые аналитики и дешевые кодеры.
«Дорогие архитекторы» в эту модель не вписываются. Сама то идея правильная: используя более четкое разделение ролей (аналитики — архитекторы — кодеры), мы получаем более качественный процесс разработки и — более качественный результат.
Получаем — если не выкидываем ключевое дорогое звено.
Обычно этого звена нет (ведь изначальная постановка задачи — удешевить процесс), и результат получается соответствующий.
По моим наблюдениям и оценкам, в этом случае, в случае позаказной (некоробочной) разработки, средний срок жизненного цикла проекта составляет 3 года.
Автор: sand14
