スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

リーン開発の現場

『リーン開発の現場 カンバンによる大規模プロジェクトの運営』を読みました。

一度読み始めて、10章くらいで少し立ち止まりましたが、時間を少しおいて再開し、その後は最後まで読み切りました。読みやすい本でした。訳がいいからのか、内容が実践的で、はまったからなのか。
私の現場はとてもアジャイルと言えたものではありませんが、そうだったとしても、具体的な話が多いので、理解しやすく、今自分の現場にアレンジして取り入れられる視点が数多くありました。

読みながら、気になったところに付箋をかなりの箇所につけました。
以下、自分の現場に取り入れる視点で、ほぼ自分用にメモを書いてみます。

=====
P.27
自分の現場では、Redmine上でタスク管理をしていて、カンバンは使っていない。
せいぜい、Backlogsプラグインで、擬似的なカンバンを見せているくらい。
しかし、障害物を明示するためには、やはりリアルカンバンがいいのかなとも思う。
ただ、一度、タスクを保留にせざるを得ないような障害物を、Redmineで表示できないか考えてみるのもいいかもと思っている。
P.105に、Google Drawingの活用というアイデアもある。

P.33
カンバンボードのスケールとして、2段階のボード運用の事例があった。
自分の現場で2段階でやろうとすると、機能開発チームのメンバーが、一つ上のボードを自分事として見るところまで、しっかりフォローしないとうまくいかなさそうだ。可能な限りは1つでやりたい。できるだけ大きいプロジェクトにしないようにしたい。避けられない場合もあるだろうけど。

P.54
バグの登録数を制限するというのは、私にとって斬新なアイデアだったけれども、内容を読んで納得した。自分のプロジェクトで一度、100個以上のバグがたまったことがあり、途方に暮れたことがあったから。
でも、今後もRedmineへのバグチケット登録は許容すると思う。
今でも、どんなにたくさんのバグがあがってきても、どれを修正すべきなのか、修正が不要なのか、見極めて修正するようにしているし、システムの特性次第だが、それを今修正した方が価値があるのなら、一向にかまわないとさえ思っている。
ただ、バグ発生から直すまでの時間は、比較的長くなる傾向にあるから、ビジネス側の要求とのバランスが必要な部分だと思っている。

P.68
第10章の継続的プロセス改善は、一度読んだだけではしっくり来なくて、何度か読み返した。結果、ふりかえりやワークショップは、そこここで適したやり方をすればいいと、自分の中の結論。
ただ、最も自分が踏み外しそうなのが、「プロセス改善の度合いを調整する」こと。変化には時間がかかることを、許容しなくてはいけない。待つだけの心の余裕を持つこと。

P.99
バージョン管理の章は、基本的なところで、どんなプロジェクトでも利用できる考えだと思う。しかし、ブランチの粒度は常に悩みどころで、結局はその時点でプロジェクトでこれが一番いい「だろう」で進めるしかないのだろう。
もちろん、変更する場合には結構手間がかかる。もう少しTFSのブランチが使い勝手の良いものになればよいのだが。

P.131、148
ここに書いてあるテスト自動化の戦略が、なかなか分かりやすい。使える。
因果関係図は、今は似たようなことを、Mind Mapを使ってやっているなぁと思った。しかし、P.159まで複雑なものはさすがに書いた(考えた)ことがない。

コメント

非公開コメント
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。