リーンソフトウェア開発

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ


リーンソフトウェア開発は、リーン生産方式の原則と実践をソフトウェア開発ドメインに変換したものです。トヨタ生産方式[1]から採用されアジャイルコミュニティ内のプロリーンサブカルチャーのサポートを受けて登場しています。リーンは、アジャイル組織をサポートする、経験から導き出され た堅実な概念フレームワーク、価値観、原則、およびグッドプラクティスを提供します。

オリジン

リーンソフトウェア開発という用語は、2003年にメアリーポッペンディークとトムポッペンディークによって書かれた同じ名前の本に由来します。[2]この本は、従来のリーン原則と22のツールのセットを再記述し、ツールを対応するアジャイルプラクティスと比較します。 。いくつかのアジャイル会議での講演を含む、アジャイルソフトウェア開発コミュニティへのPoppendiecksの関与[3]により、そのような概念はアジャイルコミュニティ内でより広く受け入れられるようになりました。

リーン原則

リーン開発は、リーン生産方式に非常に近い概念の7つの原則で要約できます。[4]

  1. 無駄をなくす
  2. 学習を増幅する
  3. できるだけ遅く決定する
  4. できるだけ早く配信する
  5. チームに力を与える
  6. で整合性を構築する
  7. 全体を最適化する

無駄をなくす

リーン哲学は、顧客に付加価値をもたらさないすべてのものを無駄と見なします(ムダ)。このような廃棄物には次のものが含まれます。[5]

  1. 部分的に行われた作業
  2. 追加機能
  3. 再学習
  4. タスク切り替え
  5. 待っている
  6. ハンドオフ
  7. 欠陥
  8. 管理活動


無駄をなくすためには、それを認識できる必要があります。一部のアクティビティをバイパスしたり、それなしで結果を達成したりできる場合、それは無駄です。開発プロセス中に最終的に放棄された部分的に行われたコーディングは無駄です。事務処理や顧客があまり使用しない機能などの余分な機能は無駄です。タスク間で人を切り替えるのは無駄です(コンテキスト切り替えに関与する人が時間を費やし、多くの場合失われるため)。他の活動、チーム、プロセスを待つことは無駄です。作業を完了するための要件の再学習は無駄です。欠陥や低品質は無駄です。真の価値を生み出さない経営上のオーバーヘッドは無駄です。

バリューストリームマッピング技術は、無駄を特定するために使用されます2番目のステップは、廃棄物の発生源を指摘し、それらを排除することです。廃棄物の除去は、一見不可欠なプロセスや手順でさえも清算されるまで、繰り返し行う必要があります。

学習を増幅する

ソフトウェア開発は、コードを書くときの反復に基づく継続的な学習プロセスです。ソフトウェア設計は、開発者がコードを記述し、何を学んだかを含む問題解決プロセスです。ソフトウェアの価値は、要件に準拠しておらず、使用に適しているかどうかで測定されます。

ドキュメントや詳細な計画を追加する代わりに、コードを記述して構築することで、さまざまなアイデアを試すことができます。ユーザー要件の収集プロセスは、エンドユーザーに画面を表示して入力を取得することで簡素化できます。コードを記述したらすぐにテストを実行して、欠陥の蓄積を防ぐ必要があります。

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

できるだけ遅く決める

ソフトウェア開発は常にある程度の不確実性を伴うため、セットベースまたはオプションベースのアプローチでより良い結果を達成し、不確実な仮定や予測ではなく事実に基づいて決定できるようになるまで、決定を可能な限り遅らせる必要があります。システムが複雑になるほど、システムに変更の容量を組み込む必要があります。これにより、重要かつ重要なコミットメントを遅らせることができます。反復的なアプローチは、この原則を促進します。変更に適応し、間違いを修正する機能です。これは、システムのリリース後に発見された場合、非常にコストがかかる可能性があります。

セットベースの開発の場合:たとえば、車に新しいブレーキシステムが必要な場合、3つのチームが同じ問題の解決策を設計することがあります。各チームは問題空間について学び、潜在的な解決策を設計します。解決策は不合理と見なされるため、削減されます。期間の終わりに、残っている設計が比較され、1つが選択されます。おそらく、他の設計からの学習に基づいていくつかの変更が加えられます。これは、可能な限り最後の瞬間までコミットメントを延期する良い例です。ソフトウェアの意思決定も、この慣行から利益を得て、大規模な先行設計によってもたらされるリスクを最小限に抑えることができます。さらに、正しく機能するが異なる(実装に関しては内部的に)複数の実装が存在することになります。これらは、すべての入力と出力が正しいかどうかをチェックするフォールトトレラントシステムを実装するために使用できます。

