Принципам agile: Что такое Agile? Как внедрить Agile в компанию? // Михаил Бакунин – Гибкая методология разработки — Википедия

Содержание

Насколько ваша команда соответствует принципам agile? Пять вопросов для проверки

Такие гибкие методологии, как Lean Startup и Scrum, помогут вам понять, чего хотят клиенты, и как им поскорее это дать. Сильнейшие Agile-команды следуют пяти основным паттернам. Чтобы понять, соответствуют ли ваши рабочие процессы принципам Agile, проверьте, насколько вы следуете этим паттернам. Чтобы оставаться гибкими, следуйте этим паттернам постоянно.

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

Мы нехотя платим за быструю адаптацию и эволюцию – мы увеличиваем в 10 раз частоту релизов, сжав зубы, страдаем на собраниях и ругаем скрам-мастеров, автоматизируем то, что раньше делали вручную, пересматриваем даты по контрактам, обучаем персонал и так далее – все потому, что хаос никуда не уходит. И если мы справляемся с хаосом лучше, чем наши конкуренты, мы выигрываем.

Мы не можем точно ответить на вопрос: мы уже Agile-команда? Абсолютно «гибких» команд не бывает. Но мы можем ответить, насколько мы соответствуем принципам Agile. Мы можем быть более или менее «гибкими», чем мы были раньше; более или менее «гибкими», чем конкурент.

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

Итак, начинаем…

Основные Agile-паттерны

Организации/команды, следующие принципам Agile…

измеряют экономический прогресс (например: скорость, индекс потребительской лояльности, число переходов, динамику изменения метрик, соответствующих стратегии компании),

проводят эксперименты ради улучшений (т.е. проводят ретроспективы в Scrum, активно работают с фидбеком в Lean Startup),

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

Устойчивые организации/команды, следующие принципам Agile…

берут на себя коллективную ответственность (это может проявляться в рамках планирования спринта или формирования ответственности перед владельцем продукта в Scrum, коллективное владение кодом в XP).

Расширяющиеся организации/команды, следующие принципам Agile…

решают проблемы системно (например, используют метод пяти «почему», теорию ограничений).

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

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

Принятие четвертого паттерна дает нам «устойчивый Agile». Коллективная ответственность (или просто личная ответственность для отдельного человека) мотивирует людей искать недостающие команде навыки, исследовать изменения рынка и учиться. Некритичные изменения просто мотивируют людей учиться больше.

Пятый паттерн – «решать проблемы системно» – расширяет нашу экспертизу и позволяет использовать подходы, выходящие за пределы нашей Agile-команды или компании. Между «гибкой» организацией и ее окружением нет жестких границ. Да, мы продолжаем брать на себя коллективную ответственность: исправлять проблемы в продукте – наша работа; но найденные нами решения могут оказаться полезны нашим поставщикам, боссам, другим отделам – для общей выгоды. Компании Toyota пришлось обучить не только своих поставщиков, но даже своего конкурента General Motors, чтобы те приняли производственную систему Toyota для облегчения процесса адаптации к постоянным изменениям.

Джефф Сазерленд (один из создателей Scrum) недавно бросил мне вызов: найти точное определение гибкости. Ничего не найдя, я придумал его сам. Достаточно ли этих пяти паттернов, чтобы дать определение устойчивым гибким методологиям? Да. Есть ли хоть один не-Agile подход, который бы соответствовал хотя бы одному из этих пяти основных паттернов? Нет. Идем дальше!

Измеряем «гибкость»

Теперь, когда мы дали определение гибкости, вы можете оценить собственную гибкость, отвечая на эти вопросы:

1. Насколько легко и часто мы измеряем наш экономический прогресс?

Рассчитываем ли мы свою юнит-экономику? Есть ли у нас сопутствующие стратегия и метрики? Какие метрики фиксируют наши основные индикаторы? Можем ли мы улучшить наши показатели для большего соответствия стратегии компании и экономике в целом?

