Archive for 11月, 2011

第9回アジャイルサムライ読書会 札幌道場を開催しました。
参加者は3名。人数が少ない分ディスカッションがみっちりでした。
なんというか、自分自身にモヤモヤする回でした。今回は6.3のみ。

今回の範囲で「グっときた」ところ

お客さんがわくわくするようなストーリー

勉強会として

ユーザーストーリーカードを書いてみる

今回は、本に書いてある「やってみよう」を実践しようということでユーザーストーリーの作成をやってみました。
正直な感想としては、難しくてよくわからなかった。
そもそも、ユーザーストーリーカードを作るという段階の立ち位置を勘違いしていたようです。
お客さんと話しながら作るものではなく、こちらからたくさんユーザーストーリーを準備していき、お客さんと話をしながら明確になったその時点でやりたいと思ったもの選んでいってもらう、という形になるのですね。
（なんとなく、自分はそういうときはユーザーストーリーカードではなく別のものに自分の考えをまとめておくものかと思っていました。）

というのも、

「本に出てくるお客さん（デイブと言います）の書いてある漠然としたやりたいことだけでは、ユーザーストーリーはほとんどかけないなぁ。あとは本人が目の前にいて話を聞きながらそろえていくものかなぁ。」

というのが１人で本を読んだ時の感想だったので、この本の会話だけでたくさんユーザーストーリーが出てくるということが想像できなかったのです。

実際にやってみて、自分がちょっとした会話からお客さんのやりたいことを形にするための手持ちのカード（スキルやアイデア）が圧倒的に足りないということがわかりました。
現実的にどういう形がいい形なのかが全く想像がつきません。
その時の思いをすべて言葉に残したものがユーザーストーリーカードなんだろうか。
「話をするきっかけとして」のユーザーストーリーカードと「誰が何のために何をしたいかをすべて書いておく」ユーザーストーリーカードと「フィーチャーとニアイコール」のユーザーストーリーカードは違うものなのか同じものなのか。
まだまだ、自分の理解と勉強が足りないなあ。

アジャイルの前に正しいウォーターフォールを

この章の全体を通したディスカッションで
「この辺りに書かれていることはそもそもアジャイル独自のことではない、ウォーターフォールもきちんと改善されれば自ずとここに書かれていることが大切になってくる」
という話が出たことから、アジャイルとウォーターフォールの話になりました。

自分には改善された生き生きしている現場 ＝ うまくいっているきちんとしたウォーターフォール開発 という図式がうまく想像できません。

「きちんとしたウォーターフォール＝開発者が辛い思いをするもの」

というインプットがされてしまっています。

これは「正しい」ウォーターフォール開発ではないというお話を聞き、頭では、たまたま私の環境が良くなかった、きちんと学べば正しいウォーターフォールの形があるということはわかるのですが・・・。
まだ、昔の（嫌な思いだけをした）プロジェクトのことを思い出しながら「あのプロジェクトはここがよくなかったからこうすればうまく行ったのかもしれない」と考えることはできません。
そもそも、どうしても（嫌な）経験と照らし合わせてしまい、ウォーターフォール開発を客観的な目で勉強することができません。体系を学ぶ前に経験が戻ってきて学習できる余裕がない。
もちろん、自分の体験の原因のすべてが「ウォーターフォールの開発だったからではない」ということはわかっているのですが・・・わかっているんだけど、うーん。
先に他の開発手法をきちんと理解した上でアジャイル開発の手法について学ぶべきなのかもしれないですね。

ただ、今はきちんとアジャイルを勉強して、開発者とお客さんが共によいものを作っていこうという考えで生み出された手法についてきちんと理解したうえで、正しいウォーターフォールやマネジメントについて学んでいけたらいいなあと思います。体系だてて比較したり両者の良い面悪い面を見たりできる段階には達していない。
しばらくはまず、今やりたいと思っていることをやり遂げたいなあと思っています。

運営の立場で

今回は逆に参加者の皆さんに自分の理解不足や勉強不足で円滑な運営どころかむしろご迷惑をかけてしまいました。
次回からも皆様の胸をお借りするつもりで、頑張りたいです。
とんちんかんな質問しないようにもっと勉強しないとなあ。

