建築で設計図が使われ、食事を作るときにレシピに従うように、効率的なソフトウェア開発には従うべき原則があります。 これらの原則は、通常、ソフトウェア開発方法論と呼ばれるものに集約されます。 ソフトウェア開発方法論は、ソフトウェア開発プロジェクトの成功につながる手順を含んでおり、不可欠です。
建築において設計図に従わなければ、結果は惨憺たるものになります。 多くの重要なステップを見逃し、最終的には無数のソフトウェア品質の課題を抱えることになります。 プロジェクトマネージャーとして、リーン開発アプローチを含むソフトウェアプロジェクトに従うべき多くのアプローチがあること、そして、正しく選択すれば、ソフトウェア開発方法論は常に高品質のソフトウェア製品を生み出すということを知ることが重要です。 リーン生産方式は、顧客価値を高め、無駄を最小限にするために、自動車生産プロセスを管理および最適化するための実践として、トヨタ生産方式によって最初に使用された、非常に成功した原則から構成されています。 製造業は物理的な製品の作成を伴うのに対し、ソフトウェア開発製品は無形であり、その価値は開発チームの心の中でしか認識されず、創造されないからです。 MaryとTom Poppendieckによる「Lean Software Development: An Agile Toolkit」と題された本で、リーン生産とリーンソフトウェア開発の間のマッピングが最初に始まりました。 この本の中で、Poppendieck 夫妻は、リーン生産の原則をソフトウェア開発にどのように生産的に適用できるかを説明しています。 製造業とソフトウェア開発は、どちらも繰り返し可能な手順に従い、正確な品質基準を必要とします。 また、チームワークに依存している。 したがって、リーン生産の7つの原則はソフトウェア開発に適用して使用することができます。
ソフトウェア開発に従うべき7つのリーン原則
ソフトウェア製品をより速く開発できるため、アジャイル開発アプローチは多くの開発会社で人気があります。 そのような企業では、すでにリーン開発の原則を導入しています。 リーン開発で従うべき最初の原則は、エンド ユーザーに価値をもたらすものをすべて排除することです。 ソフトウェア開発では、この原則は、まず構築されるソフトウェア製品の価値を特定することによって実施できます。 それができれば、「無駄」-不要なコード、不明確な要件、余分な機能、プロセスなど、製品、ひいてはユーザーに付加価値をもたらさないもの-を検出することが容易になります。 また、価値をもたらさない方法論の他のフェーズも削除する必要がある。 バリュー ストリーム マッピングなど、ソフトウェア開発における無駄の特定に役立つツールがあります。
- Create Knowledge
ソフトウェア開発そのものが、知識を生み出す進行過程である。 したがって、知識創造の原則は、開発チームが適切な学習を可能にするために適切な構造を持つことを奨励します。 単純に聞こえますが、この原則は完全な集中力とコミットメントを必要とします。 これは、トレーニング、コード レビュー、適切なコード コメント、ペア プログラミング、プロジェクト ドキュメンテーション、共有セッションなどの実施により、実装することができます。 したがって、不具合のない最終製品を保証するという概念に依存しないようにする必要があります。 逆に、チームは開発プロセスを強化し続け、機能的な最終製品のために最初から製品に不具合を分散させるのをやめるべきです。 アジャイルなアプローチであるリーン開発もまた、高速なソフトウェア配信を重視しています。 これは、プロジェクト チームがターゲットとするコンポーネントを適切な時間にユーザーに提供しなければならないことを意味します。
- Empower Your Team
Empowering your project team requires that you respect everyone – people working together as a team should respect each other ⧏35⧐ チームとして一緒に働く人々は、お互いを尊重すべきである。 物事がうまくいかないとき、ほとんどの場合そうですが、人のせいにしないようにしましょう。 その代わり、課題や対立につながるようなプロセスのギャップがないかどうかをチェックする。 全員が働きやすい環境を整え、模範を示すこと。 さらに、チームメンバーが、割り当てられたタスクに対して適切なアプローチやツールを選択し、識別できるように、革新的な自由を与えてください」
- Delay in Making Decisions
従来は、できるだけ早く決定して仕事をする傾向があったので、これは物議をかもすと思います。 リーンの原理として、決定を遅くすることは、決定を下す際に無責任であることを意味しません。 むしろ、プロジェクト チームが重要な決定を下すのに役立つデータや情報をより多く収集するために、より長い期間オプションを開いたままにしておくことを奨励します。 決断を遅らせることで、より多くのことを学び、知識を得る時間ができ、その結果、さらに良い決断ができるようになるのです。 その結果、プロジェクトは、不適切な意思決定から生じる負の影響を受けずに済むのです。 軽率な決定をして後で後悔するのと、時間をかけて情報を収集し、正しい決定をするのとでは、どちらがいいか考えてみてください。 プロセスの 1 つだけ、またはほんの数個にしか価値を付加しないと、最終製品に影響が及び、結果は最適化されていないことになります。 時間が足りなかったからといって、劣悪な製品を発売するべきではありません。 最適化されていない状態に対処するために、全体最適の原則は、悪質な開発およびテストサイクルを排除し、代わりにはるかに優れた作業能力で動作することを奨励します。 全体を最適化することで、より迅速で価値のあるデリバリーを可能にする完全なチームのための特定プロセスの価値の流れが可能になります。 したがって、最適化を達成するために、最初から最後まで、価値の流れ全体に焦点を合わせるのです
。