2. Экспериментируем ли мы ради улучшений?

Насколько активно мы сравниваем ожидаемые показатели экономического развития с фактическим результатом наших экспериментов (а именно с итерациями, спринтами или жизненным циклом разработки)? Когда мы меняем процесс (ограничения по количеству открытых задач, длину спринтов, критерии завершения, критерии готовности, методологию, и т.д.), основываем ли мы наше решение на чем-то, что мы можем измерить? Проверяем ли мы наши гипотезы? Если мы согласовали и придерживаемся установленного процесса, проводим ли мы контролируемые эксперименты?

3. Ограничиваем ли мы открытые задачи?

Сколько мы уже сделали работ, не вошедших в релиз? Какой длины наши спринты? Как насчет нашего планирования? Много ли ресурсов мы тратим на планирование, оценку, проектирование? Получим ли мы тот же результат, если будем меньше времени тратить на разработку, планирование, оценку и проектирование?

4. Есть ли у нас коллективная ответственность?

Сколько людей в нашей команде чувствовали личную ответственность за недавние проблемы команды, изменили ли они свое поведение, чтобы предупредить эти проблемы в будущем? Помогаем ли мы друг другу?

В рамках проверки можно выявить очевидные признаки, что сотрудники и руководители не чувствуют коллективной ответственности: отрицаем ли мы существование проблемы? Часто ли мы виним в проблемах других? (Если из вашей компании внезапно и таинственно исчезают хорошие сотрудники, то у вас, вероятно, есть эта проблема). Обвиняем ли мы организационную политику и структуру компании в наших проблемах? Чувствуем ли мы вину (виним ли мы самих себя в чем-либо)? Тащимся на работу, как зомби, только потому, что нам надо оплачивать счета?

5. Решаем ли мы проблемы системно?

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

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

Конечно, дело в том, что эти вопросы помогут не только оценить, насколько быстро вы выделяете основные препятствия и реагируете на внешние изменения; эти вопросы помогут вам усовершенствовать эти процессы. И это именно то, что вы хотите узнать, когда спрашиваете: «Насколько мы соответствуем принципам Agile», верно?

P.S. Дэн Грининг (автор оригинала) является одним из докладчиков тематической конференции Lean Kanban Russia, которая пройдет в Москве со 2 по 3 октября 2015 года. Регистрация уже открыта – приглашаем к активному участию!

Применение принципов Agile на практике

С момента публикации в 2001 г. «Манифеста о гибкой разработке программного обеспечения Agile» новый методологический подход успел собрать внушительную армию как сторонников, так и противников.

Доводы противников Agile не менее весомы, чем аргументы, приводимые его адептами. Константин Добрянский рассказывает о достаточно успешном случае применения Agile-подхода и рассуждает, почему его использование, вероятно, никогда не станет повсеместным.

Возможности

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

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

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

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

Ввиду того, что в туристической
компании на момент разработки продукта отсутствовал опыт работы по Scrum, и,
соответственно, отсутствовали специалисты, обладающие необходимыми знаниями, компания
приняла решение к привлечению в качестве Scrum-мастера сотрудника
компании – разработчика программного продукта.

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

¾ – быть самоорганизующейся,
¾ – быть кросс-функциональными, обладать всеми необходимыми навыками,
¾ – нести коллективную ответственность за создание Инкремента.

Рекомендуемый размер
команды, согласно Agile, – 7 (плюс-минус 2)
человек. С
учетом требований к команде были выбраны следующие сотрудники компании:

¾ – представитель отдела продаж;

¾ – представитель колл-центра;
¾ – системный администратор компании;
¾ – представитель отдела маркетинга и рекламы.

Таким образом, размер
команды составил 5 человек.

Что дальше?

В процессе разработки команда руководствовалась достаточно распространенной схемой продвижения.

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

Таблица 1 – Бэклог продукта

