Lean software development

Lean development can be summarized by seven principles, very close in concept to lean manufacturing principles:

1. Eliminate waste
2. Amplify learning
3. Decide as late as possible
4. Deliver as fast as possible
5. Empower the team
6. Build integrity in
7. Optimize the whole

Eliminate wasteEdit

Lean philosophy regards everything not adding value to the customer as waste (muda). Such waste may include:

1. Partially done work
2. Extra features
3. Relearning
4. Task switching
5. Waiting
6. Handoffs
7. Defects
8. Management activities

In order to eliminate waste, one should be able to recognize it. If some activity could be bypassed or the result could be achieved without it, it is waste. Partially done coding eventually abandoned during the development process is waste. 事務処理のような余分な機能や、顧客があまり使用しない機能は無駄である。 タスク間で人を入れ替えるのはムダです。 他の活動、チーム、プロセスを待つことは無駄である。 仕事を完了するために必要な再学習はムダです。 不良品や品質低下はムダです。

バリューストリームマッピングの技法は、無駄を特定するために使用されます。

バリューストリームマッピングの手法は、無駄を特定するために使用されます。第2段階は、無駄の原因を指摘し、それを排除することです。

Amplify learningEdit

ソフトウェア開発は、コードを書くときの反復に基づく継続的な学習プロセスです。 ソフトウェア設計は、コードを書く開発者と彼らが学んだことを含む問題解決プロセスです。

より多くのドキュメントや詳細な計画を追加する代わりに、コードを書き、構築することで、異なるアイデアを試すことができます。

ユーザー要求の収集は、エンドユーザーに画面を提示して意見を聞くことで簡略化できるかもしれません。

学習プロセスは、短い反復サイクルを使用することによって加速されます – 各サイクルはリファクタリングと統合テストと結合されます。 顧客との短いフィードバックセッションを通じてフィードバックを増やすことは、開発の現在の段階を決定し、将来の改善のために努力を調整する際に役立ちます。 このような短いセッションの中で、顧客担当者と開発チームの両方が、ドメインの問題についてより深く学び、さらなる開発のための可能な解決策を見出すことができます。 こうして、顧客は既存の開発結果を基にニーズをよりよく理解し、開発者はそのニーズをよりよく満たす方法を学ぶことができるのです。 顧客とのコミュニケーションおよび学習プロセスにおけるもう 1 つのアイデアは、セットベースの開発です。これは、可能なソリューションではなく、将来のソリューションの制約を伝えることに集中し、顧客との対話を通じてソリューションの誕生を促進します。

できるだけ遅く決める

ソフトウェア開発は常にいくつかの不確実性と関連しているので、セットベースまたはオプションベースのアプローチで、不確実な仮定や予測ではなく事実に基づいて決定できるまでできるだけ遅らせることにより、優れた結果を達成すべきです。 システムが複雑であればあるほど、より多くの変更能力を組み込むべきであり、その結果、重要かつ決定的なコミットメントを遅らせることが可能になる。 繰り返しアプローチでは、この原則、つまり、変化に適応し、システムのリリース後に発見されると非常に高くつく可能性のある誤りを修正する能力を促進します。 例えば、自動車に新しいブレーキシステムが必要な場合、3つのチームが同じ問題に対する解決策を設計することがあります。 各チームは問題空間について学習し、潜在的な解決策を設計します。 そして、その解決策が無理だと判断されると、その解決策はカットされる。 期間終了後、生き残った設計を比較し、1つを選択します。おそらく、他のチームから学んだことに基づいて、いくつかの修正を加えます。これは、最後の可能な瞬間までコミットメントを延期する素晴らしい例です。 ソフトウェアの決定にも、この方法が有効で、大きな先行設計がもたらすリスクを最小限に抑えることができます。 さらに、正しく動作するにもかかわらず、（内部的には）異なる複数の実装が存在することになります。 これらの実装を利用して、複数の実装間ですべての入力と出力の正しさを同時にチェックするフォールトトレラントシステムを実装することができる。

アジャイルソフトウェア開発アプローチは、顧客にとって選択肢の構築を早め、顧客がニーズをよく理解するまで、ある重要な決定を遅らせることができます。 また、これにより、変化に後から適応し、コストのかかる初期の技術に縛られた決定を防ぐことができます。 これは、計画を立ててはいけないということではありません。逆に、計画活動は、さまざまな選択肢と現状への適応に集中し、迅速な行動のためのパターンを確立することで混乱した状況を明確にする必要があるのです。 さまざまな選択肢を評価することは、それらが自由ではなく、遅い意思決定のために必要な柔軟性を提供するものであることがわかると同時に効果的です。

Deliver as fast as possibleEdit

