タグ

TiDDに関するhokorobiのブックマーク (78)

  • [#TiDD] チケット駆動開発によるプロセス改善(事例) -SPI Japan 2013 - - ソフトウェアさかば

  • トヨタのかんばん方式とバグ追跡システムの密接な関係 - プログラマの思索


     6.10  1BTS() BTSITS BTSPC使  TiDD:  ITi-doIT:   BTSPC BTS
    トヨタのかんばん方式とバグ追跡システムの密接な関係 - プログラマの思索
  • デブサミ2013発表資料(14-B-5)「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ」 #devsumi #devsumiB

    デブサミ2013発表資料(14-B-5)「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ」 #devsumi #devsumiB デブサミ2013、講演関連資料まとめ:CodeZine http://codezine.jp/article/detail/7003 【公開】チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ #devsumi #devsumiB: プログラマの思索 http://forza.cocolog-nifty.com/blog/2013/02/devsumi-devsumi.html

    デブサミ2013発表資料(14-B-5)「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ」 #devsumi #devsumiB
  • チケット駆動開発を上手に運用するためのプラクティス(ゲストブログ) | 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 によるガントチャートでの進捗管理よりも、頻繁な作業の変更

    チケット駆動開発を上手に運用するためのプラクティス(ゲストブログ) | Atlassian Japan 公式ブログ | アトラシアン株式会社
  • TiDD初心者から必ず聞かれる質問~「チケットの粒度」と「チケットの完了条件」 #47redmine #redmine - プログラマの思索

    「チケットの粒度」と「チケットの完了条件」は、TiDD初心者から必ず聞かれる質問だ。 チケット駆動開発を実践している人なら、周囲からいつもこの質問に対して受け答えしていないだろうか? 【参考】 第4回勉強会 - shinagawa.redmine 第4回shinagawa.redmine勉強会 : ATND チケット駆動開発のアンチパターンの事例: プログラマの思索 チケット駆動開発を上手に運用するためのポイント: プログラマの思索 プロジェクトマネージャが抱えるプロジェクト管理の問題: プログラマの思索 【公開】RedmineのFAQとアンチパターン集 #Rxtstudy: プログラマの思索 【1】「チケットの粒度」は、チケットの作り方に悩んでいる人に多い。 チケットが大きすぎると、進捗状況を把握しにくいし開発のリズムも出ない。 現場リーダーがWBSからチケットへ作業を登録する時、1~2

    TiDD初心者から必ず聞かれる質問~「チケットの粒度」と「チケットの完了条件」 #47redmine #redmine - プログラマの思索
  • 【公開】第4回品川Redmine勉強会資料「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ(ベータ版)」 #47redmine - プログラマの思索


    4Redmine() #47redmine 4RedmineCC  4shinagawa.redmine : ATND    7
    【公開】第4回品川Redmine勉強会資料「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ(ベータ版)」 #47redmine - プログラマの思索
  • チケット駆動開発を上手に運用するためのポイント - プログラマの思索

    倉貫さんがチケット駆動開発を上手に運用するためのポイントを公開されていたのでメモ。 実際の経験に裏打ちされているだけあって、とても参考になる。 【元ネタ】 チケット駆動開発で Pivotal Tracker を上手に使うための4つのポイント - Social Change! 高速で無駄のないソフトウェア開発を実現するための7つのポイント - Social Change! 【1】役割分担 (引用開始) Pivotal Trackerを使う役割はざっくり分けると2つです。一つは、開発のためのチケットを登録して、開発されたチケットを「Accept」して終わらせる役割と、もう一つは登録されたチケットを開発していく役割です。前者をプロダクトオーナー、後者をプログラマと呼んでいます。 (引用終了) 倉貫さんの指摘では、顧客がプロダクトーナーの役割を持つので、経営戦略から仕様を決定できるストラテジスト、

    チケット駆動開発を上手に運用するためのポイント - プログラマの思索
  • なぜ日本ではチケット駆動開発が注目されるのか? - ソフトウェアさかば

    このたび、障害管理ツールJIRAなどで有名なアトラシアン様のブログにゲスト記事を投稿させていただきました。この記事は書籍「チケット駆動開発 」の共著者である小川さんの記事とあわせて翻訳され、海外でも紹介される予定です。 私の記事では、外国の方に「なぜ日ではチケット駆動開発が注目されるのか?」という背景を説明しました。多くの方に読んでいただきたいので、このブログでも掲載しておきます。 なぜ日ではチケット駆動開発が注目されるのか? Makoto Sakai / SRA(Software Research Associates,Inc.) 近年、日では書籍が 発売されるなど「チケット駆動開発」が注目を集めています。「チケット駆動開発」が注目されているのは、短期間に大規模開発が行われる日独特のソフト ウェア開発の事情によるものです。しかしその利用方法を見ていると、チケット駆動開発によって、

    なぜ日本ではチケット駆動開発が注目されるのか? - ソフトウェアさかば
  • 【告知】「チケット駆動開発」ハンドブックを出版します - プログラマの思索


    2012/8/24@sakaba37 Redmine 5 @machuTracRedmine  
    【告知】「チケット駆動開発」ハンドブックを出版します - プログラマの思索
  • チケット駆動開発で Pivotal Tracker を上手に使うための4つのポイント | Social Change!

    ソフトウェア開発のタスクはどのように管理するのが効率的なのか。ソフトウェアという目に見えないものを作るためにはタスクの見える化は進捗状況を図る重要な指標になります。ソフトウェア開発で発生するタスクを、バグ管理システム(BTS)や課題管理システム(ITS)を活用することで、タスクの状態とワークフローを管理しようというのがチケット駆動開発です。 チケット駆動開発については、以前に記事を書いたので、そちらを参考にしてください。 チケット駆動開発のススメ〜No ticket! No commit チケット駆動開発をうまく実践するためにはツールが不可欠です。不具合管理や障害管理で使うツールを応用して活用することも出来ますが、最近は専用のツールも出て来ています。ソニックガーデンでは、Pivotal Trackerというツールを使っています。Pivotal Trackerでは「ストーリー」と表記していま

    チケット駆動開発で Pivotal Tracker を上手に使うための4つのポイント | Social Change!
    hokorobi
    hokorobi 2012/06/24
    ディスカッションの結果をチケット化できているのはいいな。
  • チケット駆動開発の適用範囲Part2~チケット駆動開発の運用パターン - プログラマの思索

    チケット駆動開発の適用範囲について考えたことをメモ。 【元ネタ】 チケット駆動開発の適用範囲: プログラマの思索 Twitter / @akipii: チケット駆動開発にはいくつかのパターンがある。タスクカードのように扱うタスク駆動が一番やりやすい。システム運用保守やコールセンターはインシデント駆動。システム提案や要件定義なら課題駆動。 Twitter / @akipii: チケット駆動開発では僕は課題駆動が一番難しいかもと最近思う。SEは顧客から質的な問題を見つけるために課題を何度もぶつけて探す。設計書は課題の回答をパッチのように更新して出来上がる。ソースと同じだ Twitter / @akipii: チケット駆動開発はバグ管理からアジャイル開発へ発展した手法だ。チケット駆動開発をうまく運用できてないチームはバグ管理の基から見直した方がいい。BTSの一つ一つの機能には今までの世界中の

    チケット駆動開発の適用範囲Part2~チケット駆動開発の運用パターン - プログラマの思索
  • [#TiDD] アナログ重視のアジャイルとチケット駆動開発の違い #RxTstudy - ソフトウェアさかば


    RedmineRxTstudy3 Redmine()@agilekawabata 使 webRedmine.JP44  2Redmine.jpRedmine nanocCMSRedmine Backlog 
    [#TiDD] アナログ重視のアジャイルとチケット駆動開発の違い #RxTstudy - ソフトウェアさかば
    hokorobi
    hokorobi 2012/02/05
    最近はシステム運用の中で一人でTracを使っている。やることすべてをチケットにしているわけでもなくて曖昧な状態。Todoリストに何日か滞ったら登録する感じかな。あと、運用手順をWikiに書くようになった。
  • [#TiDD] 2つのアダプタブル・ウォーターフォール開発 - ソフトウェアさかば


    212  WBSBTS/ITS
    [#TiDD] 2つのアダプタブル・ウォーターフォール開発 - ソフトウェアさかば
  • [#TiDD] チケット駆動開発で自律的な組織を目指す - ソフトウェアさかば


     1 
    [#TiDD] チケット駆動開発で自律的な組織を目指す - ソフトウェアさかば
    hokorobi
    hokorobi 2011/10/30
    「小規模で自立的」を目指したつもりだったんだけど、結局、チケットに担当を割り当てて指示するだけになっちゃった。成長を促すようにすることが難しい。自分が阻害要因でもあったはず。
  • 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 コミットの粒度とコミットメッセージあたりですね。 まちゅさんのスライドにもあるように、チケット駆動開発の最も基的な運用ルールは「

    No Ticket, No Commitの効果 - プログラマの思索
  • 【公開】DevLove関西2011発表資料「障害管理からチケット駆動開発へ~BTSから始まる進化の歴史」 #devlove0917 - プログラマの思索


    DevLove西2011BTS #devlove0917 DevLove西2009 Blog  DevLOVE西 - fkino diary(2009-09-26) DevLoveDevLove西()  501 1.5() 
    【公開】DevLove関西2011発表資料「障害管理からチケット駆動開発へ~BTSから始まる進化の歴史」 #devlove0917 - プログラマの思索
    hokorobi
    hokorobi 2011/09/18
    Mantisを引き合いに出してBTSとITSの比較をしているのは、わかりやすくていい。
  • [#TiDD] チケット駆動でAdaptable Waterfall開発! - ソフトウェアさかば


    Adaptable Waterfall 1Extreme Waterfall Extreme Waterfall() 
    [#TiDD] チケット駆動でAdaptable Waterfall開発! - ソフトウェアさかば
  • [#TiDD] チケット駆動開発で気付いたアジャイル開発の仕組み - ソフトウェアさかば


         @agilekawabataXPXP西2006@akipii3 
    [#TiDD] チケット駆動開発で気付いたアジャイル開発の仕組み - ソフトウェアさかば
  • WF型開発にとらわれすぎたTiDDのアンチパターン #tidd - プログラマの思索

    チケット駆動開発を運用してみて、悪いWF型開発のアンチパターンを頻繁に見かける。 考えたことをメモ。 【1】WF型開発がうまくいっているプロジェクトは、手戻り作業をできるだけ減らすように、前工程の品質チェックに力を入れる。 過去の経験値が生きる場合、いわゆるフロントローディングのやり方は有効に作用する。 しかし、僕はWF型の開発スタイルで上手くいった経験はあまりない。 ソフトウェア開発では、技術革新のスピードが早いため、過去の経験値が有効に作用せず、試行錯誤する回数がとても多い。 WF型開発が前提とする手戻り作業を減らす手法は、あまりにも綺麗過ぎる。 試行錯誤やリスクをあまりにも恐れている気がする。 Redmine・Trac・Mantisでチケット駆動開発をやってみると、リリースに至るまでの作業はいつも初めての問題にぶつかって試行錯誤して、どのイテレーションでも同じようにはならない。 チケ

    WF型開発にとらわれすぎたTiDDのアンチパターン #tidd - プログラマの思索
  • チケットの粒度と進捗ビューの関係 - プログラマの思索


      TiDDpart2:  1 RedmineTracMantis ()使   Agile
    チケットの粒度と進捗ビューの関係 - プログラマの思索