アジャイル開発とスクラムの全て

アジャイル開発について

アジャイル開発とは?

アジャイルとは、変化に対応しながら素早く価値を届けるための開発手法の総称です。近年は従来型の開発手法では変化のスピードに対応することが難しくなってきたため、多くの企業で採用されています。代表的なフレームワークとして、スクラムやカンバンがあります。

アジャイルとは、「柔軟なソフトウェア開発を目指そう」という思想のこと。

全ての工程を区切って、その工程の通りに進んでいく「ウォーターフォール型開発」と比べて、アジャイル型開発ではプロジェクトは変化するものと認め、イテレーションと呼ばれる小さなサイクルを何度も回して、プロダクトの価値を最大化することを最重要と考える。

4つの価値と12の原則

アジャイルソフトウェア開発宣言

プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応

12の原則

  1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
  2. 要求の変更はたとえ開発の後期であっても歓迎します。変化を見方につけることによって、お客様の競争力を引き上げます。
  3. 動くソフトウェアを、2−3週間から2−3ヶ月というできるだけ短い時間感覚でリリースします。
  4. ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
  5. 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
  6. 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
  7. 動くソフトウェアこそが進捗の最も重要な尺度です。
  8. アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
  9. 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
  10. シンプルさ(ムダなく作れる量を最大限にすること)が本質です。
  11. 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
  12. チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

アジャイル開発で最も大切なこと

お客さんに価値ある成果を毎週必ず届ける。

本当に大事なことは、動くソフトウェアを定期的に届けること。

アジャイル開発の考え方の基本は、

  1. 大きな問題は小さくする
  2. 本当に大事なことに集中して、それ以外のことは忘れる
  3. ちゃんと動くソフトウェアを届ける
  4. フィードバックを求める
  5. 必要とあらば進路を変える
  6. 成果責任を果たす

アジャイル開発では動くソフトウェアを定期的にお客さんの目の前に届けて、そこからフィードバックを得る。
そして必要とあらば進路を変えていく。

アジャイル用語集

イテレーション

開発サイクルの単位。
スクラム開発ではスプリント。
1 - 4週間で設定されることが多い。

実現したい項目(設計、実装、テストまで)をこの中で完了させていく。

イテレーションの最初にプランニング、最後に振り返りをそれぞれ行う。

ベロシティ

1回のイテレーションでチームが完了させることのできるタスク(ポイント)の量。
要するにチームの開発速度のこと。

ベロシティは最初からわかっているわけではないので、イテレーションを回しながら計測していく。
計測したベロシティを元にだんだん正確な計画をたてることができるようになる。

アジャイルプロジェクトを開始するまで

STEP1:チームづくり

アジャイルチームの特徴
  • 役割分担がはっきりと別れていない。全員が必要とあらばなんでもやる。
  • 分析や設計といった開発工程が一度きりではなく、分析→設計→実装→テストのサイクルを何度もこなす。
  • チームが一丸となって成果責任を果たすという考え方とても重視している。品質を保証するのはチームであり自分自身。

きっちりと区別しない役割分担。継続的な開発工程。チームで成果責任を果たそうとする態度。
これら3つがアジャイルチームの特徴。

アジャイルチームは、何を作るべきかわかっている人(顧客)と、それを作ることができる人(開発チーム)に別れているだけ。

アジャイルな顧客

顧客は業務に深く通じていて、ソフトウェアが何をするのか、どんな見た目になるのか、どんな具合に動くのかを心から気にかける人物である。
また開発チームに確固たる指針を与え、デモを見に来て、質問に答え、開発チームにフィードバックをしてくれる存在。

つまりはプロジェクトを流れていくあらゆる要求の「真実の源」。

また資金が期限がヤバい時に、何を作らないかを決めるのも顧客の仕事。

チームのコアメンバーでありプロジェクトの強力なパートナー。

ビジネス側と開発者は日々一緒に働かなければならない。
そのためにはお客さんと信頼関係を築く必要がある。

顧客をじかに開発へ巻き込めば巻き込むほど、プロダクトはよくなっていく。

アジャイルなコミュニケーション

メールやメッセージではなく、対話を重視する。
直接お互いが顔を合わせての会話こそが最も効率的な情報共有の作戦である、ということを全員が認めること。

