前回の開発手法は伝統的なものだ。
今も無視することはない。
しかしコンピュータの多岐に渡りコンパクト、少数になり現場ではスピード感が求められる。
そこで
新しい開発手法を紹介する。
RAD（Rapid Application Development）
短期間で開発することを重要視した開発手法。
エンドユーザーと開発者による少人数構成のチームをくみ、開発支援ツールを活用する。
プロトタイプを作ってそれを評価する。それを繰り返すことで完成度が上がっていく。
しかし何回も評価していては時間がかかる。
なので開発時間を設ける。それをタイムボックスという。
評価する時点で固まっていない要求については開発することはない。
アジャイルとXP（eXtreme Programming)
スパラルモデルの派生型でより早い反復単位で開発を行う。
これによって迅速に開発する手法をアジャイルという。
一つの機能を開発した後はソフトウェアをリリースする。
アジャイルの型の代表的な開発手法がXPだ。
少人数の開発に適用しやすい。
変更を許容する柔軟性が実現されている。
気づき
一つ一つの開発するから柔軟のなのかな。
XPの５つの価値
コミュニケーション
プロジェクトが失敗する原因の多くはコミュニケーション不足です。エクストリームプログラミングでは開発チーム内だけでなく、顧客とのコミュニケーションも重視します。
シンプル
最初の設計を極力シンプルにします。基本的な機能だけを盛り込み、そのほかの機能が必要になれば、その都度対応します。
フィードバック
ソフトウェア開発において、不要な機能を盛り込むのは大きな無駄となります。顧客からのフィードバックを得て、必要な機能を洗い出すことが大切です。
勇気
最初に綿密な計画を立てないという特性上、途中で大胆な変更が求められる場合があります。
尊重
チームで開発する以上、ほかのメンバーを尊重する姿勢は欠かせません。
出典 https://it-trend.jp/development_tools/article/32-0023
XPのプラクティス（実践）
開発プラクティス
開発プラクティスは、プログラマーなどの開発チームを対象としたプラクティスです。19つのプラクティスに分けられますが、それを大きな括りで分類して紹介します。
テスト後に実装を行う「テスト駆動開発」
プログラムの実装よりもテストコードを先に作成することです。それにより、求められる機能が洗い出され、シンプルな設計が実現します。
テストの通過を目標に開発を行えば、仕様変更などによる開発途中のブレを最小限に抑えられるでしょう。なお、テストはユニットテストと受け入れテストからなり、どちらのテストも自動化が望ましいです。
２人１組で行う「ペアプログラミング」
２人１組でプログラミングを行うことです。１人がコードを記述し、もう１人はそれを確認・補佐します。
記述しながら確認を行うと、細々とした問題をその場で解決できるメリットがあります。また、記述されたコードを把握している人物が２人いるので、その後の問題発生時にも迅速な対応が可能になるでしょう。
内部構造を整える「リファクタリング」
完成したコードをわかりやすく書き換えることです。外部の動作を変えずに、内部構造だけを変更します。同じ動作をするコードでも、わかりやすいものに変換されるので、メンテナンス性の向上や不具合の発生頻度の低下が期待できます。
必要なコードだけを記述する「YAGNI」
YANGIは「You Aren't Going to Need It」の略で「今必要なことだけをする」という意味です。つまり、必要なコードのみを記述することを意味します。
開発時には、後に必要になるであろう機能を考慮して、あれこれと盛り込みたくなるでしょう。しかし、そうした思惑は外れる場合が多く、結果として無駄になります。今必要とされるコードの記述に注力することが大切です。
ソースコードの共同所有
断りなく、チーム内の誰もが修正を行うことができる。
チーム全体が全てのコードに対して責任を負う。
出典 https://gihyo.jp/book/2020/978-4-297-11781-8
継続的インテグレーション
単体テストを終えたプログラムは、すぐに結合して結合テストを行う。
出典 https://gihyo.jp/book/2020/978-4-297-11781-8
プラクティス
- テスト主導型の開発
- ペア・プログラミング
- リファクタリング
- 集団的な所有権
- 継続的インテグレーション
- YAGNI
管理者プラクティス
管理者プラクティスは、管理者を対象としたプラクティスです。開発が適切に進行しているのか把握し、チームで共有する必要があります。
特に、チームの負荷が大きすぎないか常に確認することが求められます。エクストリームプログラミングは短期間で集中して作業を行う方法であるため、過度な労働は避けなければなりません。
プラクティス
- 責任の受け入れ
- 援護
- 四半期ごとの見直し
- ミラー
- 持続可能なペース
顧客プラクティス
顧客プラクティスは、その名のとおり顧客を対象としたプラクティスです。
エクストリームプログラミングでは、顧客も開発に携わるチームメンバーとして扱います。ビジネス的な視点から必要な機能を考え、開発の優先順位を付けるのが顧客の役割です。
具体的には、要求機能のコンセプトを短い文章にしたストーリーの作成やリリース計画を立案します。また、イテレーションごとに開発チームとともに受け入れテストを行い、求めた機能が実現しているか確認します。
プラクティス
- ストーリーの作成
- リリース計画
- 受け入れテスト
- 頻繁なリリース
出典 https://it-trend.jp/development_tools/article/32-0023#chapter-3
共通のプラクティス
関係者全員に関わる実践内容
プラクティス
- 反復
- 共通の用語
- オープンな作業空間
- 回顧
出典 https://tracpath.com/works/devops/xp_extreme_programming/
出典 https://www.alobridge.com/blog/1112
リバースエンジニアリング
既存のソフトウェアの動作を解析することで、プログラムの仕様やソースコードを導き出すこと
目的
既にあるソフトウェアを再利用することで新規開発を手助けすること。
気づき
分析するんだな。
フォワードエンジニアリング
リバースエンジニアリングで得られた仕様をもとに新しいソフトウェアを開発する手法。
注意点
元となるソフトウェア権利者の許可なくこれを行い、新規ソフトウェアを開発・販売すると、知的財産権の侵害に当たる可能性があるため注意が必要。
マッシュアップ
公開されている複数のサービスを組み合わせることで新しいサービスを作り出す手法のこと。