急速な技術進化の時代において、生き残るのは最大ではなく、最速であることです。 最終製品が大きな欠陥なく早く提供されればされるほど、フィードバックを受け取り、次の反復に取り入れることができます。 イテレーションが短ければ短いほど、チーム内の学習とコミュニケーションがうまくいく。 スピードがあれば、決断を遅らせることができる。 スピードは、顧客が昨日要求したことではなく、現在のニーズを満たすことを保証する。 そのため、より良い知識を得るまで、本当に必要なものを決めるのを遅らせることができるのです。

ジャストインタイム生産の思想は、その特定の要件と環境を認識して、ソフトウェア開発に適用することができます。 これは、必要な結果を提示し、特定の反復のために必要な結果を達成するために、チームに組織化させ、タスクを分割させることによって達成されます。 最初に、顧客は必要な情報を提供する。 これは、単純に小さなカードやストーリーで提示することができます – 開発者は、各カードの実装に必要な時間を見積もる。 毎朝のスタンドアップミーティングで、チームの各メンバーは、昨日何が行われたか、今日と明日は何を行うべきかを検討し、同僚や顧客から必要なインプットを求めます。

この原則の根底にある神話は、「急いては事を仕損じる」です。

この原則の根底にある神話は、「急いては事を仕損じる」です。しかし、リーン生産方式では、最も早い段階で出力を確認し分析するために、迅速に提供することが良い習慣であることが示されています。 ワークアウト技法では、役割が逆転します。管理者は、開発者に耳を傾ける方法を教わるので、どのようなアクションが取られるかも、改善のための提案も、よりよく説明できるようになります。

もう1つの間違った信念は、人をリソースとして考慮することです。 しかし、ソフトウェア開発では、他の組織的なビジネスと同様に、人々は、タスクのリストとタスクの完了中に邪魔されないという保証以上のものを必要とします。 手の届く範囲にある目的であり、チームが自らのコミットメントを選択できるという保証が必要なのです。 チームリーダーは、困難な状況下でサポートと支援を提供し、懐疑的な態度がチームの精神を崩壊させないようにしなければならない。 人々を尊重し、彼らの仕事を認めることは、チームに力を与える方法の 1 つです。

Build integrity inEdit

顧客はシステムの全体的な経験を持つ必要があります。

概念的な整合性とは、システムの個別のコンポーネントが、柔軟性、保守性、効率性、および応答性のバランスを保ちながら全体としてうまく機能することを意味します。 これは、問題領域を理解し、それを順次ではなく、同時に解決することで達成される可能性があります。 必要な情報は、一度に大量に受け取るのではなく、小分けにして、できれば対面でのコミュニケーションで受け取り、文書化しない。 情報の流れは、顧客から開発者への、そしてその逆方向への両方向で一定であるべきで、その結果、孤立した長い開発の後に大量のストレスとなる情報を避けることができます。

統合アーキテクチャへの健全な方法の1つはリファクタリングです。

インテグラルアーキテクチャに向けた健全な方法の1つがリファクタリングです。 リファクタリングとは、コードにシンプルさ、明確さ、最小限の機能を維持することです。 コードの繰り返しは、悪いコード設計の兆候であり、避けなければなりません。 完全で自動化されたビルドプロセスは、開発者と顧客のための完全で自動化された一連のテストを伴うべきで、システムの現在の状態と同じバージョン管理、同期化、セマンティクスを持つべきです。 最終的には、徹底的なテストによって完全性が検証され、システムが顧客の期待に応えるものであることが保証されなければなりません。 自動化されたテストも生産プロセスの一部とみなされるため、付加価値がない場合は無駄とみなされます。

全体を最適化する

現代のソフトウェア システムは、単に部品の合計ではなく、それらの相互作用の産物でもあります。 ソフトウェアの欠陥は、開発プロセス中に蓄積される傾向があります。大きなタスクを小さなタスクに分解し、開発のさまざまな段階を標準化することにより、欠陥の根本原因を発見し、排除することができるはずです。 システムの規模が大きくなればなるほど、開発に携わる組織の数が多くなればなるほど、また、異なるチームによって開発される部分が多くなればなるほど、コンポーネントが円滑に相互作用するシステムを実現するために、異なるベンダー間の関係を明確にすることの重要性は高くなります。

リーンシンキングは、具体的な現実の状況で実施する前に、プロジェクトのすべてのメンバーによってよく理解されなければなりません。 “Think big, act small, fail fast; learn rapidly” – これらのスローガンは、ソフトウェア開発プロセス全体に沿ってリーン原則を実装することの現場と適合性を理解することの重要性を要約したものです。 リーンの原則がすべて一緒に実行され、作業環境に関する強力な「常識」と組み合わされて初めて、ソフトウェア開発における成功の基盤ができるのです

。