¾ – планирование спринта не более 2 часов;
¾ – спринт с периодичностью 1 неделя;
¾ – ежедневный Scrum-митинг не более 15 минут;
¾ – ретроспектива спринта не более 1 часа.

Рисунок 1 – Схема продвижения команды разработки к спринту

Наибольшей
детализацией подверглась задача №2, которая была разбита на более мелкие задачи
с предварительной их оценкой по времени выполнения: анализ того, как это
происходит сейчас; запрос статистики наиболее распространенных вопросов-ответов
на тему запросов у колл-центра; проведение анализа вопросов в колл-центре; запрос
поведенческой статистики по сайту компании; разработка матрицы для анализа
статистики сайта компании и т.д. Решение перечисленных подзадач было
сопоставлено с трудозатратами и результатами выполнения этапов (подготовка карты
существующего процесса, оформление отчета, формирование карты цепочек наиболее
часто возникающих вопросов и ответов, подготовка таблиц со статистическими
данными о незавершенных покупках туров клиентами и т.д.).

Ретроспектива спринта по реализации 2-й задачи бэклога представлена в таблице 2.

Таблица 2 – ретроспектива спринта по реализации 2-й задачи бэклога

Например, на первой ретроспективе
было обсуждено, что будет сделано и как будет выполнена работа, а также цель спринта. С
учетом общего доступного за один спринт времени работы команды (4 человек * 8
часов * 5 дней = 160 часов) и по приоритетности задач для первого
спринта, был выбран ряд задач из бэклога. Бизнес-целью от владельца продукта на
этом этапе стало сокращение времени реакции на вопросы клиентов, увеличение
количества завершенных сделок и т.д.

По результатам
ретроспективы командой разработки были уточнены\скорректированы предварительные
оценки выполнения задач, а также распределены задачи между конкретными членами
команды. По результатам планирования спринта был создан бэклог спринта, который
отражал прогресс и использовался в течение всего спринта (см. таблицу 3).

Таблица 3 – Первый спринт по реализации ряда задач бэкл

Последние штрихи

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

По прошествии недели Scrum-мастером была организована встреча по обзору спринта. На данной встрече
были обсуждены результаты реализации задач и дана оценка готовности элементов
бэклога владельцем продукта. Scrum-мастер предложил
корректировки к формулированию целей и задач. После ретроспективы спринта цикл
повторялся: команда снова возвращалась к этапам «Бэклог» и «Планирование
спринта». Для наглядной визуализации бэклог был перенесен на доску визуализации,
размещенную в рабочем помещении команды.

Разработка чат-бота
заняла два месяца, после чего программное обеспечение было запущенно в
тестовой версии.

Итог

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

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

Делаем выводы

Рассмотренный пример
касался разработки несложного программного продукта. Компания-разработчик
использовала собственные наработки, а также известные на рынке решения. Можно
ли было в данном случае отказаться от использования Agile? Вполне. Более того, в чисто маркетинговых целях для
компании-разработчика использование традиционного «водопада» было бы наилучшим
решением более понятным для заказчика.

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

Константин
Добрянский, к.э.н.

Методология Agile в двух словах

Цель этой статьи — научить вас методологии Agile или процессу Agile простым и легким способом. Основная философия Agile заключается в том, чтобы объединять людей для совместной работы и достижения общей цели. Здесь мы фокусируемся на том, как команда может работать вместе, планировать, выполнять и поставлять качественное ПО в соответствии с гибким мышлением.

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

Потребность в гибкой методологии

Прежде чем вы адаптируетесь к Agile процессу, вы должны сначала признать, что у устаревшего способа разработки программного обеспечения «Waterfall» было много пробелов, которые нужно заполнить. Последовательность «Планировать, Проектировать, Выполнять, Проверять, Выкладывать» может работать для создания мобильных приложений или инфраструктурных проектов, но не для создания Программных приложений. В динамичной бизнес-среде, где затраты и конкуренция ведут к изменениям, методология Agile успешно смогла найти тонкий баланс между ожиданиями и исполнением.

