там просто стойки и ящики

вообще его Канбан - более похож на автоматизацию склада

там даже вон карта есть

Вы не путайте круглое с длинным. Канбан это средство визуализации. Простое и всегда перед глазами. Реальный склад тоже можно считать "канбан-доской". Как и отчетик в 1С. Смысл один, но есть более наглядные, простые и доступные способы визуализации.

вот и еще одно определение Канбан подъехало

Это не определение. Это в 2х словах для чего действительно стоит это использовать.

вот и еще одно определение Канбан подъехало

вот видишь сколько людей тебе сказали что ты не совсем правильно понимаешь канбан)

просто я про него даже не писал - я написал что для производства визуализация заполнения стоек - это деткий сад

если при начале сборки партии телефонов - у тебя на стойке с камерами загорится красный сигнал -

то это уже позно пить баржоми

а в игры с аббревиатурами я тут не играют - тут есть гораздо более образованные в этом люди

просто я про него даже не писал - я написал что для производства визуализация заполнения стоек - это деткий сад

там есть еще желтый

В банальном варианте не жопу отрывать и на склад идти, что бы весь скоуп охватить или в программе копаться, печатать и 2й лист потерять, а глаз на стенку поднял и смотришь... А там молоточек в башке стучит - жопа близко ... И так каждые 10 минут стучит, пока твою ленивую жабу не запинает и ты делом не займешься...

смотри вот ты канбанщик. твоя задача снабжать ячейки всякими болтиками. ты бежишь по цеху. или ты будешь подходить к каждой стойке и считать сколько там чего не хватает, потом чесать репу, возвращатся на склад, потом опять к стойке, а пока сбегал там уже они вообще кончились

или дешь и сразу издалека видишь где какая ситуация

в РФ такие проблемы только в Москве - где у людей есть выбор пинать свою жопу в салоне связи или на производстве

а ячеек у тебя 50. и все расходуют болтики с разной скоростью

да я не против визулизации

будешь как дибил проверять везде?

но такого я ни разу не встречал

посмотри про амазон видео

как они там автомтизировали все

Работники складов Amazon бастуют в Испании, Германии и Польше, жалуясь, что компания обогащается за счет их здоровья. Темп работы на складах постоянно ускоряется, работники боятся отлучиться в туалет, часто получают травмы, жалуются на проблемы с психическим здоровьем. Забастовка приурочена к скидочному дню Prime Day, когда количество заказов увеличивается. Подробнее: http://www.cnews.ru/news/top/2018-07-17_sotrudniki_amazon_bastuyut_po_vsej_evrope

эту видео смотреть ?

будешь как дибил проверять везде?

а ты когда видишь красный сигнал на стойке в дальнем углу - то сразу знаешь что там не хватает М3 ?

берешь сразу М3 на складе и туда несешь ?

или сначала туда идешь - потом смотришь - потом на склад - потом обратно

а ты когда видишь красный сигнал на стойке в дальнем углу - то сразу знаешь что там не хватает М3 ?

тогда ты разбираешся почему это произошло и предпринимаешь меры. уволить или лишитть премии канбанщика/закупщика/распреда и так далее. или там может тележка поломалась. тогда думаешь что надо купит резервные тележки

)))

это красиво конечно - но я часто видел другую систему заказ комплектуется в одном месте в коробку и отправлеется на сборку запасы на складе уменьшаются и кладовщикам выдается задача на коплектацию нужно привезти вот эти 10 позиций

Я к скрамтреку отношения не имею)

у некоторых пополнение оперативного склада происходит руками а коплектация заказа автоматически

это красиво конечно - но я часто видел другую систему заказ комплектуется в одном месте в коробку и отправлеется на сборку запасы на складе уменьшаются и кладовщикам выдается задача на коплектацию нужно привезти вот эти 10 позиций

ну вот канбан это по идее шаг вперед от этого

да уж куда там - автоматически коплектация заказов

древний век

был лично на производстве в тульской области там конвеер едет по складу от одного кладовщика к другуму кладовщик сканирует требуемые детали для заказа и кладет их в корзину и закзаз едет дальше

Я вам пару "канбанчиков" подкину, хотя бы для понимания как можно себе жизнь облегчить ...☝️

Пока вы спорили про 4 недели или 1 месяц, наткнулся случайно во вполне ранее "уважаемом" мною издании на такое.

😱

