プロジェクト管理ソフトウェアの開発。 問題と解決策

2001年、Habrがなく、その現代の読者のかなりの割合がいなかったとき、Waterfallは全能で、ちょうどEdgeについて話し始めていたとき、私は開発方法論のトピックと互いの違いについて少し研究しました。 その結果、わかりやすいWebサイトに掲載された記事が登場しました。 この記事は、ソフトウェアプロジェクトの管理の基礎に関するコースを準備する際に、一部の評判の高い教育機関からも参照されました。 フレンドリーなWebサイトはITに関するものではなかったため、記事は時間とともに消えていきました。 Runetの広がりから完全に消失することを防ぐために、私はそれをHabréに公開し、誰もが過去に短い遠足をとるように勧めています。 はい、多くのことは今では素朴に見えますが、多くの結論はまだ関連性があります。

注意、 2001年の記事！

この記事は、ソフトウェア開発プロジェクトの分類を試み、ソフトウェア生産の主要な方法論のレビューと簡単な分析を提供し、主要な方法論のソフトウェア開発プロジェクトのタイプへの適用性の簡単な分析を行います。

エントリー

現在、かなり多数の標準プロセスと方法論があり、それらを適用して、会社はソフトウェア生産の特定のモデルを受け取ります。 最も有名なものは、CMM（Capability Maturity Model）と一連のISO 9000標準です。原則として、組織はこれらのプロセスを、上記の標準のいずれかのプロセスのコンプライアンス証明書を受け取るためにのみ実装します。 しかし、これがいかに逆説的であっても、上記のプロセスの1つを導入しようとすると、会社の安定性に悪影響を与えます。

過去3年間で、「軽量プロセス」、「適応プロセス」、「単一合理的プロセス」、および「極端なプログラミング」という用語が西洋で流行しています。 これは何ですか また、なぜISO9000の実装の効果がマイナスになることがあるのでしょうか？ プロセスを選択するとき、どのプロセスを優先し、どの基準に従う必要がありますか？ 記事の残りの部分では、これらの質問やその他の質問に対する答えを見つけようとします。

プロジェクト分類

ソフトウェア生産プロセスのモデルとパラメーターは、プロジェクトのタイプに大きく依存します。 各チームには、この関係またはその関係が発展した顧客がいます。

「自社」顧客

開発チームが長期間にわたって単一の顧客にサービスを提供する状況。 通常、このオプションは、顧客と開発者の間の優れた関係によって特徴付けられます。 多くの場合、そのようなチームは顧客の領域に配置されます。 このタイプのプロジェクトの主な特徴：

• 顧客の可用性はいつでも;
• 顧客のニーズと要件に関する安定したアイデア。長年にわたる協力の中で形成されました。
• ソフトウェア品質の要件がかなり低い。
• 製品の継続的なサポート、洗練と改善。
• 顧客と開発者の間の安定した財務関係。
• 長期的な協力計画。

カスタム製品

開発チームがサードパーティの顧客を見つけ、特定の顧客の問題を解決するために設計されたソフトウェア製品の開発について彼に同意する状況。 このタイプのプロジェクトの主な特徴：

• 顧客の可用性は「定期的」と説明できます。
• 調査に基づいて、顧客のニーズと要件のアイデアが形成されます。
• 最終製品の受け入れのための事前に合意されたソフトウェア要件。
• 開発者は、提供された製品を所定の期間サポートします。
• 財務関係は、1回限りの契約の形で実行されます。
• さらなる協力の計画は、開発者が顧客に提供した製品の品質と持続可能性に大きく依存します。

複製製品

開発チームが特定の顧客（「箱入り製品」）をまったく持たないか、同じ製品に対してかなり多くの顧客を抱える状況。 このタイプのプロジェクトの主な特徴：

