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

    Posted on January 21st, 2010 Александр Орлов No comments

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

    Конечно, существует много конкурирующих методологий, каждая из которых предписывает разные правила, стараясь захватить доминирующую позицию. Наиболее заносчивые попытались предпринять войну методологий с маркетинговой уловкой: они называют свои правила best practices. Их цель – уменьшение чувства неуютности новичков при адаптации этих правил и увеличение неуютности при адаптировании альтернатив, которые, разумеется, worse practices, из-за которых проекты проваливаются.

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

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

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

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

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

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

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

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

    Хотя они и «просто делали проекты», они явно переняли (как оказалось, от более опытных в компании) многие обычаи, описывающие правила игры, которым они следовали без вопросов:

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

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

    Leave a reply

    You must be logged in to post a comment.