7 потерь в бережливой разработке программного обеспечения и как их предотвратить

Мышление бережливого процесса отдает приоритет искоренению и сокращению компиляции отходов. Несмотря на «бережливый» подход, принятый крупными компаниями, некоторые стандартные «отходы» сохраняются из-за их «очевидности». Природа, глубоко укоренившаяся в человеческих и организационных практиках, упряма до тех пор, пока к ней не применить строгий подход.

Что такое отходы?

Все, что требует ресурсов/времени или усилий, но не дает соответствующих результатов в плане производительности или получения дохода, называется «отходами».

В конечном счете, процедура «сокращения потерь» разработана и направлена ​​на повышение производительности и результатов команды.

Однако теперь, когда бережливая разработка программного обеспечения является праотцом гибкой разработки, мы можем принять эти семь принципов сокращения потерь при проектировании и разработке программного обеспечения, чтобы создавать эффективные продукты и услуги, снижать затраты и ускорять время выхода продукта на рынок.

1. Частично выполненная работа

Если предыдущая работа никогда не возобновлялась, то эти усилия были напрасными.

Любая работа, пока она не закончена/не завершена, не увеличивает ценностное предложение клиента; таким образом, это тратит время и затрудняет поддержку кода, если его отложить.

Современный пример — когда клиенту требуется модификация или дополнительные функции продукта. Бизнес стремится закончить их в срочном порядке; команда разработчиков должна остановить текущую работу и действовать в соответствии с требованиями. На той же странице, если предыдущая работа никогда не возобновлялась, это была пустая трата усилий.

или

Незакодированная документация: требования тщательно детализированы, но так и не реализованы.

Как уменьшить эти отходы?

• В центре внимания должно быть «завершение», а не просто «начало» проекта.
• Сокращение сроков незавершенного производства.
• Перестаньте ждать подробной спецификации по каждому требованию, пока команда не будет готова к реализации усилий (тогда это не будет безнадежным делом).

2. Дополнительные процессы

Любой добавленный процесс или непрочитанная документация, которые не несут практической ценности и без необходимости продлевают сроки выхода продукта на рынок или достижения, являются пустой тратой времени.

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

Типичные примеры:

• Ненужная детализация документации.
• Дополнительное управление или планирование без исполнения.

Как его уменьшить?

Организации могут различать то, что является потерянной причиной/усилием, и то, что приносит пользу, основное внимание должно быть сосредоточено на получении значимых результатов и направлении усилий на выполнение более «качественной» работы за счет ограничения «количественной» работы.

3. Дополнительные функции

Любая функция или малоценные функции, которые добавляются для/покупателем, но не запрашиваются/не способствуют увеличению дохода, являются пустой тратой усилий.

Компании совершают эту ошибку разработки, когда добавляют функции, которые не будут широко использоваться или применяться; эта новая функция действительно простаивает и увеличивает сложность приложения.

Правило программного обеспечения 80/20 играет важную роль: 80% пользователей используют только 20% его функций. Поэтому нужно сосредоточиться на том, чтобы сделать эти 20% функций первоклассными, чтобы удержать существующих пользователей.

У дополнительных кодов есть свои минусы:

• Увеличивает сложность приложения.
• Может стать потенциальной точкой сбоя приложения.
• Требует ненужных дополнительных усилий по отслеживанию и обслуживанию на протяжении всего жизненного цикла продукта.

Как уменьшить эти отходы?
Сосредоточьтесь на итеративной разработке — это означает, что во время первоначального выпуска продукта создайте надежные основные функции, которые определяют УТП вашего приложения.

Сосредоточьтесь на том, чтобы сделать его функциональным, и подтвердите непрерывное совершенствование продукта. Кроме того, продолжайте создавать соответствующие функции на основе вашего анализа рынка, поведения потребителей и отзывов.

4. Переключение задач

Назначение людям нескольких задач, когда им это неудобно и мешает их существующему процессу, может занять огромное количество их дней. Самый эффективный способ выполнить одно или два задания — это выполнять их по очереди.

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

Как его уменьшить?

Просто-одна вещь за один раз.

• Уменьшите переключение контента.
• Минимизируйте прерывания или отвлекающие факторы.
• Отложите неважные дела.
• Распределяйте ресурсы по одному проекту за раз.

5. Ожидание/задержки

Зависимости утверждения должны быть рассчитаны в первую очередь во время дорожной карты продукта; если конкретный интервал времени не выделен, будьте готовы к задержке ответов и обратной связи. Задержки также мешают потребителю осознать реальную ценность продукта. Но, как разработчики или дизайнеры, вы должны дождаться одобрения проделанной работы; таким образом, вы не можете полностью избежать покадровой съемки.

Что вы можете сделать, чтобы уменьшить это?

• Выберите/назначьте что-нибудь, ожидая существующих отзывов.
• Выделите время для ввода и проверки.
• Подумайте о быстрых звонках, личных беседах, а не об изменениях по электронной почте.
• Регулярная обратная связь.

6. Движение

Если команды разработчиков или исследователей были разбросаны по полученной информации и не пометили/пометили их надлежащим образом, может потребоваться целая вечность, чтобы избавиться от путаницы и вмешаться. Если информация неуместна каждый раз, когда результат передается; это резко ухудшит результаты.

Как его уменьшить?

• Отметьте полученные задания или ресурсы.
• Уменьшите время обратной связи.
• Сотрудничество лицом к лицу.

7. Дефект

Количество потерь, вызванных дефектом = (Влияние дефекта) x (Время, в течение которого он остается незамеченным)

Из-за своей сложности разработка программного обеспечения создает неизбежные дефекты, но проблема возникает, когда они затягиваются на выполнение и исправление или влияют затраты, понесенные на исправление или доработку. Кроме того, серьезные ошибки и ошибки в коде могут потенциально повлиять на весь жизненный цикл продукта и помешать ему, а также сделать его уязвимым для угроз безопасности, что приведет к потере миллионов доходов.

Что вы можете сделать, чтобы уменьшить это?

• Немедленное тестирование.
• Постоянная интеграция.
• Тестирование продукта и выпуск как можно скорее.