• 製品を形成する特定の顧客要件はありません。
• 現在および潜在的なユーザーのニーズと要件のアイデアは、市場分析と典型的なユーザー代表との接触に基づいて形成されます。 製品のユーザーからのフィードバックは、主に電子メールで行われます。
• ソフトウェアの品質は、内部品質部門とユーザーフィードバックによってのみ制御されます。 ベータテストは広く使用されています。
• 開発者は、提供された製品を所定の期間サポートします。
• 金融関係は、製品の固定価格の形で存在します。
• 製品開発計画は、市場分析に基づいて形成されます。

アウトソーシング

最も若いソフトウェア生産モデル。 ロシアのプログラマーは、欧米のプログラマーと比較して、高い資格と低い労働コストに基づいて登場しました。 このモデルの本質は、欧米のソフトウェア会社とロシアの会社の間で下請けが締結されることです。 このタイプのプロジェクトの主な特徴：

• 開発者は自分の製品の最終消費者に連絡しません。 すべての情報は、西側からの技術仕様の形式で取得されます。
• 顧客のニーズと要件のアイデアは、西側から提供された情報に基づいてのみ形成されます。
• 西側は、ソフトウェア生産プロセスとその品質に対する要件を提供します。
• 通常、製品サポートは西側で提供されます。
• 財務関係は、開発チームのメンバーと西洋の顧客との間の個別契約の形で存在します。 選択肢は、西側の顧客と開発チームに代わって行動する法人との間で契約を締結することです。

問題

プロセス編成

ロシアのソフトウェア生産プロセスの最も典型的なモデルは次のように説明できます。「各開発者は、独自の習慣や好みに応じてプログラムを作成するための特定の方法または手法を選択します。 特定の機能のパフォーマンスに対する明確な責任のほぼ完全な欠如。 ソフトウェアの品質はランダム変数であり、会社の個々の従業員の能力に直接依存します。 ほとんどすべては、複数の個人のイニシアチブとビジネス品質に依存しています。」 この文言は、「初心者」と呼ばれるCMMの第1レベルにほぼ完全に対応しています。 2年前の情報源によると、このモデルを使用しているソフトウェア会社の割合は70％を超えていました。

次に、Martin Fowler [4]がソフトウェア生産プロセスを従来の建設および生産のタイプと比較する際に導き出す結論を示します。

• ソフトウェア生産のプロセスでは、直接プログラミングフェーズ（構築）は他のすべてのフェーズ（設計、テストなど）よりもはるかに安価です。
• 生産プロセスでは、すべての主要な努力は設計に向けられます。 設計プロセスでは、創造的で才能のある人々がそれに参加する必要があります。
• 創造的なプロセスを簡単に計画することはできません。 したがって、このようなプロセスの予測可能性は達成不可能な目標になる可能性があります。
• ソフトウェア生産で従来の比phorを使用する場合は、非常に注意する必要があります。 これは、特別なプロセスを必要とする非常に特別な種類のアクティビティです。

要件と反復

90年代半ばまで世界中で使用され、構造プログラミングの時代のシンボルである古典的なソフトウェア生産プロセスは、次のステップで構成されています：検査、問題記述、設計、プログラミング、テスト、実装。 このプロセスは「ウォーターフォール」と呼ばれます。 これは、調査中に収集され、問題を設定するプロセスで正式化されたソフトウェア製品の要件が修正され、生産サイクル全体で変更されないことを意味します。 ただし、現代のビジネスは非常に動的であり、変化する要件は一般的なものです。

ファウラーはこう書いています。「ソフトウェアの生産プロセスでは、すべてが要件に依存します。 要件の持続可能性を達成できない場合、予測可能な計画を作成できません。」 どうする？ 一方では、要件は持続可能でなければならず、他方では、プロジェクト中に必然的に変更されます。

すべての鍵は、反復的な生産プロセスです。

解決策

上記の問題を解決するためのすべての方法は、プロセスが予測可能で安定し、主な目標である完成したソフトウェアを確実に満たすように、ソフトウェア生産のプロセスを変更することに限定されます。

線形および反復的なソフトウェア作成ライフサイクル

ソフトウェア作成の線形ライフサイクル（「ウォーターフォール」とも呼ばれます）は、6つの段階（試験、タスク設定、設計、プログラミング、テスト、実装）を順次通過させます。 このようなライフサイクルでは、ソフトウェアの開発段階がどれだけ長くても、タスクの策定から開発された製品の導入に関する法律に署名するまで、ソフトウェアの要件は変わらないと想定しています。

