Комментарии 5
Хорошая статья, но почему опять противопоставляют waterfall и agile? Все то же самое можно и waterfall делать, к примеру «take a bite»...., за исключением некоторых деталей…
Привет! Спасибо за отзыв!
Вся суть Take a bite в том, что мы идем короткими итерациями в неделю-две. В тех кейсах, в которых мы применяли этот подход, у нас не хватало технического понимания или бизнес-определенности.
На мой взгляд, задумываться о применении Waterfall стоит, только если есть четкое и понятное ТЗ, вы договорились с заказчиком обо всех нюансах и при этом не ожидаете каких-либо особых технических или продуктовых рисков.
В моем представлении это совершенно разные подходы. Если честно, я с интересом узнал бы ваше мнение, как их можно было бы объединить :)
Андрей Грицевич
Вся суть Take a bite в том, что мы идем короткими итерациями в неделю-две. В тех кейсах, в которых мы применяли этот подход, у нас не хватало технического понимания или бизнес-определенности.
На мой взгляд, задумываться о применении Waterfall стоит, только если есть четкое и понятное ТЗ, вы договорились с заказчиком обо всех нюансах и при этом не ожидаете каких-либо особых технических или продуктовых рисков.
В моем представлении это совершенно разные подходы. Если честно, я с интересом узнал бы ваше мнение, как их можно было бы объединить :)
Андрей Грицевич
Привет! Так waterfaal-модель так же позволяет делать похожими способами, такой подход применяют в авиации (stage-gate). Нет необходимости на старте иметь точное утвержденное ТЗ. Глобально стадии создания продукта разбивают на элементы и итерационно идут к продукту, начиная от частных ТЗ по компонентам/элементам схлопывая в общее ТЗ а потом также по системам/подсистемам разрабатывают компоненты договорившись об интерфейсах или требования к ним. Продукт разбивают на элементы, потом по элементам делают предварительный состав работ длительностью не более 2-х недель и внутри этих 2-х недель спокойно живёт сейчас популярный agile, а до этого принцип «локоть соседа». Разработав связку PBS-WBS-RBS-CBS получаем инструмент для управления и прогнозирования…
Привет. Интересно… Мне коллеги как-то рассказывали, что waterfaal шагнул далеко вперед, и теперь это не такая простая линейная структура, как было вначале. То, что вы рассказываете, как раз это подтверждает :)
С другой стороны, насколько я помню, сам автор этой методики был против того, чтобы ее пытались применить в любой ситуации. Сейчас для IT-продуктов на крайне изменчивом рынке, как мне кажется, более интересен подход, где не просто управляют зависимостями (как вы описали), а полностью отказываются от них.
Есть Владелец Продукта со своим видением того, что он хочет, и кросс-функциональная команда(ы), которая поставляет ценность клиенту. Каждая команда может вносить правки в любой компонент. В команде все вместе прорабатывают требования, разрабатывают, тестируют и деплоят. Есть идея вводить ограничение, что каждая команда не может работать больше, чем над одним элементом Бэклога одновременно (wip limit = 1 на кол-во историй в работе). Это дает ультимативную гибкость — возможность быстро и дешево остановиться и пойти другим путем к цели. Подробнее почитать можно в Google по запросу: one piece flow agilix (первая ссылка).
Мы сейчас к этому стараемся идти.
Андрей Грицевич
С другой стороны, насколько я помню, сам автор этой методики был против того, чтобы ее пытались применить в любой ситуации. Сейчас для IT-продуктов на крайне изменчивом рынке, как мне кажется, более интересен подход, где не просто управляют зависимостями (как вы описали), а полностью отказываются от них.
Есть Владелец Продукта со своим видением того, что он хочет, и кросс-функциональная команда(ы), которая поставляет ценность клиенту. Каждая команда может вносить правки в любой компонент. В команде все вместе прорабатывают требования, разрабатывают, тестируют и деплоят. Есть идея вводить ограничение, что каждая команда не может работать больше, чем над одним элементом Бэклога одновременно (wip limit = 1 на кол-во историй в работе). Это дает ультимативную гибкость — возможность быстро и дешево остановиться и пойти другим путем к цели. Подробнее почитать можно в Google по запросу: one piece flow agilix (первая ссылка).
Мы сейчас к этому стараемся идти.
Андрей Грицевич
Привет! Про классику (PMBoK,ICB,P2M...) много заблуждений и мифов… Автор как раз был сторонником что б в его модели была с итерациями, но люди как обычно, недослушали, додумали, ленились и т.п… waterfall. Да для значительной части применим подход обособления элементов, но есть комплексы которые так создаваться не могут, поищите статью тех. дира гугла и он описывал квадрант применимости гибких и классических методик.
ProdOwn с командой не противопоставление РП, разные роли для разных задач. Поищите доклады с таким опытом на конференции ADVANTA. Описанный вами framework я знаю, хорошо что он у вас работает и даёт ожидаемый результат. Удачи в WP=2, и Velocity>3SP)) P.S. Оказывается у нас есть общие знакомые
ProdOwn с командой не противопоставление РП, разные роли для разных задач. Поищите доклады с таким опытом на конференции ADVANTA. Описанный вами framework я знаю, хорошо что он у вас работает и даёт ожидаемый результат. Удачи в WP=2, и Velocity>3SP)) P.S. Оказывается у нас есть общие знакомые
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Take a bite и «Команда Тигров»: опыт применения Agile-методов для решения непонятных задач и создания больших фич