CodeGym /Java Blog /ランダム /ソフトウェア開発方法論について知っておくべきことすべて: 傾向、原則、初心者向けの落とし穴
John Squirrels
レベル 41
San Francisco

ソフトウェア開発方法論について知っておくべきことすべて: 傾向、原則、初心者向けの落とし穴

ランダム グループに公開済み
ソフトウェア開発は複雑なビジネス プロセスです。これは、IT プロフェッショナルが最適化、計画、コスト計算の言語を話す必要があることを意味します。管理概念を理解することは、雇用主と開発者の両方に大きな利点をもたらし、コラボレーションを次のレベルに引き上げるのに役立ちます。 ソフトウェア開発方法論について知っておくべきことすべて: 傾向、原則、初心者向けの落とし穴 - 1

初心者の方は注意してください!モデル、方法論、および一般的な混乱

まず重要な点を明確にする必要があります。ソフトウェア開発モデルとソフトウェア開発方法論は別個のものであり、別個のものです。モデルはシステムがどのように動作するかを予測します。システムが正常に動作するには方法論が必要です。ソフトウェア開発モデルと方法論を混同することは、すべての IT 初心者にとって標準的な操作手順であるため、これは大きな間違いとは考えられません。モデルの例としては、線形進行、各段階の目標の明確な定義、期限の厳格な管理を備えた古典的なウォーターフォール モデルがあります。もう一つのモデルはスパイラルモデルです、プロジェクトのリスクの早期発見と軽減に重点を置いています。スパイラル開発は小規模に始まり、最初は局所的な問題を解決し、次により複雑な問題に進みます。最後に、もう 1 つのモデルは反復増分開発 (IID)です。このモデルでは、プロジェクトのライフ サイクルが一連の反復に分割され、それぞれが「ミニ プロジェクト」に似ています。一般に、モデルはソフトウェア開発プロセスの記述です。しかし、方法論は、割り当てられたタスクの作業を制御、評価、監視するためのシステムです。。方法論は現代におけるアメとムチであり、開発プロセスの各ステップを制御するために必要です。これらは、プロジェクトの方向性、予算、最終製品の実装期限に基づいて選択されます。さらに、プロジェクト リーダーとそのチームの気質に基づいて方法論を選択できます。企業や顧客の理念に基づく場合でも。最も一般的な方法論を見てみましょう。

1. スクラム

スクラムはアジャイルなプロジェクト管理方法です。これは「スプリント」、つまり期間が厳密に制限された (通常 2 ~ 4 週間) の短い反復に基づいています。これにより、会議の期間は最小限に抑えられますが、会議の頻度は増加します。各スプリントは、反復の終わりまでに完了するタスクのリストで構成されており、それぞれに独自の「重み」があります。ミーティング中、チームはチームメンバーがこれまでに何をしてきたか、何をしようとしているのか、どのような問題があるのか​​について話し合います。スクラムは計画にバックログを使用します。このアプローチでは、通常、チームにはスクラム マスターがいます。この人物は、チームが中断されることなく作業できるよう支援し、チームにとって快適な環境を作り出します。プロジェクトにはプロダクトオーナーの役割を担う人もいます。この人物は開発責任者であり、製品を監視し、顧客の要求とチームが作成するものとの間の主要なリンクとして機能します。

長所:

  • 可能な限り低い予算でプロジェクトを迅速に開始する能力。
  • 毎日の進捗状況の監視、頻繁なプロジェクトのデモ。
  • プロジェクト中に調整を行う能力。

短所:

  • 予算が決まっていないため契約締結が困難。
  • 経験の浅いチームや、期限や予算が過小評価されている場合には機能しません。
  • スプリント間で常に変更を加えることができると、混乱が生じる可能性があります。

誰のためですか?

このようなシステムは、独立系か大企業内にあるかにかかわらず、最大 10 人規模のプロジェクトに適しています。これは、チームの作業量が多く、ライフ サイクルが長く、新しい市場状況に変化して適応する必要がある場合に便利です。

2.カンバン

カンバンの最大の特徴はプロジェクトのライフサイクルの可視化です。作業項目を実行するための列が作成されます。作業項目は個別に取り組みます。列には、To do、In progress、Code review、In testing、Done などのステータスがマークされます (もちろん、列名は異なる場合があります)。各チーム メンバーの目標は、最初の列の作業項目の数を減らすことです。Kanban のアプローチは直感的であり、問​​題がどこにあるのかを理解するのに役立ちます。カンバンの構造は決定的かつ取り消し不能に固定されているわけではありません。プロジェクトの詳細に応じて、即席の列を追加できます。たとえば、一部のチームでは、作業項目を実行する前に作業項目の完了ルールを定義する必要があるシステムを使用しています。この場合、Specify (パラメーターを指定) と Implement (作業を開始) の 2 つの列が追加されます。

長所:

  • 計画の柔軟性。チームは現在の作業のみに集中し、タスクの優先順位も定義されます。
  • 視認性。すべての参加者がデータにアクセスできると、世界的な問題を発見しやすくなります。
  • 開発プロセスに深く関与します。プロセスを視覚化すると、自己組織化と自己制御が向上します。

