Published on

アジャイルとスクラム

Authors
  • avatar
    Name
    Kikusan
    Twitter

アジャイル概要

マニフェスト

#既存のよりも⇒
1.プロセスやツール個々と対話⇒ チームワーク強化、モチベーション上昇
2.包括的なドキュメント動作するソフトウェア⇒ 納品が可能
3.契約交渉顧客とのコラボレーション⇒ 顧客との継続的なコラボレーション
4.計画に従順変更への対応⇒ 変更のコスト削減

12の原則

#原則原文
1.動く製品による顧客満足Customer satisfaction by early and continous delivery of valuable software.
2.変更を好むWelcome changing requirements, even in late development.
3.頻繁な動く製品の納品Deliver working software frequently (weeks rather than months).
4.動く製品こそ至高Working software is the primary measure of progress.
5.技術革新についていくContinuous attention to technical excellence and good design.
6.使わない機能は作らないSimplicity - the art of maximizing the amount of work not done - is essential.
7.ビジネス側と開発者の共創Close, daily cooperation between business people and developer.
8.チームで互いに鼓舞しあうProjects are built around motivated individuals, who should be trusted.
9.100読は一会にしかずFace-to-face conversation is the best form of communication (co-location).
10.持続可能なソフトウェアSustainable development, able to maintain a constant pace.
11.自分で動くチームであれBest architectures, requirements, and designs emerge from self-organizing teams.
12.PDCAを回せRegularly, the team reflects on how to become more effective, and adjusts accordingly.

メリット

  1. 要件ベースではなく、リソースベースで動く ⇒ 投資収益率
  2. 仕様変更ができる
  3. ドキュメントは必要に応じて
  4. 定期的なミーティングで情報共有
  5. デモで見せる
  6. 顧客エンゲージメントの維持

ただし、見積はしづらいのは留意しなければならないし、してもらわなければならない

フレームワーク

スクラム

軽量アジャイルフレームワーク。

  1. プロダクト・バックログ：要件定義・細分化
  2. スプリント・プランニング：リソース（人・時間の配分）
  3. スプリント・バックログ：１スプリント内でできることまとめ
  4. スプリント：1-4週 デイリースクラムでMTGなど
  5. インクリメント：リリースできる製品を作る
  6. スプリント・レビュー：ステークホルダーからのレビュー
  7. スプリント・レトロスペクティブ：反省会

スクラムのルールはスクラムガイドに記されている。

以下の特徴がある。

  • 要求を価値やリスクや必要性を基準にして並べ替えて、その順にプロダクトをつくることで成果を最大化する。
  • タイムボックス(固定の時間)に区切って作業を進める。
  • 透明性 : 現状や問題点を常に可視化する。
  • 検査 : 定期的にプロダクトが成果が見込まれるか、仕事の進め方に問題がないか確認する。
  • 適応 : 検査で問題があればやり方そのものを変える。
  • ５つのイベント, 3つのロール, ３つの作成物で構成されている。

リーン

7つの原則と22の思考ツールからなる概念。

  • 原則1：ムダをなくす
  • 原則2：品質を作り込む
  • 原則3：知識を作り出す
  • 原則4：決定を遅らせる
  • 原則5：速く提供する
  • 原則6：人を尊重する
  • 原則7：全体を最適化する

カンバン

TODO DOING DONE を分けて管理する手法。

XP

小規模チームに適したフレームワーク。

  • チーム全体で計画
  • コーディング規約統一
  • ペアプログラミング
  • 頻繁なリファクタリングによるソース設計からの効率化
  • シンプルなデザイン
  • 小規模リリース

HybridAgile

要件定義とシステムテスト・リリースだけ残し、それ以外をアジャイルで行う。

フレームワークはプロジェクトに１個ではなく、組み合わさる。

スクラムの実行

３つのロール

