無料ブログはココログ

« 2010年1月 | トップページ | 2010年3月 »

堂島ホテルロール

堂島ロールのモンシュシュの隣のブロックの角がサントリーで、その隣が堂島ホテルです。前を通るとなんと堂島ロールそっくりのケーキが、、、、しかも「堂島ホテルロール」。これは食べなくてはなりません。

Doujimah

昔は堂島と言えばサントリーが有名どころだったのですが、堂島ロールが有名になって、次が堂島プリンで、とうとう堂島ホテルまでロールケーキか、、、と思ったら大間違い。もともとモンシュシュは堂島ホテルで営業していて、路面店になる際にレシピを開示したとか、モンシュシュと共同開発だとか、いずれにしろ堂島ロールのレシピがベースになっているようです。

さて、お味のほうですが、結構違うような気がしました。スポンジはしっとりしていて、クリームには牛乳の香りがしています。他のブログでは堂島ロールの方があっさりと書かれていましたが、1/4を食べた感じでは、堂島ホテルロールの方がすっきりしているような感じがしました。香りのためか、甘さの違いか、単に小さいだけなのかもしれませんが、堂島ホテルロールのほうが好みです。

さて、せっかくなので関西圏のロールケーキのお勧めランキングです。

1位:(また食べたくなります)
菓子職人 京都純生ロールクラブ

2位:(クリームいっぱい)
堂島ホテル 堂島ホテルロール

3位:(高コストパフォーマンス)
バンボシュール 桂ロール

あくまで、個人的な感想です。

昔のXPのスライド・論文公開

SlideshareにTiDDのスライドを登録したところ、多くの人に見ていただけましたので、今度は、ソフトウェアシンポジウム2004に川端さん、小林さんと共に発表した資料を登録しました(論文はこちら、英語版スライドはこちら)。ぜひご覧ください。

このエントリーをはてなブックマークに追加

[TiDD] チケット媒体のバリエーションと特性

XP祭り関西2010ではチケット駆動開発(TiDD) のバリエーションに触れましたが、ここではチケットとして使う媒体のバリエーションとその特性について述べます。

TiDDはBTSの利用形態が発展して生まれたものですから、BTSのチケットが本来の姿です。しかし、チケット駆動開発のめざす価値が実現されていれば、媒体は何でも構いません。ただ、チケット媒体の特性は理解しておくほうが良いと思います。

ということで、まとめてみました。あくまでも個人的な感覚ですので、気になるところがあればコメントをお願いします(プラグインなどをあまり使わないという前提です)。

情報共有・同報通知

BTS>メール>スプレッドシート、Wiki、付箋

pullよりもpushの方が同報通知が強力、BTSは両方を兼ね備える

並べ替え(優先順位、その他)

BTS>メール>スプレッドシート>付箋>Wiki

メールはソート条件が限られているが使いやすい。チケットが独立している分だけ付箋のほうがWikiよりも並べ替えがしやすい。

抽出(全体・担当、その他)

BTS>スプレッドシート>メール>Wiki>>>付箋

BTSは抽出したViewが作成できる。スプレッドシートも可能だが難易度大、メールは検索機能が使えるが毎回設定が必要。Wikiは頑張れば可能かもしれない。付箋は抽出が破壊的になるので論外だが、一つの属性だけでよいなら色分けするという方法もある。

マイルストーンと集計

BTS>スプレッドシート>Wiki>>>メール、付箋

BTSでは標準でマイルストーンと集計がサポートされている。スプレッドシートは簡単な設定で可能、Wikiは可能性がある。メールと付箋は手計算になるので絶望的

CMSとの同期

BTS>>>メール、スプレッドシート、付箋、Wiki

BTS以外は運用を決めて手作業でやるしかない。

ワークフロー

BTS>>>付箋、スプレッドシート>メール、Wiki

BTS以外は運用を決めて手作業でやるしかない。付箋とスプレッドシートは承認印欄を作成すればそれらしくなる。

権限

BTS>メール>スプレッドシート>付箋>Wiki

BTS以外は不可能。

その他の候補

これ以外の良い候補として、カード型データベースがある。きちんと構築すれば、BTSにかなり近づけることができる。ただ、自由度は高いがBTSの方がこなれていて使いやすいでしょう。