このアプローチは、住宅の建設や工作機械の製造などの古典的な分野に適用できます。 製品の要件が開発サイクル全体で実際に変わらない場合、このアプローチはソフトウェア業界でも適用できます。 別の条件は、確立されたソフトウェア開発技術であり、まったく未踏の技術革新を使用していません。 この種のプロジェクトの例としては、月に飛ぶロケットを制御するプログラムを作成する（プログラムの執筆中に人類が月について根本的に新しいことを学んだことはほとんどありません）か、計算機を作成することができます。 しかし、たとえば、コンピューターやアクセサリーを販売している顧客向けの電子ストアを作成したい場合はどうでしょうか？

現代のビジネスは非常にダイナミックであり、電子ストアの要件は、その開発の過程で数十回以上変化します。 そしてそのたびに、コードの大部分を書き直さなければならず、新しい状況に合わせて多くのドキュメントを持ち込む必要があります。 そして、これは原則として、予定外の時間、リソース、および労力の損失であり、結果として、納期に間に合わないという結果になり、顧客の要件を満たさない（または完全に満たさない）ソフトウェアの生産につながります。 出口はどこですか？ この場合の解決策は、反復的なソフトウェア作成サイクルを使用することです。 このようなサイクルは一連の反復であり、各サイクル内でプロジェクトは上記の6つのステージすべてを通過します。 反復サイクルは、開発の初期段階で深刻な問題を特定し、リスクを管理し、テストを早期に開始します。 このようなプロセスは、より動的で制御可能になります。

既存の方法論

世界には非常に多くの典型的なソフトウェア生産プロセスがあります。 ISO9001、ISO12207、ISO15504、CMM（Capability Maturity Model）、MSF（Microsoft Solution Framework）、RUP（Rational Unified Process）、SCRUM、XP（eXtremal Programming）、Crystal Clear、ASD（Adaptive Software Development）、リーン開発-これらすべてさまざまなソフトウェア生産プロセス、プロセスファミリ、および方法論。 方法論は、ソフトウェアの生産プロセスで使用される一連の方法、実践、測定基準、および規則です。 Alistair Coburn [1]によると、方法論は以下のために必要です。

• 生産プロセスの過程に新しい人々を紹介するプロセスを促進します。
• 人々の互換性を確保するため。
• 責任を分配する;
• スポンサー/顧客に感銘を与える;
• 目に見える透明なプロセスを示します。
• 従業員向けのトレーニングベースを作成します。

Jim Highsmithの定義[16]によると、「方法論の本当の目的は生産性を高め、顧客にソリューションを提供することです」

方法論は、ヘビー、ライト、ミディアムの3つのカテゴリに分類できます。 単純化され、それぞれ大規模、小規模、中規模のプロジェクトの条件で動作するように設計されています。 ただし、後で見るように、これは完全に真実ではありません。

Alistair Coburnによると[1]：

• 方法論のサイズ-これは、暫定リリース、標準、アクティビティ、マイルストーン、品質メトリックなどを含むコントロールの数です。
• 方法論密度は、方法論の要素に必要な詳細レベルと整合性です。
• プロジェクトの重みは、方法論のサイズに密度を乗じたものです。
• プロジェクトサイズは、プロジェクトの実施に関与する人数です。

上記の定義はすべて概念的なものです。これらの数量には定量的なメトリックがないためです。

方法論の最初のカテゴリは誰よりも早く生まれ、ソフトウェア品質モデルの不可欠な部分です。 重い方法論は、要件管理やプロセス計画から下請業者との関係の規制や補助プロセスの要件の説明に至るまで、ソフトウェア会社の活動のあらゆる側面を網羅しているという事実によって区別されます。 このカテゴリのすべての方法論は、変化に耐えられず、人々を通常のリソースと見なします。 例：CMM、ISO9000、SPICE。

