Agile, как гибкая методология имеет ряд преимуществ перед Waterfall. Так же Agile больше подходит для разработки ПО, но не все компании готовы к переходу от одного к другому. Waterfall отслужил нам хорошую и долгую службу. Он по прежнему считается хорошой методологией и используется многими компаниями в ежедневной работе. Agile же относительно новая методология гибкой разработки, ключевое отличие которой заключается именно в способе контролирования процессов и в способе формирования требований к проекту.
Если вы все же решились попробовать новое. В этой статье я поэтапно расскажу как плавно перейти от Waterfall к Agile без потерь, рисков и нарушения основных налаженых процесов работы.
Выбор проекта для перехода
При выборе проекта нужно учесть несколько важных факторов. А именно:
- Размер
- Риски
- Вовлечение Заинтересованых лиц
Размер — Проект должен быть не меньше 4х недель. Это оптимальное время для формирования полноценной обратной связи и понимания самой методологии. Оптимальный максимальный размер проекта — 12 недель.
Риски — проект должен быть важный но не критический. На проекте должно отсутствовать давление со стороны времени и со стороны клиента. Так как этот проект пилотный — очень важно быть сконцентрированным именно на внедрении методологии а не на тушении пожаров.
Вовлечение стейкхолдеров. Важно что бы в проект были вовлечено как можно больше участников. ПМ, Дизайнеры, Разработчики, Тестировщики, Аналитики… Так же проект должен проходить через все стадии разработки. Концепция, Дизайн, Анализ, Разработка… Очень важно понять все аспекты внедряемой методологии и полностью окунуться в нее. Здесь важно получить обратную связь от каждого участника и на каждом этапе.
Выбор Команды.
Наверное это 2й важнейший элемент при первом опыте работы, по этому к выбору команды стоит подойти с такой же ответственностью — как и к выбору проекта. Члены команды должны обладать всеми необходимыми навыками для достижения результата проекта что бы проект завершился успешно. Но по мимо этого команда должна хотеть внедрить инициативу Agile в работу. Команда интузиастов — одна из главных состовляющих успешного завершения интеграции.
Один из ключевых аспектов Agile заключается в том, что люди и взаимодействия между ними выше чем процессы.
Формирование ролей
Следующим этапом будет формирование ролей в команде. Ключевые роли в любой Agile команде:
- Product Owner
- Scrum Master
- Development Team
- Business Analyst или Клиент (Не совсем часть команды но важная часть процесса)
Эти роли разделяются на 2 группы. Клиентская сторона и Техническая.
Клиентская сторона, а именно Product Owner и BA, отвечают за создание требований к проекту и формируют их в форме пользовательских историй или user stores. Задача владельца продукта предоставить “Just enough” информации для команды разработки, что бы последние могли начать работу над продуктом.
“Управление требованиями — отдельная очень крупная тема, которая требует более глубокого и детального рассмотрения”
Планирование и оценка
На раннем этапе происходит планирование “Road Map”. Необходимо спланировать задачи с примерным указанием когда каждая пользовательская история будет закончена. Так как это первый проект в agile — точность не тоб на что стоит делать акцент. Главное — аккуратность.
Итак, что же должно включать в себя планирование. Планирование состоит из частей функционала которые разбиты на пользовательские истории, и каждая из пользовательских историй включает в себя определенный набор критерий для принятия функционала. Каждая из этих частей является определенным “Defenition of Done”. Рассмотрим кадую из них по ближе.
Пользовательская история — инструумент описания функционала, отвечающий на главные вопросы: Кто-то что то должен сделать что бы чего то добиться.
Пользовательская история имеет вид:
Я, как _________ хочу _________ для того, что бы _______
Критерия принятия — инструмент описания конкретного требования функционала с пошаговой инструкцией достижения результата. Ее принято писать на специальном языке Gherkin. Изначально это делалось для облегчения написания тестов к готовому продукту.
Scenario: Логин
Given: Я на странице логина
And: логин поле имеет валидные данные
And: пароль поле имеет валидные данные
When: Я нажимаю на кнопку “Login”
Then: Я логинюсь как пользователь
And: Стартовая страница открывается
Теперь подойдем к оценке. Части функционала оцениваются в размерах. XS, S, M, L, XL. Но оценка Пользовательские истории же оцениваются в сравнении с другими пользовательскими историями. Выбирается одна пользовательская история к которой определяется время на разработку. Эта ПИ принимается за один поинт и каждая следующая пользовательская история оценивается в пунктах. Тоесть соотношение более крупной задачи к мелкой.
Спринт планирование и спринт
Спринт 0. В этой ситуации спринт 0 — это необходимое мероприятие, которое послужит для решения многих проблем и вопросов, которые могут возникнуть. Сформировать видение проекта, заказать необходимое для продукта, подготовить команду к работе Agile, определить размер спринта.
Размер спринта — важный вопрос для пилотного Agile проекта. Важно сформировать размер спринта так, что бы в случае срабатывания рисков у команды было достаточно времени для востановления.
Планирование спринта. Так как все User Stories написаны, оценены и релиз план составлен, настало время для планирования спринта. На планировании обсуждаются любые новые User Stories, которые были добавлены но не были оценены. Далее все истории быдут разбиты на задачи, соответствующие Acceptance criterea и все AC будут оценены. Оценены в часах.
Velocity. Это среднее количество стори поинтов которое команда способна заделиверит в течение спринта. На первом спринте у команды velocity отсутствует. По этому команда обсуждает и решает что она сможет закончить на 100% в течение спринта и подтверждается командой.
Спринт беклог фиксируется и не изменяется.
Оценка и успех спринта. Ключевые элементы влияющие на успех спринта — это Стенд АП, Взаимодействие и Измерения.
Ежедневное планирование — 15 минутное мероприятие проводимое командой каждый день в одном и том же месте и отвечающее на основные вопросы.
- Что я делал вчера
- Что я буду делать сегодня
- Есть ли у меня какие либо проблемы
Взаимодействие — Один из найболее важных факторов это командная работа и взаимодействие каждого чоена команды с каждым. Как гласит одна часть Agile манифеста: “Люди и взаимодействие важнее процессов и инструментов…"
Обзор Спринта и Демо
В конце каждого спринта имеют место быть 2 мероприятия.
Обзор спринта и Демо — мероприятие на котором обсуждается работа на спринте и прдукт законченый в течение спринта показывается заказчику или клиенту. Собирается обратная связь от каждого из участников и по необходимости создаются новые задачи.
По окончании этих 2х мероприятий проходит Ретроспектива. Это мероприятия проводится для команды и покрывает такие моменты как:
- Что за время спринта мы сделали хорошо?
- Что мы могли бы улучшить?
- Что мы улучшим в следующем спринте?
И что же дальше? Когда спринты завершены и продукт закончен. Ретроспектива всего проекта и мнение команды по поводу новых процесов — одни из важнейших элементов принятия решения.
Комментарии (33)
aquamakc
27.10.2016 16:30+6Вопрос несколько в сторону. Обязательно пользоваться англоязычной терминологией? Я бы понял, еслиб не было русских аналогов, но ведь дорожная карта (Road map) или команда разработчиков (Development Team) — вполне себе актуальные термины/словосочетания.
Coffeeguess
28.10.2016 11:50Думаю это дело привычки. Я не воспринимаю эти слова на русском языке уже.
ooptimum
28.10.2016 11:57+2«Дорожная карта» — тоже калька с английского, просто переведенная. Как человек, говорящий на английском языке, не понимаю, зачем это использовать в русском, в котором есть хорошее короткое слово «план», обозначающее то же самое, но понятное любому русскому человеку.
vc54
28.10.2016 05:32Все круто, все замечательно. Вопрос для заказной разработки с фиксированным бюджетом на проект: как работать по гибкой методологии при жестко зафиксированном на старте проекта бюджете?
Продал ты заказчику без предварительной проработки разработку портала за полтора ляма.
Начали работать, заказчик фонтанирует идеями, фичами, команда куражится — пилит, скрам-фигам, митинги-шмитинги. 6 месяцев прошло, полтора ляма освоены, портал сделан наполовину: или есть наполовину сделанное всё, или есть половина запущенного функционала, а за вторую не брались вообще.
Дальнейшие действия? Еще полтора ляма предложить доплатить?aquamakc
28.10.2016 08:58Начали работать, заказчик фонтанирует идеями, фичами
Подробное ТЗ, согласованное с заказчиком на начальном этапе должно решить подобные проблемы. Всё что сверху — за отдельные деньги. Вот только к Agile этот подход не имеет никакого отношения.
Как я понимаю гибкая методология больше подходит к бизнес-модели «сначала разрабатываем, потом продаём». Если же «сначала продаём, потом разрабатываем» — тут все шаги разработки должны быть деревянными и прибиты гвоздями.vc54
28.10.2016 15:46-1Полностью поддерживаю. Плюсануть жаль не могу: плохо дело с кармой.
lalaki
29.10.2016 12:34Гибкая разработка в таком случае не просто подходит, но и спасает. Это же не просто "модная" фишка, но попытка вылечить типовые проблемы "водопада" — в первую очередь, всевозможные отклонения от первоначального плана — из-за неучтенных скрытых трудозатрат, ошибок оценки, требований, изменившихся по ходу проекта.
Делается просто — так работала еще в 2005-м контора, в которой я и начал трудовую деятельность, и работала с такими "негибкими" заказчиками, как государство, включая военных:
- проект планируется сроком в календарный год
- на первом этапе разработчиком же пишется ТЗ и сдается как отдельный этап или отдельный контракт;
ТЗ содержит нефункциональные и конкретные функциональные требования — какие возможности в принципе система должна предоставлять пользователям — людям и другим системам
расставляются крупные вехи по готовности крупных блоков в соответствии с ТЗ, система официально демонстрируется заказчику минимум при достижении этих вех
- внутри вех идет стандартная гибкая разработка — обычно даже не скрам, а канбан как минимально затратный подход; PП может посмотреть практически каждую отдельную выполненную задачу, старается периодически показать представителю заказчика;
все возникающие запросы на изменения приоритетизируются: фокус всегда — на выполнение функционального ТЗ, затем уже допиливание хотелок; здесь РП решает по ходу дела, какие запросы целесообразно принять уже сейчас, а какие — отложить до закрытия функциональности. РП в рамках своей компетентности исходит из оценки оставшихся ресурсов и плановой трудоемкости, и понимания влияния конкретного изменения на дальнейшую разработку — например, насколько сложно будет переделать потом.
- в паре с РП работает технический руководитель проекта — одновременно спорит по приоритетам, следя за фокусом на выполнение функционального ТЗ, с другой — помогает во всех технических оценках.
P.S. Мы слова "Agile" и "Скрам" не знали lj 2007-2008 — думали, что используем RUP (Rational Unified Process от IBM), соответственно адаптированный под нашу специфику, который мы назвали СЦР — Стандартный Цикл Разработки, а потом узнали, что "изобрели" подобие канбана.
vc54
02.11.2016 05:32Скорее это на серию маленьких водопадных проектов похоже.
lalaki
02.11.2016 17:29"серия маленьких водопадных проектов" называется "спиральная разработка".
Но на нее ни разу не похоже — я же прямо написал, что используется канбан.
То есть идет непрерывный поток входящих задач на разработку, верхушка которого динамически приоритетизируется РП; РП разделяет задачи на попадающие в "критический путь", т.е. те, без которых исходное ТЗ выполнить нельзя, и остальные — либо улучщения базовой реализации ТЗ, либо запросы на изменения.
Приоритет "критических" выше.
Поток задач генерируется аналитиками, РП и техническим руководителем совместно по мере постепенной детализации ТЗ, демо заказчикам, эксплуатации и тп
Coffeeguess
28.10.2016 11:56При жестко зафиксированном бюджете и объеме работы Agile не то что бы подходит.
Фонтанирующие идеи заказчика можно отложить на потом. Один из плюсов Agile — инкремент в конце каждого спринта. Потратив половину из жестко заложенного бюджета можно создать продукт способный приносить прибыль которая в будущем и покроет фонтан идей заказчика.
troublegum
28.10.2016 11:57Вообще то да, он должен заплатить еще, ваш заказчик купил ваше рабочее время и он его бездумно / разумно растратил на свои хорошие / плохие идеи. Если заказчик адекватный и он понимал что делал изначально, то вам повезло, а если он НЕ адекватный, то я сочувствую вашем менеджерам у которых начинает период «веселых» разговором с заказчиком…
vc54
28.10.2016 15:40В заказной разработке такое очень тяжело продать, к сожалению. Хоть и хочется. Мне нравится скрам, я работал по нему, но там действительно не считали деньги.
mcgreedy
28.10.2016 11:57Если такое произошло — значит кто-то облажался. И этот кто-то или продажник, или скрам мастер. Ведь есть вначале же стоится дорожная карта, по которой нужно двигаться, и любая идея, которыми фонтанирует заказчик, должна оцениваться отдельно от начальной концепции и добавляться не только в бюджет но сроки итоговой разработки, и если это не было сделано — значит кто то сел в лужу.
vc54
28.10.2016 15:34К сожалению, это конфликтует с бюджетированием. Пошел сначала заказчик и выбил себе миллион на проект. Вместо готового проекта получил полуфабрикат. Это сразу конфликт. Второй миллион ему никто не даст. Да и вообще могут с работы уволить за непрофессионализм.
mcgreedy
29.10.2016 09:41Так об том и речь, что кто-то в данной ситуации облажался, и должен понести наказание.
Поясняю ситуацию.
Пришел заказчик с миллионом и говорит: «сделайте мне сервис». Ему подрядчик — ок, вот этот серивис будет стоить миллион — согласны? Да, договорились.
В процессе работы заказчик говорит а давайте прикрутим еще вот эту фишку. Подрядчик ему — ок, не вопрос, сделаем, только это увеличит бюджет разработки на столько, и отодвинет сроки — вот на столько делать? и тут уже вопрос к заказчику — если денег больше нет — то сидим и смотрим дальше движение по спринтам. Если деньги есть — и сроки свободны — пилим.vc54
29.10.2016 16:28Опять же модель гибкая, предварительная проработка там минимальная. Делаем стори-маппинг крупными мазками, в детали не лезем, предполагая, что будем делать это уже в спринтах.
Последовательно запускаем спринты.
И тогда достаточно сложно аргументировать, что «вот это-то нами не предполагалось, когда про миллион говорили».
И начинаются диалоги вида:
– Не вопрос, сделаем, сроки +N дней, бюджет +M рублей. Согласны?
– Да вы издеваетесь! Вы сказали, что сервис будет стоить миллион? Вы подсадили меня на финансовую иглу! Вы действуете не по-партнерски! Дайте контакты вашего директора
Вот так в реале бывает.
Или за свой счет пилишь, или запускается процедура разрыва договора.mcgreedy
30.10.2016 05:56Да, согласен, бывает и так, но это вопрос уже больше к менеджменту и руководству, согласовывать и карту и бюджет и выбирать уровень детализации карты.
Опять же, вначале должны быть зафиксированы ВСЕ фишки которые изначально планируются, если это не сделано, то вопрос к менеджменту.
PO должен понимать что если что то добавляем в продукт то что-то нужно или убирать или менять сроки\бюджет. Кстати, заказчика для разработке по гибким методологиям тоже нужно учить как это работает, а как показывает практика, большая часть — не хочет понимать и учиться.
Именно по этому поэтому, (и тут начинается ИМХО) В чистом виде модель гибкой разработки — для внешней и коммерческой разработки не есть лучший выбор. Гораздо правильнее совмещать хорошие практики из водопада и аджайла. При очень четких и формализованных технических заданиях, осуществлять итеративную разработку с допуском РО для тестирования промежуточных продуктов. Фиксированное ТЗ гарантирует того что новые фишки не будут появляться в рамках проекта без изменения (дополнения) ТЗ и\или сроков\бюджета проекта. Заказчик в курсе процесса разработки и видит как идет разработка — что экономит ему нервы и имеет возможность влиять на этот процесс.
sdenisen
28.10.2016 11:57Есть еще вариант как начать скрам, он начинается с того что команда девелоперов с тестировщиками собираются в корридоре отвечая на вопросы по форме: «что сделано» «что будешь делать» и «какие проблемы», а дальше по необходимости добавляют нужные роли, и скрам мастеров, продукт овнеров.
Но самое эффективное, мне кажется, это начинать работать с тем кто уже попробовал и прожил этот скрам) и в курсе какие роли и как они взаимодействуют.Coffeeguess
28.10.2016 12:00Скрам так не начинается)
Скрам — это четкий фреймворк со своими Ролями Мероприятиями, Артефактами и правилами которые нужно соблюдать что бы Скрам работал. Но использовать практики скрима в любой другой модели — это можно.
В этой статье описан не Скрам. Тут о Agile)
Но конечно же команда с опытом — это отлично. К сожалению не всегда такой мы обладаем.sdenisen
28.10.2016 14:29Статья очень похожа на организацию скрама, аджайл это более общее понятие.
Можно было бы еще добавить тему соблюдение принципов аджайл, чтобы у каждого была памятка :),
AmdY
28.10.2016 14:20Как же надоели эти аджайл укурки, которые наезжают на водопадную модель даже не ознакомившись с наработками хотя бы на уровне ройсовской модели. Принципы аджайла писаны с оглядкой на водопад и не заменяют его, а меняют приоритеты.
А вот скрам как раз нарушает аджайл принцыпы, так как жёстко регламентирует процесс (вроде дейли статус-митингов). Спринты обычно имеют жёсткие рамки и мешают реагировать на изменения. При этом скрам вовсе не говорит о методиках вроде документации на которую выставляются приоритеты в аджайл манифесте. Скрам просто примазался к модному термину.Coffeeguess
28.10.2016 15:44Agile — это полностью отличная от водопада методология.
Скрам — это Agile фрэймворк.
Agile манифест никогда не приоритизировал документацию а полностью наоборот.AmdY
28.10.2016 16:51Agile — набор принципов и ценностей. Под них подходит куча методологий, в том числе и водопадная модель.
Скрам хотя и называют аджайл фреймворкам, но он рпотиворечит аджайл принципам, я уже выше описал пару из них.
В манифесте написано
>>Работающий продукт важнее исчерпывающей документации;
Что это как не приоритезация, которая говорит, что приоритет у документации должен быть ниже работающего продукта. Этот принцип прекрасно кладётся на водопадну модель, т.к. в то время документации уделялось слишком много внимание, а зачастую компании и вовсе блокировали следующую фазу до окончания документрирования.
Вот объясните, почему водопадная модель не подходит под аджайл принципы?Coffeeguess
28.10.2016 17:22-1Начнем с того что Agile и Waterfall — это 2 абсолютно разные модели.
Waterfall — Это жесткая можешь основой которой является план. Стоимость любых изменений в Waterfall очень высока так как нельзя внедрять новые идеи клиента в процессе работы. Все изменения должны идти новым циклом. Waterfall — это фиксированная стоимость и как модель — не приемлет изменений стоимости.
Waterfall наиболее приемлемо использовать когда:
- Требования известны, понятны и зафиксированы.
- Нет проблем с доступностью ресурсов нужной квалификации
- В относительно небольших проектах.
Agile же — это гибкая методология основой которой являются
- прозрачность(Все знаю кто что делает)
- инспекция (Работа всегда проверяется. На каждом этапе)
- адоптация (Процесс можно корректировать)
В Waterfall как минимум отсутствует возможность корректировки процессов и подключение тестирования на ранних стадиях. Паралелить процессы эта методология так же не позволяет.
Что же касается непосредственно прописаныx принципов Agile:
- Наивысший приоритет — удовлетворение пользователей.
- Изменение требований приветствуется.
- Работающий продукт следует выпускать как можно чаще.
- Представители бизнеса и разработки должны работать вместе ежедневно.
- Над проектом должны работать мотивированные профессионалы.
- Непосредственное общение является наиболее практичным и эффективным.
- Работающий продукт — основной показатель прогресса.
- Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно.
- Постоянное внимание техническому совершенствованию и качеству проектирования повышает гибкость проекта.
- Простота — искусство минимизации лишней работы — крайне необходима.
- Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
- Команда должна систематически анализировать возможные способы повышение эффективности и соответственно корректировать стиль своей работы.
Если Вы работаете по Waterfall и он адаптирован под вас — это не waterfall. Принцип водопада в том, что назад вернуться нельзя.
Scrum — максимально точно отображает Аgile принципы, если это точный Scrum а не Скрамбан или Скрамно. По этому он и является максимально востребованным Agile фреймворком.
>>Работающий продукт важнее исчерпывающей документации;
Как вы дадите точную оценку и составите план работы в Waterfall не имея подробного технического задания и оценок работ?AmdY
28.10.2016 17:42+1Проблема водопадной модели в том, что большинство знает о ней только как об антиподе гибкой методологии и судят не удосужившись даже ознакомиться с первоисточниками. Вроде этого
http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
Водопадная модель лишь определяет этапы необходимые для разработки, определяет порядок их следование. Но при этом разрешает возвращение на любой из предыдущих этапов вплоть до сбора новых требований и составления нового плана. Это полноценная итерационная система, которая гораздо гибче идиотских фиксированных спринтов в скраме.Coffeeguess
28.10.2016 17:48Я не согласен с Вами только в том что Waterfall подходит под Agile принципы.
Coffeeguess
28.10.2016 17:25Я не защищаю Agile и не обижаю Waterfall. Я работаю и с тем и с тем.
Я просто хочу сказать что у каждой модели есть свои плюсы, но я конкретно, как и многие, выбираю Agile.
Это к теме об укурках.
M-A-XG
Нужно не методологиями пользоваться, не понимая их, как культ карго, а своей головой.
lookid
Либо проекты свои показывайте, а точнее продукты. Либо вам на woman.ru
zenkz
Зря вы так. Как я понял M-A-XG не против использования методологий, а за их разумное применение.
К примеру, часто очень хорошим вариантом (особенно при работе с гос. заказчиками) является комбинация Waterflow и Agile). Т.е. документация и доставка выполняется по Waterflow (чаще c итерациями), а раработка — с использованием части практик Agile, но владельцем выступает не заказчик, а аналитик или ПМ. Это позволяет, с одной стороны, иметь полноценную документацию, а с другой — более гибко вести разработку и контролировать прогресс работы.