|
2012年9月15日(土)に開催されたXP祭り2012のレポートです。 XP祭りの詳細は、XPJUGのHPをご覧ください。
|
■このセッションを選んだ理由
|
XP祭りに終日参加しました。レポートを書くにあたり、ボリューム的にも1セッションに絞りたいので、どれにしようか考えたのですが、
- 参加してみて面白かった。
- 午後のセッションがマルチトラックで、一人ですべてのセッションに参加できないのだから、レポートを読みたい人がいるはずだ。
- ツイートが、togatterにまとめられるだろうけれど、ワークショップは参加者がツイートできず、togatterでも様子が分からない。
ということで、A-4のイテレーション期間についてのセッションのレポートを書きます。
■自分のコンテキスト
私は50名程度のソフトウェア会社に所属しており、エンドユーザーと直接契約での受託開発が、主な業務です。
保守フェーズに入っている案件が多く、決まったイテレーション期間は、特に設けていません。お客様より「この機能がいつまでに欲しいんだけど」と、数週間から1〜2ヶ月の納期を希望されることが多く、そこをリリースターゲットにしてチケット管理システム (tracを使っています) でマイルストーンを切ってチケット登録して、という感じでやっています。
ただ、大きな案件を手がけるのであれば、いくつかのストーリーの塊でマイルストーンを切るか、タイムボックスを切って進めるでしょう。確かに、タイムボックスを切るとしたら、どのように設定すると良いのか、というのは悩むところだと思います。
■セッション内容
まずはじめに講演があり、途中でワークショップを行い、その後また講演という構成でした。
講演は、アメリカで行われたAgile2012でも発表した内容だそうです。冒頭の挨拶が英語だったので、すこしビビりました。Agile2012ではワークショップができなかったので、それをXP祭りで試してみるという企画だそうです。
■前半の講演
早稲田大学で研究しているようにアカデミックに研究する人 (Researcher) と、現場で実践する人 (Practitioner) との間で、Researcher は研究結果の Result と Knowledge を提供し、Practitioner は Data を提供し、相互にフィードバックし合うことで、アジャイル開発をよりよくしよう！というお話がありました。
アジャイル開発が成功するための要素はさまざまですが、ここでは「Iteration期間」に注目しました。
うまく設定できれば良い影響があり、間違った設定をすると悪い影響が出ると思われます。期間は短ければよい、というものでもないでしょう。
では、どのように決めていますか？と会場に質問。
会場からの回答は「プロジェクト開始当初は大きなバックログがあり、2週間の設定が適切と感じていたが、今は保守フェーズに入り、小さいバックログが多くなったので、もう少し短くても良いと感じている」というものでした。
塩浜さんは、今回の研究では、途中で期間を変えることは対象外であると断った上で、最初に適切な期間を設定すると、プロジェクト全体として良い結果になると話しました。具体的に、どのように期間を決めたらよいかは、よくあるように XPなら1週間、Scrumなら一ヶ月が最適かというと、そんなことはないだろうということでした。
(出典をメモっていないのですが) アジャイル開発が失敗した原因に、イテレーション期間の設定を間違えたという理由が多いという調査結果があるそうです。最適な期間は、プロジェクトごとのコンテキストで変わるので、単純に1ヶ月がいい、1週間がいいというものではないということです。
ここで、イテレーション期間の設定が、プロジェクトの結果にどのような影響があるかを体験するワークショップに入りました。(すみません、ワークショップ説明の紙、撮り忘れてしまいました。)
(※編集注：XP祭りスタッフが撮影した写真を掲載いたします。)
■ワークショップ
ワークショップ概要
- 1テーブル4〜5名
- 一人が顧客役、残りが開発者役
- 顧客に、ある英単語を構成する、1枚に1つのアルファベットが書かれているトランプ大のカードのセットが渡される。
- 顧客は英単語を知っているが、開発者側は知らない。
- 顧客はカードをシャッフルして、文字が見えるように適当に置いていき、それを開発者が1枚ずつとって単語に並べていく。
- 1イテレーションの開始時に、イテレーション計画として、仕様の伝達、フィードバックの提示ができる。
具体的には、- 何文字目にどの文字が来るのかを伝えることができる。
- 今並んでいるカードを、1枚ずつ正しいか正しくないかを指摘できる。
- 1週間に3回行動できる。
- イテレーション計画は1回の行動となる。
- 開発者は、1回の行動で、1枚のカードを並べるか置き換えることができる。つまり、
- イテレーションを1週間とすると、1回イテレーション計画を行い、2回開発者が行動できる。
- イテレーションを2週間とすると、1回イテレーション計画を行い、5回開発者が行動できる。
- イテレーションを3週間とすると、1回イテレーション計画を行い、8回開発者が行動できる。
ということになります。
このような形で、3つの単語でワークショップを行いました。
1回目
自分は開発者役になり、最初の単語の作業に取り掛かります。
単語のヒントは「みなさんが好きなもの」。答えは「programming」でした。
最初はフィードバックを多くして、イテレーション期間を1週間としました。当初は見当もつかず、最初のイテレーション計画で先頭の文字だけ教えてもらい、次の行動で「p」を配置、その次の行動で適当に母音を配置しました。
2回目のイテレーション計画では、2文字目が間違っていることを指摘され、2文字目を入れ替え、3文字目に母音「o」を並べました。
3回目のイテレーション計画では、4文字目を教えてもらい「g」を4文字目に配置、「r」を5文字目に配置しました。
オープンされていたカードが、あまりシャッフルされていなかったこともあり、このあたりで回答が分かり、あとは並べていくだけになりました。結果は、6週間かかりました。
やってみて感じたのは、単語が分かるとフィードバックが要らなくなる、その分の行動が無駄になり、開発に回したほうが効率的だ、ということでした。しかし今回は、最初の取っ掛かりが分からなかったので、1週間のイテレーションで良かったかもしれません。
2回目
2回目の単語のヒントは「Javaのクラスです」。答えは「LinkedHashMap」 (実際には、すべて大文字のカード)。
今回も、当初は皆目見当がつかず、1文字目を教えてもらってスタート。2文字目以降は、適当に4文字並べました。
次のイテレーションで、2文字目を教えてもらい、そこで分かったので2〜5文字目を置き換え、6文字目を配置して「linked」まで完成。
3回目のイテレーションで、7〜11文字を配置し「linkedhashm」まで完成、4回目のイテレーションの3つ目の行動で「linkedhashmap」が完成しました。
2回目のイテレーションで気づいたので良かったのですが、そこで分からなかったら無駄な行動が増えるなー、と思いました。
3回目
3回目の単語のヒントは「車のメーカー、11文字」でした。
これは、かなり単語が限定されるので、オープンされたカードで単語が分かる可能性が高そうです。ということで、フィードバックなしでもいけると判断し、3週間のイテレーションにしました。
カードを開けると、案の定、答えが分かりました。「lamborghini」でした。
最初に1文字目だけ教えてもらい、後は並べていくだけ、2回目のイテレーションの4つ目の行動で完成です。
ワークショップを終えて
チーム内では、英単語では途中で想定がつくのでフィードバックは不要になるけれど、実際のプロジェクトではストーリーを幾つか実現していくので、半分のストーリーができても、残り半分のストーリーのフィードバックが不要になるかというと違うよね、という話が出ました。
その後、各テーブルからの感想発表では、どうせ一か八かでフィードバックをなくすなら、4週間を1イテレーションにすれば、イテレーション計画で1文字を並べるのに11でぴったり4週間に収まったので、そうすべきだったと話しました。
他のテーブルからは、顧客役の人が、開発者の様子を見ることで、どんな指示やフィードバックを与えたらよいかが分かるよね、という話がありました。
■後半の講演
ワークショップの後に、もう一度講演がありました。
アジャイル開発の一般的なモデルを捉えるということで、まずリリース計画があり、イテレーションが何回かあるという構造を定義します。イテレーションには、Planning があり、Implimentation があり、Review、Release がある、という形になります。
各フェーズで、今までのいろいろな研究を元にプロジェクト毎の5つのコンテキスト要素を Input し、イテレーション期間を Output するように定式化します。
5つの要素は、
- Duration (期間)
- Developer (開発者)
- Requirements (要求、重要度と規模(コスト))
- Complexity (複雑性・依存関係)
- Uncertainty (要求変更の度合い)
です。
このシミュレータを永和システムマネジメントさんの事例レポートに適用したところ、6日と算出されたそうです。実際の開発作業は、1週間のイテレーションで回していて、メンバーからは、もう少し長くても良かったのでは、という意見もあったそうで、案外、的を射た期間が算出できているのではないか、ということでした。
5つの要素のうち、Uncertainty と Complexity に注目しており、Uncertainty は、変更が多ければ期間は短くなり、Complexity は、複雑になると期間が長くなるという、それぞれ相関関係が見られたそうです。
ただし、最も変更が多いケースでは、複雑性が最も高い時に最短期間になっていました。(見間違いでなければですが。時間切れのため、質疑応答で確認できませんでした。懇親会で聞こうと思ってたんですが、すっかり忘れてしまいました。)
質疑応答
最後に質疑応答がありました。
「ワークショップの結果から、途中でイテレーションの期間を変えたほうが効果的だと感じたが、そのような研究はしていますか？」との質問に、イテレーション期間の変更はできるようになっているそうで、今後、そのような視点での研究の成果が出てくると面白いなと思いました。
■感想
全員同席するようなプラクティスを実践できれば、いつでもフィードバックをもらえ、そのためのコストもあまり掛かりません。一方、顧客と離れた場所で開発すると、計画、フィードバックなどのコストがそこそこ掛かってしまうので、確かに、どのくらいの頻度でフィードバックするのかは考えないといけないなぁ、と感じました。
「コミュニケーションはコストである」という考えもあるように、いかに効率良くコミュニケーションするか、という観点が重要だな、と改めて思いました。ただ、「コミュニケーションはコストになるので、なるべく少なくて済むようにする」ではなく、「コミュニケーションがコストにならないようにして、より多くコミュニケーションできるようにする」という方向で考えるべきなんだろうとも思います。
最後となりますが、有意義なセッションに参加できてよかったです。
浜崎さん、鷲崎先生、どうもありがとうございました。