Если у вас "культурка" на высоте, то в канбан доску у вас уже встроена красная лампочка. А если вы её там не видите ... но она там есть. ;)

у них производство

там лампочка в стелажи встроена

они варвары

судя по вашей “культурке”

😱

😂 Да, всякое бывает...

А теперь ракета, при должном уровне культуры что дешевле? Лампочка в стеллаже со всей обвязкой как техническое решение или канбан доска с поддержкой и разделением методики и ценностей на всех уровнях?

https://vc.ru/life/51307-obrazcovyy-scrum-proekt-klient-dovolen-razrabotchik-net

Хорошая статья. Несколько замечаний: 1. "В Scrum эти хотелки называются user stories." Нет в Скрам понятия user story. Это практика экстремального программирования. 2. "Владелец продукта подтверждает состав спринта и обязательно определяет его цель". Цель Спринта в Скраме формирует не Владелец Продукта, а Скрам команда. Это важно. 3. " В Scrum задачи рассчитываются не в часах, а в относительных единицах." Нет в Скраме про это, Это практика экстремального программирования. 4. "Скрам-мастер ... обеспечивает команду маркерами и пиццей". Тут без комментариев. Даже не буду вспоминать Скрам-гайд. Но это я придираюсь. Очень правильная статья про нарушение одного принципа Аджайл разработки - "На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе".

Хорошая статья. Несколько замечаний: 1. "В Scrum эти хотелки называются user stories." Нет в Скрам понятия user story. Это практика экстремального программирования. 2. "Владелец продукта подтверждает состав спринта и обязательно определяет его цель". Цель Спринта в Скраме формирует не Владелец Продукта, а Скрам команда. Это важно. 3. " В Scrum задачи рассчитываются не в часах, а в относительных единицах." Нет в Скраме про это, Это практика экстремального программирования. 4. "Скрам-мастер ... обеспечивает команду маркерами и пиццей". Тут без комментариев. Даже не буду вспоминать Скрам-гайд. Но это я придираюсь. Очень правильная статья про нарушение одного принципа Аджайл разработки - "На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе".

Спасибо :)

Всем привет! Кто может посоветовать статью-книжку управление требованиями в scram/

Нужно нормальное руководство, как действовать, когда скоуп хотелок постоянно пухнет, а требования плавают от демо к демо.

А продукт то у вас есть?

Или ты, Ваня, продукт?)

Нужно нормальное руководство, как действовать, когда скоуп хотелок постоянно пухнет, а требования плавают от демо к демо.

Ну, пускай пухнет, главное раставить приоритет с заказчиком, что бы он понимал, что если команда может сделать 2 фичи в спринт, то она будет делать 2 самые важные фичи, а до тех что с низу возможно никогда не дойдут

от демо к демо, что вас тут смущает? как бы скрам как раз про то, что итерация в спринт позволяет быстро менять планы

Всем привет! Кто может посоветовать статью-книжку управление требованиями в scram/

https://www.ozon.ru/context/detail/id/140075435/

А продукт то у вас есть?

Есть, есть.

https://www.ozon.ru/context/detail/id/140075435/

чем эта книга отличается от того что в XP написано про US? я просто эту не читал, а читал из XP

от демо к демо, что вас тут смущает? как бы скрам как раз про то, что итерация в спринт позволяет быстро менять планы

Да меня не это смущает. Из серии Итерация 1: " Нужна зелёная круглая кнопка" -сделано. Макет, ок, прототип ок делаем. Итерация 2. "Блин круглая, давайте лучше прямоугольную", макет ок. итерация 3 "Блин зеленая, давайте серую" макет ок. Итерация 4 "нет, давайте всё токи круглую и лучше зеленную".

про управление жизненным циклом требований в разрезе agile

Ну опять же. Заказчик понимает что вместо того что бы получить важный, ценный для бизнеса инкремент продукта, он получает ненужный и бесполезный хлам?

https://www.ozon.ru/context/detail/id/140075435/

спасибо

Да меня не это смущает. Из серии Итерация 1: " Нужна зелёная круглая кнопка" -сделано. Макет, ок, прототип ок делаем. Итерация 2. "Блин круглая, давайте лучше прямоугольную", макет ок. итерация 3 "Блин зеленая, давайте серую" макет ок. Итерация 4 "нет, давайте всё токи круглую и лучше зеленную".

А потом оказывается, что фича не используется 😂

А потом оказывается, что фича не используется 😂

Вот это обычно очень больно😂