[TiDD] チケット駆動開発の生産性

チケット駆動開発で日々の作業をきちんと実施すれば、生産性が向上します。理想的なチケット駆動開発は、以下のように実施できます。

1)作業をチケットに登録する
2)期限を設定するならば、もっとも遅い締め切りを設定する
3)他のチケットよりも先に実施すべきチケットの締め切りは、それ作業の締め切りより必要な工数分だけ前に設定する
4)毎朝、チケットの一覧を確認し、必要となる工数とスケジュールから、その日に実施するチケットを決める
5)その日のチケットに書かれた作業をすべて実施する
6)完了したチケットを閉じる
7)作業中に発生した作業は、必要がない限り翌日以降に実施する

このようにその日の作業を決めてきちんとこなすことはチケット駆動開発の基本です。

かつて、小学校の先生が松下幸之助の仕事術を教えてくださいました。いくらやってもこなせないほど仕事がある社長業をこなすコツは、毎朝その日こなす作業を決めて、きっちりと終えることだそうです。そのような仕事術がチケット駆動開発には含まれています。

これらの実施法はいずれも重要ですが、1番の作業がチケットに登録されていること、そして7番の予定外の作業を増やさないこと、はチケット駆動開発の生産性を高めます。

この2つに実施法によってチケット駆動開発は、XPのプラクティスである「最適なペースの仕事」を実現するだけでなく、スクラムと同じようにプログラマの「集中」をまもることができます。

このうち、「集中」することがどのくらい重要であるかは、CMMやTSP/PSPで有名なハンフリー先生の本に載っている数値でわかります。

文献[1]のAllied Signal者の調査では、TSP導入時に当初6時間/週しか作業のための時間しかとられていませんでした。その後、手法になれて10時間/週に改善しまし、作業以外の時間を効率化して1年後に15時間/週、その後、支援を受けることでようやく16時間/週になりました。

しかし、マネジメントが外出して質問や情報収集をしないときは、なんと20時間/週を優に超えて作業をすることができたそうです。

[1] W.,S.,ハンフリー, ソフトウェアでビジネスに勝つ, 共立出版, pp.44-48, 2003.

作業に割り込みをかけないことは、このように生産性の向上を生みます。チケット駆動開発では、進捗の情報をチケットから得ることができますので、マネジメントが割り込みをかけることも少なくなり、マネジメントが外出したときのような作業効率が得られることになります。

チケット駆動開発で最適なペースを守り、より集中することは重要です。そのためには

「明日できることは明日して♪今日できることも明日して♪」

という冗談のようなことも、重要なプラクティスになりうるのです。

[TiDD] BTSがチケット駆動開発に向いている理由

XP祭り2010のチケット駆動開発(TiDD)パネルで、倉貫さんがgoogleスプレッドシートでTiDDをされていたことに、あきぴーさんはあきぴーさんは納得されていない様子です。

個人的には作業を見える化してコミュニケーションを図るという意味で、「あり」だと思いますが、あきぴーさんのこだわりの中ににTiDDを整理するヒントがありそうなので、BTSだとなぜ良いかを考えてみました。

1) 個人のビュー=ひとりスクラム

TiDDでは毎朝、あるいは作業が終わったときなどに、担当している作業の一覧を確認し、今後の進め方を計画します。作業開始後はその作業に集中して実施します。この一連の流れは、スクラムと非常に似ています。

スクラムでは、チームが要求されている作業の一覧があり、プロダクトオーナによってその優先順位がみめられます。次にスプリントの作業を決めるために、スプリントミーティングによって対象のプロダクトバックログや期限(チームにとってのスプリントバックログ)が決められ、チームによって自己組織化されて開発が実施されます。そこでは、選択したプロダクトバックログ以外に制約を受けず、、自立した開発が行われ、チームは作業に集中できます。

このスプリントバックログは、スプリント中にチームで行わないといけない要件です。これらは複数のタスクに分けられ、個人に割り当てられるものです。これ以降は、スクラムでなくても、チケット駆動開発を実施するなら同じようなプロセスになります。