Что такое Agile методология?

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

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

Короткие итерации

Унаследованные процессы разработки программного обеспечения, такие как Waterfall, имели такие фазы, как сбор требований, планирование, проектирование, кодирование, тестирование и выпуск.

Методология Agile, напротив направлена на предоставление всего выпуска в виде приращений за пару недель и полностью функциональной версии за несколько месяцев.

Коммуникация, общение внутри команды

В Agile, команды ежедневно встречаются, обмениваются информацией, обсуждают препятствия на каждом этапе проекта. Такое сотрудничество и обмен идеями гарантируют, что релиз останется на ходу, даже если требования немного изменится.

Обратная связь

Так как команда предоставляет функциональность небольшими порциями, они получают быструю обратную связь от Dev, QA, PO и клиентов. Именно так методология Agile помогает регулярно отслеживать ход цикла разработки.

Доверие

В Agile команде, каждый участник самоорганизуется. Процесс, поддерживаемый руководством, дает им возможность понять цели и определить их соответствующие пути для достижения успеха.

Согласование

Гибкая команда может быстро выровнять и настроить процесс в зависимости от необходимости. Принцип KIS или Keep It Simple — это то, чем они должны руководствоваться.

Сроки разработки гибкого программного обеспечения

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

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

Что такое Agile манифест?

Agile манифест — это рекомендация, в которой изложены ценности и принципы, которым необходимо следовать в методологии Agile.

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

Agile манифест подразумевает четкую и измеримую структуру и поощряет итеративную разработку, совместную работу и принятие изменений.

Вы можете прочитать о ценностях и принципах Agile манифеста ниже:

Ценности Agile:

Доверяйте людям и предпочитайте взаимодействие, а не процессы и инструменты
Сосредоточьтесь на предоставлении рабочего программного обеспечения, а не написанию документации
Больше вовлечения клиентов, чем просто обсуждения условий
Готовность приспосабливаться к изменениям вместо того, чтобы быть жестко идти по плану

Принципы Agile:

Короткие циклы разработки, быстрая доставка и довольный клиент
Принять изменения объема, пересмотреть цели
Непрерывная поставка рабочего программного обеспечения
Сотрудничество между всеми заинтересованными сторонами на протяжении всего проекта
Показать доверие к вовлеченным людям
Разрешить прозрачные взаимодействия
Рабочее программное обеспечение определяет прогресс
Agile процессы для нормализации скорости разработки
Связь между дизайном и технической реализацией
Простота
Самоорганизация — ключ к хорошей архитектуре, требованиям и дизайну.
Пересмотр, как стать более эффективным

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

Agile Управление проектами

Гибкое управление проектами — это проверенный метод для своевременного создания сложных проектов. Он подчеркивает следующие аспекты.

Сотрудничество,
Гибкость,
Постоянное улучшение и
Качественные результаты.

Он использует шесть основных «результатов» для мониторинга прогресса и выпуска продукта.

Видение продукта

Резюме, которое определяет цели продукта.

Дорожная карта продукта

Общий обзор требований к реализации.

Backlog продукта

Полный список возможностей, которые будут добавлены в проект.

План выпуска

Графический документ, показывающий ход релиза.

Backlog cпринта

Список пользовательских историй, выбранных в последнем спринте.

Инкремент

Рабочий продукт с функциями, реализованными в текущем цикле спринта.

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

Наиболее известные из них — Scrum и Kanban, поддерживающие жизненный цикл разработки Agile.

Подводя итоги

Действительно, Agile методология — это мощный инструмент для групп разработчиков программного обеспечения, которые ищут гибкую стратегию для разработки продуктов. Доказано, что Agile также относится к индустрии программного обеспечения. Любой ИТ-бизнес, которому нужен быстрый план действий, может использовать Agile для улучшения взаимодействия с клиентами, эффективной командной работы, осознанных изменений и, тем не менее, качественных результатов.

Введение в Agile: Основные принципы

