Дэн Олсен – MVP. Как выводить на рынок товары и услуги, которые нравятся покупателям (страница 55)
Независимо от того, какую методологию Agile вы выберете, я настоятельно рекомендую использовать при этом хороший инструмент, предназначенный для управления ходом работ. Одна из ошибок, которую допускают некоторые команды, заключается в использовании инструмента общего назначения вместо того, который оптимизирован именно под вашу методологию разработки. Опять же, я рекомендую проводить апробацию того инструмента, который, как вы считаете, лучше всего подходит для вашего случая. Если через месяц или два он вас разочарует, попробуйте другой.
Я имею опыт взаимодействия со многими разработчиками, которые указывали на наличие недостатков в той или иной методологии или инструменте, и это вполне ожидаемо. Но мне приходилось сталкиваться и с теми людьми, для которых «у соседей трава всегда зеленее». Им не нравится любые методы или инструменты разработки, которые они используют. Опробовав их в течение короткого промежутка времени, они переключаются на другие, используют их в течение месяца, снова жалуются на их несовершенство и повторяют этот цикл до бесконечности. Если ваша команда перепробовала несколько методологий или инструментов и, похоже, не может найти то, что ее устраивает, вероятно, вам стоит сделать паузу и попытаться разобраться в ситуации. Не является ли это признаком отсутствия необходимого уровня самоотдачи, недостаточной подготовки или и того и другого вместе?
Возможно, совместное посещение членами команды тренинга по Agile стнет в такой ситуации весьма удачным решением. Я знаю множество примеров, когда команды внедряли новую методологию разработки в условиях отсутствия достаточного уровня понимания у всех участников. Неудивительно, что многие из этих команд испытывали трудности. Прежде чем внедрять новую методологию, неплохо было бы оценить степень готовности каждого члена команды. Даже если некоторые из них имели дело со Scrum или Канбаном на предыдущих местах работы, есть вероятность, что практическое применение любой из этих методологий имело там свои особенности. Если вы не будете устанавливать для членов команды новых ожиданий, они, скорее всего, решат, что вы следуете тем методам, с которыми они уже знакомы. Очень важно, чтобы все участники одновременно услышали одно и то же объяснение того, как должен протекать процесс разработки продукта. Это позволит гарантировать наличие одинакового понимания, отсутствие недоразумений и повышение производительности.
Достижение успеха с помощью Agile
Независимо от того, какую методологию Agile вы выберете, приведенные ниже дополнительные советы должны помочь добиться успеха в создании продукта.
Взаимодействие внутри команды
Одной из основ Agile является тесное межфункциональное взаимодействие, под которым подразумевается свободное постоянное общение между менеджерами по продуктам, дизайнерами, разработчиками, тестировщиками и любыми другими членами команды. Важно избегать создания изолированных подсистем, в которых каждая функциональная группа живет собственной жизнью и перебрасывает свою часть продукта «через стену» для перехода на следующий этап рабочего процесса. Живые коммуникации в режиме реального времени имеет решающее значение для достижения максимального взаимопонимания и высокой скорости работы команды. Эффективность совместной работы поддерживается также за счет использования таких средств коммуникации, как чаты, инструменты для отслеживания разработки (например, JIRA Agile), а также приложения для совместной работы с базами знаний (например, wiki или Google Docs).
Каждая функция должна быть задействована на протяжении всего процесса разработки, хотя вполне естественно, что на определенном этапе какая-то из них будет задействована в большей степени, если ей определена ведущая роль. Короче говоря: менеджеры по продуктам пишут пользовательские истории, затем проектировщики создают соответствующие артефакты, для которых разработчики пишут программный код, после чего тестировщики проводят проверку полученного результата. Каждый занят своим делом, но при этом разработка продукта – это командный вид спорта. Разработчики и тестировщики должны в определенной степени участвовать в ранних стадиях рабочего процесса, чтобы понимать, на чем основаны пользовательские истории, UX-дизайн и другие базовые решения в отношении продукта. Они должны быть заинтересованы в том, чтобы задавать вопросы и вносить свой вклад на всех этапах рабочего процесса. Аналогичным образом менеджеры по продуктам и дизайнеры должны быть в курсе событий, происходящих в зоне ответственности разработчиков и тестировщиков, тем более что там часто возникают непредвиденные вопросы или неполадки. В Intuit у нас была любимая поговорка: хорошие идеи приходят отовсюду. О достигнутом внутри команды уровне сотрудничества можно судить по тому, насколько чаще члены команды, говоря о своих коллегах, употребляют местоимение «мы» вместо «они».
Эффективное сотрудничество помогает команде формировать общее видение и избегать различных проявлений недопонимания, что также позволяет двигаться быстрее. Каждый член команды ежедневно принимает множество решений, так или иначе относящихся к созданию общего продукта. Если все участники процесса имеют общее видение и совместные цели, то они с большей вероятностью будут принимать персональные решения, направленные на достижение общих интересов.
Жесткая расстановка приоритетов
Вы должны поддерживать актуальность бэклога с учетом приоритетности входящих в него заданий. Важно иметь четкое представление о наборе пользовательских историй, которые планируется отработать в следующем цикле, как только для этого появятся ресурсы. Применение такого подхода позволяет действовать быстро. Команды разработчиков высокотехнологичных продуктов обычно работают в динамичной среде, для которой характерна быстрая смена требований и приоритетов. При этом явно недостаточно присваивать заданиям такие нечеткие приоритеты, как высокий, средний и низкий. Если в бэклоге будет 15 заданий с высоким приоритетом, то как понять, к какому из них разработчик должен приступить в первую очередь? Поэтому необходимо дополнительное ранжирование заданий, входящих в состав бэклога. Я являюсь сторонником жесткой расстановки приоритетов (в противовес расплывчатому ранжированию заданий). Четкая расстановка заданий внутри бэклога дает ясное понимание того, какое из них стоит первым в очереди на отработку. Это также значительно облегчает определение места в бэклоге для вновь поступающих заданий.
Тонкость заключается в том, что жесткая расстановка приоритетов не означает отсутствие гибкости этого процесса. Вы должны четко представлять себе приоритеты ранжирования в любой момент времени; но при этом также должны уметь быстро реагировать на изменение существующих или появление новых требований. Я вижу здесь аналогию с водой и льдом. Большую часть времени бэклог подобен льду: порядок ранжирования находящихся в нем заданий фиксирован – находится в замороженном состоянии. Но с появлением новых требований или изменением приоритетов вы на короткое время растапливаете лед, переводя его в жидкое состояние, чтобы произвести перенастройку. После определения новой очередности выполнения заданий вы снова замораживаете свой бэклог. Следование такому подходу гарантирует, что всякий раз, когда кто-то из членов команды обращается к бэклогу за получением нового задания, он имеет дело с его максимально актуальной версией. Таким образом, разработчик может просто брать задание, стоящее первым в очереди, ни с кем при этом не советуясь и не тратя время на получение дополнительных подтверждений.
Создавайте для разработчиков адекватное описание продукта
Важно предоставить разработчикам всю информацию, необходимую для создания желаемого продукта. Набор хорошо написанных пользовательских историй, усиленный соответствующими вайрфреймами или макетами, обычно хорошо справляется с этой задачей. При наличии готового руководства по стилю и отсутствии необходимости обновления базовых компонентов UX обычно бывает достаточно одних только вайрфреймов. Однако, если нужно передать визуальные детали дизайна, следует использовать макеты. Для чисто серверных функций, не содержащих UX-компонентов, вайрфреймы не требуются. Постановка задачи для разработчиков не должна ограничиваться одним лишь описанием «счастливого пути», то есть ожидаемого сценария поведения пользователя. Необходимо предусмотреть и другие применимые условия и состояния. Но при этом следует обеспечивать определенный баланс интересов. С одной стороны, вы хотите предоставить разработчикам достаточно полное определение продукта, чтобы они могли приступить к своей части работы с уверенностью, что вы не упустили из виду никаких важных аспектов. С другой стороны, вы не хотите столкнуться с ситуацией, когда на обдумывание каждой детали тратится так много времени, что сроки создания продукта значительно увеличиваются.
Опережайте разработчиков
Многие команды испытывали трудности с интеграцией своего UX-дизайна в процесс Agile-разработки. В руководстве по Scrum в явном виде не говорится о том, как можно справиться с этой проблемой наилучшим образом. Понятно, что в случае, когда проектировщик создает вайрфреймы для пользовательской истории одновременно с тем, как разработчик пытается писать для этой же истории программный код, итоговый результат не будет представлять собой ничего хорошего. Для того чтобы команды, практикующие Agile, могли достичь максимальной скорости, разработчики должны быть в состоянии немедленно приступить к работе над новой пользовательской историей. Это означает, что пользовательские истории и проектные артефакты должны быть заранее подготовлены к передаче на этап разработки. Таким образом, чтобы обеспечить стабильность рабочего потока, проектировщики должны опережать текущий этап разработки как минимум на один или два спринта.