つまり、顧客の要求を書き出す時間よりも、顧客と要求について話し合う時間をもっと増やすべきである。

STEP2:共通認識をもつ

インセプションデッキ

プロジェクトの初期段階で、チーム全員の認識を合わせるために行う、手強い質問たち。

  1. 我々はなぜここにいる?
  2. エレベータピッチを作る
  3. パッケージデザインを作る
  4. やらないことリストを作る
  5. 「ご近所さん」を探せ
  6. 解決案を描く
  7. 夜も眠れなくなるような問題は何だろう?
  8. 期限を見極める
  9. 何を諦めるのかをはっきりさせる
  10. 何がどれだけ必要なのか

プロジェクトの最初にこれらの質問に答えておくことで、常にあるべき姿を関係者全員で共有することができるようになる。

STEP3:計画づくり

アジャイルな見積もり

プロジェクト初期段階の概算見積もりには大きな誤差がある。
よってアジャイル開発ではプロジェクト初期段階の概算見積もりを信用しない。

大切なのは「与えられた期間とリソースでこのプロジェクトをやり遂げられるのか?」ということ。

アジャイルのやり方は
何かを作る時には、それがどれぐらいかかったかを計測して、それをもとに計画を立てること。

具体的には、

  • 開発する機能それぞれを互いに相対的なサイズで見積もる
  • ポイントをもとにして進捗を追跡する
相対サイズで見積もる

人間は相対サイズの見積もりなら上手くこなせるらしい
なかなか上手く見積もれないのは絶対サイズでの見積もりに挑んでいるから

具体的には、開発する機能をそれぞれ、お互いがお互いに対してどれぐらいの大きさなのかを相対的に見積もる。

それから、自分たち開発チームがどれぐらいの速度で仕事を進められるか(ベロシティ)を計測する。

ポイントで見積もる

単位はどうでもいい。
注意を払うべきなのは仕事の大きさを数値として捉えて、他のストーリとの相対的なサイズとして表現できているかどうか。
アジャイルな見積もりでは、TシャツをS、M、Lなどのサイズごとに振り分けるみたいなもの。

見積もりが相対サイズになっていれば、それぞれの一つ一つに過大見積もりや過少見積もりがあったとしても、全体として辻褄は合うはず。

見積もり技法二つ

三角測量
代表的にものをいくつか基準として選出して、残りを基準になるものとの相対サイズで見積もるやり方

サイズの見当がつかない場合はスパイクを行う。
スパイクとは、一定の期間を決めて事前調査をすること。
見積もれる程度になったらやめる。
期間は長くても数日以内に留めること。

プランニングポーカー
見積もりゲーム

  1. 各々でまずは全てのものをポイントで見積もる。
  2. 次に一つ一つに対して、一斉に自分が見積もったポイントが書かれたカードを公開する。
  3. 全員のポイントが一致すればそれで決定。見積もり結果に違いがあれば、その違いについて話し合って、再び見積もる。
  4. 上記3つをチームで見積もり結果に合意できるまで繰り返す。

誰の見積もり結果が正しいとか正しくないとかは、問題ではない。
大切なのは実のある話し合いをすること。
個々人が自らの見積もりについての意見を伝え合うことで、従来よりも適切に見積もれるようになる。

アジャイルな計画作り

チームの開発速度(ベロシティ)を計測して、その速度を元にプロジェクトの完了時期を見通せるようにすること。
バーンダウンチャート、バーンアップチャートを使うのも良い。

プロジェクト終了までに必要なイテレーション数=作業量の合計 / チームの平均ベロシティなので、完了時期の見通しが立ちやすい。

計画がうまくいかなくなってきたらその都度調整する。
顧客には、新しい機能を追加するときは古いまたは重要でない機能を外すようにする、ということを予めお願いしておく。

アジャイルプロジェクトの流れ

ソフトウェア開発の3つの真実

  1. プロジェクトの開始時点に全ての要求を集めることはできない
  2. 集めたところで、要求はどれも必ずといっていいほど変わる
  3. やるべきことはいつだって与えられた時間と資金よりも多い

