読者です 読者をやめる 読者になる 読者になる

とあるエンジニア系ライダーの日常

Webエンジニアの話、バイクの話

Software in 30 days

「Software in 30 days」を読んだ感想を徒然と。

おもしろかった所

予測型プロセスの駄目な所

確かに計画なんて上手くいくはずがない。

それなのに長期的な計画を立ててやろうとするなんて。。。

スクラムチームが上手くいくために必要なこと
  • 個人の尊重

  • 開発チームに大きな裁量

エンジニアに裁量がある時が一番良いものが作れる!

詳細まで考えられていて「こういう風に作って!」

って言われたものはだいたいもっと簡単にできたり、

実際に作った後に「違う」って言われたりするなぁ。

スクラムチームの作り方
  • 召集兵より志願兵であること

  • チームメンバーを惹きつけるメッセージを作る

メンバーの入れ替えとか自発性とかを重視している本だなぁ。

チームメンバーを惹きつけるメッセージとか、

スクラムを導入しているチームに採用する時に使えるし、

考えてみようかな。

ロール毎の役割
  • プロダクトオーナー

バックログを明確に表現できる

作業の価値を保証できる

優先順位をつけれる

  • 開発者

肩書はない

自己組織化されている

チーム全体で責任を持つ

効果的なプロダクトバックログの管理方法を探す

プロダクトバックログを明確に説明できる

長期のプロダクト計画を理解している

おー。なかなかスクラムマスターとしてやっている!

良かったw

ちょろっと時間ができた時とかに

よくホワイトボードのタスクとか貼り直してみたり、

プロダクトバックログをどういう風にスクラムチーム用にするかとか、

しょっちゅうやってるなーと。

まだまだできてないことも多いしがんばろう!

プロジェクトの中止
  • 損失を限定し、機会を浪費しない価値もある。

ほんとこれがわかっていないプロジェクトが多い気がする。

ダメだってわかったらその時点で一旦破棄するべきだろう。

モチベーション

上がる時:仕事を自ら管理できている時

下がる時:もっと働けというプレッシャーがある時

結局、裁量が多ければそれだけモチベーションは上がるかなー。

まとめ

ウォーターフォールが駄目、スクラムがいいっていうだけの、

よくあるスクラム本と違って、

モチベーションのこと、チームづくり、スクラムの組織への導入について

とかがおもしろかったな。

「文化に合わせてスクラムを変えるのではなく、上手くやるために文化を変える」

とか、すごく大変そうだけど、必要なことだなと。

1時間で読めたし、オススメです!

www.amazon.co.jp