スクラムチームの中には3つのロールがある。

  1. プロダクトオーナー
    • プロダクトの価値を最大化する。
    • プロダクトバックログの管理者兼責任者であり、並び順に最終決定権を持つ。
    • 予算・リリース計画を管理する。
    • ステークホルダー折衝を担当する。
  2. 開発チーム
    • プロダクトバックログの項目を順番に開発していく。
    • 3-9人が適切な規模。
    • 機能横断的チーム : 要求分析・設計・コーディング・テスト・ドキュメントなどの能力はメンバが揃えば揃う。
  3. スクラムマスター
    • スクラムフレームワークがうまく回ることだけに尽力する。
    • 教育・ファシリテーター・コーチ
    • マネージャーではなく、アサインも進捗管理もしない。

プロダクト・ビジョン

  • 目標をWikiにまとめる。要件定義にあたる。

プロダクト・ロードマップ

  • ビジョンをガントチャートに盛り込む。要件定義にあたる。

プロダクトバックログ

実現したいことリスト。実現されたときの価値、リスク、必要性によって並べ替える。
上位のものから開発する。
書き方に決まりはない。機能一覧でもいい。が、ユーザーストーリーで書かれることが多い。

  1. ペルソナを作成（どんな人が機能の対象か）
  2. mock : プロトタイプイメージを統一する
  3. このときアーキテクチャ設計をする
  4. ユーザストーリーを作成する
    • 「ペルソナが～をできる」を要件とする
    • 受け入れ基準を定め、記載する（テストまで）
      ユニットテストカバレッジ？静的解析？受入テスト？ドキュメントがある？
    • ストーリーは以下を守る。
      1. Independent：どのストーリーも相互に順番がない
      2. Negotiable：ストーリーの詳細は共創で決める
      3. Valuable：その機能がユーザに価値がある
      4. Estimate：プログラマーが見積できる
      5. Small：実装時間は数日。イテレーションで複数のストーリーを完成させる。
      6. Testable：ストーリーが正しく機能することを確認するためのテストを書く。
    • ストーリーポイントを記載する。1,2,3,5,8,13. 8が0.5人月
    • 常にメンテナンスして最新に保つ。(プロダクトバックログリファインメント)
      • スプリントで扱えるサイズに分割する。
    • 上位の項目は見積り（ストーリーポイント・受け入れ基準）を済ませておく、定期的に見積り直す。

リリース・プランニング

  1. アイテムの見積・優先順位をつける。
  2. チームの速度（ポイント）を範囲として推定する。
  3. リリースに含まれるスプリントの数を決定する。

※見積はチームが慣れてくるとスプリントのポイントが安定してくる。
ポイントは1,2,3,5,8,13でつけて、8が0.5人月。
話し合いで決めるか、信頼のある人がチームの速度を鑑みて決める。

スプリント・プランニング

各スプリントの冒頭で行う。スクラムチーム全員が参加する。
スプリントで何を達成するか(スプリントゴール)を簡潔に決める。
達成するプロダクトバックログ項目を決める。

  1. バックログを整理
  2. ユーザストーリーを確認
  3. 進行度合いを確認
  4. スプリント計画を会議する(PBR)
    • ユーザストーリーに新しい情報がないか
    • チームの能力と速度はポイントにあっているか
    • バックログを確認し、タスクをアサインする

スプリント・バックログ

選択したプロダクトバックログ項目と必要に応じて細分化された実行計画のこと。

  • プロダクトバックログを具体的な作業に分割する。
  • 1タスクは1日以内で終わるサイズ。

スプリント

製造期間。この中でスプリントプランニングで決めたプロダクトバックログ項目を完成させる。 一か月未満の固定長で繰り返す。長さが変わってはいけない。
計画されたものをすべて必ず満たすことは保証しない。成果物(インクリメント)が動作することは保証する。

カンバンやXPに従い作業・進行管理するといい。
※ストーリーをサブタスクに分けてカンバンに貼ってもよい。

デイリースクラム

開発チームは全員参加する。必要に応じて他のロールも。
毎日決まった時間で15分固定で開発チームが行う。

  • 昨日なにをしたか、今日はなにをするか、問題はあったかをメンバーで確認する。
  • 問題解決は必要な人が別の場で行う。

