開発プロセスと開発モデル

基本の仕組み

予約画面の試作品を利用者に触ってもらい、短い周期で改善するのが反復的な進め方です。動く成果を使って認識のずれを小さくします。

ウォーターフォールは工程を段階的に進め、アジャイルは短い反復で価値ある成果を届けながら変化へ対応します。どちらも品質管理や関係者との合意は必要です。

アジャイルは計画も文書も不要という意味ではありません。優先順位、完了条件、振り返りがなければ、ただ作り直しを続ける状態になります。

開発モデルの使い分け

ウォーターフォールモデルは工程を順に確定させ、原則として前の工程へ戻らない前提で進めます。プロトタイピングモデルは試作品を利用者に見せて要求の認識を合わせ、スパイラルモデルはリスクを評価しながら設計・開発を繰り返します。

システムを機能ごとに分け、段階的に作って順次リリースするのが段階的モデル（インクリメンタルモデル）、全体を作ってから要求の変化に合わせて改良を重ねるのが進展的モデル（エボリューショナリモデル）です。DevOpsは開発チームと運用チームが連携し、自動化されたビルド・テスト・リリースで迅速に改善を続ける考え方です。

スクラムの役割とイベント

スクラムでは、プロダクトオーナーがプロダクトの価値を最大化する責任を持ち、プロダクトバックログの項目や順序を明確にします。例えば予約機能と通知機能のどちらを先に届けるかを、利用者の価値から整理します。開発者へ実装手順を一方的に命令する役割とは区別します。

デイリースクラムは、開発者がスプリントゴールへの進み具合を確認し、直近の作業計画を調整する15分のイベントです。管理者へ一人ずつ成果を報告するだけの会議ではありません。障害を見つけたら、必要な詳しい議論を別途行うこともできます。

バーンダウンチャートは、横軸に時間、縦軸に残作業量を置いて進捗を見る方法です。完了した量の累計を描くグラフと混ぜないようにします。線が下がらない場合は未完了の作業や見積りの変化を確認しますが、グラフだけで価値や品質を保証することはできません。

スクラムマスターは、スクラムの理論と実践をチームや組織が理解できるよう支援し、チームの有効性に責任を持ちます。スプリントは1か月以内の固定期間で、その中にスプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブが含まれます。

XPの代表的なプラクティス

XP（エクストリームプログラミング）では、テスト駆動開発（先にテストを書き、それを通すようにコードを書く）、ペアプログラミング（二人一組で一つのコードを書く）、リファクタリング（外部から見た動作を変えずに内部構造を改善する）、継続的インテグレーション（頻繁に統合し、ビルドとテストを自動で実行する）などを実践します。

今必要でない機能は作らないというYAGNI（You Aren't Gonna Need It）の考え方や、特定の担当者に限らず誰でもコードを修正できるソースコードの共同所有もXPの特徴です。リファクタリングは機能追加や不具合修正とは目的が違う点に注意します。