MVP. Как выводить на рынок товары и услуги, которые нравятся покупателям - Дэн Олсен

спринта. В том случае, если вы не воспользуетесь перечисленными опциями, работа приложения будет в большей степени соответствовать методологии Канбана.

Выбор правильного метода Agile-разработки

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

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

Идея жестких плановых сроков запуска новых продуктов плохо соотносится с любыми методами гибкой разработки. Большинство компаний, применяющих «водопадный» подход, привыкли к тому, что у них есть нисходящая дорожная карта, которая диктует, какие функции они должны запускать каждый месяц или квартал, хотя эти сроки часто оказываются фикцией из-за регулярных задержек. При переходе на Agile многие из них по-прежнему придерживаются «водопадного» подхода в отношении бэклогов своих продуктов. Мне нравится использовать термин «Agilefall»[24] для описания компаний, переживающих трудности перехода с «водопадного» подхода на Agile и пытающихся поначалу усидеть сразу на двух стульях. Если вашей команде будет трудно отказаться от «подушки безопасности» в виде жестких сроков запуска, то вам, скорее, подойдет Scrum, нежели Канбан. По крайней мере, используя Scrum, вы знаете, что определенный объем работ будет выполнен к концу каждой итерации, и можете примерно оценить, сколько спринтов потребуется для запуска той или иной функции. Большинство команд, работающих по Канбану, не тратят время на оценку трудоемкости или планирование сроков завершения работ. Тщательно отслеживая продолжительность цикла и используя простые статистические методы, даже в случае с применением Канбана можно делать относительно достоверные прогнозы в отношении срока запуска продукта, однако лишь немногие команды разработчиков могут похвастаться настолько высоким уровнем точности отслеживания своих рабочих процессов.

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

Я имею опыт взаимодействия со многими разработчиками, которые указывали на наличие недостатков в той или иной методологии или инструменте, и это вполне ожидаемо. Но мне приходилось сталкиваться и с теми людьми, для которых «у соседей трава всегда зеленее». Им не нравится любые методы или инструменты разработки, которые они используют. Опробовав их в течение короткого промежутка времени, они переключаются на другие, используют их в течение месяца, снова жалуются на их несовершенство и повторяют этот цикл до бесконечности. Если ваша команда перепробовала несколько методологий или инструментов и, похоже, не может найти то, что ее устраивает, вероятно, вам стоит сделать паузу и попытаться разобраться в ситуации. Не является ли это признаком отсутствия необходимого уровня самоотдачи, недостаточной подготовки или и того и другого вместе?

Возможно, совместное посещение членами команды тренинга по Agile стнет в такой ситуации весьма удачным решением. Я знаю множество примеров, когда команды внедряли новую методологию разработки в условиях отсутствия достаточного уровня понимания у всех участников. Неудивительно, что многие из этих команд испытывали трудности. Прежде чем внедрять новую методологию, неплохо было бы оценить степень готовности каждого члена команды. Даже если некоторые из них имели дело со Scrum или Канбаном на предыдущих местах работы, есть вероятность, что практическое применение любой из этих методологий имело там свои особенности. Если вы не будете устанавливать для членов команды новых ожиданий, они, скорее всего, решат, что вы следуете тем методам, с которыми они уже знакомы. Очень важно, чтобы все участники одновременно услышали одно и то же объяснение того, как должен протекать процесс разработки продукта. Это позволит гарантировать наличие одинакового понимания, отсутствие недоразумений и повышение производительности.

Достижение успеха с помощью Agile

Независимо от того, какую методологию Agile вы выберете, приведенные ниже дополнительные советы должны помочь добиться успеха в создании продукта.

Взаимодействие внутри команды

Одной из основ Agile является тесное межфункциональное взаимодействие, под которым подразумевается свободное постоянное общение между менеджерами по продуктам, дизайнерами, разработчиками, тестировщиками и любыми другими членами команды. Важно избегать создания изолированных подсистем, в которых каждая функциональная группа живет собственной жизнью и перебрасывает свою часть продукта «через стену» для перехода на следующий этап рабочего процесса. Живые коммуникации в режиме реального времени имеет решающее значение для достижения максимального взаимопонимания и высокой скорости работы команды. Эффективность совместной работы поддерживается также за счет использования таких средств коммуникации, как чаты, инструменты для отслеживания разработки (например, JIRA Agile), а также приложения для совместной работы с базами знаний (например, wiki или Google Docs).

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