На первый взгляд проблемы организации будут выглядеть как «слишком много задач» или «не достаточно ресурсов», или «нестабильная ситуация на рынке». При ближайшем рассмотрении, ключевые причины окажутся дурными привычками, сформировавшимися «рефлексами» и заблуждениями.
Одна из очень известных компаний, которая была примером успешного применения Scrum в 1997 году, обратилась за помощью в Danube Technologies, Inc. в 2009 году, потому что «рынок» показал, что они оказались менее гибкими, чем конкуренты. Начинания по внедрению Scrum, которые начались 1997 году, по-видимому, не могли выдержать десятилетие сосуществования с проблемами, присущими крупным предприятиям. К сожалению, большинство попыток внедрить Scrum в крупных организациях не приводит к долговременным преобразованиям. Препятствия для внедрения Scrum обычно также мешают достижению успеха в бизнесе в целом, а устоявшиеся организации обычно неохотно избавляются от них.
Препятствие #1: Наивный менеджмент ресурсов
В Руководстве PMBOK написано:
«зачастую возникает необходимость увеличения бюджета, чтобы добавить дополнительные ресурсы для выполнения того же объема работ в более сжатые сроки»В отношении программного обеспечения, Фред Брукс (в книге «Мифический человеко-месяц») дает утверждение, которое противоречит предыдущему:
«Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше»
Чтобы разрешить этот парадокс, давайте рассмотрим определение «ресурса».
Когда работа представляет собой разработку нового продукта, соответствующие ресурсы неосязаемы: понимание задачи, обучение, межличностное общение и инновации. Scrum-команды пытаются максимизировать их, создавая состояния индивидуального и группового «потока». Как утверждает психолог Mihaly Csikszentmihalyi: «[в потоке] вы полностью погружены в задачу, и вы используете все свои навыки на предельном уровне».
Члены Команды Разработки (Development Team) Scrum интенсивно взаимодействуют друг с другом, чтобы создавать продукты в соответствии с целями, которые они постоянно обсуждают с Владельцем Продукта (Product Owner). Владелец Продукта отвечает за принятие бизнес-решений в команде. Результаты работы демонстрируются в конце каждого Спринта (Sprint) фиксированной длительности (например, каждые две недели). Во время Спринта члены команды развивают заинтересованность в общих целях и учатся управлять друг-другом для их достижения. Даже при идеальных условиях (в том числе, говоря о помещении, где работает команда) команде требуется принять участие в нескольких спринтах, чтобы достичь успеха, и около года, чтобы реализовать свой потенциал полностью. Широко известно описание этого органического процесса — «формирование, штурм, нормирование, выполнение» модели Брюса Такмана. (Bruce Tuckman, “forming, storming, norming, performing”).
Наивно рассуждать о людях, как о ресурсах. Новые члены в команде не будут гарантировать увеличение понятия «ресурса команды», и могут даже уменьшить его. После года работы по Scrum один из моих клиентов сказал мне: «После того, как команда сформирована, лучше потерять одного члена команды, чем добавить нового». Совсем другое, если Scrum команда сама пришла к решению о найме нового сотрудника, тогда добавление нового члена команды будет хорошим решением. Но, даже при возможности команды самостоятельно нанимать сотрудников, нецелесообразно увеличивать размер команды больше семи человек.
В некоторых случаях увеличение команд может привести к ускорению работы, если это происходит с учетом того, что это нематериальные, неисчисляемые ресурсы.
Препятствие #2: Команды, организованные по функциональной принадлежности
Scrum?команды это кроссфункциональные команды, которые стараются создать тщательно протестированный инкремент продукта каждый спринт, постепенно наращивая функциональность. Самая популярная книга по Scrum использует фразу “потенциально “Готового” к выпуску Инкремента продукта” (“potentially shippable product increment”) 18 раз. Несмотря на это, я встречаю людей, которые утверждают, что «практикуют Scrum», используя при этом «аналитические спринты» или «спринты проектирования» в начале проекта, откладывая интеграцию и тестирование на потом, и привлекая разные команды для выполнения каждой части работы. Привычки, приобретённые из Водопадной Модели Управления Проектами, скрывают риски до тех пор, пока не становится слишком поздно что-то делать.
В Scrum, в течение каждого Спринта требуется сочетание разных мероприятий, присущих разработке. Мы получаем гибкость благодаря непрерывному анализу требований, непрерывному проектированию, непрерывной интеграции и непрерывному тестированию, все члены команды вместе.
Препятствие #3: Команды, организованные по архитектурно-компонентной принадлежности
Команды, созданные для работы над одним компонентом, сокращают возможности бизнеса по переориентации возможностей продукта, увеличивают количество узких мест в коммуникации с менеджерами и владельцами продукта и привносят дополнительные интеграционные риски.
Такие команды были бы эффективными, если бы разработка нового продукта была бы столь же предсказуемой, как производство. На практике, приоритеты меняются, а оценки оказываются неверными. Поэтому трудно привлечь нужных людей в нужное время, чтобы вести разработку, которая может влиять на несколько компонентов.
Противоположностью Компонентной Команды является Функциональная Команда, ориентированная на разработку новых возможностей продукта (feature team). Функциональная Команда охватывает как компоненты, так и дисциплины, и, таким образом, способна реализовывать функциональные задачи для бизнеса в тонких, полностью протестированных «вертикальных срезах» продукта. Такой подход призван заменить концепции прошлого века, основываясь на концепциях автономности команд, самоорганизованности и ответственности. Бэклог продукта Функциональных Команд основан на нуждах бизнеса, а не на зависимостях от технологий. Если вы до сих пор используете Диаграммы Гантта, скорее всего у вас пока не организованы Функциональные Команды.
Создание Функциональных Команд связано с затратами: разработчики будут должны освоить новые навыки, что замедлит их в начале. К счастью, большинство разработчиков любят осваивать новые навыки. Методы, такие как назначение технического «хранителя компонент» (“component guardian”) для каждой области могут помочь защитить архитектурную целостность, поскольку команды учатся. Как и при любой масштабной разработке, непрерывная интеграция (автоматические тесты, выполняемые гораздо чаще, чем один раз в день) имеет решающее значение для предотвращения необнаруженных дефектов общей работоспособности продукта.
После того, как организация научится управлять Функциональными Командами, следующим шагом может быть — создание Функциональных Команд Общего Назначения (general purpose feature teams) с минимальными зависимостями от функциональных областей. Этот процесс может потребовать годы непрерывного обучения внутри организации.
Препятствие #4: Отвлечение внимания
В типичных крупных организациях тратятся миллионы долларов из-за ненужного переключения между задачами. Командам не хватает сфокусированности и месяцев стабильности в отношении состава команды, чтобы достичь состояния самоорганизации, необходимого для высокой производительности и качества. Некоторые люди постоянно оказываются на нескольких «критических путях» одновременно, что серьезно ограничивает всеобщую производительность. Для эффективного масштабирования эти люди должны стать наставниками, а не исполнителями задач. Чтобы увеличить их влияние, они должны отказаться от некоторого контроля.
Традиционные методы управления, которые усиливают специализацию, только усугубят проблему. Работу следует давать Scrum-команде во время встречи для Планирования Спринта (Sprint Planning Meeting). Когда менеджер не берет это во внимание, назначая задачи на конкретных исполнителей, у специалистов не оказывается возможности наставлять и обучать других важным навыкам. На одной из встреч для Планирования Спринта я столкнулся с тем, что первый вопрос, который был задан, был: «Кто у нас будет работать на этом Спринте?». Люди, которых постоянно дергают, не будут заниматься обучением остальных, хоть это и ожидается от Scrum-команд. И организации закапываются в эти проблемы каждый день все больше и больше.
На более высоких должностях еще больше проблем, связанных с многозадачностью, отвлечением внимания, беспокойства и неспособностью получения контроля над происходящем. Владелец Продукта, на том же самой встрече, пришла раздраженная, с опозданием на час, и снова убежала через 10 минут. И мне сказали, что так происходит постоянно.
А после обеда, руководитель не смог посветить себя встрече с 60 своими сотрудниками потому, что он параллельно пытался решать другую проблему посредствам сервисов в своем телефоне. Случайный наблюдатель этих сцен не мог бы предположить, что эти бешеные рабы, управляемые событиями, были ответственны за стратегию дальнейшего развития.
Эффективная горизонтальная коммуникация между Scrum-командами помогает Владельцам Продуктов спокойно сосредоточиться на таких обязанностях, как определение приоритетов работы и определение окончательных требований.
Препятствие #5: Нежелание непрерывно пересматривать, приоритезировать и детализировать Бэклог Продукта
При разработке продукта, скорость обнаружения новых задач, которые необходимо сделать, обычно опережает скорость самой разработки. Чтобы справляться с этим, Владелец Продукта должен проводить Уточняющие Встречи (Refinement Meetings) для пересмотра, приоретизации и уточнения задач в Бэклоге Продукта каждый Спринт. Когда в Бэклоге появляются слишком большие задачи («epics»), необходимо находить их ключевые аспекты и делить их на маленькие подзадачи (обычно называемые «User Stories»). Владелец Продукта управляет объемом работ, решая, какие задачи войдут в Релиз, с учетом данных о скорости разработки и объеме работ, выполняемом в течение Спринта.
Препятствие #6: «Технический Долг»
Проблемы управления организацией, в конечном итоге, видны в исходном коде. И «технический долг» становится причиной проблем в продукте и высокой стоимости изменений. В идеале, регрессионные тесты можно автоматизировать с помощью того же языка программирования, что используется при разработке продукта, без использования проприетарных инструментов, которые только усиливают зависимость от специфичных знаний. Навыки, такие как Test Driven Development (TDD), доказали свою ценность в 20-м веке. В 21-м веке от любого разработчика ожидается навыки владение гибкими методологиями. И команды, которые этими навыками еще не обладают, должны пытаться работать с «вертикальными срезами задач», пока они не научатся.
Препятствие #7: Нежелание меняться
Scrum выделяет по одному человеку на команду (ScrumMaster), чтобы уделять основное внимание выявлению и преодолению таких препятствий. Это требует смелости, воображения и поддержки со стороны руководства. Слишком мало Scrum-мастеров уделяют должное внимание таким проблемам, а руководство часто не поддерживает тех, кто это делает.
«Слишком много задач» или «недостаточно ресурсов», или «нестабильная ситуация на рынке» не является хорошим оправданием, чтобы не внедрять Гибкие методологии, специально предназначенные для решения этих проблем. И люди, ответственные за изменения, должны быть лучше подготовлены к преодолению Препятствий для внедрения Гибких методологий, осознавая, что ключевые причины проблем в сохранении дурных привычек, сформировавшихся «рефлексах» и заблуждениях.
Текст оригинальной статьи: 7 Obstacles to Enterprise Agility
Автор: Michael James
Перевод: Daniel Chernyshev
Переведено с согласия автора.
Комментарии (45)
VolCh
23.04.2017 12:47Главная причина невнедрения — ответственные лица не видят чем внедрение улучшит ситуацию. Или понимают, что в долгосрочной перспективе улучшит, но здесь и сейчас ухудшит…
vadim1406
23.04.2017 14:08+3Работаю в такой организации :) Как раз пытаются «внедрить Agile» в виде SCRUM. Такие смешные… Во-первых, конечной цели нет — т.е. цели такие:
— сделать все дешевле
— четко знать, какой разработчик что делает, чтобы все были при деле
— ну и потому что Греф сказал, что надо быть Agile…
А так — все как написано — четкое разделение труда, кросс-функциональность встречается в штыки, еще больше наваливание работы, и прочее.
mamayama
23.04.2017 16:03В отношении программного обеспечения, Фред Брукс (в книге «Мифический человеко-месяц») дает утверждение, которое противоречит предыдущему
Брукс создавал операционную систему, если вы не в курсе.
И народу там было очень даже дохрена.
Если же речь идет о том, кто быстрее сделает сайт — программист-многорук
или отдельно: бэкендер, фронтендер, дизайнер — то я поспорю что вы не правы.
Брукс имел ввиду другое.dchernyshev
23.04.2017 16:34В статье говорится о том, что есть два противоречащих утверждения (в руководстве PMBOK и в книге Брукса «Мифический человеко-месяц»), и оба эти утверждения доказали свою состоятельность.
Причина этому противоречию в понятии «ресурс» в каждом из высказываний. Руководство PMBOK — это более общее руководство по управлению проектами в различных сферах. И понятие «ресурса» в PMBOK включает больше, чем сотрудники, тем более сотрудники, разрабатывающие новый «продукт». И именно о таких сотрудниках говорит Фред Брукс.
То есть противоречия на самом деле нет, если брать во внимание, что Брукс говорит о «нематериальных» ресурсах, а PMBOK обобщает понятие ресурса.
ACPrikh
24.04.2017 13:42«Понимание задачи, обучение, межличностное общение и инновации» — это никакие не ресурсы. Из всего можно принять с натяжкой «затраты на обучение».
Эджайл — это методика, основанная на убеждении, что если пороть кодера нагайкой, то он быстрее и больше накодит. Я думаю, этой моде осталось года два — три от силы.
Успех внедрения методики не в самой методике, а в сопутствующих вложенных ресурсах в проект.
FedjaNew
24.04.2017 15:51Забавно, что почти каждое очередное «втюхивание» Agile сопровождается сравнением с waterfall.
А вот plan-driven методологии (в том числе и waterfall) живут и работают сами по себе, никого с собой не сравнивая.dchernyshev
24.04.2017 16:07Waterfall — это один из «китов» проектного менеджмента. Причем с очень широкой областью применения и степенью распространенности. Мне кажется, в этом причина подобных сравнений.
Но следует отметить, что Project Management Institute (PMI) , авторы PMBOK (руководство, на котором основывается Waterfall), организация, выдающая один из самых уважаемых и признаваемых сертификатов в области проектного менеджмента — PMP, также выдает сертификаты в области управления проектами посредствам Agile методологий — PMI-ACP.
Этот факт, по моему мнению, свидетельствует о том, что даже PMI признает Agile, понимая его различия в сравнении с Waterfall, и разные области применения. Признает право на существование различных подходов.FedjaNew
24.04.2017 16:32PMOK вообще не «заточен» на какую-либо методологию.
Подозреваю что те, кто не хочет прочитать PMOK, создают мифы про него :)
Посмотрите, хотя бы, сюда: https://habrahabr.ru/sandbox/108060/
Для сведения: цифры там означают не последовательность, а идентификацию.dchernyshev
24.04.2017 16:51Спасибо за ссылку!
Подозреваю что те, кто не хочет прочитать PMOK, создают мифы про него :)
Вы затронули очень важную тему. Я бы продолжил ее следующим образом: «Подозреваю, что все противостояние между методологиями развивают люди, которые не потрудились из изучить»
Чаще всего, в сравнении Waterfall и Agile происходит сравнение нечто, что нельзя отнести ни к какой-то Agile методологии, ни к Waterfall
Наличие ТЗ, после которого «херачим » до окончания срока, а потом мучаемся на этапе сдачи продукта, потому как Заказчик получил вообще не то, что хотел. И снова «дохерачиваем», чтобы подписать акт о приёмо-передачи — Это НЕ Waterfall. Это разработка «на коленке» с наличием какого-то ТЗ.
Наличие понятия Спринта, хотя продолжается то же самое «херачим» что-то, но каждые 2-3 недели смотрим, на то, что получилось, и снова «херачим» код. А потом и вообще забываем даже о том, для чего нам Спринты. Без цели спринта, без фидбэка со стороны заказчика, без постоянного процесса интеграции, без переоценки Бэклога — Это не Scrum. Это снова разработка «на коленке»
Вот и выходит, что не зависимо от используемых терминов, довольно часто сравниваются не методологии, а очень искаженное представление о них.FedjaNew
25.04.2017 10:41dchernyshev > Вы затронули очень важную тему.
Я даже написал кое-что по этому поводу.
Но статью «зарубили». Возможно, лоббисты S©rum:)dchernyshev
25.04.2017 16:40Если вы согласитесь отправить статью мне в ЛС, буду рад быть среди первых читателей. И обещаю написать Вам честный отзыв.
Lofer
24.04.2017 21:09PMBOK (руководство, на котором основывается Waterfall)
Когда уже читать научатся «проповедники Agile», такое впечатление, что специально обманывают.
1.1 Цель Руководства PMBOK®
Руководство PMBOK® выделяет ту часть Свода знаний по управлению проектами, которая обычно считается хорошей практикой. «Обычно считается» означает, что описываемые знания и практики применимы к большинству проектов в большинстве случаев, причем относительно их значения и пользы существует консенсус. «Хорошая практика» означает, что в целом существует согласие относительно того, что правильное применение этих знаний, навыков, инструментов и методов способно повысить вероятность успеха для широкого диапазона различных проектов.
«Хорошая практика» не означает, однако, что описываемые знания должны всегда одинаковым образом применяться ко всем проектам; организация и/или команда управления проектом самостоятельно определяет применимость этих знаний к тому или иному проекту.FieryCat
02.05.2017 15:08Руководство PMBOK® состоит из ~600 страниц, у Agile всего одна:
http://agilemanifesto.org
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану
Waterfall, в большинстве случаев, и отличается тем, что согласование плана важнее всего процесса, а разработчики «общаются» с заказчиком через менеджеров.
В рамках Agile/(Scrum/Kanban|XP|...) первоначальные условия могут измениться на диаметрально противоположные. Здесь вообще отсутствует что-либо, где можно было бы зацепиться за отсутствие гибкости у Agile или неприемлемость Waterfall.FedjaNew
02.05.2017 15:35Опять путаница.
PMBOK НЕ СВЯЗАН с Waterfall и аналогичными plan-driven методологиями.
А agile действительно привлекает для тех, кто «ниасилил» и для кого «многабукфф».
И вообще, сравнение в стиле «в Waterfall — вот так, а вот у нас, в agile все не так и лучше» — это стандартный прием обмана.
А манифест- это просто декларация. Как «Фабрики — рабочим!»FieryCat
02.05.2017 15:50Здесь разногласий нет совершенно. И дело вовсе не в том, что «многабукфф»… а том, как подходит руководство к процессу интеграции тех или иных подходов. В контексте Agile и PMBOK сравнивать вообще нельзя. «Манифест методологии не товарищ». Аля проповедование Agile направлено лишь на один единственный пункт из PMBOK — «Руководство проектом»
… это функция надзора, соответствующая модели организационного руководства и охватывающая жизненный цикл проекта. Система руководства проектом предоставляет руководителю проекта и команде проекта структуру, процессы, модели принятия решений и инструменты для управления проектом, одновременно поддерживая и контролируя проект с целью достижения успеха.
Waterfall был взят лишь в качестве примера, для отражения «Подготовительной и заключительной фаз»
http2
А ниче, что Agile никакая не гибкая методология?.. :)
FieryCat
То, что под Agile могут маскировать всё что угодно, не отменяет её первичных принципов и признаков, как непосредственно гибкой методологии.
VolCh
Как по мне, то Agile — не методология, а набор "первичных принципов и признаков", на базе которых создаются различные методологии, относимые к Agile.
http2
Тогда вообще не использовать слово «Agile», раз 99% неправильно его понимает.
Используйте просто «гибкая методология».
Под Agile обычно понимается Scrum.
VolCh
А Kanban не Agile?
http2
Обычно
А статьи чуть реже, чем всегда, о Scrum.
VolCh
Тем не менее, это не синонимы. И если статья о Scrum, то это явно упоминается.
DzodzikovAK
Поясните
http2
Поясните, чем она гибче водопада.
Вернее, даже водопад в умных руках гибче ее. :)
dchernyshev
На самом деле, многим.
Также можно сказать, что в умелых руках — все будет работать хорошо. В неумелых — все плохо. А также следует четко понимать, что каждая методология имеет свою плюсы и минусы, и области применения.
Но для того, чтобы разговор был предметным, не могли бы вы пояснить ваше понимание слова «Гибкости» в данном контексте.
http2
Я хз.
Берите в том значении, в котором это слово используется в словосочетании «гибкая методология». :)
dchernyshev
Не понимаю вашего ответа.
Сначала вы утверждаете, что:
А на вопрос, что вы понимаете под понятием «гибкости», то есть по каким параметрам сравниваете, вы отвечаете:
Также:
Если говорить об этом значении слова «Гибкость», то хотелось бы узнать ваше мнение, на чем основано ваше утверждение: Но даже в этом случае, предполагаю, что возможно разночтение словосочетания «Гибкая методология». Поэтому для начала хочу спросить, что оно означает в вашем понимании?
http2
Дается утверждение, что Agile гибкая.
Ну так скажите в чем ее гибкость.
А то начали переливать из пустого в порожнее.
dchernyshev
Уважаемый http2, во первых с утверждений начали Вы.
При этом несколько раз вас просили объяснить, как вы пришли к такому мнению, чем, что, и по каким параметрам мерили? Ответа вы так и не дали.Эти вопросы я задавал, чтобы разговор был предметным. Потому как иначе придется угадывать, о чем именно вы имели в виду, так как первое, что я предположил, что Вы хотите обсудить некоторые проблемы каких-то из методологий семейства Agile.
Сейчас же это выглядет так, что Вы не владеете темой, и высказали утверждение, которое принадлежит не Вам. Хотя опыта я вашего и не знаю, и что-то утверждать было бы неправильным с моей стороны.
Итак, «Agile никакая не гибкая методология?»
1) «Agile» переводится на русский, как «Гибкий». Поэтому наверняка вы сравнивали с Водопадной моделью не по смыслу в названии
2) Agile — это не методология. Это семейство методологий, которые придерживаются Agile Манифеста . Это такие методологии, как Kanban, Lean Six Sigma, XP, Scrum. Это разные методологии, имеющие разные степени ограничений.
3) Если сравнивать Scrum, описанный в этой статье, с Водопадной моделью, то Скрам «гибче» в следующих моментах:
— В Скрам есть только 2 жестоких ограничения во время выполнения проекта:
— — Длительность Спринта после его начала
— — Цель Спринта
Также есть пункты, которые говорят о том, что это Скрам. Если их не придерживаться, то это уже не Скрам. Например: единственная роль в Дев. команде, это Разработчик, не зависимо от специализации сотрудника (ДБА, Тестировщих, Кодер, Аналитик и т.д.). Или то, что результатом любого Спринта должен быть потенциально «Готовый» к релизу инкремент продукта.
Водопадная модель имеет жесткие ограничения по разрабатываемому функционалу (ТЕхническому заданию) и срокам разработки (Планом проекта). Можно мне возразить, что в водопадной модели предполагаются заложенные риски, в рамках которых можно что-то поменять? Но это тоже жесткие сроки, которые выделяются на возможные риски в соответствии с их оценкой. Не заложенные изменения можно сделать в рамках «не критического пути», что все-равно не отменяет наличие «критического пути» с его спланированными сроками.
То есть, отличия в самой концепции, подходе к разработке, заложенные в основу каждой из методологий.
4) Ни один опытный человек (как я считаю) не скажет что Водопадная модель — хуже или лучше, к примеру Скрам. Потому как они просто разные. Каждая имеет свои плюсы и минусы. И каждая имеет области наилучшего применения.
То есть можно сказать, что в каком-то конкретном случае Водопадная модель будет работать хуже/лучше Agile модели. Но не в общем.
5) И последнее: Нельзя судить о самой методологии, основываясь на примере ее кривого применения. Как вы сказали, в умелых руках Водопадная модель отлично работает! И я с вами согласен. И добавлю, что в умелых руках, когда человек понимает разницу, плюсы, минуса и области применения, все хорошо работает.
Уважаемый http2, если Вы хотите обсудить какие-то тонкости, прошу Вас, делая утверждения, все-же давать объяснения, на чем эти утверждения основаны. Это поможет не угадывать, что именно вы имели в виду, пытаясь написать Вам ответ.
http2
Я?
А как же заголовок статьи?:
ОК, берем рассматриваемый в статье Scrum (обычно под Agile и понимают Scrum).
О, до Вас дошло. :)
Не после любого спринта можно релизить.
Если это разработка нового продукта, то ничего вы не зарелизите.
А если это правки существующего, то да.
Кто Вам такое сказал? :)
Так какая концепция? Какой подход?
Наличие спринтов якобы с готовым продуктом?
Это фейк, развод лохов.
Ах, уже водопад не всегда хуже? :)
А когда он лучше?
Просто чет нету некривых применений Скрама :)
Везде куча косяков и стало только хуже :)
Рад, что Вы согласились. :)
И от добра добра не ищут. :)
VolCh
В водопаде при изменениях требований пропадает впустую куча проделанной работы по планированию уже не актуальных вещей. В Agile тоже, но горизонты планирования различаются на порядок, если не больше.
Lofer
Если все «прибито гвоздями» на уровне архитектуры, то потери будут большие.
Если изменения поместятся в какоей-то уже распланированное «окно возможностей» то и незаметит никто.
А с нормальной инструментальной поддержкой — перепланировать в виде «что если» и оценить на что повлияет будет тоже в рамках «текущей работы»
http2
Коммент не туда упал :)
VolCh
Я не про архитектуру, архитектура — это собственно разработка, а аджайл, водопад и т. п. — принципы управления разработкой, они для менеджеров прежде всего. И в водопаде можно сделать гибкую архитектуру, и в аджайле можно всё прибить гвоздями.
Я именно про управления разработкой: менеджеры и прочий бизнес могут потратить кучу времени на составление планов, согласования, бюджетирование и т. д. на годы вперёд, а потом всё это окажется мусором.
http2
Сколько эти горизонты планирования?
То есть в Agile, начиная делать сайт вообще не понимают, что хотят получить или как? :)
Типа строим дом, но не планируем по началу канализацию, а потом быстренько покоцалили фундамент и ок? :)
Lofer
Иногда и так бывавает.
— Хочу домик отдохнуть.
— Ок. мы их делаем. что именно вы хотите?
— Ну хз. предложите что-то «вы же спец»
— обычно по вашему профилю: делаем домик, окна со стеклом, кухню с газом но вам рекомендуем электричество и подключение к канализации и водопроводом.
— ок. беру.
Прошло Y дней…
— Парни что за хрень вы вы мне впарили, а где я поставлю аквариум с бегемотом ?!
— ?!?!?!?!
VolCh
Зависит от конкретных методологий и проектных решений. В скраме рекомендуется порядка двух недель планировать деятельность, остальное — в бэклог.
Грубо говоря, да. Точнее — исходят из предположения что заказчик не понимает и будет менять как сами требования к конечному результату, так и приоритет реализации тех или иных фич.
Типа да, если заказчик не сказал о канализации в начале.
al_bozo
Гибкость эджайла растет из структуры — множество коротких полных производственных циклов в противовес одному или нескольким циклам водопада. Предполагается, что бОльшую часть рисков, связанных с неопределенностью требований заказчика и все связанные с нею, выявляются на этапах реализации, тестирования и использования. Короткие производственные циклы позволяют выявлять эти риски рано и регулярно. Разработка же вертикальными срезами нужна для того, чтобы функциональный заказчик (внешний и внутренний) мог видеть прогресс и управлять им, корректируя требования.
Это несколько упрощенное объяснение, но суть должна стать ясна.
http2
Сколько и какая длительность цикла при разработке среднего сайта?
Это Вы в книжках по Agile решили, что в водопаде будет 1 цикл? :)
Какая длительность цикла будет тут?
al_bozo
Сайтами не занимаюсь, с водопадом и с эджайлом знаком на практике и, надеюсь, достаточно в теории. Холиваром на эту тему не интересуюсь — подумал, что Вам интересен ответ на вопрос. Ну и вторую цитату в собственном каменте перечитайте еще разок — там написано «одному или нескольким». По Ройсу, кстати, именно один, емнип — да, с возвратами между этапами, но это совсем не итеративность циклов, а итеративность для этапов. Но в жизни, конечно, бывают очереди, которыми режут больших слонов.
Я дискретности, кстати, вообще не вижу здесь, по мне классический водопад — так вполне себе вырожденный [одно]итеративный процесс, и он лежит с абстрактным эджайлом в одном спектре итеративных процессов. Посередине не пустота, а кучка разных эджайл и совсем не эджайл зверушек с разными размерами циклов и обертками.
Lofer
Крылья… ноги… главное хвост! Цель какая?
Именно — минимизация рисков. От этого строится методология и управление рисками.