Вероятно, немного педантично спорить о терминологии, используемой для ограниченного по времени процесса доставки программного обеспечения, но выслушайте меня.
Для большинства команд, использующих Agile-процесс, этот временной интервал называется спринтом. Это должно показать, что команда «спринтирует» в течение короткого периода времени, чтобы решить сюжетные проблемы. К концу спринта команда не только добилась ценности для бизнеса, но и готова делать это снова и снова.
В чем проблема? Будет ли термин «итерация» генерировать столько же интуитивных образов? Передает ли это предполагаемую реальность или мотивирует ли команду напрягаться или подталкивать себя? Влияет ли это на то, как мы думаем об итеративной разработке? Ожидается ли изменение культуры разработки?
Эта статья представляет собой авторское мнение, надеющееся заставить вас по-новому взглянуть на итеративную разработку. Слова иногда имеют значение, потому что они определяют то, как мы думаем. Терминология, которая управляет образами, может оказать сильное влияние не только на то, как мы думаем, но и на то, о чем мы думаем.
Спринт
Термин «спринт» происходит от бега изо всех сил в течение короткого промежутка времени. Он часто используется в отношении спорта, будь то гонки или даже командные виды спорта, такие как футбол, баскетбол, футбол и т. д. Он используется в разработке программного обеспечения, чтобы мотивировать инженеров усердно работать и быстро решать конкретные проблемы и приносить реальную пользу для бизнеса. .
Тем не менее, одним из основных принципов гибкой разработки является:
«Спринт» — это не устойчивый темп.
Очевидно, что использование термина «спринт» в контексте разработки программного обеспечения не означает, что разработчики работают так усердно, что не могут поддерживать темп. Однако из-за использования этого термина разработчикам и заинтересованным сторонам (особенно руководству) легко стать жертвой образов, которые толкают разработчиков в этом направлении.
Конкурирующие философии приверженности
Есть две основные философии, с которыми я столкнулся, когда дело доходит до планирования и выполнения циклов итеративной разработки. Эти две философии связаны с ожиданием того, что во время планирования будут реализованы заложенные истории. Для целей этой статьи я обозначу эти две философии как «Обязательство» и «Растяжка».
Философия «Commit» предполагает, что разработчики выбирают набор историй, которые они могут разумно взять на себя в рамках итерации. Ожидается, что к концу итерации все истории будут завершены. Если есть дополнительное время, можно решить дополнительную работу, чтобы команда не простаивала.
Обоснование этой философии связано с восприятием того, что обязательство само по себе является мотивационным и приводит к успеху. Успех порождает успех.
Однако эта философия обычно отвергается из-за опасений, что разработчики будут увеличивать свои оценки, чтобы легко выполнить свои обязательства.
Философия «растягивания» предполагает, что разработчики выбирают набор историй, которые они могут разумно представить, но добавляют больше, чтобы «растянуть» команду. В соответствии с этой философией есть большая вероятность, что разработчики не донесут до конца все истории, но также есть вероятность, что они это сделают, если будут достаточно «ускоряться».
Причина этой философии заключается в том, что, подталкивая команду разработчиков к чрезмерным обязательствам, они будут работать усерднее («спринт») и достигнут большего, чем они думали. Пропустить обязательство не обязательно плохо, поэтому его обычно прощают (или слегка наказывают).
Тем не менее, эта философия игнорирует распространенную реакцию на чрезмерные обязательства: если наказание за несоблюдение обязательства невелико, то мало и мотивации усерднее работать для его достижения, тем более что это в первую очередь считается натяжкой (т. от наказания до боли от усердной работы).
В некотором смысле, восприятие этих двух философий может сводиться к уровню доверия руководства к своим инженерам. Если вы доверяете своим инженерам, подталкивать их не нужно, поскольку вы считаете, что у них другие мотивы. Если вы им не доверяете, вы с большей вероятностью подтолкнете их и не поверите, что они работают в срочном порядке.
Какое это имеет отношение к использованию термина «спринт» по сравнению с «итерацией»? Поскольку слова могут управлять тем, как мы думаем, нам следует позаботиться о том, как мы описываем процесс, которым следуем. «Спринт» означает быстрый бег, в то время как «Итерация» — это просто общий термин для определенного временного интервала среди временных интервалов аналогичного размера.
Что вы ожидаете от команды разработчиков во время спринта? Вы ожидаете, что они будут усердно работать, чтобы рассказать все свои истории. Что вы ожидаете от команды разработчиков во время итерации? Вы, конечно, ожидаете, что они расскажут свои истории, но вы также можете ожидать, что они будут делать и другие вещи, например, решать производственные вопросы, узнавать об инструментах, языках, библиотеках и фреймворках, которые они используют для своих историй, или даже принимать перерыв и болтовня у пресловутого кулера с водой.
Я работал с разработчиками, у которых была такая срочность, что они не останавливались после случайного решения своей проблемы со сборкой, чтобы узнать, что на самом деле решило ее. Я видел разработчиков, которым так не хватало времени, что они не посещали общественные собрания своей компании, не узнавали свою команду поближе и не тратили некоторое время на изучение новой технологии, которую команда собиралась использовать в предстоящем проекте.
банка
Есть аналогия, которую я люблю использовать при описании итерации. Итерация — это банка, а истории, над которыми нужно работать, — это шарики разного размера, которые нужно поместить в банку. Полный кувшин с шариками представляет собой обязательство рассказать идентифицированные истории (шарики в кувшине).
С этой аналогией есть проблема. В банке еще много места. Итак, ввожу песок. Насыпав в банку песок, заполните оставшееся пространство. Этот «песок» представляет собой «другие» вещи, которые выполняются во время итерации. Это могут быть просто встречи, перерывы или другие мероприятия. Это также может означать возможность решения производственной проблемы, или потратить некоторое время на обучение, или решить небольшую сумму технического долга и т. д.
Вы можете выдвинуть обвинение в том, что песок представляет собой «прокладку», о которой говорилось ранее. В некотором смысле это может быть правдой. Однако без этого песка разработчики могут перегореть, не научиться, когда им это нужно, или не справиться с обычными прерываниями, которые обычно возникают. Что еще хуже, этот песок может означать, что ваши разработчики тратят время на помощь и обучение друг друга. Без этого они могут быть менее заинтересованы в помощи другим, поскольку они сосредоточатся на своих собственных результатах, чтобы не попасть в беду, если их истории не будут реализованы.
Вывод
Успех порождает успех. Слова, которые мы используем, могут влиять на нашу способность мыслить определенным образом. Я использую слово «итерация», потому что доверяю своим разработчикам и хочу, чтобы они стали лучшими, кем они могут быть, и выпускали отличное программное обеспечение в стабильном темпе.
