Истина, как обычно, в балансе.

Morning Star, предположу не согласятся) — это про мыть полы и салфетки, если что)

Привет, ребята, есть фирма, сотрудники, рабочий процесс, канбан, и пара вопросов по всей этой солянке. Начал писать в чат, но понял что слишком длинно, поэтому ловите телеграф, Буду рад помощи! http://telegra.ph/Para-voprosov-kotorye-udobnee-chitat-v-formate-telegrafa-3-01-31-2

а писать в част али как?

голубиной почтой можно ещё

или пневмой

1. Вариант "б" убивает командность. Да, есть personal kanban, но мы же про работу командой в вашем случае, да? Если "нет", то дальше можно не читать вообще. Поэтому вариант "а", и не делайте столбик "в работе", а делайте "у маркетолога" / "рисуем дизайн" / "работает контекстолог". Каждый из таких столбцов поделите на "в работе" и "done". Лимит при этом ставите на каждую СТАДИЮ (то есть на маркетолога / дизайнера / контекстолога)! И если маркетолог всё сделал и у него всё в личном done (и он хотел бы поработать, да лимит не велит), а дизайнер завален и не может взять задачку - думаете что с этим делать 🙂 Срочная карточка летит по своему swimlane и если надо скипнуть, например, маркетолога - из очереди влетает сразу в дизайн. 2. Да, но... из контекста похоже, что у вас в "поддержке" в том числе и "разработка", плюс нет человека, который бы отвечал за приоретизацию - хотя бы суммировал результат коллегиального решения, но принимал бы решение ОДИН. Делать все карточки срочными - путь в никуда. Это значит просрать их все 🙂

А вообще деление на "поддержка"/"разработка" чревато массой проблем. Жить с ним можно, и работать по канбану поддержка может, но лучше всё-таки не делиться так и стараться иметь команду, которая ведёт продукт на протяжении всего его жизненного цикла

Как вариант с вашими двумя потоками (регулярные задачи и "срочный" фидбэк от клиентов) я бы подумал, например, о таком - завести два свимлэйна, в один пустить регуляры, в другой - клиентское запросы и установить соотношение (например, делать по очереди - одну регулярную и три клиентские, например, или в другом соотношении). Смотреть на успехи/неудачи, делать выводы и модифицировать систему. Следить за соотношением можно так - завести финальный столбик "done", накапливать в нём сделанные карточки и установить правило "снимаем с доски карточки, когда 1 done в первом свимлэйне и 3 done во втором". Плюс иметь резервный третий свимлэйн для совршенно-определённо-срочный-задач (которые должны появляться редко!).

1.a. - это однозначно; 2. да; в книге Kanban in Action рекомендуется сделать две дорожки (swimlane) - верхнюю для срочных задач, нижнюю для обычных.

1.a. - это однозначно; 2. да; в книге Kanban in Action рекомендуется сделать две дорожки (swimlane) - верхнюю для срочных задач, нижнюю для обычных.

Сначала по одной, потом по половинке, вот все что нужно для хорошей вечеринки

Спасибо за ответы! Разделить поддержку/разработку не можем т.к. пока не хватает ресурсов - 1 человек и настраивает, и далее ведёт контекст например, тоже и по сайту - 1 разработка и он же делает правки. А по поводу сообщения Serg : дорожки "срочное" - так это у нас и так есть, оно ведь никак не спасает, потому что срочно - всё. и про приоритеты я именно для этого и написал - что сложно впихивать срочные в текущий процесс, когда их много. В этом случае предложение Андрея о работе типа 1/3 1/3 1/3 вполне имеет смысл протестить.

И, кстати, у нас сейчас как раз вариант "Б", только все доски всех в одном пространстве, так мы можем видеть кто чем занят и помогать друг другу двигать то или иное вправо. При варианте "А" ведь сложно посмотреть чем именно занят конкретный человек, какие у него проблемы и чем можно помочь, чтобы продвинуть какую нибудь задачу скорее. — это придется бегать по куче проектных досок в поиске его карточек получается. А если проектов шутк 50, так вообще не представляю как.

типа есть верхнеуровневая доска где просто "очередь, в работе, готово" и там цельные карточки-проекты типа "КЛИЕНТ-САЙТ+РЕКЛАМА+ЛОГО" и от них дочерние карточки рассасываются по отдельным доскам каждого спеца, в свою очередь все доски расположены в одном пространтстве "Отдел разработки".

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

