Кент Бек - Экстремальное программирование

Грег Хатчинсон (Greg Hatchinson) пишет:

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

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

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

Третья ценность в ХР – это обратная связь. Инструктор ХР часто произносит: Не спрашивай у меня, спроси у системы и Ты еще не написал для этого тестовый случай? Обратная связь, обеспечивающая точные и конкретные данные о текущем состоянии системы, – это воистину бесценная вещь. Оптимизм – это профессиональная болезнь всего программирования. Обратная связь – это лекарство от этой болезни.

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

Обратная связь также работает в масштабе недель и месяцев. Заказчики и те, кто обеспечивает функциональное тестирование системы, разрабатывают функциональные тесты для всех историй (говоря иначе – упрощенных тестовых случаев), реализованных в рамках системы. Таким образом они обладают обратной связью, которая обеспечивает их информацией о текущем состоянии используемой ими системы. Заказчики пересматривают график работ каждые две или три недели для того, чтобы убедиться, что скорость выполнения работ соответствует плану. В случае необходимости план пересматривается. Эксплуатация системы в реальных производственных условиях начинается, как только система становится способной решать хотя бы небольшую часть возлагаемых на нее обязанностей. В результате бизнес получает возможность на практике оценить, как именно выглядит система и в каком направлении ее лучше всего развивать в дальнейшем.

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