ソフトウェア開発手法

こんにちは。最後の2回の面接では方法論について質問されました。これは最も重要な質問でも、難しい質問でもありませんが、答えのカンニングペーパーがあると便利です。この記事では、開発方法論とは何なのかを説明し、私が個人的に会ったり、相談したりした開発方法論と比較してみます。 ソフトウェア開発方法論は、特定の製品がどのように開発されるかを記述するプロセス、つまりチーム開発を組織する方法の 1 つです。このようなプロセスにはさまざまなモデルがあり、それぞれが独自のアプローチを説明していますが、その中には各プロジェクトで使用すべきモデルがあるとは言えず、すべては純粋に状況に応じたものです。そのうちの 3 つをさらに詳しく検討することを提案します。

滝

ウォーターフォール (カスケード、滝) は最も古い方法論の 1 つであり、すべての段階を厳密に順次実装することを意味し、次の段階が始まる前に各段階を完了する必要があります。つまり、次の段階への移行は、前の段階での作業が完全に完了することを意味します。この図は、最初にタスクを分析し（タスクを文書化し、困難について話し合う）、次に設計が行われ（この段階でプロジェクト構造が形成されます）、次にコーディングとテストを行っていることを示しています。それ以降のステージでは払い戻しはありません。このようなシステムは、要件が事前にわかっており、変更される可能性がほとんどない小規模プロジェクトで使用することをお勧めします。 利点:

• あらゆる段階で完全かつ一貫した文書化。
• 使いやすさ;
• 安定した要件。
• 予算と期限はあらかじめ決まっている

欠点:

• 大量のドキュメント。
• あまり柔軟なシステムではありません。
• クライアントは製品のデモ バージョンを表示できません。
• 一歩戻る方法はありません。

スクラム

スクラムは、プロセス全体を反復に分割することに基づいたソフトウェア開発システムであり、各反復の終了時にチームは製品のデモ バージョンを提供する準備が整います。この図は、チームが開発のすべての段階を並行して進めていることを示しています。これにより、各反復の終わりにはプロジェクトの一部が完成することができます。 この方法論の本質を簡単な言葉で簡単に説明しようと思いますが、ここには多くの用語があります。一番大切なのは本質を理解することであり、用語は経験とともに記憶されるものだと思います。すべての開発はスプリント(通常は 2 ～ 3 週間)に分割されます。バックログ(タスクのリスト) は、開発期間全体およびスプリントごとに個別に存在します。各タスクには独自のストーリー ポイント(難易度評価) があります。プロセスの各参加者には次の役割があります。

• スクラム チームは、プロジェクトに取り組むチーム (開発者、テスター、デザイナー) です。
• スクラム マスターは、スクラムの原則が確実に守られるようにする人です。
• プロダクトオーナー – 顧客。

このシステムではコミュニケーションに重点が置かれているため、多数の集会が行われます。

• スタンドアップは毎日開催される短いミーティングで、チームメンバー全員が参加し、各参加者が 3 つの質問に答えます。「何をしましたか?」それは何をするのでしょうか？そして、阻害要因は何でしょうか?
• 計画 – スプリントの開始時に開催され、この会議で次のスプリントでどのタスクを完了する必要があるかが決定されます。
• 振り返りはスプリントの最後に行われ、その本質は何がうまくいったのか、何が改善の余地があるのか​​を見つけることです。

利点:

• お客様は開発プロセス中に結果を観察できます。
• 開発プロセスを日々管理します。
• 開発中に調整を行う能力。
• チームメンバー全員とのコミュニケーションが確立されている。
• 少量のドキュメント。

欠点:

• 開発にかかる労力やコストの見積りが難しい
• 開発を開始する前に最大のボトルネックを特定することは困難です。
• 他のチームメンバーの育成に全員を参加させる必要性。

カンバン

カンバンは、チームのタスクを完了するプロセスを視覚化することに基づいて構築されたシステムです。このシステムの主な考え方は、現在実行中のタスク (「進行中」列) の数を減らすことです。スクラムでは、チームはスプリントを正常に完了することに重点を置きますが、カンバンではタスクが最初に来ます。主要な機能がすでに開発されており、最小限の改善とバグ修正が残っている、サポート段階にあるプロジェクトに適しています。カンバンでは、タスクは個別に送信されます。このタスクは、他のタスクに関係なく、ボード上のすべての段階を通過し、完了するとすぐに顧客に表示されます。カンバン ボードは列で構成され、それぞれが個別の開発プロセスを表します。一部の列 (進行中など) では、そこに存在できるタスクの数に制限が課されます。これは、タスクの分散において問題のある領域を簡単かつ迅速に見つけるのに役立ちます。写真はそのような単純なボードの例を示しています。列の数と名前は異なる場合がありますが、最も一般的なものを挙げます。

• To do - 実行する必要があるタスクのリスト
• 進行中 – 現在取り組んでいるタスク
• コードレビュー – 完了してレビューのために送信されたタスク
• テスト中 - テストの準備ができているタスク
• 完了 – 完了したタスク。

利点:

• 使いやすさ。
• 視覚化 (ボトルネックの発見に役立ち、理解を容易にします)
• プロセス自体へのチームの関与が高い。
• 開発の自由度が高い。

欠点:

• 不安定なタスクリスト。
• 長期的なプロジェクトで使用するのは難しい。
• 厳しい締め切りはありません。

ソフトウェア開発手法についての結論

私の意見では、管理職に就いている人、または管理職を目指す人はソフトウェア開発手法を十分に理解している必要がありますが、誰でも少なくとも基本的なことは理解しておくことが望ましいと考えています。これは開発プロセスに不可欠な部分であり、IT 分野だけでなく使用されます。私の記事を読んでいただきありがとうございます。お役に立てば幸いです。重要なポイントのみをできるだけ明確かつ簡潔に説明しようとしたため、この記事はすべてを網羅したものではありません。ぜひご意見を伺い、ご質問にお答えさせていただきます。ではごきげんよう！