インクリメント

これまでのスプリントでの成果と今スプリントで完成したプロダクトバックログ項目を合わせたものを指す。
リリースするかどうかに関係なく動作して検査可能でなければならない。

スプリント・レビュー

プロダクトオーナー主催でインクリメントをレビューする。プロダクト・オーナーに見せる。
スクラムチーム全員が参加する。

  • 完了と未完了の報告
  • バックログを確認、修正：ユーザストーリーを満たしているか、追加機能はないか
  • フィードバックを得て、プロダクトバックログを見直す。
  • 全体の残作業や進捗をトラッキングする。
  • ステークホルダー（顧客等）に参加してもらう。

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

スクラムチーム全員が参加する。
うまくいったこと、改善点を整理する。

  • 何がうまくいった？
  • 問題点は？
  • TODOは？
  • 「仕事のやり方」をカイゼンする。
  • 今後のアクションプランを作る。
  • バグを直すのではなく、バグが生まれるプロセスを直す。

顧客が満足するまで、プロダクト・バックログに戻る。

実践編

  • 足りないスキルはチームで補う。人に入ってもらう。
  • ロールは兼任しても構わない。
    ただしプロダクトオーナーとスクラムマスターは兼任してはいけない。思惑が相反するから。
  • プロダクトバックログを作る前に、ミッションとゴール(目的と目標)は定めておく。
  • ミッションとゴールを決めるのに、インセプションデッキを利用するのもいい。
  • インセプションデッキテンプレートはココ
  • プロダクトバックログはスクラムチーム全員で洗い出す。MECEにするため。
    • 超重要・重要・普通・あればうれしいで並べる。
    • 並べ方はアピールする機能を上位にしてもいいし、開発の進行のためでもいい。
    • プロダクトバックログは見通しを良くする効果もある。
    • ストーリーポイントの見積りは開発チーム全員で行う。
      作業を把握できる項目を基準にして、後から見積りが難しいものを細分化していく。
  • １スプリントで終わらせられるポイント数をベロシティという。
    それによってスプリントプランニングとリリース計画が定まる。
  • リリース作業はスクラムとは分けて考えていい。プロジェクトとしての見積りには入れておくこと。
  • スプリントバックログは、タスクを実装するにあたって不明なことが何もない状態にしておくこと。
  • 早くタスクが終わったら、リファクタリングや次のプロダクトバックログをやる。
  • 時間がちょうどいいプロダクトバックログがなかったら、分割してもいい。※動作するインクリメントになることに注意。
  • 自分たちのルールを設ける。デイリースクラムに出られない場合の対処など。
  • 間に合わないときに調整するのは？品質？予算？期間？スコープ？
    正解はスコープ。プロダクトバックログ項目を削る。
  • 一つのプロダクトバックログ項目に複数メンバで取り組むことをスウォーミングという。
    属人化を防ぎ、手戻り時の工数短縮効果がある。

バッチを小さくするプラクティス

  • フィードバック(会話応答やデモ)サイクルを小さくする
  • フィードバックには都度対応する(次のイテレーション)
  • ビルドを高速化する（小さなビルドで確認できるようにする）
  • バックログを作る
    • バックログ：ストーリーの集合で、優先順位がある。
    • ストーリー：タスクの集合で、システムで観察可能な振る舞いである。
    • タスク：イテレーションで完結可能な作業である。

重要なのは、タスクには完成（受け入れ）基準があることである。

ソフトウェア開発を計測するプラクティス

チームの以下時間を計測し、改善することが生産性につながる。

  • 価値提供までの時間を計測する：価値提供のみ、価値がある。
  • コーディング（のみ）に使った時間を計測する：コーディング以外の時間が多くないか？
  • 欠陥密度（バグ/1000step）を計測する：多いと開発プロセスのどこかが悪い
  • 欠陥検出までの時間を計測する：なるべく早く
  • 機能ごとの顧客価値を計測する：価値が高いものから取り組む
  • 機能を提供しない場合のコストを計測する：多いと機能を作ったほうがいい
  • フィードバックループの効率を計測する：なるべくサイクルは小さく

