Scrum и XP: заметки с передовой
Шрифт:
Теперь видно, что, скорее всего, нам потребуется 3 спринта для завершения всей обязательной и желательной функциональности.
3 спринта = 9 календарных недель = 2 календарных месяца. Станет ли это крайним сроком, который мы озвучим клиенту? Это полностью зависит от вида контракта, от того, насколько фиксирован объем работ, и т. д. Обычно мы берём время со значительным запасом, тем самым защищая себя от ошибочных оценок, возможных проблем, неоговоренного функционала и т. д. Значит, в этом случае мы установим срок поставки в 3 месяца, чтобы иметь месяц в резерве.
Очень хорошо, что мы можем демонстрировать клиенту что-нибудь пригодное к использованию каждые 3 недели и позволять ему изменять требования на протяжении всего времени сотрудничества (конечно в зависимости оттого, как выглядит контракт).
Корректируем план релиза
Реальность не подстроится под план, поэтому приходится его корректировать.
По окончании спринта мы смотрим на реальную производительность команды. Если эта производительность существенно отличается от прогнозируемой, мы изменяем прогнозируемую производительность для будущих спринтов и обновляем план релиза. Если это грозит нам срывом срока поставки, product owner может начать переговоры с клиентом или начать искать путь уменьшения объема работ без нарушения контракта. Или, возможно, он и команда смогут увеличить производительность или фокус-фактор путём устранения серьёзных препятствий, которые были обнаружены во время спринта.
Product owner может позвонить клиенту и сказать: «Привет, мы слегка не вписываемся в график, но я полагаю, что мы сможем уложиться в срок, если уберём встроенный Тетрис, разработка которого занимает много времени. Мы можем добавить его в следующем релизе, который будет через три недели после первого релиза».
Пусть это и не самая лучшая новость, но, хотя бы, мы были честны и дали возможность клиенту заранее сделать выбор: или мы поставляем только самую важную функциональность в срок, или же всю полностью, но с задержкой. Обычно, это не очень сложный выбор.:о)
Как мы сочетаем Scrum с XP
То, что Scrum и XP (eXtreme Programming) могут быть эффективно объединены, не вызывает сомнений. Большинство рассуждений в интернете поддерживают это предположение, и я не хочу тратить время на дополнительные обоснования.
Тем не менее, одну вещь я всё-таки должен упомянуть. Scrum решает вопросы управления и организации, тогда как XP специализируется на инженерных практиках. Вот почему эти две технологии хорошо работают вместе, дополняя друг друга.
Тем самым я присоединяюсь к сторонникам мнения, что Scrum и XP могут быть эффективно объединены!
Я собираюсь рассказать про наиболее полезные практики из XP и про то, как мы используем их в нашей повседневной работе. Не все наши команды смогли применить практики XP в полном объеме, но мы провели большое количество экспериментов со многими аспектами комбинации XP/Scrum. Некоторые практики XP напрямую соответствуют практикам Scrum, например, «Whole team», «Sit together», «Stories» и «Planning game». В этих случаях мы просто придерживаемся Scrum.
Парное программирование
Недавно мы начали практиковать его в одной из наших команд. Как ни удивительно, работает довольно-таки хорошо. Большинство других наших команд до сих пор не очень много программирует парно, однако, попробовав эту практику в одной из наших команд для нескольких спринтов, я вдохновился идеей внедрить парное программирование и в других командах.
Вот пока несколько выводов после применения парного программирования:
• Парное программирование действительно улучшает качество кода.
• Парное программирование действительно увеличивает сосредоточенность команды (например, когда напарник говорит: «Слушай, а эта штуковина точно нужна для этого спринта?»)
• Удивительно, но многие разработчики, которые выступают против парного программирования, на самом деле не практиковали его, однако раз попробовав — быстро понимают все преимущества.
• Парное программирование выматывает, так что не стоит заниматься им целый день.
• Частая смена пар даёт хороший результат.
• Парное программирование действительно способствует распространению знаний внутри команды, заметно ускоряя этот процесс.
• Некоторые люди чувствуют себя некомфортно, работая в парах. Не стоит избавляться от хорошего программиста, только потому, что ему не нравится парное программирование.
• Ревью кода — хорошая альтернатива парному программированию.
• У «штурмана» (человека, который не пишет код) должен также быть свой компьютер, но не для разработки, а для выполнения мелких задач, когда это необходимо — просмотра документации, если «водитель» (человек, который пишет код) запнулся и так далее.
• Не навязывайте парное программирование людям. Вдохновите их, дайте необходимые инструменты и позвольте самим дойти до этого.
Разработка через тестирование (TDD)
Наконец-то! Разработка через тестирование для меня важнее, чем Scrum и XP вместе взятые. Можете отнять у меня дом, телевизор, собаку, но только попробуйте запретить использование TDD! Если вам не нравится TDD, тогда просто не подпускайте меня близко, иначе я всё равно привнесу его в проект втихую:)
Курс TDD за 10 секунд:
Разработка через тестирование означает, что вы сначала должны написать автоматизированный тест (который не проходит — прим. переводчика). После этого надо написать ровно столько кода, чтобы тест прошёл. Затем необходимо провести рефакторинг, в основном, чтобы улучшить читабельность кода и устранить дублирование. При необходимости повторить.
Несколько фактов о TDD:
• Разработка через тестирование — это непросто. На деле оказывается, что демонстрировать TDD программисту практически бесполезно — часто единственный действенный способ заразить его TDD заключается в следующем. Программиста надо обязать работать в паре с кем-то, кто в TDD хорош. Но как только программист вник в TDD, то он уже заражен серьезно и о разработке другим способом даже слышать не хочет.