Данный цикл статей предназначен для знакомства методами и инструментами гибкой разработки. Я расскажу как моя компания использует agile для быстрой и экономной разработки историй пользователей. В основном мы будем обсуждать инструменты компании Atlassian и рабочие процессы команд разработчиков ПО и менеджеров контента для REALSTREAMS s.r.o. Однако я также буду предлагать вашему вниманию кейсы из других проектов и альтернативные Атлассиану инструменты.

Почему я должен работать в Agile?

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

REALSTREAMS s.r.o. использует Agile, в первую очередь, потому что, даже запустив первый прототип нашего образовательного сервиса, мы все еще не знаем, как будет выглядеть наш конечный продукт. Мне прекрасно известно, насколько разработчики опасаются такой неопределенности. Поэтому они тратят слишком много труда и денег на подготовку идеального продукта. А после этого тратят еще столько же, подстаивая уже законченный продукт под изменившиеся требования пользователей. Получается медленно и дорого, потому что не гибко.

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

ЭРГО: Медленная разработка не может дать идеальный продукт. Она не успевает за изменением требований пользователей и действиями конкурентов. Значит, на делать быстро, не теряя в качестве. Тут и нужен Agile.

Генералисты против специалистов

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

Гибкая разработка в большей степени рассчитана на генералистов. Так, например, Andrew Prentice, менеджер команды обеспечания качества Atlassian, утверждает, что QA должен выполняться всеми членами команды, а не перекладываться на плечи QA инженеров и тестировщиков. Да, это позволяет не играть в пинг-понг с задачами, а сразу выпускать качественный код. Эта мечта любого руководителя проекта не может быть достигнуть, пока исполнитель пребывает в уверенности, что его работа заканчивается сразу за пределами его рабочего стола. Более того, руководитель тоже должен поменять подход и перестать мерять качество кода исключительно количеством успешно пройденных тестов.

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

ЭРГО: Гибкая разработка делает упор на взаимодействии разработчиков, позволяя специалистам взглянуть за пределы своих компетенций. Это сокращает число конфликтов, время на общение внутри команды и, одновременно, повышает качество кода.

Рабочий процесс с Agile

Мир проектов разделяется на стадии разработки и поддержки. SCRUM позволяет быстро начать и успешно закончить проект, Kanban может поддерживать деятельность готового проекта неопределенно долго.

SCRUM нужен вам, если вы хотите избежать блуждания в нечетких ориентирах или погони за тысячами целей одновременно. Это все тормозит проект. SCRUM делает процесс разработки итерационным. Обычно, разработчики разбивают производство на двухнедельные периоды (спринты). В период спринта решаются только те задачи, которые были поставлены вначале спринта, а возникающие в процессе работы отправляются в бэклог. В конце спринта проводится ретроспектива, где подводятся итоги работы. Разработчики ясно видят результат своего труда. Кроме того, что вид дел свершенных сильно мотивирует, они могут также рассказать, почему у них не получилась та или иная задача. Это позволяет руководителям оперативно видеть проблемы и искать пути решения.

Kanban требуется для управления длительными процессами. Идеально для технической поддержки и работы с клиентами. Редакторы REALSTREAMS s.r.o. используют Kanban для работы с потенциальными ведущими, и они всегда четко представляют на каком этапе начинаются проблемы. Проблема видна, если на каком-то этапе образуется настоящая пробка из карточек. И видна она всем и сразу. Руководитель может решить проблему налету, не дожидаясь сбора отчетности. Польза от Kanban не ограничивается визуализацией проблем. С помощью системы досок редактор ясно представлет себе, какое будет его следующее действие. Не нужно лазить в инструкции или отвлекать главного редактора.

ЭРГО: Agile применим как для итерационной разработки (SCRUM), так и для этапа поддержки (Kanban). В каждом случае повышается прозрачность процесса работы и, как следствие, скорость, ведь разработчики понимают причины своих ошибок и меньше путаются в действиях.

Рекомендуемые курсы