В модели предполагается, что после Предпроектного обследования (ППО) согласовываем итоговый объем проекта и фиксируем стоимость в 5500 часов.
Тут есть пара правил переоценки:
— в первоначальной смете подробно расписать работы и прозрачно указать, что после ППО будет переоценка (~20–30%);
— после финализации ППО (занимает 1 месяц): оценить только новые выявленные пункты, но не переоценивать те, которые были в предыдущей смете;
— пункты в обоих сметах должны «биться» друг с другом;
— обычно появляется много новых пожеланий, поэтому нужно сделать новую приоритизацию с клиентом, чтобы согласовать новый состав проекта, который поместится в бюджет.
По договору:
Договор на ППО;
Договор на все работы после завершения ППО;
Доп. соглашения (по необходимости), если окажется, что ближе к концу проекта нужно еще что-то доделать или от чего-то отказаться.
С первой вообще не понятно. Как правило эти задачи сложные, не прогнозируемые по структуре и составу. И на доске могут висеть в одном статусе долго. И тут противоречие - по сути процесс такой не визуализируется, задача просто прыгает в колонку Выполнено. Сомнительное решение.
В этом и идея, что задачи, которые должны помогать развивать систему не должны быть невыполняемыми абстрактными идеями, которые никто и делать на самом деле не собирается. Задачи смартуем, приоритизируем, декомпозируем и пускаем в работу. Слева-направо отслеживая зрелость и поддерживая фокус на регулярных встречах.
Про "задачу на доработке не возвращаем" - тоже вопрос. Опять же, противоречие в визуализации. Не понятно, почему при её переносе назад херится история. Кто мешает сохранить артефакты?
История не «херится». Движение по доске справа-налево портит аналитику для Cumulitive Flow Diagram и Lead Time. Для дефектов лучше создавать новые задачи на исправление или доработку (это проводить через бэклог).
Не знаю деталей, как в Сбере применяется Agile. Так как это большая продуктовая компания, наверняка там адаптация какого-то масштабируемого фреймворка: Less/Safe/Nexus. Мы сервисная компания, поэтому нам лучше подходит Канбан-метод. С помощью которого мы работаем с тем же Сбером.
Если действительно интересно, могу разузнать у коллег из Сбера детали и написать отдельную статью на эту тему.
Да. При переходе Требования в финальный статус предлагается создать задачу на доске разработки на основе выкладок из родителя.
И есть специфические кейсы. Например, баги, связанные с разметкой (веб-аналитика) попадают на доску Requirements.
Самая большая интеграция с досками цеха, куда сливаются все задачи из всех проектов по определенным типам и подтипам. Наверно эта тема отдельной заметки достойна.
Не стал про это подробно писать, кажется это особенности наших процессов.
Не совсем так. Канбан на заводах Тойоты – это бережливое производство, определяющим принципом которого является понятие “точно в срок”. Канбан, как термин в управлении, действительно пошел от Тойоты. В переводе с японского это слово означает “сигнал” или “карточка”. На автомобильных заводах такие карточки использовались, чтобы передать информацию с одного этапа на следующий о том, сколько и каких деталей потребуется...
...Канбан-метод тоже придерживается понятия “точно в срок”, но в отличие от заводов Тойоты здесь речь идет об интеллектуальном труде. Иными словами, код программиста или идею маркетолога нельзя пощупать и увидеть обычному человеку, пока он(она) не превратится в конечный продукт или сервис. Таким образом, Канбан-метод используется для визуализации потока интеллектуальной работы и сокращения количества этой незавершенной работы. За счёт этого достигается равномерная и предсказуемая скорость оказания услуги конечному потребителю.
WIP-лимиты помогают фокусироваться на доделывании работы в стадиях уборки и проверки. Новая задача берется, когда полностью сделана предыдущая в соответствии с приоритетом. Помогает обуздать хаос, сбалансировать нагрузку и создать ритм. У команды был установлен wip-лимит на сотрудника: не более 1 задачи одновременно в работе.
Когда зависимостей между задачами мало — так легче планировать работу, но wip-лимиты не отменяются.
В этом доме не хранились драгоценности, но многие ценные вещи сгорели или испортились. Если вы имеете в виду, украли ли что-то пока устранялись последствия пожара — то нет.
В модели предполагается, что после Предпроектного обследования (ППО) согласовываем итоговый объем проекта и фиксируем стоимость в 5500 часов.
Тут есть пара правил переоценки:
— в первоначальной смете подробно расписать работы и прозрачно указать, что после ППО будет переоценка (~20–30%);
— после финализации ППО (занимает 1 месяц): оценить только новые выявленные пункты, но не переоценивать те, которые были в предыдущей смете;
— пункты в обоих сметах должны «биться» друг с другом;
— обычно появляется много новых пожеланий, поэтому нужно сделать новую приоритизацию с клиентом, чтобы согласовать новый состав проекта, который поместится в бюджет.
По договору:
Договор на ППО;
Договор на все работы после завершения ППО;
Доп. соглашения (по необходимости), если окажется, что ближе к концу проекта нужно еще что-то доделать или от чего-то отказаться.
С первой вообще не понятно. Как правило эти задачи сложные, не прогнозируемые по структуре и составу. И на доске могут висеть в одном статусе долго. И тут противоречие - по сути процесс такой не визуализируется, задача просто прыгает в колонку Выполнено. Сомнительное решение.В этом и идея, что задачи, которые должны помогать развивать систему не должны быть невыполняемыми абстрактными идеями, которые никто и делать на самом деле не собирается. Задачи смартуем, приоритизируем, декомпозируем и пускаем в работу. Слева-направо отслеживая зрелость и поддерживая фокус на регулярных встречах.
Про "задачу на доработке не возвращаем" - тоже вопрос. Опять же, противоречие в визуализации. Не понятно, почему при её переносе назад херится история. Кто мешает сохранить артефакты?История не «херится». Движение по доске справа-налево портит аналитику для Cumulitive Flow Diagram и Lead Time. Для дефектов лучше создавать новые задачи на исправление или доработку (это проводить через бэклог).
Кстати, еще специфика в том, что готовое Требование обычно декомпозируется на ряд задач в разработку, которые попадают в бэклог.
Т. е. после разработки дизайн-макета, например, в бэклог может попасть 3 задачи, которые пока делать не нужно и они должны ждать своей очереди.
В таком кейсе сквозная визуализация скорее повредит.
Хех, это внутреннее название. У нас компания называется Agima, поэтому Agimaban хорошо приживается
Спасибо.
Для больших команд тако вариант не очень подходит, если очень много работы собрано на каждой из досок.
Но для средних и небольших — может быть нормальной практикой. Запишу себе идею подумать над Агимабан_лайт)
Не знаю деталей, как в Сбере применяется Agile. Так как это большая продуктовая компания, наверняка там адаптация какого-то масштабируемого фреймворка: Less/Safe/Nexus. Мы сервисная компания, поэтому нам лучше подходит Канбан-метод. С помощью которого мы работаем с тем же Сбером.
Если действительно интересно, могу разузнать у коллег из Сбера детали и написать отдельную статью на эту тему.
Да. При переходе Требования в финальный статус предлагается создать задачу на доске разработки на основе выкладок из родителя.
И есть специфические кейсы. Например, баги, связанные с разметкой (веб-аналитика) попадают на доску Requirements.
Самая большая интеграция с досками цеха, куда сливаются все задачи из всех проектов по определенным типам и подтипам. Наверно эта тема отдельной заметки достойна.
Не стал про это подробно писать, кажется это особенности наших процессов.
1 стандарт. Канбан-метод
Здравствуйте, спасибо за материал!
А расскажите, как технически вы реализовали интеграцию Jira и Metabase?
Прошу прощения, отвечу цитатой, очень подходит:
https://scrumtrek.ru/blog/kanban/1360/chto-takoe-kanban-metod-maksimalno-korotko/
WIP-лимиты помогают фокусироваться на доделывании работы в стадиях уборки и проверки. Новая задача берется, когда полностью сделана предыдущая в соответствии с приоритетом. Помогает обуздать хаос, сбалансировать нагрузку и создать ритм. У команды был установлен wip-лимит на сотрудника: не более 1 задачи одновременно в работе.
Когда зависимостей между задачами мало — так легче планировать работу, но wip-лимиты не отменяются.
В этом доме не хранились драгоценности, но многие ценные вещи сгорели или испортились. Если вы имеете в виду, украли ли что-то пока устранялись последствия пожара — то нет.
Скажем так, скептиков было больше, чем 2–3 евангелистов, которые были за любую движуху )
Всё было достаточно стремительно. 1 день на первичную подготовку.
Точно уже не помню, но примерно так:
1 день :: 4
2 день :: 8
3 день :: 16
4 день :: 18→20