ну и вообще "если проектов 50" как-то странно. человек во всех этих проектах учавствует? тогда не удивительно что появляется желание за ним бегать. он же ничего не успевает.

Как вариант с вашими двумя потоками (регулярные задачи и "срочный" фидбэк от клиентов) я бы подумал, например, о таком - завести два свимлэйна, в один пустить регуляры, в другой - клиентское запросы и установить соотношение (например, делать по очереди - одну регулярную и три клиентские, например, или в другом соотношении). Смотреть на успехи/неудачи, делать выводы и модифицировать систему. Следить за соотношением можно так - завести финальный столбик "done", накапливать в нём сделанные карточки и установить правило "снимаем с доски карточки, когда 1 done в первом свимлэйне и 3 done во втором". Плюс иметь резервный третий свимлэйн для совршенно-определённо-срочный-задач (которые должны появляться редко!).

да, 1/3 это хорошая идея

Я обычно делаю всё на одной доске. Но! обязательно ограничиваю некоторые ресурсы чем-то. Самое простое - площадь, куда можно ткнуть стикер. Дело в том, что часть людей может быть привлечена лишь на кусочек времени и потому нельзя им просто навалить работы. Однако я человек процессный, у меня многое иначе, негибко

И, кстати, у нас сейчас как раз вариант "Б", только все доски всех в одном пространстве, так мы можем видеть кто чем занят и помогать друг другу двигать то или иное вправо. При варианте "А" ведь сложно посмотреть чем именно занят конкретный человек, какие у него проблемы и чем можно помочь, чтобы продвинуть какую нибудь задачу скорее. — это придется бегать по куче проектных досок в поиске его карточек получается. А если проектов шутк 50, так вообще не представляю как.

Всё-таки одна из сутей Канбана - командная работа, если все команды по 1 человеку и у каждого своя доска - это не про teamwork. И если есть-таки возможность и желание помогать друг другу и это часто происходит, я бы подумал, как всё это уложить на 1 общую доску.

Всё-таки одна из сутей Канбана - командная работа, если все команды по 1 человеку и у каждого своя доска - это не про teamwork. И если есть-таки возможность и желание помогать друг другу и это часто происходит, я бы подумал, как всё это уложить на 1 общую доску.

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

Как я понимаю суть камбана - на вижу загруженность, статус, пометки, динамика. Командная работа включается только после этого.

Morning Star, предположу не согласятся) — это про мыть полы и салфетки, если что)

Кто это? )

http://www.xn--80abdbnhdhfbv5bfuhmr3n3b.xn--p1ai/

9 и 10 февраля мои коллеги проводят в Москве игровой тренинг по основам Agile и Scrum. Пишите в личку за ссылкой и промокодом

http://www.xn--80abdbnhdhfbv5bfuhmr3n3b.xn--p1ai/

хотите вам рекламу в яндексе и гугле настроим?)

1. У нас настроено

2. Это не мой сайт

2. Это не мой сайт

Ясно)

судя по тому, что там "Нет мест" - им уже не нужна она)

судя по тому, что там "Нет мест" - им уже не нужна она)

спрос высокий,можно масштабировать)

Ребята привет

А где бы вы рек-ли купить pmbok 6 издание?

На Амазоне отзывы не очень, жалобы на шрифт и читабельность текста

А где бы вы рек-ли купить pmbok 6 издание?

Лучше спросить тут: @pm_russia

Там все его покупают

вы думаете книгу в разных местах печатают?)

вы думаете книгу в разных местах печатают?)

Я думаю тут немного людей покупали

Я покупал. Купил непосредственно в магазине PMI.org. До Новосибирска дошла за неделю

Там только косяк с формой оплаты у них. Данные карты, в том числе CVC нужно вносить на http странице на какой-то странной форме. Деньги сдернули не сразу а через день. Такое ощущение, что они вручную по табличке с сохраненными данными карт обрабатывают платежи.

Поэтому рекомендую виртуальную карту использовать

Мдааа

Там только косяк с формой оплаты у них. Данные карты, в том числе CVC нужно вносить на http странице на какой-то странной форме. Деньги сдернули не сразу а через день. Такое ощущение, что они вручную по табличке с сохраненными данными карт обрабатывают платежи.

эти данные запрещено хранить, так что вряд ли)

Я тоже верю в бескорыстность и честность всего человечества ))

Всем привет! Можете помочь с вопросом: в чем плюсы оценки задач в Story Point по сравнению в днях?

