アジャイル開発の導入に向けた備忘録

SCRUM BOOT CAMP THE BOOK

アジャイルサムライ――達人開発者への道

SCRUM BOOT CAMP と アジャイルサムライ

このブログも勉強したことの纏めサイト的なものになってしまってきているので、体験談や自分の考えも纏められるようにしていきたいですね、、、。今回はアジャイル開発手法の1つであるSCRUMについて計画,実施,振り返りを行う機会があったので、新しいインプットとしてSCRUM BOOT CAMPとアジャイルサムライを読んでみました。過去に独自色の強いアジャイルを試したことはありましたが、コミュニケーション時間の増加および課題の明確化ができるたものの、アジャイルの学習や進行に費やした時間に対するプロダクト成果まで結びつかず途中で挫折しました。その経験からチームビルドを半ば諦めて個人の力で打開する雰囲気作りをしていた節があったので、これを機にもう一度教科書を読んでから考え直してから実践したいと思います。掲載している内容は自分の言葉で置き換えておりますのでご注意ください。

SCRUM BOOT CAMP

• 事前に全てを予測するのは不可能。そこから計画することはできない。 という事が前提。
• 要求の分析や設計には時間をかけず、重要なものやリスクが高いものから先に作る。
• 要求の実現順、問題点を明確化、もっと良いやり方の適応などを意識する事。
• 開発チームの規模は3〜9人ぐらいがベスト。
• スプリントは短くて1週間、長ければ4週間。週単位で区切る場合が多い。
• スプリントにおいて開発する量は過去の実績値(velocity)を元に予測。
• スプリント計画で合意した内容に全力を尽くすが、完了を約束するわけではない。
• スプリント単位でリリース判断可能なプロダクトが求められる。完了の定義を事前に明確化し、途中での削除は避ける。
• スプリント内では毎日の状況確認。
• スプリント内で出来上がった動作するプロダクトを確認する。スプリントレビューはプロダクトオーナーに対してデモを披露する。
• スプリントの最後に振り返り(スプリントレトロスペクティブ)を行い、もっと成果を出すためのプランを出す。
• プロダクトオーナーとスクラムマスターの兼任は避けたほうが良い。プロダクトオーナーは製品を良くすることを考え、スクラムマスターは開発を円滑に進める。
• プロダクトバックログのためにインセプションデッキを作成する。インセプションデッキのテンプレートは以下にある。
  • https://github.com/agile-samurai-ja/support/tree/master/blank-inception-deck
• プロダクトバックログは全員が必ず理解する。
• プロダクトバックログの工数や予算は実際に作業する担当者が見積もる。見積のズレは必ず発生するので、時間をかけずに行う。基準となる作業を見つけて相対的な見積をする。当てずっぽうの見積の中でベストを尽くす。
• スプリント内で実現しようとするプロダクトバックログの量が多いと大変で良くない傾向なので、確実に終わらせる事ができる項目数を定義する。
• デイリースクラムが単純な進捗報告会とならないように、問題を見つけるように工夫する。問題が出てきたらデイリースクラムの後に関係者で集まって対応を考える。
• スプリントレビューではデモを目で見て、本当はどうすべきかを確認する。デモと完了の定義を比較して終わっているかも合わせて確認する。完了の定義はチーム内で合意をしていないといけない。
• 問題に対しては個人でなんとかしようとしがちなので、チーム全員で対応すべき。
• タスクボードを使ってTodo,Doing,Doneを分かりやすくする。
• バーンダウンチャートを使って縦軸に見積もり時間の合計、横軸に営業日を記録し、最終日が0になるような折れ線グラフを作る。これが理想線となり、実際のタスクの実行時間をプロットして理想線と比較する。
• スプリントを旨く回すために自分たちでルールを決めても良い。
• velocityに求められのは安定性。安定していないvelocityは予測に使えない。velocityを上げていくことだけを意識していくと悪影響がでる。
• みんなをサポートしてプロジェクトの目的を達成していくのがスクラムマスターの仕事、サーヴァントリーダシップと呼ばれる。またスクラムマスターはあらゆる妨害を見つけて取り除く。
• 良いスクラムマスターだと妨害リストに50個以上項目を管理している。妨害リストはチームが見えるところに貼っておくと良い。
• プロダクトバックログは日々更新されるべきで、いろいろな意見が集まるように誰でも更新できるようにしておくと良い。プロダクトバックログを観て削除できるものは優先度を下げたり諦めるなどをする。
• 開発メンバーのプロジェクトを進めるスキルがあるかどうかを判断するためにスキルマップを書いてみると良い。開発メンバーの性格や得意/不得意を知った上で各メンバーとこれまでどんなプロジェクトにいたか、仕事で重要視すること、期待されていることは何かを話し合っておくことも重要。
• 失敗を重ねて学んで行く。成長しないスクラムチームではプロジェクトがうまくいかない。失敗を繰り返さないように学んでいく。
• 通常のスプリントの後でリリースの前にリリーススプリントをやることも初期のスクラムチームでは採用される。リリースに必要なことを片付けるための期間。

