アジャイル開発の種類

スクラム開発

概要

スクラム開発はアジャイル開発の代表的な手法の一つで、中でも“チームのコミュニケーションを重視した手法”である。ラグビーで両陣が、8名ずつ肩を組んで一つの集団を作り、ぶつかり合う際のフォーメーション「スクラム」が語源。その姿から集団が力を合わせることを”スクラムを組む”と表現することもある。

特徴

・プロダクトへの要望を優先順位ごとに並べかえ、その順に機能を作る。
・固定の短い期間（1～4週間程度）の単位で開発を区切り、その中で計画を立てる。
・プロジェクトの状況や進め方に問題がないか、メンバー同士で毎日確認しあう。
・作っている機能が正しいかどうか、定期的に確認の場を設ける。

用語

【スプリント】
スプリントは、1週間や2週間といった、時間枠(タイムボックス)のことである。スプリントでは、スプリント計画、デイリースクラム、スプリント実施、スプリントレビュー、スプリント振り返りなどのアクティビティがある。


【スプリント計画(スプリントプランニング)】
次のスプリントで何をやるかを決定する。プロダクトバックログを元にしてスプリントバックログを作成する。この時、スプリントバックログは、プロダクトバックログアイテムをタスク単位に細分化しても問題ない。


【デイリースクラム】
デイリースクラムでは、1日の作業の開始時に開発チームが実施する活動である。ここでは、誰がどのスプリントバックログに着手するか、問題は発生していないかなどを15分で確認する。またデイリースクラムを行なわずに開発チームは常にコミュニケーションを行い、把握するという方法もある。


【スプリントレビュー】
スプリントレビューでは、スプリントの実施によって生み出されたインクリメントの検査と適応を行う。開催はスクラムチームが行う。スプリントレビューにはプロジェクトの利害関係者全員が参加し、スプリント実施が完了した直後に行う。デモを実施し、利害関係者にインクリメントを説明する。そして、次の質問をする。

利害関係者は、デモの結果を気にいっているか
今でも顧客に受け入れられるか
重要な機能が不足していないか
不必要な機能を作成していないか
コストをかけすぎていないか
これらの質問の答えが、プロダクトバックログのグルーミングの参考になり、リリースプランのインプットになる。


【スプリント振り返り(スプリントレトロスペクティブ)】
スプリントレビューでは、プロダクトについてのレビューを実施しますが、スプリント振り返りでは、スクラムチームの成長や、プロセスの改善を行うことが目的である。

今回のスプリントでうまくいったことは何か
今後も続けたいことはなにか
問題や課題になったことはなにか
改善したほうがよいことはなにか


【KPT】
KPTは、左上にKeep、左下にProblem、右半分にTry、最上部にテーマ、というように区分したフレームワークである。Keep は今後も続けること、Problem は問題点であること、Try は試すこと。

エクストリームプログラミング

概要

エクストリーム・プログラミング、XP（英: extreme programming）は、ケント・ベックらによって定式化され、提唱されているソフトウェア開発手法である。柔軟性の高い開発手法であるため、難易度の高い開発やビジネス上の要求が刻々と変わるような状況に向いた開発手法である。事前計画よりも柔軟性を重視する。1999年に書籍『XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法』によって発表された。

XPは、軽量開発手法あるいはアジャイルソフトウェア開発手法と呼ばれる、同種の開発手法のなかで代表的なものである。柔軟性の高い開発手法であるが、古典的には開発が進むにつれ変更コストは大きくなると言うことを前提に開発手法が構築されているのに対して、自動テストを導入するなど様々な対策をすることにより開発が進んでも変更コストが大きくならないような工夫を持ち込むことにより、変更に対する柔軟性を実現している。この変更コストが増大しないという前提が破綻すると、この手法も破綻する。

XPは比較的少人数の開発にもっとも適用しやすく、5つの価値と19の具体的なプラクティス（実践）が定義されている。XPはドキュメントよりもソースコードを、組織的開発の歯車となることよりも、個人の責任と勇気を重んじる人間中心の開発プロセスであるとしている。

共同のプラクティス

【反復】
開発を反復から構成する（⇒反復型開発）。全体の開発期間はイテレーションと呼ぶ1〜2週間の短い期間に区切り、イテレーションごとに部分的な設計・実装・テストを行い、半完成品システムのリリースを繰り返し、徐々に完全なシステムを構築していく。またより小さな単位の単体機能の実装も、コード修正とテストの繰り返しによって進める。このことで、リスクを最小限に抑えつつ、イレギュラーな変更に対応した開発が可能になる。


【共通の用語】
用語集を作成し、チーム全員（開発者・管理者・顧客）の使用する用語とその概念の不一致を解消する。


【開けた作業空間】
会話しやすく、作業に打ち込める雰囲気を作る。顧客も含めて一箇所に集まって作業を行う。


【回顧（頻繁な振り返り）】
現在の状態を明確に把握しつつ、過去のフィードバックを迅速に反映させるよう心がけ、そのための環境、体制を構築しておく。

開発のプラクティス

