(все выложенные на текущий момент части – здесь)
Игра по другим правилам
Действительно ли мир полон дурных боссов? Проекты полны некомпетентных работников? Технические ребята всегда зацикливаются на своих гиковских штучках в ущерб общему успеху проекта?
Конечно, некоторые люди могут быть довольно плохими, точно так же, как есть и супер-звёзды. В среднем же, большинство людей не будут исключительными личностями, о которых рассказывают легенды. Большинство менеджеров и членов проектных команд достаточно компетентны для выполнения хорошей работы, и у большинства вполне хорошие намерения; они делают всё в своих силах, чтобы успешно завершить проект.
Дело не в том, что «мы» умные, а «они» идиоты. Дело в том, что у разных людей разные убеждения, глубоко внутри, о том, что можно считать успехом проекта и как его достичь, а что считается неудачей проекта, и как этого избежать.
Если уж говорить прямо, то разработка приложений – это игра. В играх мы делаем ходы, основываясь на ходах других. Правила игры – это то, что мы принимаем за непреложную истину, которой руководствуемся в игре. В разработке приложений никто до конца не уверен, каковы же правила. В зарекомендовавших себя играх, вроде Монополии, шахмат и футбола, есть твёрдо установленные правила. В разработке их нет. Это относительно новая игра, и люди всё ещё пытаются понять, как в неё играть. В отсутствие чётких правил, люди стараются их угадать. В результате, разные люди играют в эту игру по разным правилам.
А откуда люди берут эти свои разные правила? Похоже, что ответ зависит от опытности человека.
Начинающие: Предписанные правила
Начинающие программисты находятся в сложной ситуации. Им не хватает опыта разработки, а потому они сталкиваются с огромной неопределённостью, даже когда работают над рутинными задачами. Чтобы преодолеть эту неопределённость, а заодно и расстройства, связанные с ней, они обращаются к более опытным разработчикам за предписанными правилами, которым они могут следовать буква в букву.
Многие из опытных людей с удовольствием делятся своими правилами, а наиболее активные из них группируют правила в некие евангелия и называют их методологиями.
В качестве примера такой группы правил, названной методологией, давайте заглянем в книгу Unified Software Development Process (USDP), от Booch, Jacobson и Rumbaugh, опубликованную Addison Wesley в 1998. Вот некоторые случайно выбранные правила:
Страница 19: «При назначении ресурсов менеджер проекта должен минимизировать передачу артефактов из одних рук в другие так, чтобы ход процесса был максимально гладким.»
Страница 34: «Разработчики начинают работу со сбора требований заказчика в виде юзкейсов. Затем они анализируют и разрабатывают систему так, чтобы она соответствовала юзкейсам, создав сперва аналитическую модель, а потом и имплементацинную модель.»
Страница 76: «Архитектура создаётся архитектором заранее (во время фазы детализации требований). Это требует существенных предварительных затрат времени.»
В книге сотни таких правил, а сама книга – это всего лишь подмножество более полного Rational Unified Process (RUP), который доступен по подписке.
Есть и другие способы группировки правил, но наиболее распространены книги с предписанными правилами. Это обусловлено тем, что начинающие программисты образуют наибольшую аудиторию этих книг, а что-либо слишком философское будет чрезмерно абстрактным для них.
Разумеется, когда я только начал работу программиста, я считал, что толстые популярные книги куда более полезны, чем тонкие книжки, предлагающие только общие советы. В университете в восьмидесятых нам дали следующие правила для разработки прилолжений: нарисуйте эти конкретные диаграммы; заполните эти формы; пишите код, используя эти методики; отдайте дизайн этим людям для проверки; и т.д. Правила были такие чёткие и ясные, что следовать им было очень легко.
Мне было довольно неуютно, когда в начале моей карьеры один из старших разработчиков сказал: «Никто этого не делает в реальной жизни». Он не был особо хорошим ментором, ибо он не предложил никаких альтернативных правил кроме «мы должны соблюдать сроки» и «твой код должен работать». Я чувствовал себя потерянным в море.
Получается, что методики, нацеленные на начинающих, предписывают авторитарные правила, которым надо следовать, авторы которых обещают: «эти правила работали для меня, и если вы будете им следовать, как положено, они и для вас сработают».
Продолжение следует…
chester January 18th, 2010 at 14:10
Чую что-то знакомое:)
http://en.wikipedia.org/wiki/Shuhari
Последние коментарии