ストーリーを分割するプラクティス

  • 複数のことが混じったストーリーをサブストーリーに分割する
  • 複雑なストーリーを既知のことと未知のことで分離する
  • 未知のことがわかるまで繰り返す（イテレーション）
  • 受け入れ基準をもとに分割する
  • ストーリー同士の依存関係を最小にする
  • １ストーリーの意図（価値）を１つにする
  • ストーリーをテスト可能に保つ

アジャイルインフラプラクティス

  • 全てをバージョン管理する
  • ワンクリックでテストまで走るビルド環境を構築する（ローカルもサーバーも）
  • 継続的に統合する（リリースとは別、最低１日１回）
  • タスクの受け入れ基準を定義する
  • テスト可能なコードを書く
  • 必要な場所のテストカバレッジ(網羅率)を維持する
  • 壊れたビルドはすぐ直す

ペアプログラミングプラクティス

  • やってみれば気に入る
  • ドライバーとナビゲーターが参加する
  • 役割を頻繁に交代する
  • すべてのやり方を試す
  • 詳細はチームで決める
  • 進捗を追跡する

レトロスペクティブプラクティス

  • 小さな改善を探す
  • プロセスを責めよ。人を責めるな。
  • なぜなぜ５回をやってみる（それはなぜ×5）
  • 根本原因に取り組む
  • 全員の意見を聞く
  • 人に権限を与える
  • 進捗をはかる

受け入れテストプラクティス

  • 作っているものが何に役立つのか明確にする
  • 誰がなんのために何をしたいのかを知る
  • 受け入れ基準を自動化する
  • エッジケース、例外、代替パス、を表す
  • 例示を使って詳細を具現化し、矛盾を一掃する。
  • 受け入れ基準と振る舞いの分離
  • 各テストを一意にする

ユニットテストのプラクティス

  • 呼び出し側の視点に立つ
  • テストを使ってふるまいを表す
  • 新しい違いを生み出すテストだけを書く（一意にする）
  • テストを使って、ふるまいを作る（例外テスト含む）
  • コードをリファクタリングする
  • テストをリファクタリングする（基本的にふるまいであれば変更は必要ない）

テストを仕様として使うためのプラクティス

  • テストを文書のように扱えるようになる
  • 意図が分かる命名をする
  • 何が重要なのかを明らかにする
  • 実装ではなくふるまいをテストする
  • モックを使ってワークフローをテストする
  • 書きすぎない
  • 正確な例を使う

バグを修正するプラクティス

  • そもそもバグを作らない
  • できるだけ早くバグを見つける
  • バグを見つけられるように設計する
  • 正しい質問（シナリオ）をする
  • バグをテストの不足とみなす
  • 欠陥をもとにプロセスを修正する
  • 失敗から学ぶ

設計のプラクティス

  • オブジェクト指向設計を理解する
  • デザインパターンを理解する
  • テスト駆動開発を理解する
  • リファクタリングを理解する
  • コードの品質にフォーカスする

クリーンコードプラクティス

  • コードに語らせる
  • テストを足すために接合部を作る
  • メソッドの凝集性を高める
  • クラスの凝集性を高める
  • ビジネスルールを抽出する（同じ処理は同じ場所に統一）
  • ポリモーフィズムを導入する
  • 生成をカプセル化する

リファクタリングプラクティス

  • 既存のシステムを学ぶ
  • 小さく改良する
  • レガシーコードをテストで改良する（テストOKならリファクタリング成功）
  • 常にリファクタリングに目を向ける
  • 詳細がわかったら実装を再設計する

いつリファクタリングを行うか

  • 重要なコードが保守されてないとき
  • コードを理解している人がいなくなったとき
  • 新しい情報によってより良い設計が見つかったとき
  • バグを修正するとき
  • 新機能を追加するとき
  • 作り直すより安いとき
Discuss on Twitter