アジャイル開発では以上の問題に対抗するために、以下の流れで開発を行う。

  1. 実現したい機能をリスト(プロダクトバックログ)にまとめ、優先順位をつける。
  2. イテレーションの期間(1〜2週間)で優先順位に従って、一つ一つの機能をテスト済みの動くソフトウェアへと変換していく。
  3. ベロシティ(仕事量)を実測して、自分たちのこなせる仕事量を把握する。
  4. これまでのベロシティを判断材料に、次回のイテレーションを考える。

現実は計画にそぐわなかったら、計画を変える。
現実に適応する計画作りはアジャイルな価値を届けるための基本。

アジャイル開発において、完了とはすぐにリリースできる状態のこと。
設計、実装、テスト、デザイン、全て終了して100パーセントの状態。

アジャイルなイテレーション

  1. 必要な時に必要な分だけ分析する
  2. しっかりと開発する
  3. 早めにこまめにテストする

なぜ必要な時に必要な分だけ分析するのか。

  • 最新かつ最も充実した情報に基づいて分析できるから。
  • 後に機能がいらなくてなって、分析の時間が無駄になった、というような状況を防げるから。

アジャイルな分析

  • フローチャートを作る
  • ペルソナを作る
  • ペーパープロトタイプでいろんなデザインをどんどん作る
  • テスト条件を書き出す

イテレーションゼロ

環境構築のこと。

  • バージョン管理のセットアップ
  • ビルドの自動化
  • コードのデプロイ先の準備
  • 開発環境とテスト環境の準備

一番最初のイテレーションで行う。

テスト:作業の結果を確認する

最後には必ず顧客に受入テスト条件をチェックしてもらう。
アジャイル開発では散々テストしているが、それでもやる。

アジャイル開発者の目標は、いつでも受入テストできるようにすること。
常に顧客からのフィードバックを積極的に取り入れていようと、結局お客さんはシステムに間違いがないかをそこまで真剣には見てくれていない。
彼らが本気を出してチェックしてくれるのは受入テストの時のみ。

アジャイルな意思疎通

開発チームは同じ仕事場に集まって作業して、ちゃんと動くソフトウェアを成果として、目の前の顧客へ定期的に見せていくべき。

また以下のミーティングを行うことで、チーム内の意思疎通を深める。

  • 今回のイテレーションの作業に備える(ストーリー計画ミーティング)
  • 今回のイテレーションのフィードバックを得る(ショーケース)
  • 次回のイテレーション計画を立てる(イテレーション計画ミーティング)
  • 次回のイテレーションで改善できる余地を探す(ミニ振り返り)

ストーリー計画ミーティングではストーリーの準備ができていることを確かめる。
受入テスト条件をレビューしたらい、見積もりの数値を確認したりする。
分析における調査に漏れがないかを確認する。

ショーケースでは成果をお披露目してフィードバックを得る機会。
実装したものをデモする。
ここで披露するのは上手に描けた絵やうまくいくであろう目論見ではなく、テストサーバにデプロイした本物のコード。
作業は全て完了済みで必要とあらば今ここで本番環境にリリースできるコード。

イテレーション計画ミーティングでは開発チームと顧客が一緒になって次回のイテレーションの作業を計画する。
チームのベロシティを確認し、次に取り掛かるタスクを整理する。
そして、次回のイテレーションでチーム全体としてコミットメントする作業量を見極める。
プロジェクトの健康状態を確認するのにもふさわしいタイミング。
何か必要なものがあったり、特に話し合っておきたい厄介な問題があるなら、それを伝えるタイミングもここ。

ミニ振り返りはチーム全員が集まってすごくうまくいったことや、もっとうまくやるためにどうすればいいかを話し合う。

デイリースタンドアップ

重要な情報をチーム内で素早く共有することを目的にした集まり。
あらゆるミーティングを無くすための究極のミーティングがデイリースタンドアップ。
5分から長くても10分。立ったままでやる。

報告する内容は自分の作業の最新状況や他のチームメンバーに知っておいてもらいたいこと。

  • 昨日やったこと
  • 今日やること
  • チームの開発速度を下げてしまうことがあれば何でも

毎日、チームのみんなに「今日、私はこれをやります」とコミットメントを表明する。

現場の状況を目に見えるようにする