アジャイルソフトウェア開発アプローチは、顧客のオプションの構築を早期に進めることができるため、顧客がニーズをよりよく理解するまで、特定の重要な決定を遅らせることができます。これにより、後から変更に適応し、コストのかかる初期のテクノロジーに基づく決定を防ぐこともできます。これは、計画が含まれるべきではないという意味ではありません。逆に、計画活動は、さまざまなオプションに集中し、現在の状況に適応し、迅速な行動のパターンを確立することによって混乱する状況を明確にする必要があります。さまざまなオプションを評価することは、それらが無料ではないことがわかったらすぐに効果的ですが、後の意思決定に必要な柔軟性を提供します。

できるだけ早く配信する

急速な技術進化の時代において、それは生き残る最大のものではありませんが、最速です。最終製品が大きな欠陥なしに納品されるのが早ければ早いほど、フィードバックをより早く受け取り、次のイテレーションに組み込むことができます反復が短いほど、チーム内の学習とコミュニケーションが向上します。スピードがあれば、決定を遅らせることができます。スピードは、顧客が昨日必要としていたものではなく、顧客の現在のニーズを満たすことを保証します。これは彼らがより良い知識を得るまで彼らが本当に必要とするものについて彼らの決心を遅らせる機会を彼らに与えます。顧客は高品質の製品の迅速な配達を高く評価しています。

ジャストインタイムの本番イデオロギーは、その特定の要件と環境を認識して、ソフトウェア開発に適用できます。これは、必要な結果を提示し、チームが自分自身を整理し、特定の反復で必要な結果を達成するためのタスクを分割できるようにすることで実現されます最初に、顧客は必要な入力を提供します。これは、小さなカードまたはストーリーで簡単に提示できます。開発者は、各カードの実装に必要な時間を見積もります。したがって、作業組織は、毎朝のスタンドアップミーティング中にセルフプルシステムに変わります。、チームの各メンバーは、昨日何が行われたか、今日と明日何が行われるかを確認し、同僚や顧客から必要な入力を求めます。これにはプロセスの透明性が必要であり、チームのコミュニケーションにも役立ちます。

この原則の根底にある神話は、急いで無駄にするというものです。ただし、無駄のない実装では、出力をできるだけ早く確認して分析するために、迅速に配信することをお勧めします。

チームに力を与える

組織の意思決定については、ほとんどの企業で伝統的な信念があります。マネージャーは労働者に自分の仕事のやり方を教えます。ワークアウト手法では、役割が変わります。マネージャーは開発者の話を聞く方法を教えられるので、どのような行動を取るかをよりよく説明し、改善のための提案を提供できます。リーンアプローチは、アジャイルの原則[6]「やる気のある個人を中心にプロジェクトを構築し[...]、仕事を成し遂げるために彼らを信頼する」[7]進歩を促し、エラーを見つけ、障害を取り除きますが、マイクロ管理は行いません。

もう1つの誤った信念は、人を資源として考えることです。統計データシートの観点からは人はリソースかもしれませんが、ソフトウェア開発や組織のビジネスでは、タスクのリストと完了時に邪魔されないという保証以上のものが必要です。タスクの。人々は、チームが独自のコミットメントを選択する可能性があるという保証を持って、到達可能な現実の中での目的のために働くためのモチベーションとより高い目的を必要としています。開発者には顧客へのアクセス権を与える必要があります。チームリーダー困難な状況でサポートと支援を提供するだけでなく、懐疑論がチームの精神を台無しにしないようにする必要があります。人々を尊重し、彼らの仕事を認めることは、チームに力を与える1つの方法です。

で整合性を構築する

お客様は、システムの全体的な経験を持っている必要があります。これは、いわゆる認識された整合性です。つまり、広告、配信、展開、アクセスの方法、使用の直感性、価格、問題の解決方法です。

概念の整合性とは、システムの個別のコンポーネントが全体としてうまく機能し、柔軟性、保守性、効率、および応答性のバランスが取れていることを意味します。これは、問題のドメインを理解し、それを順番にではなく同時に解決することで達成できます。必要な情報は、1つの大きな塊ではなく、小さなバッチで受け取られます。できれば、書面による文書ではなく、対面でのコミュニケーションによって受け取られます。情報の流れは、顧客から開発者、そしてその逆の両方向で一定である必要があります。これにより、長期間の開発を単独で行った後の大量のストレスの多い情報を回避できます。

