Some Days You Get the Bear

IT系エンジニアの、日々の気づきや考えたこと。

「スクラムマスター研修はいいぞ」!

qiita.com
すごくよい! 良記事です!
付いてるリンクもいいです。

こういうこと、
コンパクトにまとめて明文化されているようで、なかなかなくて
(こういう研修を受けないと聞けないのかと思うくらい)。
そして、こういうことをもっとみんなに知ってほしいと思います!
 

開発チームは「自己組織化されたチーム」を目指す
そもそも「自己組織化された状態」というものがなんなのか、開発チームが深く理解する必要がある。
(中略)
 ・「自己組織化された状態」を目指すモノだと開発チームが理解している必要がある。
  ・自己組織化されていない状態では、「指示待ち」「責任分担」が多発し、
   アジャイルが生まれた前の状態に戻ってしまう。
 ・「チームの責任範囲ではない」という表現が出てきたらおかしい。
  ・「自己組織化されたチーム」なのであれば、自己が管轄する責任範囲すら定義し直せるはず。
   プロダクトの成功のために必要なことをなすべきである。
(中略)
 ・とは言え、「人事制度上の問題」など、
   「開発チーム」よりも「組織長」などが動いた方が課題解消に効率的な問題があるのは事実。

個人の専門性を高める工夫
(中略)
 ・社内にこだわる必要はない
 ・なるべく広いコミュニティに関わる方が新しい知見を得られる

そう。もっと社外に出ようよ!

進捗の評価
WBSは作らない。あくまで「動くソフトウェア」だけが進捗たり得る。
これによって得られる効果
 過度な未来予知作業を避けられる
実現のために注意スべきこと
 ・スプリントレビューの結果「Doneに辿り着けなかった」としても過度に悲しむ必要はない
  ・そこから得られた知見が重要なケースの方が多い
   (「プロダクトの成功」よりも「チームの成長」に価値を置くを忘れずに)
 ・「進捗しない状態がずっと続いている」のなら「組織的な課題がある」ということを推測すべきである

既存のシステム評価手法とのコンフリクト
(中略)
・進捗
 ・既存:WBSでの定量評価
  ・「タスクが消化されているかどうか」であって、
   「システムがどれくらい作られているか」ではない。
 ・スクラム:システムがどれくらいインクリメントされているか?
  ・実質「エンドユーザーにどれだけ価値を提供できているか?」が指標となり、より本質的である。

さいごに
スクラムマスター研修はいいぞ」