Ну кстати, если уж речь зашла о Ту-144, то его конкурент, Конкорд, за счёт более экономичных двигателей имел дальность полёта почти в два раза больше и легко смог бы совершать рейсы Москва - Владивосток без дозаправок.
Насчёт числа пилотов, то там тоже не 2 vs 4: если я не ошибаюсь, на один самолет нужно порядка 7 экипажей (один летит, другой в резерве, два отдыхают и тд). То есть получается уже 14 vs 28. А ещё их нужно где-то размещать, кормить, облучать и тд.
Но на самом деле это все проявления одной и той же проблемы: недостаточного технологического уровня промышленности. И если в краткосрочной перспективе это не сильно важно (ну 28 вместо 14 и ладно), то в долгосрочной это ведёт к тотальному отставанию в отрасли.
Понятно, что шасси создают дополнительное сопротивление и снижают градиент набора. Но с исправным двигателем (одним) а321 все равно набирает высоту. Это подтверждают как летавшие на нем пилоты, так и тот факт, что команда на уборку шасси (которую не сказал впавший в оцепенение второй пилот) даётся только при положительном изменении высоты. То есть самолет СНАЧАЛА начинает набирать высоту и лишь ПОТОМ убирают шасси.
Что касается вашего примера в Сочи, именно поэтому взлет производят только в сторону моря, так как в противоположном направлении не обеспечивается безопасный взлет с одном отказавшим.
Все так. Если бы они сделали все идеально -- то мощности оставшегося полудохлого двигателя хватило бы на горизонтальный полет и даже на набор высоты "в час по чайной ложке".
Однако, был бы двигатель исправен -- не было и нужды в идеальном пилотировании: тяговоружоенности Эйрбаса с лихвой хватает, чтобы продолжить взлет на одном двигателе невзирая на выпущенные шасси и прочие "раскоряки".
В случае с посадкой в кукурузу это не удалось в первую очередь из-за того, что оставшийся двигатель также серьзено пострадал и не выдавал необходимую тягу. Был бы в порядке -- никакая "раскоряка" и не убранные шасси не создали бы проблемы -- это неоднократно проверялось на тренажерах и обсуждалось пилотами пилотирующих Эйрбасы.
Кроме того, насчет того что "летели раскорякой" -- не следует забывать, что там весь полет занял полторы минуты. Да еще не в спокойной обстановке, а с кучей отказов, постоянной разбалансировкой самолета из-за помпажирующего двигателя и тд.
А вы правы: уже начал писать коммент с возражением, но решил еще раз прочитать Скарм Гайд ) И действительно: там нигде не сказано, что ВСЕ задачи, взятые в спринт, должны быть выполнены. Там сказано лишь, что результатом спринита должен быть один или несколько инкрементов -- задач соответствующим критериям готовности.
То есть никакого запрета на то, чтобы брать в спринт задачи, которые будут готовы лишь в следующем спринте Скрам Гайд не накладывает.
Проблема зиждется на скрам-методологии, которая декларирует необходимость выпуска готовой протестированной фичи в конце спринта. Все пытаются в это прокрустово ложе поместиться, но я ни разу не видел, чтобы у кого-то это получилось.
Имхо, Инструкции и Водопад -- это одно и тоже: заранее определенный порядок действий ведущий к заранее определенному результату. Визуализируете вы этот порядок действий в виде Гант-чарта или в виде нумерованного списка -- вопрос личных предпочтений и необходимости.
В больших проектах можно (и, зачастую, нужно) использовать совокупность подходов:
Роадмэп в виде гант-чарта (Водопад), чтобы согласовать с заказчиком очередность блоков работ
Канбан для управления процессом сбора требований, так как много внешних задач.
WIP установить -- никаких проблем не составляет: сделали вторым столбец "первичный анализ", на котором и будете принимать решения о том, что требование разобьется на несколько сторей и сделали его без WIP, как и первый столбец на доске. Все остальные столбцы сделали с WIP (хотя на мой взгляд, использовать его для работы аналитика -- бессмысленно)
CFD -- аналогично: начиная со второго столбца она все прекрасно будет показывать
Разработчики не смогут просто взять в работу задачи, у них обязательно будут возникать вопросы, они подойдут к аналитикам (про аналитическую поддержку я в статье написал). А у вас аналитики за спринтом,
В скраме кто должен отвечать на вопросы команды? -- Product Owner. При том что он тоже находится, как вы выразились "за спринтом". В больших проектах аналитик как раз и играет роль Product Owner для команды.
Scrum Team у вас не кроссфункциональная, значит ваш скрам не полноценный.
Кроссфунциональная -- вовсе не означает, что команда может делать все на свете, это означает, что она в состоянии самостоятельно выполнять те, функции, которые ей назначили. Например, девопс-часть или нагрузочное тестирование часто выносят в отдельные команды. Перестает ли от этого дев-тима быть кроссфунцкиональной? -- разумеется нет.
Окей, и как из этого следует, что в случае синтеза канбан разрешает менять сущности в процессе работы, а в случае анализа -- нет?
Канбан -- это визуализация этапов работ. Меняете вы сущности внутри процесса или нет -- не важно совершенно, канбан от этого не перестает быть канбаном.
Работа аналитика более творческая, чем сборка узлов на конвейере, но ее точно также можно разбить на этапы. Например: "проработка требований", "согласование с заказчиком", "обсуждение с командой" и тп -- в зависимости от проекта. И вот эти этапы работ вы визуализируете на канбан-доски, что позволяет наглядно видеть весь процесс работы аналитика.
As Scrum’s use spreads, developers, researchers, analysts,scientists, and other specialists do the work. We use the word “developers” in Scrum not to exclude, but to simplify.
Хорошо, а теперь поясните, каким образом данный фрагмент подтверждает ваши слова "вы вынесли анализ вперед, значит у вас не скрам"?
PS. признаться, мне надоело спорить про термины. У вас в статье описана проблема? -- я предложил решение. Если вам интересно решить вашу проблему -- вы можете попробовать проверить данное решение на прочность, задавая те или иные кейсы, а я покажу, как оно работает. В конце концов, если вы не хотите называть это канбаном -- то дело ваше, мне, в целом, все равно )
Поясните, плиз, каким образом такой фактор, как формализация процесса позволяет вам в одном случае принимать тот факт, что в процессе канбана сущности меняется (на входе комплектующие, на выходе автомобиль), а в другом случае выступать категорички против (на входе хотелки, на выходе стори)?
Юзер-стори я имел ввиду. Ваши ведь слова:
Тип задачи "стори" вы записываете всё подряд, ну значит и скрама у вас нет.
Откуда вы это взяли? Скрам не накладывает никакого ограничения на то, что содержится в юзер-сторе. Более того, там даже слова такого нет.
В сраме анализ производится разработчиками, вы вынесли анализ вперед, значит у вас не скрам.
Откройте Скрам гайд и попробуйте найти подтвержение своих слов. Но не найдете, так как слово "анализ" там вообще не встречается.
В предлагаемом мною сетапе процесса команда разработки управляется по скраму, аналитик (или команда аналитиков) -- по канбану.
Как известно, канбан впервые был применен на конвейере Тойота: на вход конвейера подавались комплектующие, а на выходе -- готовый автомобиль, а канбан помогал делать этот процесс более наглядным и управляемым.
Так в чем вы видите разницу с нашим случаем, когда на вход мы получаем хотелки заказчика, а на выходе -- готовые к принятию в работу дев.тимой стори?
Тип задачи "стори" вы записываете всё подряд, ну значит и скрама у вас нет.
Почитайте Scrum Guide -- там вообще нет ни определения что такое сторя, ни описания какие типы задач там должны или могут быть. Какие вам необходимы -- те и используйте, Скрам от этого не перестает быть Скрамом.
Почему не может? Заказчик завел баг, а оказалось, что это запрос на новую фунциональность -- пример, встречающийся сплошь и рядом.
Но в большинстве случаев нам не нужно усложнять и делать отдельный тип задач "Change Requests": все хотелки заказчика сразу заводим с типом "Story". Если хотелка выливается в ряд сторей -- ну значит на каком-то этапе аналитик просто разобьет ее на на несколько частей. Разбивка одной стори на несколько -- это же вообще часто встречающися сценарий, в нем нет ничего особенного.
может ролевую модель нужно поменять, а может формат выгрузки, а может интеграцию описать, а может <что угодно>
Чтобы он не делал, в конечном итоге это должно попасть к команде разработки в виде стори. Изминился формат выгрукзи? Ну значит будет сторя: "Изменения формата выгрузки", в которой будет описан новый формат. Поменялась ролевая модель -- аналогично, создаем сторю "Изменение ролевой модели".
В чем же вы увидели противоречие? Все так и есть: на вход к аналитику попадают хотелки заказчика (Change Requests), в процессе его деятельности они превращаются в стори. И весь этот процесс наглядно виден всей команде на канбан-доске аналитика. А последняя колонка в его доске (Ready to Dev) маппится на первую колонку в скрам-доске команды разработки (To Do).
Ну у меня то как раз решение есть, и оно описано в моем первом комменте. Более того, это плюс/минус стандартный подход, даже странно, что вы о нем ничего не слышали.
Аналитик не работает по сторям, набор сторей и не только сторей может быть результатом проработки задачи аналитика. Соответственно задача с доски аналитика никогда не перепрыгнет на доску разработки
Чего это вдруг? Именно так он и работает: на вход получает хотелки от заказчика (ченч-реквесты), а на выходе -- готовые к реализации стори. И они обязаны "перепрыгивать" на доску разработки. Если у вас так не происходит -- значит, вы делаете что-то не так, и именно поэтому у вас ситуация, в которой вы не можете найти решение.
Задачи анализа зависят от внешних обстоятельств намного сильнее, чем задачи разработки, они могут замораживаться, закрываться, перекрываться в зависимости от пользователей, заказчика, владельца продукта, менеджера проекта и текущего понимая предметной области, а понимание приходит во процессе анализа.
Это именно та причина, по которой запихивать задачи аналитика в скрам-доску -- бессмысленно.
Максимум, что вы создадите на этой доске – это некое обобщённое предложение, что нужно проанализировать/спроектировать.
Да нет же. На доске я и вся команда увидим ход подготовки сторей к последующим спритам: столько-то пришло хотелок от заказчика, столько-то уже взято в работу, столько-то согласновано с заказчиком, а вот столько уже проработано и готово к тому, чтобы взять их в работу в следующий спринт.
Вы ходите всю эту аналитическую кухню, с непонятными задачами показать разработчикам? Аналитик же должен рассказать «что сделал», «что будет делать» и «проблемах». А разработчики его поймут за отведенное дейликом время, ему они смогут помочь? Или у вас проект идет спокойно, времени вагон, разработчикам нечего больше делать, кроме как помогать аналитику? У них есть в этом компетенции? Тогда у вас кросс-функциональная команда, зачем вам канбан, вам как раз нужен скрам…
Что вы имеете ввиду под "аналитической кухней с непонятными задачами"? Мне даже на ум ничего подобного не приходит )
Разработчики могут помочь аналитику определиться, какие задачи прорабатывать в первую очередь, а какие -- во вторую, поскольку какие-то они чисто технически не смогут взять в работу в ближайший спринт, например. Или у аналитика вознкнет вопрос насчет технической реализуемости того или иного требования, полученного от заказчика. Вариантов -- масса.
Отдельных дейли-митингов проводить не надо: просто в процессе обычного дейлика, когда доходит очередь до аналитика, скрам-мастер переключается на вкладку с канбан-доской, по которой аналитик расскажет команде о ходе работ по подготовке сторей.
Интересно ли это команде? -- безусловно. Мы все ещё одна команда? -- разумеется, и поэтому ретроспектива общая для всех. Это все ещё скрам? -- для дев-тимы -- да, а для аналитика -- канбан.
А не надо аналитика в спринт засовывать ) Вместо этого помимо существующей скарм-доски дополнительно создаем канбан-доску (Jira это позволяет делать), отражающую процесс подготовки сторей для взятия их в работу дев-командой. Там будут примерно такие столбцы (конкретный набор зависит от вашей специфики):
New -- для вновь созданных сторей
Requirement clarification -- для сторей, над которыми аналтик работает в данный момент: утоянет требования и тд
Ready for grooming -- стори, заапрувленные клиентом и готовые для детального обсуждения с командой
Ready for Dev -- стори, готовые для взятия в спринт.
Таким образом, вы наглядно будете видеть всю работу бизнес-аналитика, и ему тоже будет удобно, поскольку не придется вести отдельные доски в Trello или еще где.
И чтобы понимать, насколько хорошо у нас обстоят дела на аналитическом поприще, достаточно просто сравнивать число сторей в столбце Ready for Dev со скоростью работы вашей команды: если там есть запас на 2-3 спринта -- отлично. Если меньше -- аналитик не справляется и надо понять почему.
Статус Ready for Dev канбан-доски мэппится на столбец TO DO в скрам-доске, таким образом, для команды разработки ничего не меняется: они как и раньше будут брать из этого столбца стори и с ними работать.
А если зайти еще немного вперед, то мы поймем, что жизненный цикл стори не завершается на моменте, когда дев-команда перенесла ее в столбец Done. После этого могут быть приемочно-сдаточное тестирование у заказчика, подготовка к включению в релиз (не все 100% сдаланных фич может идти в ближайший релиз), деплой на прод и тд. Добавляем все эти этапы в виде колонок в нашу канбан-доску и, вуаля! -- весь жизненный цикл разработки у нас как на ладони.
Ну у самой массовой серии Ту-144 дальность была 3.000 км, потом, действительно, довели до 5.300. У Конкорда же судя по https://www.britishairways.com/en-us/information/about-ba/history-and-heritage/celebrating-concorde -- 6.667 км, при том что расстояние между Москвой и Владивостоком -- 6.400.
Ну кстати, если уж речь зашла о Ту-144, то его конкурент, Конкорд, за счёт более экономичных двигателей имел дальность полёта почти в два раза больше и легко смог бы совершать рейсы Москва - Владивосток без дозаправок.
Насчёт числа пилотов, то там тоже не 2 vs 4: если я не ошибаюсь, на один самолет нужно порядка 7 экипажей (один летит, другой в резерве, два отдыхают и тд). То есть получается уже 14 vs 28. А ещё их нужно где-то размещать, кормить, облучать и тд.
Но на самом деле это все проявления одной и той же проблемы: недостаточного технологического уровня промышленности. И если в краткосрочной перспективе это не сильно важно (ну 28 вместо 14 и ладно), то в долгосрочной это ведёт к тотальному отставанию в отрасли.
Понятно, что шасси создают дополнительное сопротивление и снижают градиент набора. Но с исправным двигателем (одним) а321 все равно набирает высоту. Это подтверждают как летавшие на нем пилоты, так и тот факт, что команда на уборку шасси (которую не сказал впавший в оцепенение второй пилот) даётся только при положительном изменении высоты. То есть самолет СНАЧАЛА начинает набирать высоту и лишь ПОТОМ убирают шасси.
Что касается вашего примера в Сочи, именно поэтому взлет производят только в сторону моря, так как в противоположном направлении не обеспечивается безопасный взлет с одном отказавшим.
Все так. Если бы они сделали все идеально -- то мощности оставшегося полудохлого двигателя хватило бы на горизонтальный полет и даже на набор высоты "в час по чайной ложке".
Однако, был бы двигатель исправен -- не было и нужды в идеальном пилотировании: тяговоружоенности Эйрбаса с лихвой хватает, чтобы продолжить взлет на одном двигателе невзирая на выпущенные шасси и прочие "раскоряки".
В случае с посадкой в кукурузу это не удалось в первую очередь из-за того, что оставшийся двигатель также серьзено пострадал и не выдавал необходимую тягу. Был бы в порядке -- никакая "раскоряка" и не убранные шасси не создали бы проблемы -- это неоднократно проверялось на тренажерах и обсуждалось пилотами пилотирующих Эйрбасы.
Кроме того, насчет того что "летели раскорякой" -- не следует забывать, что там весь полет занял полторы минуты. Да еще не в спокойной обстановке, а с кучей отказов, постоянной разбалансировкой самолета из-за помпажирующего двигателя и тд.
А вы правы: уже начал писать коммент с возражением, но решил еще раз прочитать Скарм Гайд ) И действительно: там нигде не сказано, что ВСЕ задачи, взятые в спринт, должны быть выполнены. Там сказано лишь, что результатом спринита должен быть один или несколько инкрементов -- задач соответствующим критериям готовности.
То есть никакого запрета на то, чтобы брать в спринт задачи, которые будут готовы лишь в следующем спринте Скрам Гайд не накладывает.
Проблема зиждется на скрам-методологии, которая декларирует необходимость выпуска готовой протестированной фичи в конце спринта. Все пытаются в это прокрустово ложе поместиться, но я ни разу не видел, чтобы у кого-то это получилось.
Имхо, Инструкции и Водопад -- это одно и тоже: заранее определенный порядок действий ведущий к заранее определенному результату. Визуализируете вы этот порядок действий в виде Гант-чарта или в виде нумерованного списка -- вопрос личных предпочтений и необходимости.
В больших проектах можно (и, зачастую, нужно) использовать совокупность подходов:
Роадмэп в виде гант-чарта (Водопад), чтобы согласовать с заказчиком очередность блоков работ
Канбан для управления процессом сбора требований, так как много внешних задач.
Скрам для управления командой разработки
Хорошо, видимо, не так вас понял.
Я пытаюсь понять, что вас смущает?
WIP установить -- никаких проблем не составляет: сделали вторым столбец "первичный анализ", на котором и будете принимать решения о том, что требование разобьется на несколько сторей и сделали его без WIP, как и первый столбец на доске. Все остальные столбцы сделали с WIP (хотя на мой взгляд, использовать его для работы аналитика -- бессмысленно)
CFD -- аналогично: начиная со второго столбца она все прекрасно будет показывать
В скраме кто должен отвечать на вопросы команды? -- Product Owner. При том что он тоже находится, как вы выразились "за спринтом". В больших проектах аналитик как раз и играет роль Product Owner для команды.
Кроссфунциональная -- вовсе не означает, что команда может делать все на свете, это означает, что она в состоянии самостоятельно выполнять те, функции, которые ей назначили. Например, девопс-часть или нагрузочное тестирование часто выносят в отдельные команды. Перестает ли от этого дев-тима быть кроссфунцкиональной? -- разумеется нет.
Попробуйте переписать ваш коммент еще раз, избегая перехода на личности.
Окей, и как из этого следует, что в случае синтеза канбан разрешает менять сущности в процессе работы, а в случае анализа -- нет?
Канбан -- это визуализация этапов работ. Меняете вы сущности внутри процесса или нет -- не важно совершенно, канбан от этого не перестает быть канбаном.
Работа аналитика более творческая, чем сборка узлов на конвейере, но ее точно также можно разбить на этапы. Например: "проработка требований", "согласование с заказчиком", "обсуждение с командой" и тп -- в зависимости от проекта. И вот эти этапы работ вы визуализируете на канбан-доски, что позволяет наглядно видеть весь процесс работы аналитика.
Хорошо, а теперь поясните, каким образом данный фрагмент подтверждает ваши слова "вы вынесли анализ вперед, значит у вас не скрам"?
PS. признаться, мне надоело спорить про термины. У вас в статье описана проблема? -- я предложил решение. Если вам интересно решить вашу проблему -- вы можете попробовать проверить данное решение на прочность, задавая те или иные кейсы, а я покажу, как оно работает. В конце концов, если вы не хотите называть это канбаном -- то дело ваше, мне, в целом, все равно )
Поясните, плиз, каким образом такой фактор, как формализация процесса позволяет вам в одном случае принимать тот факт, что в процессе канбана сущности меняется (на входе комплектующие, на выходе автомобиль), а в другом случае выступать категорички против (на входе хотелки, на выходе стори)?
Юзер-стори я имел ввиду. Ваши ведь слова:
Откуда вы это взяли? Скрам не накладывает никакого ограничения на то, что содержится в юзер-сторе. Более того, там даже слова такого нет.
Откройте Скрам гайд и попробуйте найти подтвержение своих слов. Но не найдете, так как слово "анализ" там вообще не встречается.
В предлагаемом мною сетапе процесса команда разработки управляется по скраму, аналитик (или команда аналитиков) -- по канбану.
Как известно, канбан впервые был применен на конвейере Тойота: на вход конвейера подавались комплектующие, а на выходе -- готовый автомобиль, а канбан помогал делать этот процесс более наглядным и управляемым.
Так в чем вы видите разницу с нашим случаем, когда на вход мы получаем хотелки заказчика, а на выходе -- готовые к принятию в работу дев.тимой стори?
Почитайте Scrum Guide -- там вообще нет ни определения что такое сторя, ни описания какие типы задач там должны или могут быть. Какие вам необходимы -- те и используйте, Скрам от этого не перестает быть Скрамом.
Почему не может? Заказчик завел баг, а оказалось, что это запрос на новую фунциональность -- пример, встречающийся сплошь и рядом.
Но в большинстве случаев нам не нужно усложнять и делать отдельный тип задач "Change Requests": все хотелки заказчика сразу заводим с типом "Story". Если хотелка выливается в ряд сторей -- ну значит на каком-то этапе аналитик просто разобьет ее на на несколько частей. Разбивка одной стори на несколько -- это же вообще часто встречающися сценарий, в нем нет ничего особенного.
Чтобы он не делал, в конечном итоге это должно попасть к команде разработки в виде стори. Изминился формат выгрукзи? Ну значит будет сторя: "Изменения формата выгрузки", в которой будет описан новый формат. Поменялась ролевая модель -- аналогично, создаем сторю "Изменение ролевой модели".
В чем же вы увидели противоречие? Все так и есть: на вход к аналитику попадают хотелки заказчика (Change Requests), в процессе его деятельности они превращаются в стори. И весь этот процесс наглядно виден всей команде на канбан-доске аналитика. А последняя колонка в его доске (Ready to Dev) маппится на первую колонку в скрам-доске команды разработки (To Do).
Ну у меня то как раз решение есть, и оно описано в моем первом комменте. Более того, это плюс/минус стандартный подход, даже странно, что вы о нем ничего не слышали.
Чего это вдруг? Именно так он и работает: на вход получает хотелки от заказчика (ченч-реквесты), а на выходе -- готовые к реализации стори. И они обязаны "перепрыгивать" на доску разработки. Если у вас так не происходит -- значит, вы делаете что-то не так, и именно поэтому у вас ситуация, в которой вы не можете найти решение.
Это именно та причина, по которой запихивать задачи аналитика в скрам-доску -- бессмысленно.
Да нет же. На доске я и вся команда увидим ход подготовки сторей к последующим спритам: столько-то пришло хотелок от заказчика, столько-то уже взято в работу, столько-то согласновано с заказчиком, а вот столько уже проработано и готово к тому, чтобы взять их в работу в следующий спринт.
Что вы имеете ввиду под "аналитической кухней с непонятными задачами"? Мне даже на ум ничего подобного не приходит )
Разработчики могут помочь аналитику определиться, какие задачи прорабатывать в первую очередь, а какие -- во вторую, поскольку какие-то они чисто технически не смогут взять в работу в ближайший спринт, например. Или у аналитика вознкнет вопрос насчет технической реализуемости того или иного требования, полученного от заказчика. Вариантов -- масса.
Отдельных дейли-митингов проводить не надо: просто в процессе обычного дейлика, когда доходит очередь до аналитика, скрам-мастер переключается на вкладку с канбан-доской, по которой аналитик расскажет команде о ходе работ по подготовке сторей.
Интересно ли это команде? -- безусловно. Мы все ещё одна команда? -- разумеется, и поэтому ретроспектива общая для всех. Это все ещё скрам? -- для дев-тимы -- да, а для аналитика -- канбан.
А не надо аналитика в спринт засовывать ) Вместо этого помимо существующей скарм-доски дополнительно создаем канбан-доску (Jira это позволяет делать), отражающую процесс подготовки сторей для взятия их в работу дев-командой. Там будут примерно такие столбцы (конкретный набор зависит от вашей специфики):
New -- для вновь созданных сторей
Requirement clarification -- для сторей, над которыми аналтик работает в данный момент: утоянет требования и тд
Customer's acceptance -- проработанные аналитиком стори, ожидающие аппрува клиента
Ready for grooming -- стори, заапрувленные клиентом и готовые для детального обсуждения с командой
Ready for Dev -- стори, готовые для взятия в спринт.
Таким образом, вы наглядно будете видеть всю работу бизнес-аналитика, и ему тоже будет удобно, поскольку не придется вести отдельные доски в Trello или еще где.
И чтобы понимать, насколько хорошо у нас обстоят дела на аналитическом поприще, достаточно просто сравнивать число сторей в столбце Ready for Dev со скоростью работы вашей команды: если там есть запас на 2-3 спринта -- отлично. Если меньше -- аналитик не справляется и надо понять почему.
Статус Ready for Dev канбан-доски мэппится на столбец TO DO в скрам-доске, таким образом, для команды разработки ничего не меняется: они как и раньше будут брать из этого столбца стори и с ними работать.
А если зайти еще немного вперед, то мы поймем, что жизненный цикл стори не завершается на моменте, когда дев-команда перенесла ее в столбец Done. После этого могут быть приемочно-сдаточное тестирование у заказчика, подготовка к включению в релиз (не все 100% сдаланных фич может идти в ближайший релиз), деплой на прод и тд. Добавляем все эти этапы в виде колонок в нашу канбан-доску и, вуаля! -- весь жизненный цикл разработки у нас как на ладони.
Вопрос в том, как я понял, что в данном случае можно организовать целенаправленную атаку под совершенно безобидным видом.
Была-была, тоже ей пользовались чтобы над недостаточно технически подкованными коллегами шутки всякие шутить )