以下4つが効果的。

インセプションデッキ
インセプションデッキを貼り出す。
チームがプロジェクトのゴールを見失わないためのツール。常に意識する。

リリースボード
イテレーションで完了したタスクと残っているタスクを貼り出す。

ストーリーボード
現在のイテレーションで取り組んでいるタスクの状態を貼り出す。
Todo、Doing、Doneに分ける。

チームの平均ベロシティとプロジェクトのバーダウンチャート
ベロシティはチームの生産性の度合いを図るのに最適な指標。
バーダウンチャートはチームのベロシティを元に、顧客の要望リストをどれぐらいの速さで焼き尽くすことができるかを予測する。

アジャイルなプログラミング

問答無用で実践するべき、アジャイルなソフトウェアエンジニアリングのプラクティス。

  • ユニットテスト
  • リファクタリング
  • テスト駆動開発(TDD)
  • 継続的インテグレーション

ユニットテスト:ビルドしたコードがちゃんと動くことを示す技法。
リファクタリング:コードをシンプルでクリーンな状態に保ち、読みやすくするための技術。
テスト駆動開発:複雑さに立ち向かうための設計技法。
継続的インテグレーション:決まった間隔で全てを統合し、プロダクトをリリース可能な状態を保ち続ける取り組み。

ビルド、インテグレーション、デプロイといった一連の作業を日常茶飯事にする。
1行目のコードを書いたその瞬間から、プロジェクトのコードは本番環境に置かれているかのように扱う。

スクラムとは何か

スクラムとは?

アジャイル型開発手法の1つ。
複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価
値の高いプロダクトを生産的かつ創造的に届けるためのもの。

他にもXP(エクストリームプログラミング)、かんばんなどがある。

スクラム用語集

プロダクトオーナー

顧客と同じ。
開発するプロダクトにおける責任者。そのプロダクトが実現するビジネス価値に対して責任を負う。

スクラムマスター

スクラムチームがスクラムの価値を理解しプロセスを正しく実践できることに責任を負う。
スクラムの推進者。

ステークホルダー

経営者・経営陣・他部署などの、プロダクトに対して利害関係を持つスクラムチーム以外の人を指す。

プロダクトバックログ

プロダクトを作成するにあたっての実現したい要求事項を優先順位を付けて並べたリスト。
スクラムではリストの上から順番に終わらせていく。

プロダクトオーナーが内容と優先順位付けに責任をもつ。

スプリントバックログ

スプリント期間内で実施すると判断したプロダクトバックログの項目と、それらを分析し具体的なタスクに落とし込んだもの。

スプリント

イテレーションと同じ。
開発期間の単位のこと。
多くのスクラムチームでは1週間〜4週間の期間のいずれかを採用する。

この期間内に開発チームは要求事項を「完成」させ、動作するリリース判断可能なインクリメントを作る。

スプリントプランニング

スプリント開始時にプロダクトバックログの上位からどの項目を実現するか、 選択された項目をどうやって達成するかをの2点を明らかにするミーティング。
各タスクの見積もりを行い、これまでのベロシティを元にスプリントの合計ポイントを決める。

デイリースクラム

朝会。
1日に1回15分以内でやり、進捗や予定、問題の共有を行うミーティング。
昨日やったこと、今日やること、困っていることを話す。

スプリントレビュー

スプリントの成果物をデモし、フィードバックを得る。 必要があれば今後のスプリントの進め方について話しあい、プロダクトバックログを調整する。

スプリントレトロスペクティブ

スクラムチームが自分たちの現状を見直し、次回以降の仕事の進め方を改善するためのミーティング。
良かったこと、困ったこと、改善策の三種類の項目を挙げていき、それについて話し合う。

インクリメント

完成の定義を満たしており、リリースしようと思えばリリースできるプロダクトのこと。

スクラムの流れ

  1. スプリントプランニングで開発する項目を選択。
  2. スプリントを行う(1〜4週間)
  3. 毎日デイリースクラム
  4. スプリントレビューでデモを実施しフィードバックを得る。
  5. スプリントレトロスペクティブで振り返り。

最後に

下の記事が面白いのでぜひ。
ミルクボーイがアジャイルを説明したら