アジャイルサムライ新宿道場#4に参加しました

　朝から風が強く雨も若干混じる悪天候の中、少し早めに新宿に行って
軽く壁に上った後、第4回アジャイルサムライ新宿道場に参加してきました。
（当日のタイムテーブルはこちら http://bit.ly/H8zFaI ）

　で、今回は3回のワールドカフェがありましたが、男気じゃんけんに
見事勝利したので、一番奥のテーブルの主として居座り続けることになりました。

テーマは「アジャイルな分析は、何を何処までやればよいのか」です。
チーム名は（六本木付近勤務者が多かったということで）「チームギロッポン」。

　以下、散文的になってしまいますが話し合われた内容について、メモ。
　
　・「分析」という事に関して、WFと（XP、スクラムといった）アジャイルでは
　　根源的には同じく「やりたい事（＝ゴール）」を決める行為、もしくは
　　「要求をまとめる行為」なのかもしれないが、その捉え方が違う。
　　
　　WFの場合、始めに全てのスコープに対してそれを行いゴールを「固定」する。
　　Agileの場合、「その時点」でのゴールを「スナップショット的に」固める。

　　例えばWFにおいても「画面モック」を作成してユーザとの要件定義を
　　行う場合があったが、それは「仕様を始めに決めきって、設計書を作る為の材料」となる。
　　（言い換えると、その「画面モック」はある意味絶対的な存在となる）
　　
　　一方Agileにおける「画面モック」はその時点で開発を行う為に
　　「スコープを限定して深堀りする為のもの」となる。
　　（言い換えると、開発が進んで別の要件等が発見されたら、それは捨ててしまう前提となる）

　・また、「どこまで」という問いに対しては「実装ができるところまで」という事に
　　なると思うが、WFとAgileではタイミングが（上記の通り）違う。
　　
　・同じ週の木曜にあった「すくすくスクラム」の勉強会で出た
　　「アーキテクチャジャンプ」についても若干話がでました。
　　
　　⇒　WFの場合、（始めにやる事を決めきってしまう前提なので）
　　　　本来アーキテクチャジャンプは発生しない。
　　　　（もし、発生したら初期の要件定義・技術検討が甘かったせい、という事に
　　　　　なると思います）
　　　　
　　　　一方Agileの場合は、発生する可能性が高くなってしまう。
　　　　それを出来るだけ発生させないようにする為には、
　　　　日々のリファクタリングや、テスティングを実践を積み上げるしか無さそう。
　　　　それによってジャンプの発生頻度や、その距離を短くしたりできると思う。
　　
　・アジャイルな分析のメリットは言わずもがな、変化に強い、ということ。
　　逆にデメリットは、随時変化に対応が出来る分、開発のEndが見えにくくなってしまい、
　　契約が出来ない、ということと、「局所最適化に陥る可能性が高い」という事。
　　
　　⇒　後の方はある意味宿命かもしれませんが、良いPOがいたら、
　　　　その危険性をかなり下げる事ができるのではないか、という事になりました。
　
　・また、TDDの拡張版であるBDDについても少し話が出ました。
　　⇒　参考サイト：http://bit.ly/HDJQzP
　　
　後は夕方頃から、そのままの流れでビア（スシ）バッシュに突入しつつ、
振り返りも合わせてやって、次回の道場ネタも決まりました。
（次回は手を動かすネタで）

　21:00頃までやって、本日は道場終了。僕はその後鼻メガネの会の2次会にコソッと
お邪魔して、ちょこちょことお話させてもらいましたよ、と（名刺を忘れていたのが残念な感じでしたが(汗)）