XP祭り2007 レポート vol.2
XP祭り2007 レポート vol.1 - Lucid Dreamで、翌日書くと言っていながら、ゼミ合宿やらインターン仲間との合宿やらで10日も経ってしまった。
会社の昼休みなので、整形する暇がないけど、とりあえず・・・。
以下、走り書きのメモを再構成しているので、発言者が入れ替わったり、内容が誤っている部分があるかもしれませんが、その部分の責任はすべて筆者にあります。また、内容を公開することそのものについて問題があれば、すぐに引っ込めます。
大島修さん@NRI技術調査部
遠隔地の3チームによるXPの実践例の報告。
XPのmotivationはいろいろだが、何よりも開発者が望んだ。
どっちかというと、社内はウォーターフォール文化なので、XPが得意な永和システムマネジメントとテクノロジックアートの協力を受けた。
bug trackingシステムはtracを採用。
trac-hacks.orgのニコニコカレンダーで各自の状態を共有できるようにした。
はじめは週3日ほど集合してペアプロや勉強会を実施した。
その後も、常時チャット接続して、リアルタイムな質問＆情報共有を心がけた。
週40時間労働のプラクティスのためもあって、朝/夕会は極力内容を定式化したうえで、15分に限定するようにした。
その後は、同一拠点でペアプロをしたうえで、重要なものについてのみ拠点間でレビューを実施。
TDDには、Perl Unitを使った。
イテレーションは2週間ではなく1週間
隔週で顧客デモを実施し、要望を反映させた。
XPの成功事例蓄積で、社内定着につながるのではないか。
市谷聡啓さん@TIS、藤原士朗さん@TIS
社内外の温度差を何とかしたかったので、社内デブサミを開催した。
相馬純平さん（id:j-souma）@ラグザイア
トリアージ・プロジェクトマネジメントを提唱
救急医療のトリアージと同じ意味
ソフトウエアは、アーキテクトという言葉のように建築工事に例えられることが多い。一昔前のプロジェクトならばよかったかもしれないが、現在も正しいのか？
そもそも、誰も作ったことがないものを作るのに対して、「見積もり」が成立するのだろうか。
現在では、技術が複雑化したこともあって、さらに見積もりは困難になっている。
要求増加や変更に対応しづらいし、検討そのものに工数がかかるうえ、末端のプログラマにしわ寄せがくる。
その一方で、XPイコール開発者天国という認識もあるが、見積もりなしでコンペに出たり受注したりできるだろうか。
XPを部分適用するなら可能だが、それだけでは無理。
「反復を短くするとアジャイルになる」は誤解。
そもそも、アジャイルはボトムアップの方法論であり、トップダウンではないから。
感覚としては、アジャイルというのは保守の繰り返しに近い。保守というのは、既存のシステムを理解して、リファクタリングを施す過程であるからだ。
プロジェクトの目的は、有限リソースで、より多くの価値を「救う」ということ。
分類を行うこと自体は、対処する上では前提となるので、それほど重要ではない。
すべての機能や方法を決めずに、目的、いわば「プロジェクト憲章」的なものに向けて頑張って、それを実現するというイメージ
先ほどの、ライブ開発でも、結局はHTMLタグを手打ちしていた。UIの開発方法論が進化していない。この流れは、Adobe AirやMSのSilverLightなどで変わるかもしれない。
アジャイルに適した契約形態とは
- 一括請負契約は受注側にリスクが大きい
- SES契約は発注側にリスクが大きい
- そこで、準請負契約
- 納期・コストを固定
- 機能は固定しない
- 実際に作ったものに対してのみ瑕疵担保責任。時間が足りなくて作らない、作れなかったものに対しては責任を負わない。
本来、価値の単位は、「ユーザ登録」や「ログイン」のようには分けられないはず。