Чем SP лучше, чем дни разработки?

Если у команды растет производительность, то это будет видно (стали за то же время делать больше SP)

Если у команды растет производительность, то это будет видно (стали за то же время делать больше SP)

это если не происходит инфляции sp ;)

Это решается отдельно (эталонными задачами, например =)

Еще плюс - не будет давления (оценили в день, делаем два дня... фу какие мы плохие!)

Еще плюс - не будет давления (оценили в день, делаем два дня... фу какие мы плохие!)

будет давление "ваш эталон: 1 сторипоинт = 1 день, вы оценили в 1 стори поинт, а делаете как 2 дня") какой-то некорректный пример

Не надо просто к дням поивязывать sp

плюс в том, что вы не завязываетесь на сроки, а оцениваете задачи примерно как "легкая, средняя, сложная, очень сложная". В первых спринтах предполагаете, что "легкая" занимает 2 дня, средняя - 5 дней. Потом по ходу вы корректируете оценки и сложность, а само понятие сложности остается

таким образом находите свой эталон

и можете разбивать, что легкая - у джуниора 2 дня, у сеньора - 1 день

таким образом у каждой задачи есть именно сложность, а не срок

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

Да, но с ростом команды сложные задачи становятся легкими, идет инфляция. Синьоры будут задачу оценивать как легкую, а джуниоры как сложную. Эталонные и нужны, чтобы инфляции не было - чтобы было общее представлегие, какие задачи относим к легким, какие к сложным (независимо от скорости реализации)

FTE разных специалистов имеет разную стоимость, но и разную производительность

К гибким это не так подходит.

Посоветуйте, пожалуйста, хорошую обзорную статью по lean. Лонгрид, но не книгу

Да, но с ростом команды сложные задачи становятся легкими, идет инфляция. Синьоры будут задачу оценивать как легкую, а джуниоры как сложную. Эталонные и нужны, чтобы инфляции не было - чтобы было общее представлегие, какие задачи относим к легким, какие к сложным (независимо от скорости реализации)

прикол в том, что эталонные не всегда работают, поскольку одинаковых задач очень мало. у команд, у которых кпи на велосити в сп, есть тенденция на инфляцию сп - методы простые как палка - поделить среднюю задачу на кучу маленьких (2+2+2+2 > 5), начать учитывать всякие сложные и неопределенные моменты в задачах, что увеличивает размер по сравнению с эталонной и тд

Панацеи нет...

#noestimates

#noestimates

+1 ;) оценки - это издержки, которые обычно необоснованы

#noestimates

после просветления 😄

Посоветуйте, пожалуйста, хорошую обзорную статью по lean. Лонгрид, но не книгу

http://www.leanprimer.com/downloads/lean_primer.pdf

Всех приветствую! Посоветуйте пожалуйста достойные курсы по agile и scrum с уклоном в ИТ, чтобы можно было прокачаться в данных темах при наличии базовых знаний? Заранее спасибо!

Скрамтрек, Люксофт

Unusual Consepts

Всех приветствую! Посоветуйте пожалуйста достойные курсы по agile и scrum с уклоном в ИТ, чтобы можно было прокачаться в данных темах при наличии базовых знаний? Заранее спасибо!

В скраме есть что-то кроме базовых знаний?

Остальному учить еще не научились)

В скраме есть что-то кроме базовых знаний?

Есть

Скрам это фреймворк, не решение)

Всем привет. Работаю продуктовым менеджером, в основном по методологии Аджаил, но иногда и просто "молотком по старинке". Есть несколько крупных и мелких проектов в области телемедицины (web-сервисы и мобильные приложения).

Скрам это фреймворк, не решение)

Это не означает, что на практике он простой. Как раз наоборот

Всем привет. Работаю продуктовым менеджером, в основном по методологии Аджаил, но иногда и просто "молотком по старинке". Есть несколько крупных и мелких проектов в области телемедицины (web-сервисы и мобильные приложения).

Что за проекты в телемедицине?

Это не означает, что на практике он простой. Как раз наоборот

вместо инструкции для сборки мебели у вас видосики как пользоваться отдельно отверткой и молотком

о какой простоте на практике идет речь?

Что за проекты в телемедицине?

doctis.ru один из проектов

вместо инструкции для сборки мебели у вас видосики как пользоваться отдельно отверткой и молотком

Не понял к чему ваша метафора