つまり、チームのプロダクトバックログは、作業の個人にとっての(つまりひとりスクラムの)プロダクトバックログです。割り当てられた作業は担当者によって優先順位や作業順序が決められ(個人にとっての)スプリントバックログが決まります。担当者は期限(スプリント)内ではコミットしたプロダクトバックログ(プロジェクトにとってのスプリントバックログ)に集中して、自立した開発が行えます。

この個人のプロダクトバックログがチケットだと思います。こなさなければいけないプロダクトバックログ(チケット)を日々一覧で確認し、順にこなしていきます。大切なことは、優先付けされた作業の一覧があり、順にこなされていくこと。期限さえ守れば、作業のこなし方は自立的に決められ、作業に集中できることです。

BTSなら、個人の担当作業の一覧を容易に見ることができますが、スプレッドシートではちょっと手間です。「集中できる」という価値が減少し、リズムが乱れがちになってしまいます。

2) ワークフロー

XP祭り関西2010で発表したように、チケット駆動開発には「ワークフロー型」のチケット管理方式と、「オープン型」のチケット管理方式があります。「オープン型」ならスプレッドシートでも問題ありませんが、ワークフロー型だとツールで支援されていたほうが便利です。(このあたりが、わたしとあきピーさんの違いでしょう)

3) メール

BTSには、チケットの登録や変更時に関係者に通知メールを出す機能があります。これが、個人に割り当てられた作業のうち気になるものをひとりチケット駆動開発的に管理する際は役立ちます。また、リーダが気になるチケットを管理する際にも役立ちます。

このような理由で、BTSが(特にワークフロー型の)チケット駆動開発に向いているのだと思います。

2月9日追記
最近のBTSにはRSSをフィードで切るものがあります。日常的にRSSリーダを使われているなら、ある程度メールのかわりになると思います。

[TiDD] ひとりチケット駆動開発はメールを使え!

XP祭り関西2010で、「ひとりチケット駆動開発は楽しくなかった」と述べましたが、訂正します。

「ひとりチケット駆動開発にBTSは向かない。メールを使うべきだ」

発表の後で、色々な人に「昔からやっているんですけど、忘れないように自分にメールする方が便利なんですよね」と言っていました。でも、倉貫さんがスプレッドシートでチケット駆動開発(TiDD)と言われていたことを思い出して、メールによるものもTiDDであると考えます。

すると私は、ひとりTiDD歴がかれこれ4半世紀になります(チョット自慢<-おじさんなだけですorz)。

まじめな話、メールはひとりTiDDに最適です。こんな感じです。

1) 忘れてはいけない作業が発生したときに、自分にメールします。
2) 必要なら、専用のフォルダを作成してメールを振り分けます。
3) 優先順位の高い作業にはタグなど目印をつけます。
4) 完了していない作業は未読、完了すれば既読にします。

こんな感じですが、いかがでしょうか?

実はこの方法は、普通のチケット駆動開発においても、

a) 担当している作業のうち、重要な作業
b) 担当外だが、関連する作業
c) クリティカルパスになっているなど、リーダが重要と思う作業

を管理する際に有効です。これがTiDDにBTSが向いている理由にも関連します(続く)。

元気が出るチケット駆動開発 - 補完型TiDDの経験 - @XP祭り関西2010

XP祭り関西2010で発表してきました。2次会では長瀬さんとお話できるなどとても楽しい1日でした。

倉貫さんの発表では、受託開発がPoint of sales、クラウドがPoint of salesというお話は考えさせられるものがありました。受託開発では納品した瞬間が最高だが、クラウドでは常に最高でなければならないというのは、日本でアジャイル開発が難しい理由を的確に表現されていると思いました。

最近、スクラムの本を読んで去年の土屋さんのお話で、チームは常にそこにあって要求が順に入力されてソフトウェアが出てくると言われた理由がわかったような気hがします。一つ一つの契約でなく、常に保守(成長)させていくような開発でなければうまくいかないと思っていたところでしたので、妙に納得した次第です。

そのような日本の環境では、いかにアジャイル的な要素を従来のプロセスに組み込んでいくかが必要だと思いました。そういう意味では、私の発表もそのような経験談ですので、良かったら見てください。

ダウンロードは許可していませんので、印刷したい方は以下のPDFをご利用ください。

ダウンロード XP2010TiDD6.pdf (452.2K)

« 2010年1月 | トップページ | 2010年3月 »