ウォーターフォールのほかに、他の計画主導のソフトウェア開発方法論は何ですか?


8

私はただバランスの敏捷性と規律を読みました。悪いタイトルはさておき、PSP / TSPを採用していた計画主導のプロジェクトチームと、Extreme Programmingを使用したアジャイルチームとは対照的でした。

著者が計画主導の方法論の例を提供したとき、彼らはパーソナルソフトウェアプロセス/チームソフトウェアプロセスを使用しました。すぐに使用できるこれらは計画主導の方法論ですが、これらはプロセスフレームワークとして使用するようにも設計されており、最終的には実行する処理の種類ではなく、実行する処理の種類のみを指定します。アジャイル環境でも。俊敏でありながらPSPの原則を順守することは可能であり、私はTSPについて十分に理解していません。

本のある時点で、彼らはいくつかの方法論を列挙し、敏捷性の観点からそれらをランク付けしています。スクラム、リーン、クリスタル、XPなどのメソッドが上位にあります。下部(アジャイルの大部分から最小)は、Rational Unified Process、チームソフトウェアプロセス、機能主導開発、CMMI、ソフトウェアCMM、パーソナルソフトウェアプロセス、およびクリーンルームで構成されています。

PSP:ソフトウェアエンジニア向けの自己改善プロセスのワッツハンフリーは、プロセスの定義、特にパーソナルソフトウェアプロセスの変更に関する章を設けています。共通のテーマは、プロセスは規範的(彼らは何をすべきかを言う)であり、記述的(どのようにそれを行うのか)ではないということです。TSPもほとんど同じだと思います。CMMIもアジャイルメソッドと組み合わせて使用​​されており、SEIにはその本(まだ読んでいない)があります。

機能駆動型開発は、プロジェクト管理へのアジャイルアプローチとしてよく宣伝されていますが、著者はそれをアジャイル性の低い方法論としてランク付けすることを選択しています。

RUPは反復フレームワークです。信じられないほど詳しくはありませんが、フレームワークであることから、SW-CMM、CMMI、PSP / TSPとグループ化して、アジャイルまたはプラン主導の方法論として実装できるようになりました。

この本で私が同意する唯一の他の例は、クリーンルームソフトウェアエンジニアリングです。クリーンルームの主要なコンポーネントは、正式な方法の使用、統計的な品質管理、および統計的に適切なテストです。時間とコストのオーバーヘッドが加わったため、これらをアジャイル(反復/増分)メソッドで使用できなかった理由はわかりません。

私が何を求めているかを明確にするために、アジャイルメソッドのファミリーには、スクラムとエクストリームプログラミングの形で抽象的なアイデアの特定の実装が含まれています。これらは、反復的かつ段階的な開発、変化への対応、人(個人とチーム)、頻繁に機能するソフトウェアの提供、顧客との共同作業などの概念を実現します。彼らは、役割、成果物、会議、タイムボックス、およびその他のプラクティスを明確に指定し、「スクラムを実行する」または「エクストリームプログラミングを実行する」とは、パッケージを取ることを意味します。たとえそうであっても、それらは調整可能性と新しいプロセスの作成を可能にします(しかし、あなたは「スクラムをしている」または「XPをしている」ではありません)。しかし、「do X」は見つかりませんでした

だから、私の質問:より計画主導のソフトウェア開発方法論の例は何ですか?多くのプロセスフレームワーク(PSP / TSP、SW-CMM、CMMI、RUP)では、計画主導またはアジャイル開発も可能ですが、説明的なものはありません。しかし、たとえばスクラムやエクストリームプログラミングに直接対応するような、真に計画主導の方法論はありますか?


あなたはその本を「PSP / TSPを採用していた計画主導型のプロジェクトチームと、Extreme Programmingを使用したアジャイルチームとを対比させた」と書いています。XPの実装については、多くの計画を立てていると確信しています。XPの人たちが計画を立てていないのではないかと思うと少し戸惑う。私の経験は違います。私の2セント。
Manfred、

@John計画主導の方法論は、従来のエンジニアリング手法を適用し、要件から最終的にはデリバリー製品まで体系的に移動しながら、ステップで検証と検証を実行することに集中しています。それらは、システムの存続期間中の強力な文書化とトレーサビリティによって特徴付けられます。詳細な計画、ワークフロー、および作業成果物(作業ソフトウェア以外のもの)があります。
Thomas Owens

回答:


5

正直なところ、私は、敏捷性と規律を互いに相殺する本でなされたいかなる主張の正当性にも疑問を持っています。アジャイル方法論は、私の経験では、他の種類の開発よりもはるかに多くの規律を必要とします。

つまり、アジャイルプロセスの利点を活用する場合は、それらに付随する有効化プラクティスに従う必要があります(Martin FowlerのIs Design Dead記事を参照してください。彼は主にXPについて話していますが、それはすべてのアジリティに適用されます)私の意見)。それには多くの規律が必要です。

しかし、あなたの質問に答えるために、私はすべての真の計画主導型の方法論のような滝のバリエーション、あると思いスパイラル滝のアプローチに切り替える前にプロトタイピングの複数のレベルを介して開発をとり、およびキャップジェミニSDM非常に滝で、それぞれが別の開始前に終了する明確なフェーズ。


1
同意します。「アジャイル」と「規律」の比較は好きではありません。「アジャイル」対「計画主導」の方がはるかに優れており、アジャイルであるためには専用の知識豊富な経験豊富なチームが必要であると私はいくつかの情報源で読んだことがあります(ただし、頭から言うことはできません)。計画ベースの方法よりもはるかに優れています。あなたの最後の段落について-それらはまだフレームワークです。多くの計画主導のフレームワークがありますが、「これはスクラムです」または「これはエクストリームプログラミング」と同じように「これは{ここに名前を挿入}」で明示されているものはありません。
Thomas Owens

1
@ThomasOwens:スパイラルは方法論であり、フレームワークではありません。あなたはVモデルについてもポイントを持っているかもしれません。Cap Gemini SDMが良い例かもしれませんが、私にとっては常にSpiralによく似ています。en.wikipedia.org/wiki/System_Development_Methodology
pdr

1
スパイラルははるかに近い-それはフェーズといくつかのドキュメント(要件、conops、開発計画、テスト計画と手順)と技術的な出力(プロトタイプ、最終製品)を明確に定義します。キャップジェミニSDMは私が探しているものに非常に近いと言えます(投稿にSDMを追加できますか?)。+1。
Thomas Owens

1
@ThomasOwens:完了し、Vモデルを置き換えました。
pdr
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.