読書会のディスカッションのwikiはこちらになります。
https://github.com/agile-samurai-ja/support/wiki/Readingagilesamuraiinsapporo20111122

最後に。毎回会場を提供していただいた弊社に感謝。
ありがとうございます。
今年はあと2回ほど開催する予定です。
よろしくお願いします。

第8回アジャイルサムライ読書会 札幌道場を開催しました。
参加者は6名。
今日は、１人で本を読んだ時には割とすっきりしていた所だったのだけど、いざディスカッションをしてみるとなんだかすごくモヤモヤとした、よくわからない疑問がわいてきた。
ディスカッションの力ってすごいな。「わかった気」にはさせてくれない。

今回の範囲で「グっときた」ところ

アジャイルプロジェクトへの参加を決めるという覚悟

文書とは会話できない

読書会として

今日で第二部が終わり、第三部に入りました。

• 5.5 何がどれだけ必要なのか
• 6.1 文書化の難しさ
• 6.2 そこでユーザーストーリーですよ

「アジャイルプロジェクトへの参加を決めるという覚悟」について考えさせられた。
良い物を作るためにお客さんにも覚悟を決めてもらう、
そのためには自分がAチームの一員となるスキルを身につけなければ行けない。
少なくとも、Aチームのメンバーとして最高のパフォーマンスを出さねばならぬという覚悟が必要。
それって、開発する側としても、普段以上のパワーや気持ちや体力が必要だよな。普段の努力も怠れない。
お客さんに参加してもらって巻き込むからにはこっちも全力だよ、ってなるもん。
それでもアジャイル的な開発をしてみたいと思うか？という問いに「YES」と答えられるか。
そう考えた時に、
「環境も自分自身も足りないものがたくさんだけどやっぱりお客さんと一緒にいい物をつくってみたい。」
この原点に戻るんだよな、自分は。

「文書化の弊害」は反省することしきり。
103ページの上にある、文書を見ながら”連休だったことを考慮した方がいいのかな”と勝手に考え始めているのは、私か、いつかの私なのか。
長いこと102ページのような「だって書いてあるじゃない、最初に書いたじゃない」が”正（証拠）”となる文化にいたのもあって、文書を信じ込んでお客さんとの対話をおろそかにする部分が残っている。
勝手に文書の裏の裏をよんで「ほら、裏を読んでいたから大丈夫」とするのではなくて、「これって裏を返すとこういうこと？考え過ぎ？」という気持ちをお互いに確認すること、大事。
口に出すことを億劫がってはコミュニケーションはとれないですね、チーム間でもお客さんとでも。
こんなことではいけないなあ、と我が身を振り返った時間でした。

ディスカッションの内容はGitHubのwikiにまとめてあります。

運営の立場で

ディスカッション、白熱しました。しかし、今日はモヤモヤした部分がたくさん。
今日の会話で少し出てきた
「達人プログラマ読書会は”よし、これは実践してみよう！”と思えることが多いけど、
この読書会は”あんな現実や、こんな現実や、どうすりゃいんだ・・・” と現実の壁にぶつかってくじけそうになることが多い」
という意見は、今やっている読書会をよく表しているなと思いました。

この本を読んで、現実と比べて、モヤモヤする。
だって、１人ではどうにもできない無理なことがたくさん書かれている。
無理なことのうちできることはないか、モヤモヤを解消するためにできることは何か、
ディスカッションをしてヒントを手に入れる。
それぞれが持ち帰ったり感じたりして、現実世界に生かす。
この読書会はそういう読書会（アジャイルサムライがそういう本）だな、とここ数回でとても感じています。

毎回何かで打ちのめされて、何かをつかんで這い上がろうとするようなイメージ。
（決してMとかそういうのではありません。）

運営としては「無理じゃん」という下向きの気持ちのまま終わらないように、その先の話ができるよう意識していたいと思っています。運営として意識しなくても勝手にそうなっているけれど。

最後に。毎回会場を提供していただいた弊社に感謝。
ありがとうございます。
次回もよろしくお願いします。