アジャイル

ウォーターフォールとアジャイルは、どちらが優れているかではなく、何を先に決めるかが違います。試験ではこの違いを言い換えた選択肢が並ぶので、考え方の前提から押さえます。

ウォーターフォールの前提と弱点

ウォーターフォールモデルは、要件定義、設計、プログラミング、テストという工程を上流から下流へ順に進める進め方です。滝が上から下へ流れるように、前の工程が終わってから次に進みます。

前提になっているのは、最初に要件をすべて決められるという考え方です。工程ごとに成果物を確定させるので進捗が管理しやすく、大人数での分担にも向きます。

弱点は、後の工程で要件の間違いが見つかったときです。設計まで戻ってやり直す手戻りが大きく、費用も期間も膨らみます。また、動くものが出てくるのが終盤なので、利用者が実物を見て意見を言える機会が遅くなります。

アジャイルの考え方

アジャイルは、短い期間の開発を何度も繰り返し、動くソフトウェアを早い段階から少しずつ届けます。仕様は途中で変わるものだという前提に立ち、変更を受け入れながら進めます。ドキュメントを軽くし、利用者や関係者と対話しながら優先度の高い機能から作ります。

反復の単位を短く区切るので、方向がずれても1回分の作業しか無駄になりません。ここが手戻りの大きさの違いです。

両者の比較

スクラムとXP

アジャイルの代表的な進め方がスクラムです。用語がそのまま出題されます。

• スプリントは、1週間から4週間程度に区切った開発の反復単位です。
• デイリースクラムは、毎日短時間で行う進捗と課題の共有会です。作業の詳細な指示や問題解決の場ではありません。
• プロダクトオーナーは、作るものの優先順位に責任を持つ人です。
• スクラムマスターは、チームが円滑に進むよう妨げを取り除く人です。進捗を管理して指示を出す監督ではありません。ここは頻出の引っかけです。

XP（エクストリームプログラミング）は、開発の実践手法をまとめたものです。

リファクタリングは機能を追加する作業ではありません。動きは同じまま中身を整える作業です。

DevOps

DevOpsは、開発（Development）と運用（Operations）が協力し、リリースを速く安全に繰り返せるようにする考え方です。自動テストや自動デプロイの仕組みを使い、開発と運用の間の壁をなくします。開発ツールの名前ではなく、体制と文化を含む考え方である点に注意してください。