К основному контенту

Какие проекты лучше всего подходят для применения Agile

Автор: Майк Кон (Mike Cohn)
Переведено с английского проектом Agile Translations.



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

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


Сегодня на обед я пошел в свой любимый китайский ресторанчик. Я заказал себе блюдо «тройной супер острый халапеньо». Вероятно, это был первый раз, когда они готовили это блюдо именно таким способом, поэтому оно было в какой-то мере новым и уникальным. Тем не менее, повар приготовил его чудесно, а поскольку я мог наблюдать их кухню, я вам скажу с уверенностью, что им не понадобились Daily stand-up митинги и даже TDD, чтобы приготовить мой обед (хотя, я там заметил некоторые признаки канбана :)

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

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

Теперь давайте посмотрим еще на одну ситуацию, в которой нам часто приходится слышать о применении Скрама, речь пойдет о свадьбах. Как минимум пару раз в год мне приходится слышать о паре, которая планировала свою свадьбу, используя Скрам. В таких случаях обычно всегда существует "свадебный беклог" – купить торт, нанять фотографа, разослать приглашения, выбрать платье и т.д. Но что из себя представляет процесс планирования свадьбы через призму тех трех факторов, которые я предлагаю? Ощущение срочности? – Понятное дело, свадьба всегда заранее назначается на конкретный день, и, как правило, эта дата очень фиксирована. Сложность? – Согласен, свадьба – это, конечно, не проект по разработке программного обеспечения, но все равно она имеет ряд своих специфических сложностей, еще и усиленных такими нефункциональными требованиями, как ограниченный бюджет, правильная рассадка гостей за праздничным столом, виды подаваемых блюд, необходимость договориться с двоюродным братом, чтобы он со своей музыкальной группой сыграл у тебя на торжестве и т.д. Новизна? – А почему бы и нет! Большинство людей не так часто женятся, да еще и с грандиозными церемониями, чтобы планирование подобного рода событий превратилось в обыденное дело

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


Переведено с английского проектом Agile Translations - Дарьей Дубининой, Андреем Перервой, Натальей Новотной и Ильей Павличенко.

Оригинальная статья: "Deciding What Kind of Projects are Most Suited for Agile"

ПОПУЛЯРНОЕ

Шаблоны декомпозиции Пользовательских Историй (User Stories)

Автор: Richard Lawrence Переведено с английского проектом Agile Translations   Хорошие Пользовательские Истории следуют INVEST модели , предложенной Биллом Вейком (Bill Wake). Они независимые ( I ndependent), обсуждаемые ( N egotiable), ценные ( V aluable), поддающиеся оценке ( E stimable), небольшие ( S mall) и тестируемые ( T estable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели. Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая” , однако, не сможет похвастаться тем же в случае с “независимая” и “ценная” . За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

Основополагающие принципы Agile-манифеста

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

Скрамбан - собираем лучшее

Автор: Илья Павличенко . Иногда я слышу фразу - «теперь у нас будет СкрамБан». И, к сожалению, наблюдаю, что чаще всего это означает, что у команды теперь не будет ни полноценного Скрама, ни внедренного должным образом Канбана. Хотя это понятие (СкрамБан) подразумевает и первое, и второе. Таким образом, команды лишают себя преимуществ обоих методов, переходя в серую зону неопределенности. Привожу цитату Алана Шалловея, одного из родоначальников Канбана (полностью его блог-пост по этому вопросу можно прочесть здесь ): « Теперь стало модно у многих Скрам команд уходить от итераций и кросс-функциональных команд и говорить, что теперь у них внедрен Канбан. Я принимаю то, что в Канбане отсутствует и первое, и второе. Но Канбан не определяется отсутствием итераций или кросс-функциональных команд. Он определяется визуализацией, управлением потока, наличием явных полиси и т.д. Если у вас был Скрам и вы решили уйти от итераций - у вас не Канбан. Вы даже и близко не подошли к тому, чтобы

Все о Скрам от Майка Кона

На сегодняшний день многие уже знают основы Scrum. Однако я часто сталкиваюсь с разночтениями, и даже спорами по некоторым моментам. Поэтому считаю, что нужно обратиться к истокам. Как, наверняка, многие знают Майк Кон – один из наиболее популярных Scrum-тренеров, он работает с этой методологией более 10 лет, написал 2 концептуальные книги по практикам Agile, а также множество интересных и ценных статей, является одним из основателей Scrum-альянса и Agile-альянса. По праву его можно считать тем специалистом, определениям которого можно доверять. Читать дальше...

Планирование релиза: уходим от термина, но не от практики

Автор: Майк Кон (Mike Cohn) Перевод с английского. Я хочу обратить внимание на термин, используемый в Скраме (точнее, даже Аджайл термин), который во многом пережил себя: планирование релиза. Общепринятое использование "релизного планирование" заключалось в том(я так тоже делал), что мы смотрели в будущее на несколько спринтов вперед и пытались предсказать, что бы мы могли выпустить. Было бы хорошо в идеале эти предположения выражать в виде диапазона значений, возможно даже с использованием интервалов вероятности. В течение многих лет я учил команды делать именно так. Скажем, мы могли сказать, что “Мы уверены на 90%, что через шесть месяцев сможем выпустить продукт с функционалом в диапазоне между 150 и 200 стори поинтов.” Я до сих пор считаю эту практику полезной и каждый Скрам-мастер должен знать как это делается. Что на самом деле потеряло смысл, так это сам термин “планирование релизов”.