Roman
окей, как выяснить это очень быстро, в чем основная идея?
Slava
взять скоуп
Slava
прийти к заказчику
Slava
сказать - чувак топ 3 фичи, пальцем ткни
Slava
сделать только 1, показать - ОНО?
Slava
вкратце - так
Roman
ну то есть иными словами аджайл позволяет эффективно отсеч из скоупа лишнее - и сосредоточиться на самом нужном
Roman
я правильно понял?
Slava
максимально не делать лишнего изначально
Slava
пока не сделаешь - не узнаешь лишнее оно или нет
Slava
если задача - сделать такой же сайт как у тех ребят
Slava
не про agile
Roman
если у меня скажем есть набор задач, которые в итоге точно должны быть реализованы, раньше или позже, то аджайл мне не поможет
Slava
;)
Roman
не про agile
вот да, теперь понятно. это я и мел в виду
Slava
ну плюс минус
Slava
контекст задач важен, если задача на инновацию - то agile, если нет - то необязательно
Slava
ща
Slava
https://www.youtube.com/watch?v=rCLth07UAsA&t=153s
Roman
спасибо
Slava
Угу, основная проблема - система не complex, а complicated, а мы agile )
Slava
Но с другой стороны, на кеневина можно так посмотреть, если мы умеем себя погружать в контекст complex-систем, то можем применять agile и становиться более гибкой компанией на рынке
Slava
это можно так прочитать "если я программист и делаю simple задачи, то и получаю как simple" ;)
Slava
Slava
Это реклама
Slava
А у вас как, ясно кто виноват? ))
Алексей
@neemah мониторишь рекламу конкурентов?)
Slava
рекламирую!
Slava
скрам по-мегаплановски кто был виноват вчера кто сегодня кто будет завтра?
Ivan
Виновных нет, но вы держитесь!
Ivan
(С) Agile
Igor
мегаплан разве как то связан с agile
Slava
хороший вопрос, а как это - быть связаным с agile? :)
Timur
наручниками к б̶а̶т̶а̶р̶е̶е̶ agile приковать виноватых
Shamil
мегаплан это про контроль исполнения поручений, а в этой области каждый второй виноват в просрочке
Slava
ну теоретически, agile команда вольна выбирать инструмент
Slava
наручниками к б̶а̶т̶а̶р̶е̶е̶ agile приковать виноватых
а я все думал, что же это за слово-то такое "agile-трансформация", вот оно чо!
Serge
Агил-игил
Anonymous
Идея для названия столбцов на рабочей канбан-доске: -Отрицание -Гнев -Торг -Депрессия -Принятие -Беклог
Anonymous
ну и видимо наручниками к батарее в процессе..
Slava
Это же kanban discovery называется
Slava
а как тогда будет часть kanban delivery ?
N.
Идея для названия столбцов на рабочей канбан-доске: -Отрицание -Гнев -Торг -Депрессия -Принятие -Беклог
Не подскажете где взять руководство по внедрению такого подхода? Заранее спасибо.
Anonymous
Не подскажете где взять руководство по внедрению такого подхода? Заранее спасибо.
смотря что нужно внедрять, в принципе любую книжку про канбан можно брать, хотя лучше за авторством Девида Андерсона ;)
N.
Речь была именно про эти стадии
Dmitry
Йоу, чатик Обычно тут я привожу кейсы из "каноничного" скрама, но на этот раз мне нужна ваша помощь. Я провожу небольшое исследование. Если тут есть кто-то, кто работает по настоящему скраму и у кого ЕСТЬ цель спринта, можете покидать ваши формулировки? (можно в личку, если не хотите публичности, шарить в открытом виде не собираюсь) Кто скинет – тому лучи добра и плюсы в карму ;) Cпасибо!)
Slava
Nariman
Коллеги, как выстроить скрам-процесс в отделе разработки при множестве заказчиков? Интересно Ваше мнение и подобный опыт. Работа протекает примерно следующим образом - Задачи разрабам поступают от множества других отделов. Составляется план на 2 недели, определяются приоритеты задач (в жалких спорах рук отделов между собой) и примерная сложность - без разбиения задач и детального их разбора. Детальный разбор проходит уже в течении спринта. Проблемы - неверные оценки сложности и плохая коммуникация - заказчиков приходится отлавливать по возникающим вопросам => еще больший срыв сроков. Как проводить скрам-планирование? продукт овнеров много и тратить их время на разбор чужих задач. Как проводить оценку приоритетов задач? Что попадет в спринт / что нет. При внедрение скрам в проектном отделе, где продакт-овнер один и спринты обычно имеют определенную цель с подобными проблемами не столкнулись.
Dmitry
Коллеги, как выстроить скрам-процесс в отделе разработки при множестве заказчиков? Интересно Ваше мнение и подобный опыт. Работа протекает примерно следующим образом - Задачи разрабам поступают от множества других отделов. Составляется план на 2 недели, определяются приоритеты задач (в жалких спорах рук отделов между собой) и примерная сложность - без разбиения задач и детального их разбора. Детальный разбор проходит уже в течении спринта. Проблемы - неверные оценки сложности и плохая коммуникация - заказчиков приходится отлавливать по возникающим вопросам => еще больший срыв сроков. Как проводить скрам-планирование? продукт овнеров много и тратить их время на разбор чужих задач. Как проводить оценку приоритетов задач? Что попадет в спринт / что нет. При внедрение скрам в проектном отделе, где продакт-овнер один и спринты обычно имеют определенную цель с подобными проблемами не столкнулись.
почему скрам?
Slava
https://medium.com/@kaiten_ru/kanban-команда-из-четырех-человек-поддерживает-девять-проектов-30ed88efaae1
Slava
не уверен что механика описанная в компании сохранилась
Slava
но в качестве информации рекомендую ознакомиться
Nariman
почему скрам?
Возможно, потому что мал кругозор. Что посоветуете? Внедрение скрама не является целью, но из нашего небольшого опыта некоторые элементы скрама - скрам-планирование и дейли митинги - возымели большой эффект.
Slava
скрам не конвеер по обслуживанию множества закачиков
Slava
ну то есть представьте себе продукт овнера, который принимает решение по проекту
Slava
к нему бегают куча чуваков и каждый говорит что его задача важнее другого
Slava
тут сразу встает вопрос - приоритезации
Slava
начинается - а давайте фичи взвешивать, а давайте критерии определим, а давайте еще 25 совещаний проведем
Dmitry
скрам для разработки продуктов 1 команда – 1 продукт – 1 PO
Slava
ага, если каждому заказчику по команде - супер
Slava
ну так и работает в принципе
Dmitry
ага, если каждому заказчику по команде - супер
ну заказчики разные бывают) может и по пять команд)
Slava
ну в эту сторону-то ))))
Slava
обычно - а давайте мы вот из этих 5 ребят 7 продуктов сделаем )))
Slava
а чо, ну не умирают же
Nariman
тут сразу встает вопрос - приоритезации
В статье это описано, обязательно изучу подробно. Теперь такой вопрос - у нас беда с коммуникацией. В скраме подробный разбор задачи проходит один раз, и застать продукт овнера пусть и на 4 часа но один раз в 2 недели относительно легко. Но застать его 4 раза по 1 часу гораздо сложнее. По большому счету в процессе "спринта" всем пофиг - заказчики вспоминают о своих задачах только к дедлайну
Slava
это все выстраивается
Slava
в описанной системе
Slava
с помощью лимитов на входящую очередь, это совсем базовые беды
Slava
об этом можно просто потолковать со мной в привате после прочтения
Nariman
Благодарю, будем изучать
Slava
https://www.youtube.com/watch?v=QlyYfR6Nm8Y
Anonymous
коллеги, а где вы ищите программеров-скраммастеров? внезапно нужен юнитевщик
Igor
а кто это такие? :D
Anonymous
ну можно и так наверное :)
Anonymous
мне в первую очередь нужен девелопер который не будет ныть от того что у нас спринты, а еще и научит работать по скраму джунов :)
Karina
так девелопер, не ноющий, что спринты - это же не скрам-мастер?