短所:

  • 5 人を超えるチームでは機能しません。
  • 長期的な計画を意図したものではありません。
  • やる気のないチームには向きません。カンバンでは、すべての作業項目に期限がありません。また、この方法論では遅延に対する罰則も規定されていません。

誰のためですか?

カンバンは、チームが成長して成果を達成することに意欲的な企業で効果を発揮します。すでに明らかなはずですが、これは小規模なチーム向けです。もしかしたら、分遣隊やチームの一員かもしれません。

3. 合理的統一プロセス (RUP)

RUP 方法論では、反復開発モデルが使用されます。各イテレーション (2 ~ 6 週間かかります) の終わりに、チームは計画された目標を達成し、一時的ではありますが、プロジェクトの実用的なバージョンを取得する必要があります。RUP では、プロジェクトを 4 つのフェーズに分割することが求められています。各フェーズでは、次世代製品の開発、開始、精緻化、構築、移行という作業が行われます。フェーズの終わりに、プロジェクトのマイルストーンが達成されます。チームがその結果を評価する瞬間は、プロジェクトのマイルストーンと考えることができます。これは、主要な機能が最初のフェーズでリリースされ、追加機能が後続のフェーズで追加されることをこの方法論が意味していることを意味します。

長所:

  • 顧客からのタスクの変化と業務の過程で生じる変化の両方に対処できるようになります。
  • 製品の継続的な改善を保証します。反復中に、プロジェクトを注意深く評価できます。
  • これにより、作業の初期段階でリスクを特定して排除し、開発の品質を効果的に管理できるようになります。

短所:

  • この方法論はかなり複雑で、小規模なチームや会社で実装するのは困難です。
  • 専門家のタスク設定能力に依存します。
  • 要件の過剰な文書化が必要です。

誰のためですか?

製品をできるだけ早くリリースする必要がある場合、明確に確立された要件とリスクが十分に理解されている大規模プロジェクト。機能を犠牲にしてでも、自分のニッチな分野をすぐに占領し、後から最後の仕上げを追加するために。

方法論はたくさんありますが、傾向としては 1 つあります

間違いなく人気があり、アジャイル原則に基づくスクラムとカンバン、および耐久性の高い反復的な RUP 方法論に加えて、企業はさまざまな方法論を使用しています。ある企業は、極端なプログラミングに近づき、最も迅速かつシンプルな意思決定を行う可能性があります。もう 1 つはテスト駆動開発に近いものかもしれません。さらに、高速アプリケーション開発 (RAD) を好む人もいます。とはいえ、複数の方法論を同時に使用するという強力で疑いの余地のない傾向があります。。あるいは、モデルと方法論を組み合わせて独自の管理システムを構築することもできます。今日の企業は、部門や組織単位の間で責任を転嫁することなく、官僚的な障壁を排除し、組織内に統一されたチームワークの雰囲気を作り出すことに努めています。スクラムアライアンスによると, IT企業の7割がスクラムを採用しています。その中には、Google、Amazon、Salesforce、Microsoft、Adobe などの巨大企業も含まれます。スタートアップや若いプロジェクトはカンバンを使用する傾向がありますが、トヨタや、たとえばウォーゲーミングのゲーマーもカンバンを使用しています。スクラムは計画ツールですが、カンバンは進捗状況を監視するためのものです。RUP に関しては、従業員数 50 ~ 200 名、売上高 100 ~ 1,000 万ドルの欧米企業で最もよく使用されています。ただし、IBM は RUP を修正してアジャイル原則に近づけ、OpenUP 方法論 (RUP、ただしアジャイル) をリリースしました。この自慢のアジャイル手法が現在 IT 世界を推進しています。これは単なる一時的な流行ではなく、今でも革新的であり、実際に多くの大企業で活用されています。シリコンバレーではアジャイルが使われています。FacebookとUberはそれを使用しています。

結論

各プロジェクトには独自のソフトウェア開発方法論があり、チーム、資金、期限、顧客の要件によって異なります。普遍的な管理手法は存在しません。広く普及しているアジャイル手法でさえ、開発プロセスへの最適なアプローチを保証することはできません。その結果、方法論は慎重に、時には原則に基づいて選択されます。その方法論を調べることで、企業そのものやその顧客についての結論を導き出すことができるほどです。方法論は混合され、モデルで補足され、適応されます。新しいアプローチが生まれるほどです。とはいえ、管理の領域は最終的にはスクラムとカンバンの手に残り、ウォーターフォール モデルや反復 RUP 方法論の予期せぬ要素が伴います。
さらに読む:
ウェブサイト: 書籍:
  • アンドリュー・ステルマン、ジェニファー・グリーン: 「アジャイルの学習」。
  • Per Kroll、Bruce MacIsaac: 「アジリティと規律を簡単に: OpenUP と RUP からの実践」
  • マイク・コーン: 「アジャイルで成功する: スクラムを使用したソフトウェア開発」;
  • ロバート C. マーティン: 「アジャイル ソフトウェア開発: 原則、パターン、実践」;
  • マーカス・ハンマルバーグ、ヨアキム・スンデン:「アクションのカンバン」。
  • I. ジェイコブソン、G. ブーチ、J. ランボー: 「統合ソフトウェア開発プロセス」。
コメント
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION