Теперь и комитет международного экономического форума отмечает, что эпоха классического менеджмента подходит к концу. Когда это поймут топы и перестанут цепляться за свои статусные позиции?
Кстати, на форуме уже несколько лет говорят о 4й промышленной революции и неминуемой смене парадигм во всех сферах нашей жизни.
https://www.weforum.org/agenda/2017/12/is-management-era-over/?utm_content=buffer61d04&utm_medium=social&utm_source=facebook.com&utm_campaign=buffer
Кстати, на форуме уже несколько лет говорят о 4й промышленной революции и неминуемой смене парадигм во всех сферах нашей жизни.
https://www.weforum.org/agenda/2017/12/is-management-era-over/?utm_content=buffer61d04&utm_medium=social&utm_source=facebook.com&utm_campaign=buffer
World Economic Forum
Is the era of management over?
Traditional hierarchies are giving way to more open and creative workplace cultures.
#принятиеРешений #самоуправление
Зачастую любые инновации, а иногда и необходимые производственные решения, буксуют из-за необходимости согласования с вышестоящим руководством.
Можно выделить три главных недостатка данной схемы:
1. Увеличение времени принятия решения и потеря потенциальной прибыли.
2. У руководство может отсутствовать компетенция в области, в которой принимается решение (даже если менеджер "вырос" из рядового специалиста, в силу постоянно меняющегося рынка и практик он уже не имеет достаточно актуального взгляда).
3. Сотрудник теряет чувство ответственности ("Как я могу отвечать за решения, которые фактически были приняты не мной".
Как избавиться от лишних согласований и при этом иметь возможность влиять на принимаемые решения?
1. Внедрить практику внутреннего консультирования. Данный подход предполагает, что человек имеет право принять любое решение, проконсультировавшись при этом с людьми, которые так или иначе будут затронуты данным решением. При этом ни один человек не может наложить вето на решение, а сотрудник, который принебрег внутренним консультированием (не обсудил решение с коллегами или формально подошел к обсуждению) может получить выговор.
2. Менеджеры должны подключаться к выработке того или иного решения в качестве участника процесса и на ровне со всеми обсуждать идеи и предлагать свои. При этом финальное решение должна принимать группа, а не менеджер единолично.
3. Сотрудник в рамках определенных сессий "продает" определенную концепцию идею, защищает ожидаемые результаты и далее имеет полную свободу в рамках согласованной идеи. Важно отметить, что согласовываться формат должен в разумных пределах, чтобы не возвращаться к микросогласовательству.
Зачастую любые инновации, а иногда и необходимые производственные решения, буксуют из-за необходимости согласования с вышестоящим руководством.
Можно выделить три главных недостатка данной схемы:
1. Увеличение времени принятия решения и потеря потенциальной прибыли.
2. У руководство может отсутствовать компетенция в области, в которой принимается решение (даже если менеджер "вырос" из рядового специалиста, в силу постоянно меняющегося рынка и практик он уже не имеет достаточно актуального взгляда).
3. Сотрудник теряет чувство ответственности ("Как я могу отвечать за решения, которые фактически были приняты не мной".
Как избавиться от лишних согласований и при этом иметь возможность влиять на принимаемые решения?
1. Внедрить практику внутреннего консультирования. Данный подход предполагает, что человек имеет право принять любое решение, проконсультировавшись при этом с людьми, которые так или иначе будут затронуты данным решением. При этом ни один человек не может наложить вето на решение, а сотрудник, который принебрег внутренним консультированием (не обсудил решение с коллегами или формально подошел к обсуждению) может получить выговор.
2. Менеджеры должны подключаться к выработке того или иного решения в качестве участника процесса и на ровне со всеми обсуждать идеи и предлагать свои. При этом финальное решение должна принимать группа, а не менеджер единолично.
3. Сотрудник в рамках определенных сессий "продает" определенную концепцию идею, защищает ожидаемые результаты и далее имеет полную свободу в рамках согласованной идеи. Важно отметить, что согласовываться формат должен в разумных пределах, чтобы не возвращаться к микросогласовательству.
#кратныйРост
Основные тезисы:
Кратный рост достигается за счет фокусировка на кратном росте всей команды.
Три важные вещи, которые позволят команде сфокусироваться на кратном росте:
1. Ритуалы:
- Питчи (каждый член команды формулирует гипотезы и тестирует их)
- Наставники (наставник по ремеслу и наставник по питчам)
- Исключение наказаний (нет депремирования, и мудаков (люди, которые говорят, что идея не сработает а потом напоминают, что она не сработает))
- Сокращенный рабочий день 6 дней в неделю, корпоративные завтраки.
- Белые доски, как основной инструмент для обсуждений и фиксации. Цели на день.
- Небольшие команды.
2. Люди и команда:
- В найме участвует руководитель.
- Основная энергия тратится на отличников, а не на троечников
- Командная задачи (командный дух появляется при выполнении командных задач)
- Контроль и доверие.
3. Поведение руководителя:
- Нет возможности "просрать" ни один день
- Помощь руками (если что то пошло не так, то делаем что то своими руками)
https://www.youtube.com/watch?time_continue=1341&v=5kpaCPaa6co
Основные тезисы:
Кратный рост достигается за счет фокусировка на кратном росте всей команды.
Три важные вещи, которые позволят команде сфокусироваться на кратном росте:
1. Ритуалы:
- Питчи (каждый член команды формулирует гипотезы и тестирует их)
- Наставники (наставник по ремеслу и наставник по питчам)
- Исключение наказаний (нет депремирования, и мудаков (люди, которые говорят, что идея не сработает а потом напоминают, что она не сработает))
- Сокращенный рабочий день 6 дней в неделю, корпоративные завтраки.
- Белые доски, как основной инструмент для обсуждений и фиксации. Цели на день.
- Небольшие команды.
2. Люди и команда:
- В найме участвует руководитель.
- Основная энергия тратится на отличников, а не на троечников
- Командная задачи (командный дух появляется при выполнении командных задач)
- Контроль и доверие.
3. Поведение руководителя:
- Нет возможности "просрать" ни один день
- Помощь руками (если что то пошло не так, то делаем что то своими руками)
https://www.youtube.com/watch?time_continue=1341&v=5kpaCPaa6co
#трансформация
Еще один пример того, что Scrum без Agile ценностей не принесет большой пользы. Многие руководители считают, что стоит внедрить DSM, спринты и ретроспективы и это сразу изменит ход работы.
Да, Scrum позволит структурировать работу, сделает процесс более прозрачным, но он не даст прорывных результатов, если участники процесса не будут работать над изменением формата своего мышления.
https://habrahabr.ru/post/344444/
Еще один пример того, что Scrum без Agile ценностей не принесет большой пользы. Многие руководители считают, что стоит внедрить DSM, спринты и ретроспективы и это сразу изменит ход работы.
Да, Scrum позволит структурировать работу, сделает процесс более прозрачным, но он не даст прорывных результатов, если участники процесса не будут работать над изменением формата своего мышления.
https://habrahabr.ru/post/344444/
Хабр
Scrum внедрили, agile — забыли
Недавно мне посчастливилось начать работу с одной относительно немаленькой компанией (~100 человек), где, как выразился наниматель, “по-отдельности все хорошие с...
#scrummaster #самоорганизация
Отличная статья о том, кто такой скрам мастер и какие у него обязанности: http://www.barryovereem.com/a-day-in-the-life-of-a-scrum-master/
Наиболее интересным мне кажется тезис, что основная активность скрам мастера - это активное бездействие. Очевидно, что скрам мастер не должен сидеть сложа руки и лишь цитировать скрам гайд, однако систематическое выполнение задач, которые члены команды способны решить самостоятельно, может привести к тому, что скрам мастер постепенно превратится либо в проджект менеджера либо в золушку, выполняющую всю грязную работу.
Чтобы не уходить в крайности я выработал для себя правило:
1. Член команды должен попытаться решить проблему самостоятельно или при поддержки коллег.
2. Если ему это не удалось, то мы вместе начинаем искать возможные решения и совместно устраняем препятствие.
3. При возникновении проблемы повторно член команды решает ее самостоятельно или делится опытом с коллегами.
Отличная статья о том, кто такой скрам мастер и какие у него обязанности: http://www.barryovereem.com/a-day-in-the-life-of-a-scrum-master/
Наиболее интересным мне кажется тезис, что основная активность скрам мастера - это активное бездействие. Очевидно, что скрам мастер не должен сидеть сложа руки и лишь цитировать скрам гайд, однако систематическое выполнение задач, которые члены команды способны решить самостоятельно, может привести к тому, что скрам мастер постепенно превратится либо в проджект менеджера либо в золушку, выполняющую всю грязную работу.
Чтобы не уходить в крайности я выработал для себя правило:
1. Член команды должен попытаться решить проблему самостоятельно или при поддержки коллег.
2. Если ему это не удалось, то мы вместе начинаем искать возможные решения и совместно устраняем препятствие.
3. При возникновении проблемы повторно член команды решает ее самостоятельно или делится опытом с коллегами.
#книги #литература #scrummaster
Отличный сборник профессиональной литературы от одного из лучших обучающих центров.
https://www.unusual-concepts.ru/blog/2017/04/30-books-for-scrum-master/
Отличный сборник профессиональной литературы от одного из лучших обучающих центров.
https://www.unusual-concepts.ru/blog/2017/04/30-books-for-scrum-master/
#практики #декомпозиция
Крутой кейс применения User Story Mapping от Додо Пицца. Ребята пошагово описали, как использовали данный инструмент и как он им позволил сократить время реализации функционала с 6 до 2,5 месяцев.
https://m.habrahabr.ru/post/345524/
Крутой кейс применения User Story Mapping от Додо Пицца. Ребята пошагово описали, как использовали данный инструмент и как он им позволил сократить время реализации функционала с 6 до 2,5 месяцев.
https://m.habrahabr.ru/post/345524/
Habr
Как сторимэп помогает не завязнуть в разработке нового продукта на годы
«Додо Пицца» развивается в США. В середине 2016 года мы открыли доставку в Оксфорде и быстро поняли, что предпочтения клиентов в США и России отличаются. Американцы — индивидуалисты. Они привыкли,...
#совершенствованиеПроцесса #триз
Создатель ТРИЗ (Теория Решения Изобретательских Задач), Генрих Альтшуллер, в рамках своих работ ввел концепцию Идеального Конечного Результата (ИКР). В основе данного понятия лежит представление о том, что идеальная система - это система, которой нет, но функция ее выполняется. Как это применимо в рамках SCRUM?
Каждый раз, обсуждая различные нововведения на ретроспективах, задавайтесь вопросом, можно ли избежать создания нового процесса и использовать уже существующие церемонии и практики? Ограничивайте себя, стараясь найти решение какого-то вопроса.
Например, при разработке сложных модулей программистам не хватает одной лишь формулировки пользовательской истории и критериев приемки. В связи с этим на ретроспективе члены команды предлагают добавить детализированное описания задачи. В рамках обсуждения становится понятно, что для этого потребуются аналитики, которые работают на спринт вперед. Является ли это оптимальным решением?
Сформулируем ИКР для данной проблемы: разработчики самостоятельно могут ответить на вопрос, без привлечения других членов команды.
Из формулировки ИКР вытекает вопрос - могут ли разработчики самостоятельно принять решение без консультации с кем-либо из команды? Если да, то решение есть. Если нет, то следует посмотреть на набор минимальных активностей, которые приведут к нужному результату. Есть ли в команде человек, который потенциально способен дать ответ на любой вопрос разработчика? Да, есть. Это владелец продукта. Адресовав ему вопрос в течении спринта, разработчик может достаточно быстро и без лишних затрат получить необходимые пояснения. Если данную практику скомбинировать с правом самостоятельно принимать решения в случае отсутствия ответа от PO, то мы лишь не на много отклонимся от сформулированного ИКР.
Создатель ТРИЗ (Теория Решения Изобретательских Задач), Генрих Альтшуллер, в рамках своих работ ввел концепцию Идеального Конечного Результата (ИКР). В основе данного понятия лежит представление о том, что идеальная система - это система, которой нет, но функция ее выполняется. Как это применимо в рамках SCRUM?
Каждый раз, обсуждая различные нововведения на ретроспективах, задавайтесь вопросом, можно ли избежать создания нового процесса и использовать уже существующие церемонии и практики? Ограничивайте себя, стараясь найти решение какого-то вопроса.
Например, при разработке сложных модулей программистам не хватает одной лишь формулировки пользовательской истории и критериев приемки. В связи с этим на ретроспективе члены команды предлагают добавить детализированное описания задачи. В рамках обсуждения становится понятно, что для этого потребуются аналитики, которые работают на спринт вперед. Является ли это оптимальным решением?
Сформулируем ИКР для данной проблемы: разработчики самостоятельно могут ответить на вопрос, без привлечения других членов команды.
Из формулировки ИКР вытекает вопрос - могут ли разработчики самостоятельно принять решение без консультации с кем-либо из команды? Если да, то решение есть. Если нет, то следует посмотреть на набор минимальных активностей, которые приведут к нужному результату. Есть ли в команде человек, который потенциально способен дать ответ на любой вопрос разработчика? Да, есть. Это владелец продукта. Адресовав ему вопрос в течении спринта, разработчик может достаточно быстро и без лишних затрат получить необходимые пояснения. Если данную практику скомбинировать с правом самостоятельно принимать решения в случае отсутствия ответа от PO, то мы лишь не на много отклонимся от сформулированного ИКР.
#kanban #канбан #трансформация
Kanban-доска - это наиболее простой и быстрый способ сделать процесс работы более прозрачным. Фиксация всех выполняемых задач и их статуса (To Do, In Progress, Done) позволит получить ценные данные об узких местах, непрофильных (non value-adding) задачах, а также выявить основные проблемы, мешающие эффективной работе.
Естественно, Kanban-доска не серебряная пуля, но ее структура и фокусировка на потоке заставляет команду/отдел задуматься над тем, как можно улучшить свою работу.
В статье по ссылке автор дает советы, каким образом стоит внедрять данный инструмент и как он может использоваться для повышения прозрачности и эффективности процесса.
http://www.interactionagility.com/index.php/2017/12/22/4-steps-to-improve-delivery-of-value/
Kanban-доска - это наиболее простой и быстрый способ сделать процесс работы более прозрачным. Фиксация всех выполняемых задач и их статуса (To Do, In Progress, Done) позволит получить ценные данные об узких местах, непрофильных (non value-adding) задачах, а также выявить основные проблемы, мешающие эффективной работе.
Естественно, Kanban-доска не серебряная пуля, но ее структура и фокусировка на потоке заставляет команду/отдел задуматься над тем, как можно улучшить свою работу.
В статье по ссылке автор дает советы, каким образом стоит внедрять данный инструмент и как он может использоваться для повышения прозрачности и эффективности процесса.
http://www.interactionagility.com/index.php/2017/12/22/4-steps-to-improve-delivery-of-value/
Interaction Agility
4 Steps to Improve Delivery of Value
If you are involved in knowledge work where more than a single operation or task is required to move an idea to production, you're operating a workflow. Effectively delivering value through knowledge and service work is challenged by the fact that not only…
#фасилитация #групповоеПринятиеРешений
Отсутствие менеджеров и плоская структура организаций подразумевает, что основные решение принимаются командами. К сожалению, многие коллективы не умеют конструктивно обсуждать проблемы и приходить к взевешенным, разумным решениям (обратите внимание, что консенсус не обязателен и вообще редко достижим).
Что мешает группам эффективно взаимодействовать? Причин множество. Среди них:
1. Отсутствие в коллективе атмосферы доверия.
2. Неумение контролировать свои эмоции и амбиции.
3. Нежелание слышать другую точку зрения.
4. Непомерное эго.
5. Незнание эффективны практик по построению обсуждения и многие многие другие причины.
Дабы преодолеть эти проблемы, необходимо прибегнуть к помощи фасилитатора. Фасилитатор - это человек, который помогает группам найти наиболее эффективное решение того или иного вопроса.
Используя различные инструменты, фасилитатор помогает команде:
1. Услышать различные точки зрения (охватить весь спектр мнений).
2. В конструктивном ключе выявить достоинства и недостатки каждого мнения или идеи.
3. Исходя из полученной информации сконструировать рабочее решение.
В рубрике #фасилитация я буду рассказывать о практиках, которые помогают команде "без потерь" достигать целей встреч и дискуссий.
Отсутствие менеджеров и плоская структура организаций подразумевает, что основные решение принимаются командами. К сожалению, многие коллективы не умеют конструктивно обсуждать проблемы и приходить к взевешенным, разумным решениям (обратите внимание, что консенсус не обязателен и вообще редко достижим).
Что мешает группам эффективно взаимодействовать? Причин множество. Среди них:
1. Отсутствие в коллективе атмосферы доверия.
2. Неумение контролировать свои эмоции и амбиции.
3. Нежелание слышать другую точку зрения.
4. Непомерное эго.
5. Незнание эффективны практик по построению обсуждения и многие многие другие причины.
Дабы преодолеть эти проблемы, необходимо прибегнуть к помощи фасилитатора. Фасилитатор - это человек, который помогает группам найти наиболее эффективное решение того или иного вопроса.
Используя различные инструменты, фасилитатор помогает команде:
1. Услышать различные точки зрения (охватить весь спектр мнений).
2. В конструктивном ключе выявить достоинства и недостатки каждого мнения или идеи.
3. Исходя из полученной информации сконструировать рабочее решение.
В рубрике #фасилитация я буду рассказывать о практиках, которые помогают команде "без потерь" достигать целей встреч и дискуссий.
#scrum #scrumMythsbusters
10 основных мифов о Scrum (по Барри Оверем):
1. Скрам-мастер должен присутствовать на стендап митинге (DSM).
2. Беклог спринта не может меняться в течении спринта.
3. Релиз функционала происходит только в конце спринта.
4. Беклог продукта должен включать в себя только пользовательские истории.
5. Беклог продукта полностью приоритизирован.
6. Владелец продукта - прокси для стейкхолдеров.
7. Скрам-мастер должен самостоятельно устранять все препятствия.
8. Скрам-мастер - начинающий Agile коуч.
9. Оценка задач производится только в стори поинтах.
10. В скраме нельзя планировать на длительный срок (более одного-двух спринтов).
О том, почему все перечисленные утверждения - это мифы, вы можете прочитать здесь: http://www.barryovereem.com/a-summary-of-the-10-scrum-myths/
10 основных мифов о Scrum (по Барри Оверем):
1. Скрам-мастер должен присутствовать на стендап митинге (DSM).
2. Беклог спринта не может меняться в течении спринта.
3. Релиз функционала происходит только в конце спринта.
4. Беклог продукта должен включать в себя только пользовательские истории.
5. Беклог продукта полностью приоритизирован.
6. Владелец продукта - прокси для стейкхолдеров.
7. Скрам-мастер должен самостоятельно устранять все препятствия.
8. Скрам-мастер - начинающий Agile коуч.
9. Оценка задач производится только в стори поинтах.
10. В скраме нельзя планировать на длительный срок (более одного-двух спринтов).
О том, почему все перечисленные утверждения - это мифы, вы можете прочитать здесь: http://www.barryovereem.com/a-summary-of-the-10-scrum-myths/
#scrumEvents #dailyScrum #DSM #стендап
Очень часто ежедневные встречи команды (далее - DSM) проходят в стиле "вчера мы копали яму, сегодня мы будем копать яму, проблем нет". Естественно, что мероприятие в подобном формате не будет приносить никакой пользы и команда будет просто терять время на ней. В этом посте я хочу поделиться подходами, которые позволят наполнить смыслом ежедневные стенд апы.
До 2017 года создатели фреймворка рекоммендовали проводить DSM, опираясь на три базовые вопроса: что я делал вчера, что я делаю сегодня, какие проблемы. Однако в последней редакции Scrum гайда, авторы отметили, что формат стенд апа может быть любым, главное, чтобы команда понимала его ценность и использовала его с целью инспекции прогресса на пути к цели спринта.
Итак, как можно повысить эффективность данного события:
1. Не пускайте на DSM менеджеров и не позволяйте владельцу продукта опускаться на уровень микро менеджмента. На DSM он присутствует для того, чтобы ответить на вопросы команды, скорректировать приоритеты и сделать небольшие объявления по бизнес части продукта.
2. Фокусируйтесь на цели спринта. Если цель явно не сформулирована, то по умолчанию подразумевается, что должны быть реализованы все задачи. Спросите команду, есть ли угроза, что какая-либо задача не будет реализована. Ваша цель - на раннем этапе выявить проблемы и обратить на них внимание команды, пока не поздно.
3. Вместо вопроса "Какие проблемы возникли" уточняйте, что тормозит выполнение задачи, что мешает завершить ее максимально быстро.
4. Попробуйте применить канабан подход к проведению DSM - выберете наиболее приоритетную задачу в беклоге спринта и уточните у команды, что мешает ее закрыть и что еще необходимо сделать, чтобы она перешла в Done. Повторяйте это со следующими историями, пока не истекут 15 минут.
5. Используйте необходимые артефакты (burn-down chart, канбан доску с задачами), чтобы повысить "предметность" разговора.
6. Если ведете burn-down chart, то на DSM обращайте внимание на отставание от линии идеального прогресса.
7. Не пресекайте обсуждение любой проблемы на DSM. Если осуждение вопроса занимает разумное количество времени, то можно не выносить его в отдельную встречу. Однако, если возникает спор - стоит тут же предложить продолжить дискуссию после встречи.
8. Как скрам-мастер, старайтесь минимально участвовать в DSM и подключайтесь только при обращении к вам.
9. Поддерживайте энергичную атмосферу, чтобы мероприятие несло заряд бодрости на весь день.
Очень часто ежедневные встречи команды (далее - DSM) проходят в стиле "вчера мы копали яму, сегодня мы будем копать яму, проблем нет". Естественно, что мероприятие в подобном формате не будет приносить никакой пользы и команда будет просто терять время на ней. В этом посте я хочу поделиться подходами, которые позволят наполнить смыслом ежедневные стенд апы.
До 2017 года создатели фреймворка рекоммендовали проводить DSM, опираясь на три базовые вопроса: что я делал вчера, что я делаю сегодня, какие проблемы. Однако в последней редакции Scrum гайда, авторы отметили, что формат стенд апа может быть любым, главное, чтобы команда понимала его ценность и использовала его с целью инспекции прогресса на пути к цели спринта.
Итак, как можно повысить эффективность данного события:
1. Не пускайте на DSM менеджеров и не позволяйте владельцу продукта опускаться на уровень микро менеджмента. На DSM он присутствует для того, чтобы ответить на вопросы команды, скорректировать приоритеты и сделать небольшие объявления по бизнес части продукта.
2. Фокусируйтесь на цели спринта. Если цель явно не сформулирована, то по умолчанию подразумевается, что должны быть реализованы все задачи. Спросите команду, есть ли угроза, что какая-либо задача не будет реализована. Ваша цель - на раннем этапе выявить проблемы и обратить на них внимание команды, пока не поздно.
3. Вместо вопроса "Какие проблемы возникли" уточняйте, что тормозит выполнение задачи, что мешает завершить ее максимально быстро.
4. Попробуйте применить канабан подход к проведению DSM - выберете наиболее приоритетную задачу в беклоге спринта и уточните у команды, что мешает ее закрыть и что еще необходимо сделать, чтобы она перешла в Done. Повторяйте это со следующими историями, пока не истекут 15 минут.
5. Используйте необходимые артефакты (burn-down chart, канбан доску с задачами), чтобы повысить "предметность" разговора.
6. Если ведете burn-down chart, то на DSM обращайте внимание на отставание от линии идеального прогресса.
7. Не пресекайте обсуждение любой проблемы на DSM. Если осуждение вопроса занимает разумное количество времени, то можно не выносить его в отдельную встречу. Однако, если возникает спор - стоит тут же предложить продолжить дискуссию после встречи.
8. Как скрам-мастер, старайтесь минимально участвовать в DSM и подключайтесь только при обращении к вам.
9. Поддерживайте энергичную атмосферу, чтобы мероприятие несло заряд бодрости на весь день.
#greatScrumTeam #scrumMaster #ProductOwner
Доброе утро! По ссылке содержательная статья с ключевыми компетенциями скрам мастера, владельца продукта и команды разработки.
https://www.infoq.com/articles/great-scrum-team
Доброе утро! По ссылке содержательная статья с ключевыми компетенциями скрам мастера, владельца продукта и команды разработки.
https://www.infoq.com/articles/great-scrum-team
InfoQ
Characteristics of a Great Scrum Team
This article explores 'What makes a great Scrum team?' by offering detailed descriptions of the characteristics and skills needed in the Scrum roles of Product Owner, Scrum Master and Development Team.
#совершенствованиеПроцесса #leanSoftwareDevelopment
В случае, когда команда стабилизировала процесс разработки и предсказуемо реализует каждый спринт определенный объем функционала, необходимо искать новые точки роста. Здесь на помощь приходят 7 базовых категорий "отходов" из концепции бережливого производства ПО:
1. Частично выполненная работа (не до конца реализованный функционал).
2. Избыточные функциональные возможности.
3.Повторное приобретение знаний (игнорирование уже накопленного опыта).
4. Передача работы (передача задачи кому-то другому после завершения работы своей части работы).
5. Переключение между задачами (смена контекста ведет к потере до 80% процентов энергии).
6. Задержки (барьеры, мешающие доставить пользователю/клиенту конечную ценность).
7. Дефекты (некачественный функционал, которое требуется переделывать).
Каждую из категорий можно использовать, в качестве зоны, в которой команда еще может улучшить свой процесс. Используйте данные категории на ретроспективах, чтобы найти узкие места и стимулировать процесс дальнейшего развития.
В случае, когда команда стабилизировала процесс разработки и предсказуемо реализует каждый спринт определенный объем функционала, необходимо искать новые точки роста. Здесь на помощь приходят 7 базовых категорий "отходов" из концепции бережливого производства ПО:
1. Частично выполненная работа (не до конца реализованный функционал).
2. Избыточные функциональные возможности.
3.Повторное приобретение знаний (игнорирование уже накопленного опыта).
4. Передача работы (передача задачи кому-то другому после завершения работы своей части работы).
5. Переключение между задачами (смена контекста ведет к потере до 80% процентов энергии).
6. Задержки (барьеры, мешающие доставить пользователю/клиенту конечную ценность).
7. Дефекты (некачественный функционал, которое требуется переделывать).
Каждую из категорий можно использовать, в качестве зоны, в которой команда еще может улучшить свой процесс. Используйте данные категории на ретроспективах, чтобы найти узкие места и стимулировать процесс дальнейшего развития.