[#TiDD] アナログ重視のアジャイルとチケット駆動開発の違い #RxTstudy
Redmineとタスクマネジメントの勉強会であるRxTstudyの第3回勉強会に参加しました。
「Redmineプラグインの作り方(仮)」:@agilekawabataさん
残念ながら懇親会費の集計やお釣りの準備などで、川端さんプラグインのお話はあまり聞けませんでしたが、キチンとフックを使ってプラグインが完成したようです。あとでお勉強しようと思います。
webサイト「Redmine.JP」 4年4ヶ月: 前田 剛さん
2番目の前田さんは、私も色々とお世話になっているRedmine.jpというサイトのお話でした。アンオフィシャルではありますが、多くのRedmineユーザがお世話になっていると思います。 nanocというテキストベースのCMSで管理されているそうです。Redmineの普及とともにドンドン稼いでいただいて、今後もさらに良いサイトにしていただきたいと思います。
Backlog の開発で大事にしていること:@tksmdさん
どのようにより良いUiを作るか、「仕事を楽しくして何が悪い!」と、どのように開発者の能力を発揮させるかという熱い発表でした。技術者として、より良いものを作るという姿勢がうらやましく思えました。発表の中でサブタスキングの要望に対して、説明できないものは導入しないとの姿勢でしたが、Rubyの松本さんの名言「ある種の制約は自由を増す」という側面もあるのではないかと思いました。
チームにRedmineを適用せよ:@daipresents 藤原 大さん
先日も品川Redmineで発表された藤原さんですが、今回は別の内容でお話ししていただけました。今回は品川で、疑問だったRedmineのタスク管理をやめてアナログにされたことについて、ヒントをいただきました。Scrumを進めているうちに、Redmineのチケットがの更新が負担なったこと、タスクは2-3日ぐらいの粒度にそろえているというお話でした。あと、Doingのチケットは2枚までにされているとのことでした。
メリットから考えるアジャイルとチケット開発の違い
チケットの粒度は良く議論されるところです。私は細かなチケットがBTSへの依存を増し、仕事のミスを減らしてくれると思っています。XPJUG関西で議論した際も、チケットは付箋、備忘録のように使う、という議論がありました。これは、ライフハックのGTD(リンク先はWikipedia)のような考え方です。作業の大きさではなく、リスクに気付けば、チケットを切り、プロジェクトのリスクを共有していく開発法だと思っています。
一方、Scrumのようなアナログ重視のアジャイル開発ではタスクの粒度をそろえて、プロジェクト全体を見渡せるようにします。プロジェクト全体でゴールを共有し、作業を進めていきます。
チケットあるいはタスクカードの粒度を除けば同じようなことをしているのですが、重視するものが違うように思います。タスク(チケット)の粒度をそろえられるということは、そこに含まれる細かな問題は把握されていることがある程度前提とされていると思います。つまり経験値の高い熟練者なのでできると思います。もちろん、細かな問題はあるでしょうから、それは、それは早めに小さく失敗するということなのでしょう。
一方のチケット駆動開発は、そんなに安心できない未経験なことが多く発生するプロジェクトに有効です。わからないことが多いから気付いた人がチケットを登録し、問題点をを皆で共有し、協力します。これは次々と色々なアプリケーションを色々な環境で開発する独立系の会社や、新規性の高い戦略的な開発などに有効なのかもしれません。
この辺りは懇親会で皆さんと議論していたところなのですが、残念ながら藤原さんとはあまりお話しできなかったので、いつか議論させていただきたいと思います。
Agile Japan 2012でお話しします。
さて、3月16日(金)に大阪のATCホールでAgile Japan 2012が開催されます。これまでAgile Japanは東京で開催され、大阪はサテライトの扱いでしたが、今年は初めて大阪で開催されます(RxTstudyも後援してます)。
この中のセッション「チケット駆動開発の課題と展望」で、小川(あきぴー)さん、中村 洋さんと共にお話しさせていただきます。チケット駆動開発の背景にあるビジョンについてお話しするつもりですので、今回の議論にも少し触れると思います。
なお、今回のキーノートスピーカーは、アジャイルサムライのJonathan Rasmussonさんです。ぜひお越しください。
« [#TiDD] チケット駆動開発で困難を乗り切ろう! #47redmine | トップページ | [#TiDD] プロジェクトを成功に導くチケット駆動開発のビジョン »
「チケット駆動開発」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- [#TiDD] ポケモンGOにチケット駆動開発のポイントを学ぶ(2018.05.01)
- [#TiDD] プロジェクトを成功させるチケット管理(2017.07.02)
この記事へのコメントは終了しました。
« [#TiDD] チケット駆動開発で困難を乗り切ろう! #47redmine | トップページ | [#TiDD] プロジェクトを成功に導くチケット駆動開発のビジョン »
コメント