Definition of Done

Transcript

1. はじめてのことは不安
2. アジャイルとスクラムの歴史、なぜスクラムか？ クリストファー・ コロンブス コロンブス自身は平気なふりをしていた が、計算を越えて長い航海となったこと に不安を感じるようになる。10月6日に は小規模な暴動が起こり、3日後には船 員の不安は頂点に達し、コロンブスに 迫って「あと3日で陸地が見つからな かったら引き返す」と約束させた。その 後、流木などを発見し陸が近くにあると 船員を説得する。 Wikipedia 「クリストファー・コロンブス」より
3. はじめてのことは、不安。 ゴールも見えない。 このまま進めていて いいのかなぁ？
5. 西回りでインド を目指してた人
6. 実際に起きたこと = 新大陸発見
7. 近いところは予測しやすい。 遠い未来は予測が難しい。 間違っていたのは予測のほう。
8. はじめてのことで 過少評価も過剰評価も することなく、 正確な見積もりができる という人は、 たぶん経験不足か、 ウソつきかのどちらかだ
9. やってみることもなく 失敗することもなく 新しいことを学ぶことは できない。 同じ研修の課題でも、 毎年異なる人、チーム、 異なる環境で行っている。
10. なので、 現地・現物・現場。 仮説を立てて実験し、 観察から学び、 言語化して議論し、 一つ一つうまくなる 必要がある。
11. マクロ (巨視的) な 視点ではまだまだ先 が長いと感じる。想 定より遅れていると 感じるかもしれない。
12. ミクロ(微視的)な視点 では着実に進んでいる。
13. https://en.wikipedia.org/wiki/Cynefin_framework 複雑 煩雑 明確 混沌 混乱 促進する制約 疎結合 統制する制約 密結合 制約の欠如 結合なし 厳格に制約される 自由度なし 探査-感知-対応 創発的プラクティス 感知-分析-対応 グッドプラクティス 行動-感知-対応 斬新なプラクティス 感知-分類-対応 ベストプラクティス クネビンフレームワーク
14. ちゃんと解けば明確にゴールへの ルートが分かるのが 煩雑(Complicated)。 やってみないとわからないのが 複雑 (Complex)。 煩雑(Complicated)。 複雑 (Complex)
15. １ステップの完了に ちゃんと着目しよう。 完成の定義 Definition of Done
16. 進捗が人を前向きにする
17. https://www.youtube.com/watch?v=-PViKTC9WLY&t=416s テレサ・アマビール さんの本の話
18. インナーワークライフ （個人的職務体験） やりがいのある仕事が進捗すること マネジャーたちは、多くのビジネス本が 喧伝するような、「評価」や、「具体的 なインセンティブ」や、「明確な目標」 といった手段を好んでいた。(中略) いかなるマネジャーの職務記述書も、 まず「毎日部下たちの進捗を 手助けすること」を記すべきだ。 “ ” https://www.amazon.co.jp/ dp/4862762409/ 進捗の法則 従業員の 日誌を調査
19. 自己効力感 人はよく「これは仕事だ。パーソナルな ことではない」と言う。しかし仕事こそ パーソナルなものである。特にキャリア 形成に向けて何年も教育に投資してきた 専門職の人間たちは、自分の仕事と自分 のアイデンティティを重ね合わせている。 “ ” https://www.amazon.co.jp/ dp/4862762409/ 自己効力感 - 自分には望む目標を達成す るために求められる作業をプランニング し実行する能力があるという信念だ。 “ ”
20. 障害と感情 研究では、個人的に重要な目標の達成を目 指す際に障害に出くわすと(重要でない目 標を目指すときと比べて)被験者はより自 分のことに意識が集中し、それらの障害に 思いを巡らす時間が増えるという。自分の ことに集中しすぎると気分の落ち込みに繋 がることが多いため、こうした研究結果は、 個人のアイデンティティや自尊心にとって 重要な目標と実際の成果の間に食い違いが あると、健全な感情が短期的に傷つけられ る可能性があることを示唆している。 “ https://www.amazon.co.jp/ dp/4862762409/ ”
21. 進捗は 動機付け 個人的に意義のある目標へ向けて前進した とき、あるいはその目標が達成されたとき、 期待と現実が噛み合って人は気分が良くな り、自己効力感がポジティブなものになり、 次の仕事により張り切って取り組むように なり、心も次の物事に移っていける。 進捗は難しい挑戦をためらいなく受け 入れ、より持続的に取り組んでいくよ う人を動機づけするものだ。 “ https://www.amazon.co.jp/ dp/4862762409/ ”
22. 透明性・検査・適応
23. スクラムの3つの柱（透明性・検査・適応） 透明性 検査 適応
24. スクラムの3つの柱（透明性・検査・適応） 透明性 創発的なプロセスや作業は、作業を実⾏する⼈とその作 業を受け取る⼈に⾒える必要がある。スクラムにおける 重要な意思決定は、3 つの正式な作成物を認知する状態 に基づいている。透明性の低い作成物は、価値を低下さ せ、リスクを⾼める意思決定につながる可能性がある。 透明性によって検査が可能になる。透明性のない検査は、 誤解を招き、ムダなものである。 スクラムガイド (2020) より スクラムガイド(2020)
25. スクラムの3つの柱（透明性・検査・適応） 検査 スクラムの作成物と合意されたゴールに向けた進捗状況は、頻繁 かつ熱⼼に検査されなければならない。これは、潜在的に望まし くない変化や問題を検知するためである。スクラムでは、検査を ⽀援するために、5 つのイベントでリズムを提供している。 検査によって適応が可能になる。適応のない検査は意味がないと される。スクラムのイベントは、変化を引き起こすように設計さ れている。 スクラムガイド (2020) より 適応 プロセスのいずれかの側⾯が許容範囲を逸脱していたり、成果と なるプロダクトが受け⼊れられなかったりしたときは、適⽤して いるプロセスや製造している構成要素を調整する必要がある。そ れ以上の逸脱を最⼩限に抑えるため、できるだけ早く調整しなけ ればならない。 関係者に権限が与えられていないときや、⾃⼰管理されていない ときは、適応が難しくなる。 スクラムチームは検査によって新しいことを学んだ瞬間に適応す ることが期待されている。 スクラムガイド (2020) より スクラムガイド(2020)
26. プロダクトバックログ 開発者(たち)
27. プロダクトバックログ 優先順位付けされた 機能リスト。 開発者たちが見積もる。 納期は決められない。
28. 自己組織的に働く人々。 優先順位に合わせて 出荷判断可能な プロダクトの増分を 生み出していく。 開発者(たち)
29. プロダクトバックログ 動作する プロダクト (の増分) 上から順に 生み出していく
30. 動作する プロダクト (の増分) 上から順に 生み出していく 価値があるか どうかがわかる プロダクトバックログ
31. 安定したチーム 決まった期間 仕掛を作らない 継続的にリリース
32. これはいつ できますか？
33. これはいつ できますか？ たぶん３スプリント目
34. 動作する プロダクト (の増分) 上から順に 生み出していく 価値があるか どうかがわかる プロダクトバックログ
35. 完成の定義
36. 完成の定義(Definition of Done) ✓ 完成の定義：プロダクトの品質基準を満たす インクリメントの状態を示した正式な記述 (チェックリスト) ✓ 目的：「完成」に対する共通認識の確立と透明性の向上 ✓ 適用範囲：プロダクトバックログアイテム（PBI）が インクリメントの一部となる条件 スクラムにおける位置づけ ✓ インクリメントの確約（コミットメント）： 3つの作成物の確約の一つ ✓ 品質の基準：スクラムチームが遵守すべき最低品質ライン ✓ 透明性の源泉：作業完了の客観的判断基準
37. 完成の定義(Definition of Done)の作成 ステップ1：現状の棚卸し ✓ 既存プロセスの確認：現在の品質管理活動の洗い出し ✓ 暗黙知の明文化：チームが無意識に行っている品質活動の可視化 ✓ ツールとプラクティスの整理：使用中のツールと手法の一覧化 ステップ2：ステークホルダーとの協議 ✓ 期待品質レベルの確認：プロダクトオーナーや顧客の品質要求 ✓ 組織標準との整合：会社全体の品質基準との調整 ✓ 規制要件の確認：業界標準や法的要件の考慮 ステップ3：初期版の策定 ✓ 実現可能性の考慮：現在のチーム能力で達成可能なレベル ✓ 測定可能性の確保：客観的に判断できる具体的基準 ✓ 段階的改善の余地：将来の改善に向けた発展性
38. 完成の定義(Definition of Done)の継続的更新 定期的見直し ✓ スプリントレトロスペクティブでの評価： DoDの効果と課題の確認 ✓ 四半期ごとの大幅見直し：技術進歩や要求変化への対応 ✓ チーム成熟度に応じた強化：段階的な品質基準の向上 フィードバックループ ✓ 品質メトリクスの活用： バグ率、カスタマー満足度等の定量評価 ✓ チーム内議論の促進： DoD改善に関する積極的な意見交換 ✓ 他チームとの知識共有：ベストプラクティスの水平展開
39. 完成の定義(Definition of Done)の例 : 開発プロセス関連 コード品質 コードレビューが完了し、 2名以上の承認を得ている 静的解析ツールでの警告がゼロである コーディング規約に100%準拠している 複雑度指標が基準値以下である 重複コード率が5%以下である テスト要件 単体テストカバレッジが90%以上である 統合テストがすべて成功している 受け入れテストがすべて成功している 負荷テストが基準値をクリアしている セキュリティテストで 脆弱性が検出されていない ドキュメント要件 API仕様書が最新状態に更新されている ユーザーマニュアルが作成・更新されている 運用手順書が整備されている 設計書が実装と整合している リリースノートが作成されている
40. 完成の定義(Definition of Done)の例 : プロダクト品質関連 機能要件 すべての受け入れ基準を満たしている プロダクトオーナーの承認を得ている ユーザビリティテストで 満足度80%以上を達成 アクセシビリティ基準 （WCAG 2.1 AA）に準拠 多言語対応が完了している 非機能要件 レスポンス時間が要求基準以下である 可用性が99.9%以上である データバックアップが正常に動作している モニタリングとアラートが設定されている 災害復旧手順が検証済みである
41. 完成の定義(Definition of Done)の例 : リリース準備関連 デプロイメント ステージング環境での動作確認が完了している 本番環境へのデプロイ手順が確認済みである ロールバック手順が準備・検証済みである データ移行スクリプトが検証済みである 環境設定ファイルが本番用に更新されている 運用準備 監視ツールに新機能が登録されている 運用チームへの引き継ぎが完了している サポートチームの準備が完了している 緊急時対応手順が整備されている 性能基準値が設定・監視対象に追加されている
42. 完成の定義(Definition of Done): よくある課題 過度に高い基準設定 ✓ 問題：理想を追求しすぎて実現不可能な基準を設定 ✓ 対策：現在の能力を基準とした段階的改善アプローチ ✓ 解決策：「今すぐ実現可能」から 「3ヶ月後の目標」への段階設定 チーム間の基準ばらつき ✓ 問題：チームごとに異なる基準で混乱が発生 ✓ 対策：組織レベルでの最低基準設定と定期的な調整会議 ✓ 解決策：コミュニティオブプラクティスでの知識共有
43. 完成の定義(Definition of Done): よくある課題 形骸化の防止 ✓ 問題：チェックリストの機械的実施で本来の目的を見失う ✓ 対策：定期的な目的確認とDoDの価値に関する議論 ✓ 解決策：品質メトリクスによる効果測定と改善活動 技術進歩への対応 ✓ 問題：新技術導入時のDoD更新遅れ ✓ 対策：四半期ごとの技術動向確認と基準見直し ✓ 解決策：技術調査専任者の設置と定期的な基準更新
44. 完成の定義(Definition of Done): スクラムマスターの役割 DoD策定支援 ✓ ワークショップの企画： チーム全体でのDoD策定セッション ✓ ステークホルダー調整： PO、開発者、組織間の合意形成支援 ✓ 継続的改善の促進：レトロスペクティブでのDoD改善議論 品質文化の醸成 ✓ 品質意識の向上：DoD遵守の重要性に関する継続的な啓蒙 ✓ ベストプラクティス共有：他チームの成功事例の紹介 ✓ メトリクス活用支援：品質指標の可視化とチームでの活用