March 2021
Beginner to intermediate
288 pages
5h 8m
Japanese
| ギル・ブローザ | ![]() |
デイリースクラムが進ちょく会議のように感じられないだろうか?
マネージャーやステークホルダーは、プロダクトバックログをプロジェクト計画のように扱っていないだろうか?
スクラムマスターがタスクを管理したりプロセスを守ることを約束したりしていないだろうか?
答えが全部イエスなら、あなたのスクラムで起こっている、ほかの症状を当てて見せよう。チームでレトロスペクティブをしてもあまり改善されず、メンバーは協力しあっておらず、ちゃんとした「完成」の定義も共有していないはずだ。あなたが開発チームなら、自動テストのカバレッジは低く、表面的にしかリファクタリングしておらず(ほとんどしていないかもしれない)、本番環境へのデプロイにはたくさんの計画と注意が必要なはずだ。プラクティスには従っているように見えるものの、アジリティは感じられない。どうしてだろうか?
状況を理解するには、なぜスクラムチームが特定のプラクティス、ミーティング、役割、作成物を用いるのかを知る必要がある。まずは、これらの戦術が効果的に使われているときには、どんな原則が作用しているのか見てみよう。
デイリースクラムについて考えてみよう。アジャイルの観点では、デイリースクラムは、チームメンバーが重要な作業を終わらせるためにお互いに協力しあって自己組織化している場合に、いちばん効果が出る。透明性を保ち、すべてのことに誠実に参加できるような心理的安全性を感じられるからだ。
プロダクトバックログは価値がありそうな作業のリストで、順番に並んでいる。そのとおりに使えば、この ...
Read now
Unlock full access