方法論の2番目のカテゴリは 、成功したプロジェクトで小規模な開発チームが使用する一連の方法と実践として生まれました。 ここでは、チーム内の人々の間の関係が非常に重要であり、寛容性やその他の心理的側面の問題が考慮されます。 このカテゴリのすべてのプロセスは、ソフトウェア開発の反復的なライフサイクルを提供します。 軽い方法論の主な意味を定式化しようとすると、「最小限の制限と規則でソフトウェア開発の最大の速度と品質を確保する」ことができます。 特に、すべての軽い方法論では、必要最小限のドキュメントのみが提供されます。 「文書は理解できない」という原則に敬意を表します。 これらの方法論と最初のタイプの方法論の大きな違いは、計画に対する態度です。 何よりも、この違いの本質はジム・ハイスミスによって表現されました。「従来の計画では、計画からの逸脱は排除しなければならないエラーです。 しかし、適応プロセスでは、逸脱が正しい決定につながります」[4]。 例：SCRUM、XP（eXtremal Programming）、クリスタルクリア。

いわゆる「ユニバーサル」プロセスは、方法論の3番目のカテゴリに分類されます 。 このカテゴリの最も明るく最も有名な代表者はRUPです。 このようなプロセスの主な特徴はスケーラビリティです。つまり、 プロセスは、小規模プロジェクトの小規模チームと大規模で深刻なプロジェクトの大規模チームの両方で機能するように構成できます。

プロセス適用性分析

クリスタルの著者であるアリスター・コバーンは、彼の研究方法論の主題を作った最も有名な現代の専門家の一人です。 この分野での彼の研究の結果は、「アジャイルソフトウェア開発」[1]という本であり、著者はさまざまな観点からソフトウェアの生産プロセスを分析しています。 Alistair Coburnは、「ソフトウェア開発は発明と相互作用の共同ゲームです」というコンセプトの著者です。 彼はこのゲームの2つの目標を特定します。

• 最初の目標：実用的なソフトウェアを開発および実装する。
• 2番目の目標：次のゲームのコースを成功させるためのすべての条件を確保する。

したがって、minimaxタスクは定式化されています：ソフトウェアを作成し（多くの場合、ドキュメントを作成する必要はありません）、このソフトウェアの次のバージョンの開発を保証します（ただし、たとえば、次のいずれかの場合に必要な多数のドキュメントを作成する必要があります）コア開発者はチームを離れます）。 この概念の観点から、XP方法論が作成された作業中のC3プロジェクトは、失敗したゲームでした。 すべての主要な開発者がチームを去った後、ソフトウェア製品の開発は不可能になりました。 この理由は、残っている人の誰もこれに必要な知識を持っていなかったという事実であり、プロジェクトに関する詳細なドキュメントはコンパイルされていませんでした。

同時に、大規模なプロジェクトや、正常に動作するための重要度が非常に高い製品での作業には、軽いプロセスは適用できません。

図1-3は、さまざまな規模の開発チームによるさまざまな方法論の使用パターンを示しています。

図1は、複数の人で構成され、異なる方法論を使用するチームのパフォーマンスダイナミクスを示しています。 小さなチームは、軽い方法論を使用して正常に動作します。 より重い方法論により、チームは直接開発する時間とエネルギーがますます少なくなります。

図2は、さまざまな重みの方法論を使用した大規模なチームのパフォーマンスダイナミクスを反映しています。 軽い方法論ではプロセスを適切に制御できないため、スケジュールの開始時にはチームのパフォーマンスは低くなります。 チームは、制御された動的なプロセスを確立するのに十分な方法論を使用して最高の生産性を達成しますが、方法論をさらに重視すると、生産性の緩やかな低下が観察されます。

図3は、異なる重みの方法論を使用する場合のチームの能力の上限を反映しています。

分類

Coburnは、プロジェクトのサイズと重要度という2つのパラメーターに基づいて、プロジェクトタイプの分類[1]を開発しました。 次の重大度が区別されます。

