チケット駆動開発のテーラリング

Ryutaro YOSHIBA @ryuzee

確かにあきぴーさんの見解知りたいね RT @kaorun55: TiDDはさかばさんがフレームワーク担当で、あきぴーさんが実装担当のイメージ。no ticket～はさかばさんはオプションだけど、あきぴーさんは必須という立ち位置だと思ってる。

中村 薫 @kaorun55

個人的にはチケットやバージョン管理やったことない人が始める時は必須にしてしまうのがいいと思ってる。矯正ギプス的な

中村 薫 @kaorun55

で、慣れてきたら取捨選択を考える。

中村 薫 @kaorun55

ただ、速度を上げるとチケット(タスク)の部分がボトルネックになるので、最終的にはやりたいこと(フィーチャー)とゴールがあればいいかと。そういういみではPivotalTrackerのチケット駆動が到達目標。というのが最近の感覚

さかば @sakaba37

Pivotalとかいうのがありましてね、、 RT @kaorun55: TiDDはさかばさんがフレームワーク担当で、あきぴーさんが実装担当のイメージ。no ticket～はさかばさんはオプションだけど、あきぴーさんは必須という立ち位置だと思ってる。

akipii @akipii

なるほど RT @sakaba37: PivotalとかいうのがありましてねRT @kaorun55: TiDDはさかばさんがフレームワーク担当で、あきぴーさんが実装担当のイメージ。no ticket〜はさかばさんはオプションだけど、あきぴーさんは必須という立ち位置だと思ってる。

akipii @akipii

なるほど RT @ryuzee: 確かにあきぴーさんの見解知りたいね RT @kaorun55: TiDDはさかばさんがフレームワーク担当で、あきぴーさんが実装担当のイメージ。no ticket〜はさかばさんはオプションだけど、あきぴーさんは必須という立ち位置だと思ってる。

Toru Nagashima @mysticatea

チケット駆動開発 no ticket, no commitは誤解 | Act as Professional http://t.co/CjpSvv1E チケット駆動開発をアジャイル開発だけでなく〜 という文章に違和感。 順序が逆じゃないかしら。

akipii @akipii

「テーラリング」という概念は僕は正直好きじゃない。プロセスやパッケージ製品はそのままでは導入できず、FG分析や測定評価してやっと少しだけ使える。RUP、CMM、ERPなどのテーラリングの歴史を見れば失敗事例ばかりだ。ERPのカスタマイズ案件ほどデスマーチになりやすい案件はない。

akipii @akipii

ではアジャイル開発にもテーラリングは必須なのか？多分それは違う。XPでもScrumでもプラクティスや原則を都合よく解釈して、部分導入しただけでは多分成功しないと直感している。複数のプラクティスが有機的に結合して初めて「アジャイル」になる。都合のいいテーラリングは効果なしと思う

hirocaster @hirocaster

本日の記事です。提唱者が日本人であることと、自らが執筆した書籍が発売されるので、この夏にチケット駆動開発はブームが起きるかもしれません。 チケット駆動開発 no ticket, no commitは誤解 http://t.co/9eQQHApA

akipii @akipii

RT @HIROCASTER 本日の記事です。提唱者が日本人であることと、自らが執筆した書籍が発売されるので、この夏にチケット駆動開発はブームが起きるかもしれません。 チケット駆動開発 no ticket, no commitは誤解 http://t.co/oTFzje8B

さかば @sakaba37

RUPやCMMでどんな失敗事例かあるのでしょうか？ RT @akipii: RUP、CMM、ERPなどのテーラリングの歴史を見れば失敗事例ばかりだ。ERPのカスタマイズ案件ほどデスマーチになりやすい案件はない。

○○() @ksomemo

[tidd][チケット駆動開発]この誤解とれると大きい / “チケット駆動開発 no ticket, no commitは誤解 | Act as Professional - hiroki.jp by HIROCASTER” http://t.co/oweqq4J6

さかば @sakaba37

ブログを書きました。 / [#TiDD] 書籍「チケット駆動開発」では広い議論を狙っています http://t.co/TRNESSKR

さかば @sakaba37

提唱者というと言い出しっぺのイメージもあるのですが、二人とも言い出しっぺではありません。

akipii @akipii

テーラリングという言葉が好きでないので、Blogの記事を「適用」に修正した。やっぱり違和感がある。

akipii @akipii

平鍋さんが提唱されたPFはアジャイル開発の日本風なテーラリングなのか？多分違う。平鍋さんはアジャイルのエッセンスを深く理解されていて、そのエッセンスをチームビルディングのプラクティス集として抽出した。PFを編み出すためにフィットギャップ分析や都合のよい解釈をしたわけではないはず

さかば @sakaba37

みんな、チケット必須がよほど嫌だったようだ、、

さかば @sakaba37

@akipii フィットギャップ分析とか都合の良い解釈は、テーラリングですか？

杉本啓 @sugimoto_kei

@akipii プラクティスが有機的に結合している（特にXPでは）という理解には賛成です。一方で、ケント・ベックさんは、すべてのプラクティスを一気に採用する必要はない、とも言っているんですよね。この辺、一番難しいところと思います。突き詰めれば、チームそしてメンバの主体性？

杉本啓 @sugimoto_kei

@akipii ・・・（続き）でも、特にXPでは、チームやメンバの主体性さえ、最初に与件として前提されているのではなく、プラクティスの中から「立ち上がってくる 」という面があるんですよね。難しいです。

さかば @sakaba37

好き勝手に改造して、むちゃくちゃにするのがカスタマイズ。すそ上げとか、肩幅を広げるとか、一定のルールや法則に従って仕立て直すのがテーラリングで、そのためにテーラリングガイドが作られると思っています。

akipii @akipii

@sakaba37 過去のプロジェクトにおける開発プロセスやERPのテーラリングで随分嫌な体験をしたので、どうしても違和感がありました。多分僕が興味あるのは、TiDDでいかにアジャイルに開発できるか、であって、WF型開発へのテーラリングに興味が無いだけです(笑)

akipii @akipii

@sugimoto_kei アジャイル開発の個別のプラクティスは品質や効率、進捗管理について何一つ説明していないにも関わらず、複数のプラクティスを組み合わせて初めて高品質で高速な開発が実現されます。アジャイル開発のテーラリングは多分ありえないと思うのです。