Может нужно на продукт метрики повесить и сказать - ты сюда не смотри, вон туда смотри )

теперь ещё один из критериев на приоритет как часто и как много пользователей это используют

А теперь ракета, при должном уровне культуры что дешевле? Лампочка в стеллаже со всей обвязкой как техническое решение или канбан доска с поддержкой и разделением методики и ценностей на всех уровнях?

Алексею удобно лампочки - он такую систему внедряеть готов или сами писать

теперь ещё один из критериев на приоритет как часто и как много пользователей это используют

+++ очень важно

Ну опять же. Заказчик понимает что вместо того что бы получить важный, ценный для бизнеса инкремент продукта, он получает ненужный и бесполезный хлам?

Если на демо не нравится, то в доработку уходит. В сборку не поподает...

Я как-то больше про Lean startup подумал нежели чем об управлении требованиями в скраме 😜

чем эта книга отличается от того что в XP написано про US? я просто эту не читал, а читал из XP

я xp читал оч давно, вряд ли смогу сказать чем они отличаются, но Паттон много раз ссылается на Кента Бека, поэтому он о том же, только расшяряя тему User Story Mapping Название немного вводит в заблуждение, книга на самом деле не просто про пользовательские истории, а про использование карт пользовательских историй. Затронуты концепции Lean startup, методы семинара по историям, three amigos, сетка возможностей, метод проектной студии. Вот лишь несколько ценных моментов, которые я отметил для себя: * Общие документы не дают единого понимания * Истинная цель использования историй - достижение единого понимания * Истории нужно рассказывать, а не писать. * Включайте в карту лишь то, что необходимо для поддержки обсуждения. * У вас никогда не будет достаточно людей, времени или денег, чтобы разработать все, что нужно. Никогда * Владелец продукта не может в одиночку написать все истории и присутствовать на всех обсуждениях. Это не работает. * Передача всех подробностей истории кому-то ещё для реализации не работает. Не делайте этого. * Есть смысл разделять командное ревью спринта и демо для всех заинтересованных людей из бизнеса. * Точная оценка - это оксюморон, ее не бывает. * Работу над великим произведением искусства невозможно завершить - ее можно только прервать * Кто, что, почему и только потом как. * Чтобы обсуждения были эффективными, на них не должно присутствовать больше 6 человек.

Люди почему метаются из стороны в сторону - у них велосипеда нет т.е. нет целей, короче, нет основы для принятия решений. И тогда начинаются докапывания до "нопочек"

А это не совсем про скрам. Хотя вот та книжка про user story mapping может и помочь )

Люди почему метаются из стороны в сторону - у них велосипеда нет т.е. нет целей, короче, нет основы для принятия решений. И тогда начинаются докапывания до "нопочек"

Старый анекдот - вам шашечки или ехать? Нормальный антипаттерн, так и работать нужно с ним ...

Старый анекдот - вам шашечки или ехать? Нормальный антипаттерн, так и работать нужно с ним ...

агась

Люди почему метаются из стороны в сторону - у них велосипеда нет т.е. нет целей, короче, нет основы для принятия решений. И тогда начинаются докапывания до "нопочек"

scram же про доверие. Будет доверие будет ускорение. Просто заказчик выкотил скоуп. Требование собрали. По ним сделали сначало прототип , затем красивый макет. В процессе закрыли многие хотелки. То есть максимально сэкономили время devteam, но на демо находятся или тот кто проспал, или тот кто забыл что то сказать. А на восклицание, где были раньше "Вы же продукт делает, норм же"

scram же про доверие. Будет доверие будет ускорение. Просто заказчик выкотил скоуп. Требование собрали. По ним сделали сначало прототип , затем красивый макет. В процессе закрыли многие хотелки. То есть максимально сэкономили время devteam, но на демо находятся или тот кто проспал, или тот кто забыл что то сказать. А на восклицание, где были раньше "Вы же продукт делает, норм же"

Честно, не понял замечания. Что делать-то? :) Или всё норм?

scram же про доверие. Будет доверие будет ускорение. Просто заказчик выкотил скоуп. Требование собрали. По ним сделали сначало прототип , затем красивый макет. В процессе закрыли многие хотелки. То есть максимально сэкономили время devteam, но на демо находятся или тот кто проспал, или тот кто забыл что то сказать. А на восклицание, где были раньше "Вы же продукт делает, норм же"

Так то скрам он не долько про доверие, он еще про империзм, про фокус...