【テスト駆動開発】
実装を行うより先に、テストを作成する。実装は、そのテストをパスすることを目標に行う。テストを先に作成することで、求める機能が明確化され、シンプルな設計が可能になる。なお、このテストは、部品単位での正確性を確認するユニットテスト（ホワイトボックステスト）と、全体が顧客の要求を満たしているかを確認する受け入れテスト（ブラックボックステスト）の観点で作成する。テストは、自動テストであることが推奨される。なぜなら、それによって、コードの共同所有、リファクタリング、頻繁な結合が可能になるため、開発が進んでも変更コストの増大を抑制することができる。


【ペアプログラミング】
プログラミングは、二人一組で行う。一人がコードを書き、もう一人はそれをチェックしながら、仕様書を確認したり全体構造を考えたりするなど、ナビゲートを行う。二人は、この役割を定期的に交代しながら仕事を進める。ナビゲータのサポートにより、以下の効果が得られる。
細々とした問題の解決に要する時間が短くなる。
常にコードレビューを行うことができる
集中力が持続する。
コードの詳細を理解したメンバーが常に2人以上いることで後々のコード共有に役立つ。


【リファクタリング】
完成済みのコードでも、随時、改善処置を行う。この際、外部から見た動作は変更させずに、内部構造がより見通し良く優れたものになるようにする。テストが作成されていることが前提になる。


【ソースコードの共同所有】
誰が作ったソースコードであっても、開発チーム全員が断りなく修正を行うことができる。ただし、全てのコードに対する責任を、全員が担う。


【継続的インテグレーション】
単体テストをパスするコードが完成するたび、すぐに結合テストを行い、問題点や改善点を探す。少なくとも一日に一回は、結合テストを行う。また、全体のコンパイルおよび自動テストを行うための継続的インテグレーション用のコンピュータを準備することが推奨されている。


【YAGNI】
You Aren't Going to Need It.（必要なことだけ行う）。先を見据えて、前払い的に機能を増やし、実装を複雑化させることは避ける[6]。むしろ無駄な機能があれば削りとり、今必要な機能だけのシンプルな実装に留めておく。これにより、後のイレギュラーな変更に対応しやすいようにする。シンプルで洗練され、安定性の高い機能・コードのまま、同時に将来的な汎用性も高めることは問題ないが、把握を難しくし、不安定化を招く機能・コードは、可能な限り削り落とす。

リーンソフトウェア開発

概要

リーン開発の手法は、トヨタなどの企業が過去数十年に渡り完成させたリーン生産プロセスから生まれたものである。リーン開発の目標は、ビジネスが競合力を保つために必要とされる複雑なソフトウェアシステムを定義し、構築し、引き渡すという取り組みに対処することである。リーン開発は、技術的なプラクティスではなく、ソフトウェア開発のプロジェクトマネジメント面を重視している点でスクラムと似ており、特にプロジェクトのコストとROIの属性を焦点にしている。

リーン開発の大きな柱になっているのが、「正しい」要件の収集である。要件はビジネスへの影響に基づいて評価し、明確で完全で検証可能な方法で定義しなければならない。不完全な要件、見つからない要件、間違った要件、検証不可能な要件、競合している要件は、要件定義プロセス時に除外されます。

このように要件を重視するため、リーンプロセスでは顧客が絶対不可欠な役割を果たす。生産の観点から見れば、リーン開発は新製品の開発のようなものと考えることができる。要件に焦点を置くことは、顧客が果たす役割と価値を具体化するのに役立つ。開発チームが対処しているビジネス価値と機能要件について顧客からコンスタントなフィードバックを得ることが、リーンアプローチの中心的要素である。

機能駆動型開発（FDD）

概要

機能駆動型開発（FDD）は、5つの基本活動からなるモデル駆動型の短期反復方式の開発工程である。ソフトウェア開発プロジェクトの正確な状態報告と監視のために、各 feature についての進捗を示すマイルストーンが定義されている。最初の3つの逐次的な活動によって、全体モデルの形が決まる。その後の2つの活動は feature 毎に反復的に実施される。

【全体モデル開発】
プロジェクトは、システムの範囲とその内容についての高レベルなウォークスルー（ソフトウェア開発において、ソフトウェア成果物の品質向上を目的に、その作成者が主体となって開催するレビューのこと）から開始される。次に、部門毎の詳細なウォークスルーが、各モデリング分野ごとに行われる。各部門のサポートを受けて、複数のウォークスルーモデルが少人数で制作され、査読と議論のたたき台とされる。提案されたモデルのうちの1つまたは複数をまとめたものが、その特定の分野のモデルとして選択される。分野ごとのモデルが結合されて全体モデルとなり、全体モデルとしてその後調整が行われる。


【feature リスト構築】
初期のモデリングで収集された知識は機能（feature）のリストアップに使われる。このとき、領域を顧客が重要と考えている点ごとに分類する。この分類された各点にはそれぞれ何らかのビジネス活動が含まれ、各ビジネス活動内のステップ群に feature リストが対応する。この観点での feature とは、顧客にとっての価値を生む小規模な機能単位であり、