Software in 30 days
「Software in 30 days」を読んだ感想を徒然と。
おもしろかった所
予測型プロセスの駄目な所
確かに計画なんて上手くいくはずがない。
それなのに長期的な計画を立ててやろうとするなんて。。。
スクラムチームが上手くいくために必要なこと
個人の尊重
開発チームに大きな裁量
エンジニアに裁量がある時が一番良いものが作れる！
詳細まで考えられていて「こういう風に作って！」
って言われたものはだいたいもっと簡単にできたり、
実際に作った後に「違う」って言われたりするなぁ。
スクラムチームの作り方
召集兵より志願兵であること
チームメンバーを惹きつけるメッセージを作る
メンバーの入れ替えとか自発性とかを重視している本だなぁ。
チームメンバーを惹きつけるメッセージとか、
スクラムを導入しているチームに採用する時に使えるし、
考えてみようかな。
ロール毎の役割
- プロダクトオーナー
バックログを明確に表現できる
作業の価値を保証できる
優先順位をつけれる
- 開発者
肩書はない
自己組織化されている
チーム全体で責任を持つ
- スクラムマスター
効果的なプロダクトバックログの管理方法を探す
プロダクトバックログを明確に説明できる
長期のプロダクト計画を理解している
おー。なかなかスクラムマスターとしてやっている！
良かったｗ
ちょろっと時間ができた時とかに
よくホワイトボードのタスクとか貼り直してみたり、
プロダクトバックログをどういう風にスクラムチーム用にするかとか、
しょっちゅうやってるなーと。
まだまだできてないことも多いしがんばろう！
プロジェクトの中止
- 損失を限定し、機会を浪費しない価値もある。
ほんとこれがわかっていないプロジェクトが多い気がする。
ダメだってわかったらその時点で一旦破棄するべきだろう。
モチベーション
上がる時：仕事を自ら管理できている時
下がる時：もっと働けというプレッシャーがある時
結局、裁量が多ければそれだけモチベーションは上がるかなー。
まとめ
よくあるスクラム本と違って、
モチベーションのこと、チームづくり、スクラムの組織への導入について
とかがおもしろかったな。
「文化に合わせてスクラムを変えるのではなく、上手くやるために文化を変える」
とか、すごく大変そうだけど、必要なことだなと。
１時間で読めたし、オススメです！