• 快適性の喪失（快適性の喪失）。 快適性の喪失とは、システムにエラーが発生した場合、人々の生活が少し複雑になり、中断された通信チャネルを補うために、より多くの手作業を行うか、お互いに電話をかける必要があることを意味します。 通常、企業インフラストラクチャサポートプログラムはこの領域にあります。
• 相当な金額の損失（裁量的資金）。 これは、ある程度の金額またはその他の相当する金額の損失を意味しますが、それは不快な枠組みの中でのみです。 通常、ストレージシステムは現場にあります。
• かけがえのないお金の損失（かけがえのないお金、不可欠なお金）。 企業の破産に匹敵する金額の金銭またはその同等の損失を意味します。 国立銀行の管理システムはこの分野にあります。
• 命の損失（命の損失）。 これは、そのようなシステムのエラーの場合、人間の生命に危険があることを意味します。 原子力発電所、宇宙船、および航空機の制御システムがフィールドにあります。

提案された分類方法にいくつかの修正を導入することにより、プロジェクトの分布度（特にアウトソーシングプロジェクトに関連）、チームの資格、その他の微妙な違いも考慮することができます。

結論

次に、プロジェクトの種類に戻って、特定のケースで使用するのに最も適切な方法論の種類を確認します。

あなたの顧客

顧客が常に利用可能であり、ソフトウェア品質に特別な要件がないため、軽い方法論の実装に最も有利なタイプのプロジェクト。 ただし、開発者の数とその分布の程度を考慮する必要があります。 原則として、そのようなチームは認証を必要としません。したがって、主にCMMやその他の難しい技術に注意を払うことは価値がありません。

カスタム製品

最も脆弱なタイプのプロジェクト。 会社は完全に契約の数に依存します。 常に新しい顧客を探しています。 もちろん、このような状況では、特に欧米の顧客の場合、ISOまたはCMM証明書の存在が非常に望ましいです。 ただし、ISO9001、SPICE、またはCMMの実装は時間がかかるプロセスであり、必ずしも成果を上げるとは限りません。 したがって、明らかに、さらなる認証に目を向けて、RUPの実装を開始することをお勧めします。

ただし、上記の分析が示すように、小規模企業の認定は、多くの場合、彼らにとって悲惨なものです。 したがって、特定の人数に達した場合にのみ認証について検討する価値があります。これは、大規模または中規模の方法論のいずれかを実装するのに十分です。 それ以外の場合は、簡単な方法のいずれかを使用するのが最適なソリューションです。 特に、会社に成長の見込みがある場合は、クリスタルクリアを導入して、このファミリのより重い方法論への移行を試みることができます。

複製製品

定義上、最も安定したプロジェクトのタイプ。 複製された製品のリリースは、単一のコピーのリリースと比較して、生産コストが常に低いことを常に特徴としています（同様に-コンベアと手作業）。 これらの条件では、顧客と常に作業する方法がないため、純粋な形での軽い方法論の使用は通常不可能です。 この場合、すべてはチーム管理方法、確立された伝統、その戦術的および戦略的目標に依存します。

アウトソーシング

このタイプのプロジェクトは、顧客とのコミュニケーションが標準形式の文書の形式で行われるため、プロセスが悪化するための分散構造と初期前提条件によって特徴付けられます。 西側がチームに独自の技術プロセスを提供する場合、もちろん、選択の自由はありません。 それ以外の場合、中程度の重大度の特定のプロセスを選択する価値があります。これは、一方では顧客との通常の対話に十分であり、他方では動的で安定しています。

おわりに

いずれにしても、上記の結論はすべて一般化されています。それぞれの場合の状況は一意であり、ソフトウェア生産プロセスの標準的なレシピがなく、ありそうもないからです。 人間の活動のこの分野はまだ非常に若く、人間の要因に十分に依存しています。 ただし、この記事の著者は、上記の方法論のレビューとそれらの適用性の簡単な分析が、問題の本質を理解し、正しい決定を下すのに役立つことを望んでいます。 「使用する方法論の重みの比較的小さな増加は、プロジェクトのコストの比較的大きな増加につながる」ことを覚えておく必要があります[1]。