Комментарии 15
Понятно, что проделана большая работа — но остается много вопросов.
Первое — зачем? Понятно, что можно из буханки хлеба сделать троллейбус, научить медведя ездить на велосипеде, и научить зайца курить — но есть ли от этого польза? Если верхний уровень управления сидит в водопадной модели и предпочитает лить ресурсы в фазы планирования — какой смысл играть в спринты внизу? Мне кажется, что при этом получается опять вариант карго-культа, когда от agile остаются, в основном, ритуалы. Ибо как вы не крутитесь в спринтах, деньги и время у вас уже зафиксированы. Такое может прокатывать только если оценки времени в водопаде даны с бо-о-льшим запасом, и в терминах гибкой методологии — у вас фиксированный скоуп, но вы можете хотя бы управлять временем (и через это — ресурсами).
Второй момент — представление "разработки ПО" как проекта является ошибочным (в том числе и в голове высокого начальства). Ибо подразумевает, что есть момент где ПО написано, сдано в эксплуатацию и к нему больше не прикасаются. В 99.9% случаев — это не так. Соответственно, команда обеспечивает не только создание, но и весь life-cycle приложения, а это уже не проект — или проект, но очень длинный. Или даже управление портфелем приложений в команде...
Третий момент — почему бы тогда банку как таковому не взять SAFe? Там это немного логичнее будет происходить — на уровне руководства будут определены приоритеты, потом планирование инкремента даст вам роадмап на 3 месяца, а потом вы в рамках этого уже живите в недельных или двухнедельных спринтах...
В четвертых, мне кажется что мы выливаем ребенка вместе с водой. Смысл гибкой методологии не в том, чтобы устроить спринты, а в том, чтобы максимально сократить время "скрытой" разработки любой фичи. В водопаде вы обычно идете от входов системы к выходам. А в agile, вы наоборот, смотрите — какие выходы вы обязаны выдать вашим внешним или внутренним клиентам в рамках проекта — и любой ценой пытаетесь дать им хотя бы что-то похожее не реальный результат как можно раньше. Потому что моя практика показывает — все эти бизнес-анализы, подписание требований кровью и прочие ритуалы — не гарантируют что вам в рамках проекта ставят правильные цели. Люди врут (в том числе сами себе), люди ошибаются, люди не предвидят последствий, и много еще чего "не!". Единственный способ убедиться что люди захотели того, что им действительно надо и смогут что-то улучшить с помощью ИТ-продукта или данных — это дать им хоть в какой-то степени пригодный продукт или данные, и попросить попробовать им пользоваться. После этого они мгновенно вам начнут рассказывать — что с этим не так. И начнется feature creep. Который страшен в каскадной модели — ибо время и ресурсы уже зафиксировали, и приветствуется в agile — ибо чем раньше мы начнем узнавать истинные запросы, тем лучше. Понятно что бизнес не может весь жить по Agile (сомневающимся я предлагаю отказаться от получения фиксированной зарплаты каждого 10-го числа, и перейти на гибкую модель — когда платить будут неизвестно когда и неизвестно сколько). Но опять же, SAFe вы можете рассматривать как короткие водопады по 3 месяца. Тоже есть шанс наделать что-то не то — но хотя бы потери от этого ограничены.
В общем, у меня вопросы к попыткам скрещивания честного водопада на верхнем уровне и честного аджайла внизу — или водопад нечестный получается, или аджайл...
Спасибо Вам за комментарий!
Зачем? Для создания решений и продуктов, конкурирующих с лидерами рынка.
Waterfall ни когда не заканчивается в срок и бюджеты… «не так страшны первые 80% проекта, как его оставшиеся 80%», плюс заказчик на входе в проект не знает, что ему нужно, и за время проекта требования меняются, так что Waterfall обречён давать результат, далеко отличный от реальных потребностей.
Используя гибридный подход нам удаётся делать конкурентные продукт, плюс Заказчик на среднем уровне втягивается и начинает работать по Agile.
Вы абсолютно правы, для входа в проект должен быть запас по срокам и бюджетам, об этом как раз описано в данной статье с привязкой к предполагаемому обьему предстоящего проекта (запас на риск, запас на новые требования) наша практика.
Результат фиксирован без детализации, для небольших задач, а для крупных проектов, постановка является первичным соглашением, и меняется на протяжении проекта. В статье это описано.
По второму моменту, если проект бессрочный, оформляется следующий этап, если конечный, оформляется поддержка и в рамках неё формируется скоп задач.
Третье, SAFe снова про гибкие методологии с самого верха до продуктовых команд. Гибрид возникает когда нет возможности продать подход ТОП менеджменту.
Четвертое, согласен, для этого и идёт планирование в гибкой чести методологии, по принципам Agile, с определением самых важных и быстрых фич. Данное планирование перекраивает водопадный план. Когда изменения существенны, пересмотр плана выносим на ТОП уровень.
Сложная, но подъёмная задача в данном процессе, управление ожиданием, и гибридная методология именно про это.
Комбинация каскадных и гибких методик весьма распространена. Дело в том, что гибкие методики очень хорошо ложатся на процесс разработки софта. И практически только на него. Для софтверного бизнеса даже и не понятно зачем применять что-то ещё, кроме гибких методик. Но если проект включает в себя что-то ещё, кроме чисто разработки - строительство ЦОДа, разворачивание инфраструктуры, внедрение стандартного софта, обучение пользователей, стройку, прокладку кабелей, реорганизацию предприятия - то я вообще не представляю как это можно делать спринтами, это чисто каскадные проекты. Я сталкивался с внедрением стандартного софта гибкими методиками. Точнее попытками натянуть сову на глобус и выдать это за гибкую методику. По факту это очень сильно за уши притянуто к эджайлу, а не деле тот же каскадный подход.
По тому, если проект включает в себя разработку и реорганизацию и внедрёж и инфраструктуру и обучение и пр. - то его вести надо именно по гибридной методике - на верхнем уровне каскад, а в разработке - спринты. Поскольку автор из банка, а не из софтверной компании, у него как раз такая ситуация.
Ну это потому что когда дело касается харда — у людей лучше срабатывает инстинкт самосохранения. Вот представьте, что вы построили людям оперный театр — со сценой, окрестровой ямой, и так далее… И тут на совещании креативный директор радостно сообщает, что они подписали контракт на выступление балета на льду — и спрашивают, какую кнопку надо нажать чтобы оркестр с ямой поднялся наверх, а сцена замерзла?.. Такого директора тут же повезут в дурку — ну потому что… А софт — в порядке вещей...
Дело не в инстинкте. Вы не можете строить самолёт спринтами. Сначала сделать с одним мотором, показать заказчику, потом сделать с двумя, потом переставить крыло, потом переделать фюзеляж и пр. Вы идёте по каскаду - эскиз-проект, расчёты, чертежи, постройка, испытания, приёмка. Точно так же с домом - вы не можете в первом спринте построить стены, во втором приделать фундамент, в третьем переделать фундамент, потом вписать бассейн, потом убрать бассейн и пр. Такие фокусы только с софтом проходят.
А вот не факт. Семолеты часто появляются с двигателями первого этапа. Редко самолёты разрабатывают "с ноля". Почти всегда есть куча модификаций. Вспомните последний боинг и историю с движками нарушающими центровку и не помещающихся под крылья. В ПО +- так же. Что бы что-то показать нужно инвестировать в базовые вещи. Базовый фронт, авторизация, хоть какой-то бэк (кликбельные прототипы не рассматриваем). В самолетостроении "база больше". А разработка движков и прочего проходит множество итераций (спринтов). И с домом тоже есть примеры. Каркасные дома, плиты сразу приезжают на сборку с окнами. Все это вопрос скоупа работ и объема спринта.
От двигателя первого этапа до второго "спринт" занимает лет пятнадцать :-) И вообще к эджайлу это никакого отношения не имеет, это планируется заранее со всеми этапами каскадной модели, а не то, что вы показали заказчику самолёт с одним мотором, он поцокал языком и говрит: "а внесите ка в бэклог - давайте поставим вместо него другой". Если он даже такое скажет - в проект будут внесены изменения по всем правилам каскадной модели.
Тут уже ответили, но я добавлю. В авиации используются прототипы. Во-первых, это модели для аэродинамических испытаний. Причем — разного размера, полных и частями. И их неоднократно переделывают, пока не добьются нужных характеристик. Сейчас, конечно, в основном строят и "продувают" цифровые модели — но все-равно, чтобы не закладываться на возможные ошибки и погрешности софта — потом делают модель и дуют ее в настоящей аэродинамической трубе.
Дальше — отдельные элементы конструкции проверяются на т.н. "бастардах". Двигатель ставят новый одним из четырех на каком-то большом самолете. Иногда модифицируется самолет так, что у него в носу дополнительный движок можно поставить… Пилотажное оборудование обкатывается на реальных опытных бортах (благо, шины сейчас практически унифицированы). Даже крылья или их секции могут облетывать — широко известный пример когда Туполев ввиду сложности проектирования и расчета крыла для Ту-144 делал прототип на базе Миг-21 с оживальным крылом. Это не есть agile прямо вот в том виде как в софте — потому что конечного пассажира на бастардах не катают — но внутренние клиенты (кб, будущие эксплуатанты) получают доступ к прогнозам и результатам испытаний задолго до того как будет кровью подписано ТЗ на разработку и контракты на будущую поставку чего-либо.
Это вообще не эджайл ни разу. Это всё предусмотрено ГОСТом на проектную документацию. Вы можете исследовать, испытывать, пробовать, переделывать, но это не отменяет прохождения всех этапов каскадной модели и соответствующей отчётности по ним. Никакого MVP вы не получаете ни в одном из ваших "спринтов" и первый и единственный раз вы получаетет готовый продукт только после приёмки, пройдя все этапы испытаний. По эджайлу вы можете после каждого спринта выкатывать в прод инкремент продукта и ваши юзеры могут ими наслаждаться каждые 2 недели. Какой нибудь Яндекс.Такси обновляется себе постоянно, все счастливы. По каскаду ваши юзеры не получат обновлённый продукт после продувки очередной модели в трубе. От того, что кто-то испытал новое крыло на МиГ-21 ни один пассажир на Ту-144 не полетел ни с новым ни со старым крылом.
А в чем новизна? Это же обычное дело: верхнеуровневое планирование осуществляется в виде гант-чарта (водопадной модели), а разработка -- по скраму.
Не тогда, когда и спрашивать по Ганту. Дало в деталях. что для нас оказалось важным: Управление ожиданиями, Управление рисками, управление новыми фичами, система определения запаса времени и бюджета.
В общем, при всем уважении, вы просто заново изобрели велосипед. Но то, что смогли извлечь из этого пользу -- это безусловный плюс )
Сколько методик не изучал, ответы на свои вопросы получил «изобретая велосипед», если для вас, это так очевидно, поделитесь пожалуйста ссылки на данные материалы.
Думаю всем читателям это будет так же полезно. Спасибо!
Ну потому что управление рисками, равно как и бюджетирование не имеет никакого отношения к методологии разработки софта. Поэтому вы и не находили там ответы на вопросы.
Между тем материалов по риск-менеджменту, бюджетированию, ченч-менеджменту в сети великое множество -- можно брать любой материал, который кажется более понятным и начинать использовать и совершенно неважно, какую методологию вы используете на уровне команд.
Гибридная методология ведения проектов WaterScrum как мы это настроили