ソフトウェア開発手法

多くの面接では、おそらく方法論について質問されるでしょう。これは最も重要な質問でも難しい質問でもありませんが、カンニングペーパーがあると便利です。この記事では、開発方法論とは何かを伝え、それらを比較していきます。ソフトウェア開発方法論は、特定の製品を開発するために使用されるプロセスです。つまり、開発者チームによる開発を組織する 1 つの方法です。さまざまな開発モデルがあり、それぞれが独自のアプローチを定義しています。それらのいずれかをすべてのプロジェクトに使用する必要があるとは言えません。適切なアプローチは完全に状況によって異なります。そのうちの 3 つをさらに詳しく検討していきたいと思います。

滝

ウォーターフォール手法は最も古い手法の 1 つであり、厳密に逐次的な実装が必要です。つまり、各ステージは次のステージが始まる前に完了する必要があります。つまり、次のステージへの移行は、前のステージの作業が 100% 完了したことを意味します。図は、それがどのように機能するかを示しています。まず、問題を分析し (タスクを文書化し、課題について話し合います)、次に設計を行い (この段階でプロジェクトの構造が形になります)、次にコーディングとテストを行います。前のステージに戻ることはできません。このアプローチは、要件が事前にわかっていて変更される可能性が低い小規模プロジェクトに推奨されます。 利点:

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

短所:

• 大量のドキュメント
• あまり柔軟ではない
• クライアントは製品のデモ版を表示できません
• 後退するオプションはありません

スクラム

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

• スクラム チームは、プロジェクトに取り組む専門家 (開発者、テスター、デザイナー) で構成されます。
• スクラム マスターは、スクラムの原則が確実に尊重されるようにする人です。
• 製品の所有者は顧客です。

この方法論はコミュニケーションに依存しているため、非常に多くの会議が行われます。

• スタンドアップ – これは毎日開催される短いミーティングで、チーム メンバー全員が参加します。各参加者は 3 つの質問に答えます。「私は何をしましたか?」何をしたらいいでしょう？そして、どのような妨げとなる問題があるのでしょうか?
• 計画ミーティング – このミーティングはスプリントの開始時に開催されます。次のスプリントで実行する必要があるタスクは、このミーティングで特定されます。
• 振り返り - このミーティングはスプリントの最後に開催され、何がうまくいったのか、何が改善の余地があるのか​​を特定することが目的です。

利点:

• お客様は開発プロセス中に結果を確認できます
• 開発プロセスの毎日のモニタリング
• 開発中に調整が可能
• チームメンバー全員とのコミュニケーションを確立する
• 少量のドキュメント

短所:

• 開発にかかる人件費などのコストの把握が難しい
• 開発開始前にボトルネックを特定するのが難しい
• 他のチームメンバーの仕事に全員を参加させる必要性。

カンバン

カンバンは、チームのタスクの完了における進捗状況の視覚化に基づいた手法です。主なアイデアは、現在実行中のタスク ([進行中] 列) の数を減らすことです。スクラムでは、チームはスプリントを正常に完了することに集中します。カンバンでは、タスクが最も重要な位置を占めます。これは、基本的な機能がすでに実装されており、最小限の改善とバグ修正が残っているメンテナンス段階のプロジェクトに適しています。カンバンでは、タスクは個別に割り当てられます。タスクは他のタスクとは独立してボード上のすべての段階を通過し、完了すると顧客に表示できます。カンバン ボードは列で構成され、それぞれが個別の開発プロセスを表します。一部の列 (「進行中」など) ) 保持できるタスクの数を制限します。これは、タスクの分散における問題領域を迅速かつ簡単に見つけるのに役立ちます。写真はまさにそのようなボードの例を示しています。列の数とその名前は異なる場合があります。最も一般的なものを紹介します。

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

利点:

• 使いやすさ
• 可視性 (ボトルネックの特定に役立ち、理解を容易にします)
• プロセス自体へのチームの関与が高い
• 柔軟性の高い開発

短所:

• 不安定なタスクリスト
• 長期プロジェクトに適用するのは難しい
• 厳しい締め切りの欠如

ソフトウェア開発方法論についての最後の言葉

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