2010年2月27日土曜日

XP寺子屋第5回「ペアプロ体験」ふりかえり

盛況の内に終了しました。

あらかじめ参加者にパソコンとペアを各自用意して頂いた。その結果,欠席者ゼロというスゴイ記録が生まれた。通常,参加者の1〜2割が欠席するのが常識となっているのに,「欠席者ゼロ」とはスゴイ事である!

当初,参加条件が厳しかったためか参加者集まらなくて焦りを感じたので,下記2点の初の試みを実施。

■その1:資料の事前公開
いつも資料は当日まで公開されないが,参加者が内容を事前に把握した方が安心できると思い,事前公開してみた。

■その2:目立つテンプレートの使用
見た人に興味を持ってもらう様,目立つテンプレートを使用した。
いつもお世話になっているMS様のテンプレートでは物足りず,フリーのテンプレートを探し,印象に残るものをチョイス。

実際のワークも盛り上がった。
最初の15分でインストラクション&アイスブレイク。アイスブレイクで久々に「しりとらず」を実施したが,凍り付いた場が数分で和やかな空気に変わるのを感じた。
残りの時間をペアプロに割り当てた。あるペアはタスクかんばんを使い,あるペアはデザインパターンで熱い議論を交わし,会場は静かにヒートアップ

最後に「拍手2回でふりかえり」を行い全員の感想をシェア。「有効なやり方」「会社では教えられない細かい事を指導できた」「楽しかった」「もっとやりたい」等々,前向きな意見が多かった。

◆◆◆◆◆◆◆◆◆
自分自信のふりかえり

■KEEP
・ペアプロのワークショップを実現した
・期待していた効果が得られた
・参加者が10名を超えた
・ソフト業界以外の方も参加

■PROBREM
・ヘルプファイルを忘れていた
・見学者への対応が不十分だった
・自分も開発していたので十分フォローできなかった

■TRY
・XP寺子屋継続
・XPの全プラクティスを使ったWSの開催
・IT業界へのペアプロの展開


これからも,XP寺子屋を続けて行きたい。

2010年2月20日土曜日

XPの真価を伝えたい

2007年,XPJUG関西のスタッフにして頂いた。


当時,「XPをもっと世間」に広めたいという思いを強く持っていた。


人に自分の知識を教えるのが好きな性格だったため,XPJUG関西を通じて誰かにXPの良さを伝えたかった。それを形にしたのが「XP寺子屋」である。


今まで通算4回開催し,本当に多くの方々に参加頂き,様々な気付きを頂いた。


今月,5回目を開催する。
内容は,念願のペアプログラミング。「やってみたいXPのプラクティス」で常に上位にランキングされるプラクティスである。


ただ,予算の都合上,様々な制約事項をつけなければならなかった。


機会があれば,制約事項を減らして再度企画してみたい。

2010年2月16日火曜日

ペアプログラミング

XPのプラクティスの中で注目度の高いプラクティスの一つである「ペアプログラミング」、通称「ペアプロ」。

「XPを知ってますか?」と聞くと、殆どの方が「TDDとかペアプロするんですよね」と答える、XPの代名詞と言っても過言ではないプラクティスである。

TDD、リファクタリング、コード共同所有、シンプル設計、ペアプロなど、開発に直結するプラクティスの内、ペアプロだけが一人で試すことができない。できないからこそ、注目度が高いのではないのだろうか。

或いは、「2人で1台のパソコンを使って開発すると、生産性を落とさず高品質になる」という、従来の考え方(個々人の能力の高さが生産性と品質に直結する)と相反する考え方だからだろうか。

私は、両方の理由からペアプロに挑戦しようと考え、約3年間取り組んできた。
その経験から学んだ事は、「ペアプロは、ペアを組む相手により結果が変化する」という事である。
 特に、ペアプロを有効と感じないメンバーが居るプロジェクトでは、上手く機能しない。つまり、2人1組で開発することの弱点となる。

ここを上手くクリアできなかればべ、ペアプの有効性を感じることは難しい。

2010年2月7日日曜日

XPと受託開発はマッチしない

「XP祭り関西2010」が無事終了した。
今回のテーマは「アジャイルマインドの育て方」となっており,ご登壇頂いた皆さん,アジャイルマインドについて,熱く×100語っていた。
特にpapandaさんの熱さには驚かされた。
◆ ◆ ◆
基調講演で「XPと受託開発はマッチしない」というお話しがあった。
曰く,「品質よりスピード」,「シンプルより多機能」,「(契約の関係で)複数回リリースより1回リリース」という,XPと異なる価値を重視しているためである,と。
「XPはお客様と協調し,良い製品を作るための手法だ」と言われて久しいが,(少なくとも)日本ではXPの価値がお客様の満足度に貢献できていない様に感じる。
お客様にとって,開発手法は重要ではない。「XPは素晴らしい」と言っても,お客様の満足が得られなければそれは技術者の自己満足でしかない。
イベント終了後,知人とそんな話をしていると,ふとアイディアが浮かんだ。
「受託開発者で,お客様が満足するプラクティスを開発する」
ケント・ベックが教えてくれた「プラクティス」を実践するという事は,「守破離」で言う『守』の段階である。だから,受託開発に最適化したプラクティスを開発(『破』)し,成功(『離』)を目指さなければ単なる開発者の自己満足で終わってしまう。

そして,一番重要なのは「XPとは変わる事」だという事。
XPの本質は「ソフトウェア開発において正しい事を最大限に実行する事」であると考えている。その考えに基き,価値と原則とプラクティスが策定されたはずであるが,「価値・原則・プラクティス」は,プロジェクトや前提条件によって変化するのではないだろうか。
ならば,「日本の受託開発」という前提条件を満たす「価値・原則・プラクティス」を考えればよいのではないか。

一つ言える事は,「現状のソフト開発スピードでは,顧客満足が得られない」という事。
ハードウェアスペックの向上によりコンパイル時間は短縮された。次の10年ではソフト開発の時間短縮が実現されるだろう。
その時,XPはどんな進化を遂げているのだろうか。