/ Flickr / ハムザ・バット / cc
滝
ウォーターフォール、またはカスケードモデルは、1970年以来存在していた伝統的な方法論です。 その中で、プロジェクトの開発は、システム要件の分析から製品のリリースまでの段階に分けられます。
各ステップはソフトウェア開発の個別のフェーズであり、チームは次のフェーズに進む前に1つのフェーズを完了する必要があります。 Waterfallの「クリーンな」実装では、前の段階に戻ることは禁じられています。開発サイクル全体を実行するには、「フローに合わせて」しか実行できません。 Quoraユーザーは、このモデルを、駅から駅へと移動し、後戻りできない列車と比較します。
当初、Waterfallの作者であるWinston Royce は、カスケードモデルを、バグや低品質の製品につながるソフトウェアを開発する非効率的な方法の例として引用しました。 しかし、その後、彼の記事で彼は方法論を「念頭に置いて」、テストからコードの記述などへのフィードバックと移行に注目しました。
PMIの調査によると、企業の12％が継続的にWaterfall方法論を使用しており、回答者の40％が頻繁にそれを使用すると回答しています。 また、 LiquidPlannerによると 、カスケードモデルは組織の25％で使用されています。
Waterfallのステージ数は会社によって異なりますが、一般的なアプローチは次のとおりです。
- コンセプト作成。 ソフトウェア開発ライフサイクル（ SDLC ）の最初のフェーズには、費用対効果の分析とプロジェクト範囲の評価が含まれます。
- 準備。 チームの募集、目標と目標の定義。
- 分析。 作業範囲と要件を検討します。
- デザイン。 プロトタイプの作成と顧客との調整。
- 開発/コーディング。 承認されたプロトタイプに基づいてソフトウェアを作成します。
- テスト。 最終製品がテストされます。
- 実装。 製品が市場に参入します。
- メンテナンス トラブルシューティングとサポート。
方法論の利点の中で、明確な構造と予測可能なワークフローを区別できます。 これにより、プロジェクトの開始前に、コストの見積もりと期限の見積もりが簡単になります。 Quoraの住民は、そのような微妙さは金融会社や保険会社、またはハードウェアを開発する会社にとって重要であると主張しています。
さらに、モデルには各ステップの文書化が含まれます。 これは、後続のプロジェクトの基礎を作成するのに役立ちます。 また、大量のレポートにより、いつでも顧客または管理者に製品の段階を示すことができます。
ただし、欠点もあります。 プロトタイプを見るまで、顧客は自分が本当に欲しいものを知らないことがよくあります。 また、Waterfallによると、すべての要件を事前に決定する必要があるため、何かを失うリスクがあります。 エリクソンABのウェブサイト開発プロセスの調査では、カスケードモデルが混乱を招き、初期要件の26％が役に立たないことが示されました。
ただし、ウォーターフォールの主な欠点は変更です。 製品はライフサイクルの最後にテストされますが、何かを支配するには遅すぎる可能性があります。 トヨタが別の開発方法への切り替えを検討するきっかけとなったのは、変更のコストです。
同社のチーフプロジェクトマネージャーである石井S氏によると 、生産後に1,000〜10000倍のコストで発見された欠陥を修正しているという。 そのため、トヨタはウォーターフォールを放棄してリーンに行くことにしました。これについてはさらに検討します。
無駄のない
この用語は無駄のない開発を意味します。 そのルーツは 、トヨタの歴史と問題解決へのアプローチに深く根ざしています。 同社は、有益で、最小限のコストを必要とし、計画時間の30％を超えない変更のみを行います。 これにより、日本企業は数時間でコンベアを別のモデルの生産に切り替える方法を学ぶことができましたが、他の自動車メーカーは数週間かかりました。
Mary（Mary Poppendieck）とTom Poppendieckの開発にはリーン方法論を使用しました。 彼らは、Lean Software Developmentという本を書きました。 さらに詳しい情報は、LeanのWebサイトにもあります。
PMIの調査によると、企業の8％が常にリーン原則を使用しており、26％がリーン原則を頻繁に利用しています。 無駄のない原則 ：
- 過剰の除去：有益ではないもの。
- トレーニングを重視：周期的な開発、顧客からのフィードバック。
- 決定は、予測ではなく、事実に基づいて行われます。
- すべての整合性：顧客への通知からリファクタリングまで。
- 本格的なビジョン：プロジェクトを部分的にではなく、全体として評価することが重要です。
方法論の利点の中でも、製品のクイックリリースは際立っています。 LakeslipのIntel Fab Operations DivisionのマネージャーであるJoe Foleyは、5年前に新しいチップの製造を開始するには14週間かかったと主張しています。 無駄のない原則のおかげで、このプロセスには10日かかります。
さらに、チームがリーン開発の原則に従うと、タスクを実行するだけでなく、エラーの少ない製品を作成するよう努めます。 その調査では、BBC社はリーンがソフトウェア開発の速度を37％向上させ、バグの数を24％削減することを発見しました。
また、リーンビジネスレポートの調査によると、このアプローチの10の利点の1つはプロジェクトのコスト削減です。IT企業の27％がリーンの原則を実装することでコストを削減しました。
ただし、すべての人に適しているわけではありません。 GlobalLuxSoftチームは 、外出先での学習は不可能であり、製品の作成がリスクにさらされるため、経験豊富な開発者がプロジェクトに接続している場合にのみリーン開発を適用する必要があると指摘しています。
すべての決定は、分析データとプロセス監視の結果によってサポートされる必要があります。そうしないと、チームはあまりにも多くの変更に突入し、プロジェクトの主な目標を忘れてしまう危険があります。 ここでは、トヨタの経験に目を向けることができます。側面からの厳密な制御は、開発者が優先タスクから逸脱することを許可しません 。
/ Flickr / セバスチャン・シコラ / cc
機能駆動開発
機能駆動開発 （FDD）は、ベストプラクティスを組み合わせ、クライアントの観点から役立つ機能に開発者を集中させる方法論です。 ここでは、FDDの開発アルゴリズムのおおよそのスキームを見つけることができます。 調査によると、11％の企業が常に機能駆動開発を使用しており、31％がこの方法論を時々使用しています。
FDDの作成者であるJeff De Lucaは、シンガポールの銀行向けソフトウェアを開発するための最適なソリューションを探していた1997年に最初に方法論を提案しました 。 次に、彼は5つのプロセスの組み合わせを提供しました。
- 共通モデルの開発。 開発チームはグループに分けられ、個々のタスクのモデルを作成します。 次に、提案されたモデルの1つまたはその組み合わせが選択されます。
- 機能のリストを作成します 。 チームが共通モデルを開発したとき、それはクライアントに役立つ機能を定義します。
- 計画中。 重大な問題の発生を防ぐために、グループの負担、リスク、およびその他の側面を考慮することが重要です。
- 設計と開発。 プロジェクトマネージャーは、最初のプロセスのデータに基づいて、チームが一定期間実装する必要がある機能のグループを選択します。
- 実装。 チームがコードとモジュールを開発およびテストした後、ソフトウェアの作成に進みます。 この段階と前の段階では、開発チームの75％の努力が必要です。
プロジェクトの成功は、主要なプログラマーの経験と知識に依存します。 FDDでは、リーダー、メンター、アナリストなど、すべての主要な役割を果たします。 同時に、この方法論は長期プロジェクト向けに作成されたため、Stack Overflowの住人として、小さなタスクに使用するのは意味がありません。
ただし、プラスもあります。 すべてのレベルで進行状況を継続的に報告することで、進行状況と結果を追跡できます。 これにより、プロジェクトを定期的に更新し、エラーを特定し、いつでもクライアントに情報を提供できます。 Stack Overflowの住人の1人は、FDDの主な利点は、プロジェクトが予定より遅れているか、より速く動いているかどうかをいつでも評価できることだと主張しています。
すでに述べたように、FDDは大規模プロジェクトで使用されます。最初の段階は、製品を理解できる共通モデルの開発だからです。 同じプロパティは、新しい開発者を仕事に引き付けるのに役立ちます。 同時に、プロジェクトの要件とクライアントの期待をより深く理解することで、不要な「驚き」 のリスクを減らします。
PS企業ブログで他に何を書いていますか：