統合アーキテクチャに向けた健全な方法の1つは、リファクタリングです。元のコードベースに追加される機能が増えると、さらに改善を加えることが難しくなります。リファクタリングとは、コード内の機能の単純さ、明確さ、最小数を維持することです。コード内の繰り返しは、悪いコード設計の兆候であり、回避する必要があります(つまり、DRYルールを適用することによって))。完全で自動化された構築プロセスには、システムの現在の状態と同じバージョン管理、同期、およびセマンティクスを備えた、開発者と顧客のテストの完全で自動化されたスイートを伴う必要があります。最後に、完全性を徹底的なテストで検証する必要があります。これにより、システムが顧客の期待どおりに機能することを確認できます。自動テストも製造プロセスの一部と見なされるため、付加価値がない場合は無駄と見なす必要があります。自動テストは目標ではなく、目的を達成するための手段、具体的には欠陥の削減です。

全体を最適化する

最新のソフトウェアシステムは、単にそれらの部分の合計であるだけでなく、それらの相互作用の産物でもあります。ソフトウェアの欠陥は、開発プロセス中に蓄積する傾向があります。大きなタスクを小さなタスクに分解し、開発のさまざまな段階を標準化することで、欠陥の根本原因を見つけて排除する必要があります。システムが大きくなればなるほど、その開発に関与する組織が増え、さまざまなチームによって開発される部品が増えるほど、スムーズに相互作用するコンポーネントを備えたシステムを作成するために、さまざまなベンダー間で明確に定義された関係を持つことが重要になります。より長い開発期間中、より強力な下請け業者ネットワークは、 Win-Winの関係を可能にしない短期的な利益の最適化よりもはるかに有益です

無駄のない考え方は、具体的な現実の状況で実施する前に、プロジェクトのすべてのメンバーが十分に理解する必要があります。「大きく考え、小さく行動し、迅速に失敗し、迅速に学ぶ」[8] –これらのスローガンは、フィールドを理解することの重要性と、ソフトウェア開発プロセス全体にリーン原則を実装することの適合性を要約しています。無駄のない原則のすべてが一緒に実装され、作業環境に関する強力な「常識」と組み合わされた場合にのみ、ソフトウェア開発の成功の基礎があります。

リーンソフトウェアプラクティス

リーンソフトウェア開発の実践、またはポッペンディークが「ツール」と呼ぶものは、アジャイルソフトウェア開発の元の同等物からわずかに言い換えられています。そのような慣行の例は次のとおりです。

アジャイルソフトウェア開発は、アジャイルマニフェストで表現された価値と原則に基づく一連の方法と実践の総称であるため、リーンソフトウェア開発はアジャイルソフトウェア開発方法と見なされます。[9]

も参照してください

参照

  1. ^ 門田安弘(1998)、トヨタ生産システム、ジャストインタイムへの統合アプローチ、第3版、ジョージア州ノークロス:Engineering&Management Press、 ISBN0-412-83930  -X
  2. ^ メアリーポッペンディーク; トムポッペンディーク(2003)。リーンソフトウェア開発:アジャイルツールキットアディソン-ウェスリープロフェッショナル。ISBN 978-0-321-15078-3
  3. ^ Mary Poppendieck:「ソフトウェア開発におけるリーダーシップの役割」 https://www.youtube.com/watch?v=ypEMdjslEOI
  4. ^ メアリーポッペンディーク; トムポッペンディーク(2003)。リーンソフトウェア開発:アジャイルツールキットアディソン-ウェスリープロフェッショナル。pp。13–15。ISBN 978-0-321-15078-3
  5. ^ メアリーポッペンディーク; トムポッペンディーク(2003)。リーンソフトウェア開発:アジャイルツールキットアディソン-ウェスリープロフェッショナル。pp。19–22。ISBN 978-0-321-15078-3
  6. ^ 「アジャイルマニフェストの背後にある12の原則-アジャイルアライアンス」agilealliance.org2015年11月4日。
  7. ^ マークライン; スコットW.アンブラー(2012)。規律あるアジャイルデリバリー:企業におけるアジャイルソフトウェアデリバリーの実践者ガイドIBMプレス。pp。54–。ISBN 978-0-13-281013-5
  8. ^ メアリーポッペンディーク; トムポッペンディーク(2003)。リーンソフトウェア開発:アジャイルツールキットアディソン-ウェスリープロフェッショナル。pp。182–。ISBN 978-0-321-15078-3
  9. ^ 「アジャイルソフトウェア開発とは何ですか?」agilealliance.org2015年6月29日。

さらに読む