トヨタのかんばん方式とバグ追跡システムの密接な関係 - プログラマの思索
「実践 反復型ソフトウェア開発」の6.10節「トヨタのかんばん方式とバグ追跡システム」がとても興味深かった。 チケット駆動開発との関係も含めて、ラフなメモ書き。 【1】BTS(バグ追跡システム)は、本来は障害管理から生まれた。 だが、BTSの開発フローがソフトウェア開発にとても有効であったために、タスク管理やユーザのサポート管理として扱うITSないしチケット駆動開発へ発展した。 BTSのチケットは、PCやサーバーなどの資産管理にも使える。 そのアイデアは下記に書いた。 情報システム部門がTiDDを運用する時の注意点: プログラマの思索 IT資産管理システムi-doIT: プログラマの思索 「実践 反復型ソフトウェア開発」では、BTSチケットをPC資産のようなハードウェアと紐づけて管理するのはとても有効だろう、そこからトヨタのかんばん方式へ発展させるのは自然なアイデアだと書いている。 BTS
チケット駆動開発を上手に運用するためのプラクティス（ゲストブログ） | Atlassian Japan 公式ブログ | アトラシアン株式会社
前回のゲストブログ Part 1 に続き今回は Part 2 をお届けします。今、日本のソフトウェア開発において注目されており、先日書籍も出版された「チケット駆動開発」について紹介するシリーズの後編です。Part 2 はもう一人の著者である akipii 様から寄稿頂きました。 akipii / XPJUG Kansai (eXtreme Programming Japan User Group at Kansai) 概要 チケット駆動開発 (TiDD) とは、JIRA や Redmine などのチケット管理から生まれたプロジェクト管理の技法の一つです。「ソフトウェア開発に現れる全ての作業や課題はチケットに起票してから開発する」という原則 (Ticket First) を守り、チケットを中心に開発する手法です。 従来の Excel によるガントチャートでの進捗管理よりも、頻繁な作業の変更
TiDD初心者から必ず聞かれる質問～「チケットの粒度」と「チケットの完了条件」 #47redmine #redmine - プログラマの思索
「チケットの粒度」と「チケットの完了条件」は、TiDD初心者から必ず聞かれる質問だ。 チケット駆動開発を実践している人なら、周囲からいつもこの質問に対して受け答えしていないだろうか？ 【参考】 第4回勉強会 - shinagawa.redmine 第4回shinagawa.redmine勉強会 : ATND チケット駆動開発のアンチパターンの事例: プログラマの思索 チケット駆動開発を上手に運用するためのポイント: プログラマの思索 プロジェクトマネージャが抱えるプロジェクト管理の問題: プログラマの思索 【公開】RedmineのFAQとアンチパターン集 #Rxtstudy: プログラマの思索 【1】「チケットの粒度」は、チケットの作り方に悩んでいる人に多い。 チケットが大きすぎると、進捗状況を把握しにくいし開発のリズムも出ない。 現場リーダーがWBSからチケットへ作業を登録する時、1～2
【公開】第4回品川Redmine勉強会資料「チケット駆動開発のフレームワーク～現場の経験知からパターン言語へ(ベータ版)」 #47redmine - プログラマの思索
【公開】第4回品川Redmine勉強会資料「チケット駆動開発のフレームワーク～現場の経験知からパターン言語へ(ベータ版)」 #47redmine 本日行われた第4回品川Redmine勉強会の発表資料をCCアトリビューションライセンスで公開します。 スタッフの皆さん、参加者の皆さん、お疲れ様でした。 第4回shinagawa.redmine勉強会 : ATND 今僕が考えている「チケット駆動開発をパターン言語で表現できるか」という問題に対して、勉強会のお題「チケットの粒度」「チケットの完了条件」について当てはめると、どれだけ本質に迫れるか、考えた結果を話しました。 内容は完成版でないし、解法は一つではないです。 オープンディスカッションの前座として、どれだけ皆の議論を引き出せるか、という観点で話しました。 オープンディスカッションでは7チームで議論してもらった結果、白熱したチームもあれば、違
チケット駆動開発を上手に運用するためのポイント - プログラマの思索
倉貫さんがチケット駆動開発を上手に運用するためのポイントを公開されていたのでメモ。 実際の経験に裏打ちされているだけあって、とても参考になる。 【元ネタ】 チケット駆動開発で Pivotal Tracker を上手に使うための4つのポイント - Social Change! 高速で無駄のないソフトウェア開発を実現するための7つのポイント - Social Change! 【1】役割分担 (引用開始) Pivotal Trackerを使う役割はざっくり分けると２つです。一つは、開発のためのチケットを登録して、開発されたチケットを「Accept」して終わらせる役割と、もう一つは登録されたチケットを開発していく役割です。前者をプロダクトオーナー、後者をプログラマと呼んでいます。 (引用終了) 倉貫さんの指摘では、顧客がプロダクトーナーの役割を持つので、経営戦略から仕様を決定できるストラテジスト、
なぜ日本ではチケット駆動開発が注目されるのか？ - ソフトウェアさかば
このたび、障害管理ツールJIRAなどで有名なアトラシアン様のブログにゲスト記事を投稿させていただきました。この記事は書籍「チケット駆動開発 」の共著者である小川さんの記事とあわせて翻訳され、海外でも紹介される予定です。 私の記事では、外国の方に「なぜ日本ではチケット駆動開発が注目されるのか？」という背景を説明しました。多くの方に読んでいただきたいので、このブログでも掲載しておきます。 なぜ日本ではチケット駆動開発が注目されるのか？ Makoto Sakai / SRA(Software Research Associates,Inc.) 近年、日本では書籍が 発売されるなど「チケット駆動開発」が注目を集めています。「チケット駆動開発」が注目されているのは、短期間に大規模開発が行われる日本独特のソフト ウェア開発の事情によるものです。しかしその利用方法を見ていると、チケット駆動開発によって、
【告知】「チケット駆動開発」ハンドブックを出版します - プログラマの思索
2012/8/24に@sakaba37さんと「チケット駆動開発～プロジェクトを成功に導くための「現場からの改善」提案を完全網羅」を出版します。 前作「Redmineによるタスクマネジメント実践技法」に続くチケット駆動開発の解説本になります。 過去5年間、チケット駆動開発とは如何なるもので、一体何ができるのか、という根本的な問題をずっと考えてきた結果を全て書きました。 元々は@machuさんがTracのチケット管理から提唱したアイデアを参考にして、故意にそのアイデアを拡張して、Redmine上でアジャイル開発を実践できるように、自分なりのノウハウを詰め込みました。 その後、チケット駆動開発について講演したり、コミュニティで議論しながら、アジャイル開発だけでなく、技術や開発プロセス全般、ソフトウェア工学など色んな観点で分析するように努めてきました。 そして、チケット駆動開発に関する技法や適用方
チケット駆動開発で Pivotal Tracker を上手に使うための4つのポイント | Social Change!
ソフトウェア開発のタスクはどのように管理するのが効率的なのか。ソフトウェアという目に見えないものを作るためにはタスクの見える化は進捗状況を図る重要な指標になります。ソフトウェア開発で発生するタスクを、バグ管理システム（BTS）や課題管理システム（ITS）を活用することで、タスクの状態とワークフローを管理しようというのがチケット駆動開発です。 チケット駆動開発については、以前に記事を書いたので、そちらを参考にしてください。 チケット駆動開発のススメ〜No ticket! No commit チケット駆動開発をうまく実践するためにはツールが不可欠です。不具合管理や障害管理で使うツールを応用して活用することも出来ますが、最近は専用のツールも出て来ています。ソニックガーデンでは、Pivotal Trackerというツールを使っています。Pivotal Trackerでは「ストーリー」と表記していま
チケット駆動開発の適用範囲Part2～チケット駆動開発の運用パターン - プログラマの思索
チケット駆動開発の適用範囲について考えたことをメモ。 【元ネタ】 チケット駆動開発の適用範囲: プログラマの思索 Twitter / @akipii: チケット駆動開発にはいくつかのパターンがある。タスクカードのように扱うタスク駆動が一番やりやすい。システム運用保守やコールセンターはインシデント駆動。システム提案や要件定義なら課題駆動。 Twitter / @akipii: チケット駆動開発では僕は課題駆動が一番難しいかもと最近思う。SEは顧客から本質的な問題を見つけるために課題を何度もぶつけて探す。設計書は課題の回答をパッチのように更新して出来上がる。ソースと同じだ Twitter / @akipii: チケット駆動開発はバグ管理からアジャイル開発へ発展した手法だ。チケット駆動開発をうまく運用できてないチームはバグ管理の基本から見直した方がいい。BTSの一つ一つの機能には今までの世界中の
[#TiDD] アナログ重視のアジャイルとチケット駆動開発の違い #RxTstudy - ソフトウェアさかば
Redmineとタスクマネジメントの勉強会であるRxTstudyの第3回勉強会に参加しました。 「Redmineプラグインの作り方(仮)」：@agilekawabataさん 残念ながら懇親会費の集計やお釣りの準備などで、川端さんプラグインのお話はあまり聞けませんでしたが、キチンとフックを使ってプラグインが完成したようです。あとでお勉強しようと思います。 webサイト「Redmine.JP」 4年4ヶ月： 前田 剛さん 2番目の前田さんは、私も色々とお世話になっているRedmine.jpというサイトのお話でした。アンオフィシャルではありますが、多くのRedmineユーザがお世話になっていると思います。 nanocというテキストベースのCMSで管理されているそうです。Redmineの普及とともにドンドン稼いでいただいて、今後もさらに良いサイトにしていただきたいと思います。 Backlog の開
[#TiDD] ２つのアダプタブル・ウォーターフォール開発 - ソフトウェアさかば
従来型の開発をチケット駆動開発によって補完するアダプタブル・ウォーターフォールには、大きく分けて２つのパターンがあります。 １）全工程2重管理型 これは上流工程から下流工程までチケット駆動開発するものです。すべてのタスクをチケットで管理しますが、既存のプロジェクト管理と併用します。既存のプロジェクト管理では、ベースラインごとに計画が定められてそれを基準にプロジェクトの予実が管理されます。チケットに登録されるタスクはベースラインで定められたタスク、あるいは、より詳細化したタスクから始めますが、必要に応じて計画が変更されます。 この方法はすべての管理をチケットを中心に実施する完全型チケット駆動開発に似ています。チケットは階層構造を持っていますので、WBSをそのまま表現することができます。BTS/ITSのガントチャートによる進捗報告が許されるなら、管理を一元化できますので、多くのメリットが生まれ
[#TiDD] チケット駆動開発で自律的な組織を目指す - ソフトウェアさかば
自律的な組織とはリーンソフトウェア開発で「海兵隊」で示されたような、自己決定のための裁量権を持っていて、課題や問題を自らの判断で解決できる組織です。集中体制は変化に弱く、想定外の事象によって独裁国家の様に一気に崩壊する危険性をはらんでいます。これに対して自律的組織は、オブジェクト指向のメタファに用いられる多くの細胞の組み合わせからなる生命体のような構造です。各細胞に対する攻撃は、各細胞やその近隣の細胞で解決されますので、想定外の事象にも比較的強い構造といえます。 自律的組織を実現するには自己決定権を実現するための見積もり技術が不可欠ですが、ここでは単に裁量権の観点で議論してみます。 １．アジャイル開発における自律的な組織 アジャイル開発においては、開発組織とユーザとの間で、優先順位したがって各イテレーションのスコープが決定され、開発組織の裁量で開発作業のタスクが実施されていきます。タスクは
No Ticket, No Commitの効果 - プログラマの思索
No Ticket, No Commitの効果について考えたことをメモ。 【元ネタ】 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) 明日からできる！バージョン管理システムへのコミット粒度を最適化するトレーニング方法 - 刺身☆ブーメランのはてなダイアリー Twitter / @yusuke_kokubo:RedmineのリポジトリをウォッチしてるとJPLのコミットの粒度の適切さに感心する。Redmineの使い方はredmine.orgに学ぶことが多い。(それにくらべてBacklogsプラグインは…ゴニョゴニョ) Twitter / @yusuke_kokubo: @akipii コミットの粒度とコミットメッセージあたりですね。 まちゅさんのスライドにもあるように、チケット駆動開発の最も基本的な運用ルールは「
【公開】DevLove関西2011発表資料「障害管理からチケット駆動開発へ～BTSから始まる進化の歴史」 #devlove0917 - プログラマの思索
【公開】DevLove関西2011発表資料「障害管理からチケット駆動開発へ～BTSから始まる進化の歴史」 #devlove0917 DevLove関西は2009年にも開催されていましたが僕は参加できませんでした。 ですが、下記のBlogからその情熱は感じ取りました。 だから、僕自身も無意識に熱くなっていたのかもしれません。 DevLOVE関西に心を込めて花束を - fkino diary(2009-09-26) DevLoveは情熱的なコミュニティと知ってましたが、今日のDevLove関西も懇親会(渾身会と呼ぶらしい)も、高校生の文化祭や高校野球みたいなノリノリの雰囲気でした。 楽しかったです。 肝心の発表は50分枠だったので余裕で話せるだろうと思ったのですが、1時間近く話しても言い足りなかった。 よしうみさんから、今日のあきぴーさんは1.5倍速でしたよ、と言われてしまった(笑) 上記の資
[#TiDD] チケット駆動でAdaptable Waterfall開発！ - ソフトウェアさかば
前に書いたようにチケット駆動揮発の特徴はプロジェクト改善です。そのプロセスはアジャイル的で、アジャイル開発においても効果的であるほか、従来型の開発においても管理上の問題を補完して効果を発揮するものです。これらはそれぞれ、完全型、補完型のチケット駆動開発と呼ばれています。ここでは、補完型のチケット駆動開発をAdaptable Waterfall 開発として再定義したいと思います。 １．Extreme Waterfallの限界 品質管理を強化した日本的な従来型開発をExtreme Waterfallと呼ばれています。実装に至るまでの課題をあらかじめ検討しておいて、定量的な数値(メトリクス)を用いて管理することで安定した開発を行うというものです。 このような従来型の開発において混乱の原因となるのが、仕様変更や予想外の不具合、実行環境の変化です。これらは、昔からある混乱原因です。それぞれ変更管理、
[#TiDD] チケット駆動開発で気付いたアジャイル開発の仕組み - ソフトウェアさかば
結果は最悪でした。 ・タスクが荒くて進捗が見えない ・めったに更新しないので、誰も参照しない ・リスクが高く、だらだらした開発 当時はアジャイルの親切な本もなく、アジャイルの良さとしてタイムボックス管理によるスコープの変更がようやく知られるようになった頃でしたので、なぜ失敗したかも良くわかりませんでした。 その後、@agilekawabataさんと出会い、XPのプラクティスに関する論文を書いたり、XP祭り関西の2006のスタッフなどをして理解を深めましたが、それぞれのプラクティスと繰り返し開発のメリットは感じたものの、過去の失敗の原因としてピンとくるものはありませんでした。さらにしばらくして@akipiiさんと出会い、聞きかじったチケット駆動開発を実践することで、ようやくアジャイル開発の仕組みに気付いたのです。 ３．チケット駆動開発で気付いたアジャイル開発の仕組み チケット駆動開発を簡単に
WF型開発にとらわれすぎたTiDDのアンチパターン #tidd - プログラマの思索
チケット駆動開発を運用してみて、悪いWF型開発のアンチパターンを頻繁に見かける。 考えたことをメモ。 【1】WF型開発がうまくいっているプロジェクトは、手戻り作業をできるだけ減らすように、前工程の品質チェックに力を入れる。 過去の経験値が生きる場合、いわゆるフロントローディングのやり方は有効に作用する。 しかし、僕はWF型の開発スタイルで上手くいった経験はあまりない。 ソフトウェア開発では、技術革新のスピードが早いため、過去の経験値が有効に作用せず、試行錯誤する回数がとても多い。 WF型開発が前提とする手戻り作業を減らす手法は、あまりにも綺麗過ぎる。 試行錯誤やリスクをあまりにも恐れている気がする。 Redmine・Trac・Mantisでチケット駆動開発をやってみると、リリースに至るまでの作業はいつも初めての問題にぶつかって試行錯誤して、どのイテレーションでも同じようにはならない。 チケ
チケットの粒度と進捗ビューの関係 - プログラマの思索
チケットの粒度と進捗ビューの関係について、考えたことをメモ。 【元ネタ】 TiDD初心者によく聞かれる質問part2～チケットの粒度はどれくらいが妥当ですか？: プログラマの思索 【1】チケットの粒度はどれくらいが妥当か？という質問はよく聞く。 RedmineやTrac、Mantisで色々試行錯誤した結果、気にせず登録した方がいい、という回答にしている。 その代わり、トラッカー(ワークフロー)単位では粒度を揃えて、ビューによる切り替えを上手く使えばいい、と回答することにしている。 前者の回答は、チケット駆動開発を運用した場合、チケットはタスク、要望、課題、問合せなど色んな種類があるので、そもそも観点が異なるし、粒度を揃えること自体が無意味だからだ。 開発者の観点では、チケットの粒度を揃えて綺麗にチケットを書くよりも、成果物を早く作るための作業記録代わりにみなした方がいい。 Agile開発な
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[#TiDD] チケット駆動開発によるプロセス改善(事例) -SPI Japan 2013 - - ソフトウェアさかば
デブサミ2013発表資料(14-B-5)「チケット駆動開発のフレームワーク～現場の経験知からパターン言語へ」 #devsumi #devsumiB
