храбрость.
Прежде чем на основе рассказа об управлении автомобилем сформировать набор методик разработки программного обеспечения, мы должны найти некоторый критерий, благодаря которому сможем узнать о том, что движемся в правильном направлении. Согласитесь, что было бы плохо, если бы мы создали стиль разработки, а потом узнали, что этот стиль нам не нравится или что он не срабатывает.
Краткосрочные индивидуальные цели часто конфликтуют с долгосрочными социальными целями. Общество решает эту проблему при помощи набора ценностей, подкрепленных мифами, ритуалами, наказаниями и наградами. Без уважения к этим ценностям люди забывают о социальных нуждах и стремятся реализовать свой собственный индивидуальный краткосрочный интерес.
Четыре ценности для ХР – это:
• коммуникация (communication);
• простота (simplicity);
• обратная связь (feedback);
• храбрость (courage).
Первая ценность ХР – это коммуникация. Проблемы, которые возникают в процессе работы над проектом, почти всегда связаны с тем, что кто-то не сказал кому-то о чем-то важном. Иногда программист не сообщает кому-то о важном изменении в дизайне. Иногда программист не задает заказчику важного вопроса, и в результате важное принятое им решение оказывается неправильным. Иногда менеджер не задает программисту важного вопроса, в результате у него складывается неполное, а иногда и неправильное представление о состоянии проекта.
Плохая коммуникация – это не случайность. Существует огромное количество предпосылок, которые ведут к нарушению коммуникации. Например, программист сообщает менеджеру плохие новости и менеджер наказывает программиста. Заказчик сообщает программисту нечто важное, а программист делает вид, что не понял или просто проигнорирует эту информацию.
Дисциплина ХР нацелена на обеспечение непрерывной, постоянно осуществляемой коммуникации между участниками проекта. В рамках ХР используются многие методики, которые невозможно реализовать без коммуникации. Эти методики направлены на достижение краткосрочных целей, например, тестирование модулей, программирование парами, а также оценка сложности задачи. В процессе тестирования, программирования парами и формирования предварительных оценок программисты, заказчики и менеджеры вынуждены тесно взаимодействовать.
Это не означает, что излишние разговоры мешают работе. Люди часто попадают в ситуацию, когда они сомневаются, делают ошибки, отвлекаются. В рамках ХР существует специальное ответственное лицо – инструктор (coach), в чьи обязанности входит следить за тем, чтобы люди общались тогда, когда это надо. Если инструктор замечает, что люди перестают общаться, он стимулирует коммуникацию.
Вторая ценность ХР – это простота. Инструктор ХР спрашивает команду: Какова самая простая вещь, которая скорее всего сработает? (эта фраза является часто употребляемым выражением, в определенном смысле девизом, так что в мире ХР даже существует специальная аббревиатура – Do The Simplest Thing That Could Possibly Work[4],
Простота – это далеко не так просто. Напротив, это очень даже сложно – не обращать внимания на вещи, которые вы намерены реализовать завтра, на следующей неделе, в следующем месяце. Вы должны понимать, что если вы намеренно пытаетесь предугадать, как в будущем будет развиваться проект, это значит, что вы боитесь экспоненциального роста стоимости изменений. Программист боится, что завтра ему придется тратить массу усилий для исправления ошибок, которые он сделает сегодня, в результате он зачастую делает код более сложным. Время от времени инструктор должен мягко напоминать программистам, работающим над проектом, что вместо того, чтобы заниматься решением текущих задач, они пытаются прислушаться к собственным внутренним страхам. Если ты пытаешься заставить работать это динамически сбалансированное бинарное дерево, значит, ты умнее, чем я. У меня складывается впечатление, что в данном случае можно обойтись обычным линейным поиском.
Грег Хатчинсон (Greg Hatchinson) пишет:
Один человек, которого я консультировал, пришел к выводу, что для отображения текста нам потребуется универсальное диалоговое окно. Мы обсудили интерфейс этого диалога и как он будет работать. Программист решил, что диалог должен быть достаточно совершенным, он должен автоматически менять собственный размер и количество символов переноса строки в отображаемом тексте в зависимости от размера шрифта и других факторов. Я поинтересовался у него, какое количество других программистов, так же как он, нуждается в подобном диалоговом окне. Он ответил, что на текущий момент такое диалоговое окно нужно только ему. Я предложил не делать диалоговое окно столь интеллектуальным и ограничиться более узким набором возможностей. В этом случае диалоговое окно можно было бы реализовать минут за двадцать. Мы могли бы сделать класс с известным интерфейсом, а затем, когда появится такая необходимость, мы всегда могли бы усовершенствовать наше окно так, как этого потребует конкретная ситуация. К сожалению, я не смог убедить его, в результате он потратил два дня на реализацию своей идеи. На третий день условия задачи, для решения которой требовалось данное диалоговое окно, изменились и надобность в подобном диалоговом окне полностью отпала. Таким образом, два человеко-дня ушло на то, чтобы решить проблему, которая сразу же после этого перестала быть актуальной. Все же если вы сможете найти применение для данного кода, сообщите мне об этом.
ХР делает свою ставку. Предполагается, что лучше сделать простую вещь сегодня и заплатить чуточку больше завтра для того, чтобы модифицировать ее (если в этом возникнет необходимость), чем разработать более сложный код сегодня, а потом узнать, что этот код больше не нужен.
Простота и коммуникация обладают замечательной взаимоподдерживающей связью. Чем больше вы общаетесь, тем яснее для вас становится, что именно вы должны сделать, и тем больше вы уверены в том, чего делать не надо. Чем проще система, тем меньше тем для обсуждения, а значит, тем полнее становится общение, особенно если вы упрощаете систему настолько, что для работы над ней требуется меньшее количество программистов.
Третья ценность в ХР – это обратная связь. Инструктор ХР часто произносит:
Обратная связь работает в разных временных масштабах. Во-первых, обратная связь работает в масштабе минут и дней. Программисты пишут тесты для всей логики в системе. Любой из этих тестов может не сработать. Так программист получает обратную связь, которая ежеминутно обеспечивает его сведениями о состоянии системы. Когда заказчик пишет новые истории (описания возможностей системы), программисты немедленно оценивают их, благодаря чему заказчик получает обратную связь, которая обеспечивает его сведениями о качестве его историй. Человек, который следит за своевременным решением задач в рамках проекта, обеспечивает всех членов команды сведениями о том, какова вероятность того, что запланированный объем работ будет реализован в установленные сроки.
Обратная связь также работает в масштабе недель и месяцев. Заказчики и те, кто обеспечивает функциональное тестирование системы, разрабатывают функциональные тесты для всех историй (говоря иначе – упрощенных тестовых случаев), реализованных в рамках системы. Таким образом они обладают обратной связью, которая обеспечивает их информацией о текущем состоянии используемой ими системы. Заказчики пересматривают график работ каждые две или три недели для того, чтобы убедиться, что скорость выполнения работ соответствует плану. В случае необходимости план пересматривается.
