Agile-истории не говорят нам, что кодировать; они всего лишь примеры. Они предлагают небольшие кусочки более крупных абстракций, которые нам обычно нужны.
Истории - это крошечные окна, через которые мы можем смотреть, когда пишем код. Простота рассказа мотивирует и концентрирует наши творческие усилия. Их ценность заключается в том, чтобы изложить более широкую картину предметной области и того, чего на самом деле хочет заказчик, простым языком. Команда должна со временем проработать более крупные абстракции.
Как бы нам ни хотелось, чтобы каждая история была полностью самодостаточной, многие абстракции охватываются несколькими историями. Абстракции просачиваются в будущие истории, которые еще не были написаны, которые не будут написаны в течение нескольких месяцев. Принятие изменений означает выбор абстракций с использованием неполной информации.
Тем не менее, мы не должны много заниматься предварительным дизайном. Достаточно, чтобы покрыть следующие недели или две. Однако по мере роста проекта нам все чаще приходится делать более глубокие операции. Рефакторинг. Речь идет не только о СУШИВАНИИ кода. Его высшая цель - развитие абстракций. Это помогает нам привести код в соответствие с нашим последним пониманием общей картины.
Рефакторинг решает более глубокую проблему, заключающуюся в том, что наше программное обеспечение не всегда гибко. У нас нет идеального взгляда на будущее, но мы должны разработать гибкие возможности в программном обеспечении уже сегодня.
Agile ищет золотую середину между предварительным проектированием и рефакторингом. Гибридный подход, при котором мы делаем наброски абстракций, признавая, что наш дизайн всегда будет неполным. Мы делаем наброски ровно настолько, чтобы делать мудрые ставки, чтобы дать нам представление о том, как мы могли бы найти правильный путь через лес во время написания кода.
Пари. Это важное слово. Будущее неизвестно, поэтому мы делаем ставку на то, какие абстракции будут иметь смысл. Кодифицируем ставки.
Если мы не замечаем и не принимаем ставки, которые мы делаем, они могут оказаться неблагоразумными. Некоторые из ставок, которые сегодня являются довольно тонкими, станут важными позже. Тем не менее, если мы попытаемся слишком умно делать ставки, мы рискуем преждевременной оптимизацией. Сообразительность приводит к слишком грандиозным и пестрым абстракциям.
Истории не говорят нам о ставках, которые мы собираемся сделать. Они маскируют ставки примерами. Но процесс написания историй и связанных с ними проектных работ начинает обнаруживать ставки прошлого, настоящего и будущего. Вот почему разработчикам так важно писать свои собственные истории.
Старшие инженеры делают мудрые ставки, потому что они всегда держат в курсе того, в каком направлении движется проект и бизнес, и это помогает им принимать решения во время кодирования. Младшие инженеры делают ставки вслепую.
Но это зависит не только от отдельного разработчика. Мудрые пари должны исходить от разумной организации. Если продуктовая организация постоянно меняет свое мнение или не приводит команду в соответствие с более широким видением, неизбежны плохие ставки.
Плохо сделанные ставки могут превратиться в технический долг. По мере того, как разрыв в абстракции между программным обеспечением и видением продукта (и отставанием по продукту) растет, становится все труднее двигаться.
(Это часто дает стартапам огромное конкурентное преимущество. Кодовая база крупной компании в конечном итоге выйдет за рамки рынка, и стартап может начать с нуля с более современными абстракциями. Если стартап сможет достаточно упорно двигаться в новом направлении, их гибкость преодолеет жесткость большой компании.)
Но всякий раз, когда владелец продукта меняется и предлагает совершенно новую точку зрения, или перерисовывается дорожная карта, или меняется миссия или видение организации, мы сразу можем ожидать, что у нас возникнет большой долг перед программным обеспечением.
Это не технический долг. Это долг за товар. Это долг по пари.
Следует ли нам отслеживать ставки, которые мы делаем? Если да, то как? Для этого у Agile нет конкретного механизма.
Очки истории вообще помогают? Что ж, сюжетные точки возвращают информацию о прошлых ставках в обсуждение продукта: может быть, нам стоит сначала сделать X (2 балла) и отложить Y (5 баллов), хотя Y несколько важнее, потому что есть гибкость для X, но Y сначала потребует большого рефакторинга.
К этому моменту мы спорим с прошлым. Продуктовой команде уже слишком поздно что-либо сказать.
Несмотря на то, что Agile ставит во главу угла реакцию на изменения, мы встраиваем в программное обеспечение жесткость. Мы постоянно ожидаем, где произойдут изменения, либо явно (с предварительным дизайном), либо неявно (через спонтанный, часто негласный выбор дизайна). Таким образом, команда создаст лучшее программное обеспечение, если она будет больше знать о потребностях клиента и о том, где потребуется гибкость. Тогда задача состоит в том, чтобы найти баланс между предварительным проектированием, разумными ставками (и своевременной оптимизацией) и рефакторингом.
