アジャイルサムライを読み終えたよ

最近はあっちゃこっちゃで道場が開かれているアジャイルサムライ−達人開発者への道− ですが、私も読んでみました。とても読みやすい内容でしたが、少し内容が単調な気がしました。

とはいうものの、アジャイルサムライはアジャイル開発の概要を見渡すにはちょうど良い書籍ではないかなぁと思っています。もちろん、前提として私はアジャイル開発の「ア」の字ほどもアジャイルな開発をチームで行ったことがないので想像の世界ですが…。

特に気に入ったところをいくつかピックアップしてみました。

アジャイルプロジェクトではメンバーの一人ひとりが、役割という名の帽子を複数かぶり分けることになる

これって、当たり前のようで当たり前にできないことだなぁと思う。誰かが自分の仕事を助けてくれたときに、素直にありがとうと言えるときもあるけれども層でないときもやっぱりある。自分の仕事をとられた！とか思ったりすることもある。また、なぜ自分がそんなことをしなきゃいけないのか？と感じてしまうこともある。チームという視点で成果を中心に考えたときには、誰がやろうがOK。むしろ、自分にできることかを常に意識するべき何だろうなぁ。

トレードオフスライダー

アジャイル開発の話では、可視化がうるさいくらい出てくる。確かにみんながわからないと意味がないし、情報の共有には可視化することが一番わかりやすい。ただ、お客さまに機能の選択をしてもらうときに可視化する方法は思いつかなかったね。優先度と重要性から必要なものを取捨選択する必要があっても、なかなかその情報がないためにうまくいかないことが多いと思う。そんな中で、トレードオフスライダーってとても便利なのではないかな。

考え方を返る

アジャイルサムライを通して出てくる話だけど、失敗は失敗ではないという見方を変えたとらえ方を柔軟にすることがとても大事かも。たとえば、何も価値を見いだせなかったイテレーションはお客さまに成果を提示できないかというと、そうではないと。提示することでチームが二度とそのような状態に陥りたくないような恥ずかしい経験ができるよねとくる。これまでの経験では、こういう失敗は往々にしてあったけど、そのときまで気づかないで恥ずかしい思いをすることは結構あった。でも、チームリーダーがそうさせるように仕向けるというのもチームがうまく回る一つの手段なんだなぁと。

3つほど思いつくままに書きました。見積りについてもとてもすばらしいと思うのですが、こちらはすでにアジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ を読んでいたのでおさらいのような感じでした。