• Культуры программных проектов: часть 7

    Posted on January 18th, 2010 Александр Орлов 1 comment

    (все выложенные на текущий момент части – здесь)

    Игра по другим правилам

    Действительно ли мир полон дурных боссов? Проекты полны некомпетентных работников? Технические ребята всегда зацикливаются на своих гиковских штучках в ущерб общему успеху проекта?

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

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

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

    А откуда люди берут эти свои разные правила? Похоже, что ответ зависит от опытности человека.

    Начинающие: Предписанные правила

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

    Многие из опытных людей с удовольствием делятся своими правилами, а наиболее активные из них группируют правила в некие евангелия и называют их методологиями.

    В качестве примера такой группы правил, названной методологией, давайте заглянем в книгу Unified Software Development Process (USDP), от Booch, Jacobson и Rumbaugh, опубликованную Addison Wesley в 1998. Вот некоторые случайно выбранные правила:

    Страница 19: «При назначении ресурсов менеджер проекта должен минимизировать передачу артефактов из одних рук в другие так, чтобы ход процесса был максимально гладким.»

    Страница 34: «Разработчики начинают работу со сбора требований заказчика в виде юзкейсов. Затем они анализируют и разрабатывают систему так, чтобы она соответствовала юзкейсам, создав сперва аналитическую модель, а потом и имплементацинную модель.»

    Страница 76: «Архитектура создаётся архитектором заранее (во время фазы детализации требований). Это требует существенных предварительных затрат времени.»

    В книге сотни таких правил, а сама книга – это всего лишь подмножество более полного Rational Unified Process (RUP), который доступен по подписке.

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

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

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

    Получается, что методики, нацеленные на начинающих, предписывают авторитарные правила, которым надо следовать, авторы которых обещают: «эти правила работали для меня, и если вы будете им следовать, как положено, они и для вас сработают».

    Продолжение следует…

    Производительность команды, Эксперты
     

    One response to “Культуры программных проектов: часть 7”

    1. chester January 18th, 2010 at 14:10

      Чую что-то знакомое:)
      http://en.wikipedia.org/wiki/Shuhari

    Leave a reply

    You must be logged in to post a comment.