Новые методологии программирования
Страница 8. Программисты - это ответственные профессионалы

Программисты - это ответственные профессионалы

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

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

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

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

Управляем процессом, ориентированным на человека

Ориентация на человека проявляется в гибких процессах по-разному. Это приводит к различным результатам, причем иногда противоречивым.

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

Из всего этого следует интересный вывод: только сами разработчики могут решить - использовать адаптивный процесс, или нет. Особенно это справедливо для Extreme Programming (XP), при осуществлении которого необходима строгая дисциплина. С этой точки зрения Crystal имеет некоторое преимущество, так как требует минимальной дисциплины.

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

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

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

Роль бизнес-консультантов

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

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

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

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

Адаптация адаптивного процесса

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

Основа изменений в адаптивном процессе - регулярный его пересмотр. Обычно это делается в конце каждой итерации, когда вы собираетесь на короткое собрание и задаете себе следующие вопросы (по Норму Керту (Norm Kerth))

• Что мы делали хорошо?
• Чему мы научились?
• Что мы можем делать еще лучше?
• Что поставило нас в тупик?

Если "настройка" процесса происходит во время какого-либо проекта, то процесс становится еще более индивидуализированным, характерным для данной компании. Чтобы углубить такую "настройку" я бы посоветовал разработчикам делать пересмотр процесса еще более строгим и отмечать главные вехи проекта в виде ретроспективных сессий, как это описано у Норма Керта. Ретроспективные сессии включают в себя двух-трех дневное собрание вне офиса компании при содействии специального наставника. Такие сессии служат источником знаний не только для команды разработчиков, но и для всей организации.

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

Адаптивная сущность самого процесса более всего подчеркивается в ASD и Crystal. Что касается ХР, то на первый взгляд может показаться, что строгие правила этой методологии не позволяют вносить в процесс изменения. На самом деле это не так. Однако главное отличие по сравнению с другими гибкими методологиями состоит в данном случае в том, что пропагандисты ХР предлагают следовать "официальной версии" этой методологии в течение нескольких итераций, а уже потом менять ее. Кроме того, источники по ХР вообще не упоминают пересмотры процесса и не считают их частью методологии (хотя существует мнение, что они должны быть сделаны одной из практик ХР).