そこに仁義はあるのか(仮)

略してそこ仁!

SCRUM BOOT CAMPを読んだ!読みやすい!2日で読めた!

SCRUM BOOT CAMPをよみました!
ところどころが漫画で書いてあるし、内容もすごく噛み砕いて書いてあったので、
すごく読みやすかった!2日で読めた!!
でも、ちゃんと内容も充実していた!!
初心者にはすごくおすすめ!

SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK



ちなみに、書籍のなかで紹介されている@さんのインセプションデッキのテンプレがこちら!!

support/blank-inception-deck at master · agile-samurai-ja/support · GitHub


SCRUMやってみたい。

新人配属してからずっと保守運用チームで、最近開発チームに移動しまして、
いま、初めての開発(ウォーターフォール)をやっているんですが、
なにせ、外部設計工程・内部設計工程・PG工程と、それぞれで期間が空いちゃう。
ウォーターフォールにはウォーターフォールで良いところはあるのかもしれないけど、
外部設計工程で考えた事を、内部設計工程で思い出しなおして考えて、
PG工程でまた思い出しなおして考えて、って無駄な時間をかけちゃってる気がする。
あと、(これは設計書のフォーマットが悪いのかもしれないけど、)
内部設計工程でメソッドに引数の型を記載する項目が設計書*1にあったりして、
余計な考察をしなきゃいけなかったりする。(作ったほうがはやい!)
スクラムでは、1ストーリーを通しで実装出来るぶん、↑で書いたみたいな余計な時間をかけなくて済む感じある!!!


開発チームとスクラムマスターの役割に関しては、(知見ある人に教えいただければ、)部内でも始められそうな気がする。
ただ、私のいる環境で一番難しいのは、良いプロダクトオーナーを確保することなんじゃないかなぁと思う。
私のいる部署は内部受託開発請負の部署で、お客さまとの距離がわりととおくて、
要件や仕様をきめるのは他の部署の人なんだけれど、そういう人に要請をだすのがハードルになる気がするなぁ。

きちんと要件や仕様を決定することができて、
スプリントレビューやデイリースクラムにも積極的に参加してくれて、
スコープの調整を顧客に行ってくれる。
そういうプロダクトオーナーがいるっていうのが、開発を救う気がする。

*1:共通コンポーネント設計書。業務Actionクラスより前に作成している。。。コンポーネントって、共通化できる部分を切り出して作っていくものだと思ってた…。