「チーム開発の生産性を高めるプロセスを体感しよう（入門編）」に行ってきた

IBMで行われた「チーム開発の生産性を高めるプロセスを体感しよう（入門編）」に行ってきた。

内容としては、アジャイル開発（主にスクラム）の基礎的な話と、ちょっとした実践、IBM Rational Team Concertを使ったデモ。

以下、気づいたことなど。

ウォーターフォールとアジャイルの違いを、映画と連続ドラマに例えてたのはわかりやすいと思った。映画は公開後の手直しができなくてハイリスク、連続ドラマは毎回視聴者の反応を見ながら手直しできる
要求仕様が前提となるのがWF、リソースと納期をベースに考えるのがアジャイル。要求は24ヶ月で25%変質する ⇒個人的にはパーセンテージはもう少し高い印象
今までの組織で管理を担当していた人は、アジャイルでは役割が「プロダクトの下支え」となる。管理職も変わらなきゃいけない。 ⇒これは管理職だけでなく一般社員にも言えることだなー。自律的に動くという意識を忘れないようにしないと（させないと）いけない
業務システムの75%が寿命を全うすることなく使われなくなってる。これまで「残業するから金をくれ」と言ってきた部分もあったりしたと思うが75%のために残業するんですか？、と。
アジャイル開発の品質やスピードはツールにも左右される。 ⇒自分のところではここがまだ弱いので今後もツール導入をどんどん進めていきたい
ストーリー（戦略的計画と言ってた）の粒度は数日～２週間が目安、タスクは8時間（理想は5時間）
5～6イテレーションごとに「リファクタリング」を入れると良い。そこで変更を吸収する
優先順位は顧客のビジネス的価値によって決まるが、どうしても決まらない場合はリスクと思われるところからやる
あいまいな部分は仮説を立てて、必ず確認するように。棚上げ禁止
ワークショップでストーリーとタスクの立て方をやったけど、正解は無くとも、こういう視点でこういう風に作りましょう、みたいなのを示して欲しいと思った。自分のチームはストーリーもタスクも粒度が荒すぎた気がするので。
それとも無料でなくお金払ったら教えてもらえたのかしらん？（笑）
ストーリーポイントでなく理想時間で見積もりをやったのが気になった。自分の中の理解では、最終的には時間に落とすけど、まずポイントで見積もるのがアジャイルの１つの特徴でもあると思うので。
個人的には”アジャイルもどきを実践で始めた”程度なので楽しめたけど、既に実践されている方にとっては、ちょっと言いたくなる、ワークショップだったかもしれない
講師の三井さんはパワー溢れる方だった。あの年代の方でアジャイルとか言う方はあんまりいない気がするのでがんばっていただきたいと思う
RTCについて、普段Tracを使ってるので抵抗無く飲み込めた。EclipseやVisualStudioプラグインがあるみたいだしSVNも使えるみたいだし、単純に画面が違うことによる戸惑いはありそうだけど、うまく使えば使えるかも、という感じなので今後試してみたい。Linuxでも動くのかなぁ。