アジャイルサムライ

• チームの持てる力を最大限に出すことでプロジェクトの成功確率を向上させる。
• 本当に価値があるものに対して集中し、余分なものは捨てて身軽になる。
• アジャイル開発は気弱な人には合わず、隠すことが無い、質の高い仕事へ情熱を持つこと、価値を生み出すことを期待するのであるならアジャイルを採用することによって得ることは多い。
• プロジェクトの3つの真実。1.プロジェクトのスタートでは全ての要求を決めれない、2. 要求はどれも変わる、3. やる内容は時間と資金より常に多い。
• チームを縦割り組織にしないで、役割分担を区別しない、継続的な開発、チームで責任を果たそうとする態度の3つが大事。
• ビジネスを理解しているプロダクトオーナーと開発者は日々一緒に働かなければならない。
• 人に合わせて役割を決めることがチームビルディングのコツ。
• 自分たちで計画を立てることで当事者意識を持たせる。
• “最良のアーキテクチャ・要求・設計は，自己組織的なチームから生み出される”
• 良い組織状態はアジャイルプロジェクトマネージャーが1週間いなくても業務に支障がでないこと。
• 我々は何故ここにいるのか、司令官は何を考えているのかを把握する。
• リスクを全て洗い出す。リスクを分類して解決に取り組む価値のあるリスクを取り除く働きをする。
• 時間と予算は有限、品質は高いものでないといけない、やるべきことが際限ないという4つのフォースがプロジェクトを支配している。
• 文書に頼らず顔を合わせて話してすこともアジャイル開発の原則。
• 良いユーザーストーリの6つの要素。1. 独立(Independent)、2.交渉可能(Negotiable)、3.価値ある(Valuable)、4.見積もり可能(Estimatable)、5.小さい(Small)、6.テスト可能(Testable)。これらの頭文字でINVESTと呼ばれる。
• プロジェクト初期段階での概算見積もりは最大4倍ほどの差があると思っておくこと。
• 人は相対見積もりだとうまくいく。絶対見積だと難しい。仕事の大きさを相対的な数値として捉えられることが重要。大きさを小、中、大の3つに分類し、それぞれ1pt、3pt、5ptなどのように定義する。基準となるストーリーを１つずつ決め、残りのストーリーはそれと同じ基準で当てはめて考える。
• 見積もりを行うときにプランニングポーカーを利用しても良い。チームメンバーの意見を聞く事が可能。
• アジャイルでは計画の見直しとしてリリース期日を延ばすことよりスコープを柔軟に対応することのほうが多い。
• team velocity = 完了したストーリー数 / イテレーション数が通常の計算だが、実際の現場では以下のようになる。team velocity = 完了させたスローリーポイント数 / イテレーション数。
• バーンダウンチャートとバーンアップチャートのどちらかを採用して見える形でプロジェクトへの期待をマネジメントする。
• プロジェクトの途中からアジャイルを導入することも可能。