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

日々常々

ふつうのプログラマがあたりまえにしたいこと。

#scrumbc 大阪 に参加してきた

2012/06/16 に行われたScrumBootCamp in 大阪に参加してきました。「Scrumとか知りませんし」とか言い続けてたんですけど、これで知りませんと言えなくなりました。無念。


詳細は語りません。そんなものは自分で参加して感じてきてください。ScrumBCが始まって今日で一年だそうです。今後も各地で開催されていくでしょうし、まだ参加されてない方は是非参加してもらいたいなと思いました。

開発チームの役割

開発チームは作るだけではない。作り続け、それを維持し続ける。単に作るだけでなく、続けること。持続可能と言われるのもここですか。

軽量

やらなければならないことはやらなければならない

当然のことです。しかしやり方は変わります。やるべきことを漏らさないために、軽量な仕組みの組み合わせでフォローする。もしかしてこれって単一責任原則ですかね。

透明にする

何でもかんでも透明にする。メンバーの気分すらも見えるようにする。透明にしてれば検査出来る。検査できれば適応出来る。

POを作る

スクラムがいきなりできるような環境だったらやればいい。やれないならば、自分だけでも開始出来なくはない。自分のやることにはっきり優先順位を付けるように促す。これでPOができる。かも。

障害物リスト

解決出来なくてもいい、チームが抱えている問題を書いておく。問題は一度に片付けない。できる時に。

良いストーリー

「自分にしかわからない計画」なんてものの価値は低い。「何ができるようになるか」を書くと伝わりやすい。書き辛いときはテンプレート(xxとしてyyをしたい。なぜならzzだからだ)を使う。「機能名+できる」はよくない。短く書くと会話の約束になる。今度話さざるをえなくなる。

時間をかけてもいい

弊害は沢山ある。短時間で済ませるメリットは多い。でも全てはトレードオフ。あまりに軽く済ませて役に立たないんじゃ本末転倒だし。

緊急時の規律

「Scrumは追い込まれたらやってることを最初からやるだけ」

懇親会で聞いた言葉。優先順位を付け、タイムボックスを切り、全員の作業を見える化し、必要なものから順にリリースする。トラブった時に大慌てで必死になってやることはあります。それをなぜ最初からしない?大変だから?なら軽くして出来るようにしよう。それがScrum。

なるほど、確かにScrumで挙げられるようなものの幾つかは修羅場では自然発生します。それを洗練させれば、火事場の馬鹿力に匹敵するパワーを常時発揮することが。出来る、のかも。

さて、「緊急時の規律」はCreanCoderの11章156ページにあります。引用。

平時にTDDの規律を守り、緊急時にそれを守らないとすれば、TDDの効果を心から信じていないと言うことだ。(略)ピンチに陥っても行動を変えては行けない。規律が最善の方法であれば、緊急時になっても守るべきである。

これの逆かなと思いました。緊急時に採られる方法には大きな力があり、そこにメリットを感じているわけです。出来ない理由は大変だから。そりゃそうですよね。あんなの続けてたら保つわけありません。
だからと言って諦めるのではなく、大変じゃなくして常にやるってのがScrumなのかなーと。

感想

ねんがんの ScrumBootCamp に参加出来ました。主催、スタッフの皆様にはものすごく感謝しています。特にワークの内容は秀逸で、それぞれのメッセージがダイレクトに伝わってきた気がします。気のせいじゃないと嬉しいです。そしてワークで出来ることが何故仕事で出来ないんだ?いや出来るはずだろう。とか思いました。

会社でもやりたいなーと思ったのですが、私の理解もまだまだ浅いでしょうし、講演無しのワークにアレだけのメッセージを持たせられるか疑問を抱いてしまって思案中。

兎にも角にも、素晴らしい刺激でした。


Clean Coder プロフェッショナルプログラマへの道

Clean Coder プロフェッショナルプログラマへの道