リーンソフトウェア開発における7つの無駄とそれらを防ぐ方法

リーンプロセス思考は、廃棄物の編集を根絶し、削減することを優先します。 大手企業で採用されている「無駄のない」アプローチにもかかわらず、いくつかの標準的な「無駄」の慣行は、その「明白な性質」のために存続しています。 人間や組織の慣習に深く刻まれている性質は、厳格なアプローチを取るまで頑固です。

廃棄物とは何ですか？

リソース/時間または労力を必要とするが、パフォーマンスまたは収益の発生に関連する結果をもたらさないものはすべて、「廃棄物」と呼ばれます。

最終的に、「廃棄物削減」手順は、チームの生産性と結果を向上させるように設計およびガイドされています。

しかし、リーンソフトウェア開発がアジャイルの先駆者となった今、ソフトウェアエンジニアリングと開発にこれらの7つの廃棄物削減原則を採用して、効果的な製品とサービスを生み出し、コストを削減し、製品の市場投入までの時間を短縮することができます。

1.部分的に完了した作業

前の作業が再開されない場合、その作業は無駄でした。

完了する/完了するまでの作業は、顧客の価値提案に追加されません。 したがって、保留にすると、時間とコードの維持に課題が発生します。

現代的な例は、クライアントが製品の変更または追加機能を必要とする場合です。 ビジネスはそれらを緊急に終了することを約束します。 開発チームは、進行中の作業を停止し、要件に基づいて行動する必要があります。 同じページで、前の作業が再開されない場合、それは労力の無駄です。

また

コード化されていないドキュメント：要件は完全に詳細化されていますが、実装されることはありません。

この無駄を減らす方法は？

• プロジェクトの「開始」だけでなく、「終了」に焦点を当てる必要があります。
• 進行中の作業期間を短縮します。
• チームが努力を実行する準備ができるまで、すべての要件の詳細な仕様を待つのをやめます（それが失われた原因になることはありません）。

2.追加のプロセス

実用的な価値を伝えず、製品市場のタイミングや成果を不必要に延長する追加のプロセスや未読のドキュメントは無駄です。

ただし、ビジネスポリシーでは、多くの場合、そのようなドキュメントが義務付けられており、かなりの事務処理が行われていますが、読むことはありません。 それらの努力は贅沢です。

典型的な例：

• ドキュメントの不必要な詳細。
• 実行せずに追加の管理または計画。

それを減らす方法は？

組織は、失われた原因/努力とテーブルに価値をもたらすものを区別できます。焦点は、意味のある結果を生み出すことと、「量」の作業を制限することによってより「質の高い」作業を行うための努力を導くことに焦点を当てる必要があります。

3.追加機能

顧客のために/顧客によって追加されたが、収益の増加を求められていない/貢献していない機能または価値の低い機能は、労力の無駄です。

企業は、あまり利用または実行されない機能を追加すると、この開発エラーが発生します。 この新機能は確かにアイドル状態にあり、アプリケーションの複雑さを増します。

ソフトウェア80/20の法則は重要な役割を果たします。ユーザーの80％は、その機能の20％しか利用していません。 したがって、既存のユーザーを維持するために、これらの20％の機能を一流にすることに焦点を当てる必要があります。

追加のコードには欠点があります。

• アプリケーションの複雑さが増します。
• アプリケーションがクラッシュする可能性があります。
• 製品ライフサイクル全体の追跡と保守に不必要な後作業が必要です。

この無駄を減らす方法は？
反復型開発に焦点を当てます。つまり、最初の製品リリース中に、アプリケーションのUSPを定義する堅牢な主要機能を構築します。

それを機能させることに焦点を合わせ、製品の継続的な進歩を学ぶことを検証します。 さらに、市場分析、消費者行動、フィードバックに基づいて適切な機能を構築し続けます。

4.タスク切り替え

人々がそれに慣れておらず、既存のプロセスを妨げているときに複数のタスクに人々を割り当てると、膨大な日数がかかる可能性があります。 特定のタスクを1つか2つ完了する最も効率的な方法は、一度に1つを完了することです。

タスクを切り替える際に、既存のタスクを閉じてもう一方のタスクに勢いをつけるのに少し時間がかかります。これはコンテキストスイッチと呼ばれ、あるタスクから別のタスクへの継続的な移行が予想される場合、これらのコンテンツスイッチは蓄積されて遅延します。 「結果」または「納期」。

それを減らす方法は？

シンプル-一度に1つのこと。

• コンテンツの切り替えを減らします。
• 中断や気を散らすものを最小限に抑えます。
• 重要でないものを延期します。
• 一度に1つのプロジェクトとしてリソースを割り当てます。

5.待機/遅延

承認の依存関係は、主に製品ロードマップの間にタイミングを合わせる必要があります。 特定の時間間隔が割り当てられていない場合は、返信とフィードバックの遅延に備えてください。 遅延はまた、消費者が製品の実際の価値を実現することを妨げます。 ただし、開発者または設計者は、完了した作業の承認を待つ必要があります。 したがって、タイムラプスを完全に回避することはできません。

これを減らすために何ができますか？

• 既存のフィードバックを待っている間に何かを選んで割り当てます。
• 入力とレビューに時間を割り当てます。
• 変更をメールで送信するのではなく、迅速な電話、対面での会話を検討してください。
• 定期的なフィードバック。

6.モーション

開発チームまたは研究チームが取得した情報に散在していて、それらに適切なマーク/ラベルを付けなかった場合、混乱と立ち寄りをかすめるのに永遠の時間がかかる可能性があります。 成果物が渡されるたびに情報が置き忘れられた場合。 結果を大幅に妨げることになります。

それを減らす方法は？

• ラベルの割り当てまたは取得したリソース。
• フィードバックのタイミングを減らします。
• 対面のコラボレーション。

7.欠陥

欠陥によって引き起こされた廃棄物の量=（欠陥の影響）x（検出されなくなる時間）

その複雑さのために、ソフトウェア開発は避けられない欠陥を作ります、しかし問題はそれらが実行と固定で延長されるか、固定または再作業の影響で発生するコストで発生します。 さらに、主要なコードエラーやバグは、製品のライフサイクル全体に影響を与えて妨げ、セキュリティの脅威に対して脆弱なままにして、何百万もの収益を失う可能性があります。

これを減らすために何ができますか？

• 即時テスト。
• 一定の統合。
• 製品のテストとリリースをできるだけ早く。