Пусть Lean Thinking вдохновит вас
Lean Thinking - это мощный инструмент, который хорошо дополняет метод Agile при разработке программного обеспечения. Есть несколько способов, с помощью которых бережливое мышление может вдохновить и побудить Agile-команды совершенствоваться в своей работе и сделать их рабочую жизнь более гладкой. Это помогает командам на пути к постоянному совершенствованию.
В знаменитой книге Lean Software Development: An Agile Toolkit Мэри и Том Поппендик упоминают, что научиться замечать отходы - это первый шаг в достижении прорыва с помощью бережливого мышления. . Далее они определяют семь категорий потерь при разработке программного обеспечения.
Если ваша организация решила использовать структуру Scrum для разработки продукта, что означает «видеть отходы» в этом контексте?
Если вы являетесь членом команды разработчиков:
Хорошие команды Scrum постоянно ищут улучшения. Вот где им может быть чрезвычайно полезна возможность «видеть отходы». Как только они увидят отходы, они смогут принять меры, чтобы избавиться от них или, по крайней мере, минимизировать их. Помимо очевидных преимуществ сокращения отходов, часто команды чувствуют большое чувство достижения, когда они могут убрать определенные отходы, которые препятствуют разработке продукта, например давний организационный процесс / практика, которая больше не добавляет ценности, или мертвый фрагмент кода и т. д.
Если вы являетесь частью Управления:
В организации, использующей Scrum, руководство может играть ключевую роль в поддержке всех усилий команд по выявлению и устранению потерь. Много раз в своем стремлении к сокращению отходов команды сталкивались с организационным сопротивлением и другими подобными препятствиями. Они часто нуждаются в поддержке со стороны тех, кто имеет более широкое влияние или авторитет в организации. Такие ситуации дают руководству возможность обслуживать команды и повышать уровень гибкости организации. Помощь командам в сокращении отходов и поощрение их к регулярному выделению этих отходов является обязанностью руководства.
Если вы Scrum-мастер или Agile-коуч:
Скрам-мастера и гибкие тренеры могут внести огромный вклад в эту область. Они могут научить команды улучшать их способность видеть отходы, обучая их бережливому мышлению и обнаруживая, что считается отходами в их конкретном организационном контексте. В своем стремлении выявить отходы Скрам-мастера могут побудить команды ставить под сомнение все, что не добавляет ценности с точки зрения клиента. Подобно менеджменту, Scrum-мастера могут помочь командам в их усилиях по сокращению потерь, когда команды обращаются за такой помощью. Одним из важных способов, которыми Скрам-мастера могут внести свой вклад в организацию, является то, что они сами указывают на отходы и инициируют дискуссии о том, как их уменьшить.
Как я упоминал ранее, бережливое мышление неплохо дополняет способ работы Agile. Например, если вы используете структуру Scrum, то для выявления потерь можно использовать такие события, как Sprint Retrospective или даже Daily Scrum. Фактически, способность видеть отходы можно практиковать постоянно, на ежедневной основе, и эти Scrum-мероприятия предоставляют идеальную платформу для мозгового штурма возможных решений или элементов действий по сокращению отходов.
В повседневной работе много раз мусора прямо перед вами, однако вы не можете увидеть его. Для этого может быть несколько причин: вы можете не понимать, что классифицируется как отходы в вашем контексте, или у вас может не быть привычки активно выявлять отходы, чтобы постоянно улучшаться. В обоих случаях бережливое мышление дает вам отличное руководство и воодушевляет, чтобы вы начали замечать потери, которые в противном случае могли бы быть не так очевидны для вас.
Задавать вопросы своим сотрудникам - это хороший способ начать работу и научиться видеть отходы. Примеры таких вопросов могут быть:
- Есть ли устаревшие ветки кода, которые давно не объединялись?
- Время от времени накапливается слишком много незафиксированных изменений кода?
- Есть ли у инженеров привычка фиксировать изменения кода перед запуском всех тестов?
- Слишком много компонентов, а не функций, что приводит к большому количеству передач и зависимостей?
- В вашей рабочей модели слишком много бункеров?
- Часто ли происходят серьезные изменения в стеке технологий?
- Документации слишком много или слишком мало?
- Легко ли читается код? Есть ли в коде ненужные или нечитаемые комментарии?
- Слишком много переключения контекста? Участвуют ли члены команды в нескольких проектах?
- Разница в часовых поясах вызывает слишком много времени ожидания или передачи обслуживания?
- Требуется ли слишком много времени для подготовки сред разработки?
- Слишком много внешних зависимостей?
- Есть ли слишком много функций, которые не используются пользователями?
- Вы используете новейшие технологические инструменты только потому, что они новые и блестящие?
Увидеть расточительство - это, возможно, только первый шаг к применению бережливого мышления в ваших методах работы. Бережливое мышление может предложить так много, чтобы помочь в постоянном совершенствовании. Пусть Lean Thinking вдохновит вас!
