TiDD初心者から必ず聞かれる質問～「チケットの粒度」と「チケットの完了条件」 #47redmine #redmine - プログラマの思索
「チケットの粒度」と「チケットの完了条件」は、TiDD初心者から必ず聞かれる質問だ。 チケット駆動開発を実践している人なら、周囲からいつもこの質問に対して受け答えしていないだろうか？ 【参考】 第4回勉強会 - shinagawa.redmine 第4回shinagawa.redmine勉強会 : ATND チケット駆動開発のアンチパターンの事例: プログラマの思索 チケット駆動開発を上手に運用するためのポイント: プログラマの思索 プロジェクトマネージャが抱えるプロジェクト管理の問題: プログラマの思索 【公開】RedmineのFAQとアンチパターン集 #Rxtstudy: プログラマの思索 【1】「チケットの粒度」は、チケットの作り方に悩んでいる人に多い。 チケットが大きすぎると、進捗状況を把握しにくいし開発のリズムも出ない。 現場リーダーがWBSからチケットへ作業を登録する時、1～2
[TiDD] ひとりチケット駆動開発はメールを使え！ - ソフトウェアさかば
XP祭り関西2010で、「ひとりチケット駆動開発は楽しくなかった」と述べましたが、訂正します。 「ひとりチケット駆動開発にBTSは向かない。メールを使うべきだ」 発表の後で、色々な人に「昔からやっているんですけど、忘れないように自分にメールする方が便利なんですよね」と言っていました。でも、倉貫さんがスプレッドシートでチケット駆動開発(TiDD)と言われていたことを思い出して、メールによるものもTiDDであると考えます。 すると私は、ひとりTiDD歴がかれこれ4半世紀になります(チョット自慢<-おじさんなだけですorz)。 まじめな話、メールはひとりTiDDに最適です。こんな感じです。 1) 忘れてはいけない作業が発生したときに、自分にメールします。 2) 必要なら、専用のフォルダを作成してメールを振り分けます。 3) 優先順位の高い作業にはタグなど目印をつけます。 4) 完了していない作業
![[TiDD] ひとりチケット駆動開発はメールを使え！ - ソフトウェアさかば](https://cdn-ak-scissors.b.st-hatena.com/image/square/cb3189f8cb55f68fc5c2b0270b2e8657e0d2eb43/height=288;version=1;width=512/http%3A%2F%2Fsakaba.cocolog-nifty.com%2F.shared-cocolog%2Fnifty_managed%2Fimages%2Fweb%2Fogp%2Fdefault.png)
RedmineとGitを巡る疑問点～Gitとの連携機能の強化がRedmineの課題 - プログラマの思索
RedmineとGitを巡る疑問点をメモ。 詳細は後で書き足す。 【参考】 チケット駆動開発に分散バージョン管理を組み合わせるアイデア: プログラマの思索 分散バージョン管理ツールにおけるブランチ戦略: プログラマの思索 Gitによるチケット駆動開発の事例: プログラマの思索 A successful git branching model とgithub flowの比較: プログラマの思索 第9回RxTstudy勉強会の感想～Redmineとチケット駆動開発の今後の課題 #RxTStudy: プログラマの思索 GitHubのプルリクエスト駆動におけるチケット駆動開発の問題点: プログラマの思索 【1】Redmineは日本のSIでかなり普及しているらしい。 その状況と並行して、オープンソース界隈では、GitHubでチケット管理する運用も多い。 すると、最近の状況としては、RedmineとG
GitHubのプルリクエスト駆動におけるチケット駆動開発の問題点 - プログラマの思索
GitHubのプルリクエスト駆動におけるチケット駆動開発の問題点について指摘していた記事があったのでメモ。 【参考】 GitHub でチケット駆動開発とプルリクエスト駆動開発を併用する - mallowlabsの備忘録 GitHub の Issue をあとから Pull Request にする (あとからコードを添付する) - Qiita [キータ] Fujimura ? GitHubで既存のissueに対してpull requestする hub コマンドで github から fork して pull request をさくっと - #生存戦略 、それは - subtech Git+Redmineな人におすすめのフックスクリプト集 - みずぴー日記 bleis-tift/Git-Hooks かんばん！～もし女子高生がRedmineでスクラム開発をしたら（6）：Redmine×Gitのハー
なぜ日本ではチケット駆動開発が注目されるのか？(ゲストブログ) | Atlassian Japan 公式ブログ | アトラシアン株式会社
今回はゲストブログです。今、日本のソフトウェア開発において注目されており、先日書籍も出版された「チケット駆動開発」について2回に渡り紹介していきます。今回は Part 1 ということで著者のお一人である Makoto Sakai 様から寄稿頂きました。 Makoto Sakai / SRA (Software Research Associates,Inc.) 近年、日本では書籍が発売されるなど「チケット駆動開発」が注目を集めています。「チケット駆動開発」が注目されているのは、短期間に大規模開発が行われる日本独特のソフトウェア開発の事情によるものです。しかしその利用方法を見ていると、チケット駆動開発によって、分散開発が可能な電子カンバン、チケットを中心としたコミュニケーション、ツール連携と情報の管理、ワークフローによるプロセスの自動化、などソフトウェア開発における制約を取り除く事を目的とし
トヨタのかんばん方式とバグ追跡システムの密接な関係 - プログラマの思索
「実践 反復型ソフトウェア開発」の6.10節「トヨタのかんばん方式とバグ追跡システム」がとても興味深かった。 チケット駆動開発との関係も含めて、ラフなメモ書き。 【1】BTS(バグ追跡システム)は、本来は障害管理から生まれた。 だが、BTSの開発フローがソフトウェア開発にとても有効であったために、タスク管理やユーザのサポート管理として扱うITSないしチケット駆動開発へ発展した。 BTSのチケットは、PCやサーバーなどの資産管理にも使える。 そのアイデアは下記に書いた。 情報システム部門がTiDDを運用する時の注意点: プログラマの思索 IT資産管理システムi-doIT: プログラマの思索 「実践 反復型ソフトウェア開発」では、BTSチケットをPC資産のようなハードウェアと紐づけて管理するのはとても有効だろう、そこからトヨタのかんばん方式へ発展させるのは自然なアイデアだと書いている。 BTS
チケット駆動開発で作業管理はしないほうがいい - arclamp
先日、2013/3/23（土）に弊社でチケット駆動と開発環境に関するイベントを開催しました。リンク先には資料も上がっていますので参照ください（※アトラシアン製品関連のイベントです）。 基調講演にはチケット駆動開発を推進されている関西XPUGのあきぴーさんをお招きして「チケット駆動開発をパターン言語で読み解く」という話をしていただき、最終枠ではパネルディスカッションをしました。 チケット駆動開発とウォーターフォール パネルディスカッションでは、僕が「チケット駆動開発を作業計画に使うのは難しく、WBSとの併用が現実的」と話し、あきぴーさんが「作業計画をチケット駆動開発で回していくには」というノウハウを紹介されていました。 この違いは僕がウォーターフォール的な新規案件を、あきぴーさんがアジャイル的な開発/保守運用案件を前提にしているためです。 僕自身はBTS（Bug Tracking Syste
チケット駆動開発を導入しても変わらないこと - rabbit2goのブログ
Tracのようなツールを導入してチケット駆動開発を始めた人から必ず聞かれる質問の1つに、下記のようなものがある。 「チケットの数が多くて管理出来ません。やっぱりチケット駆動開発は無理です」 確かに、やること、やらねばならない事を片っ端からピックアップしてチケットへ放り込んでいくと、小さなプロジェクトでもあっという間にチケットの山が出来てしまう。沢山のチケットが並んでいるレポート画面を見るだけでも嫌になるし、ウンザリした気分にさせられるのは確かだから、このような拒否反応を示すのだろう。 でも、良く考えてみれば、これは少々変な話しだ。チケットで表現されている内容は、本質的にチケット駆動開発とは何ら関係の無く、従来からプロジェクトの中には存在していはずだ。今までの作業の中で、例えばWBSのような形でタスクの管理を行って来たのであれば、チケットは単にその形が変わっただけのものだから、チケットの数は
チケット駆動開発 - Wikipedia
チケット駆動開発 (ticket-driven development; TiDD) とは、プログラム開発手法の一種で、作業をタスクに分割しBTS（Bug Tracking System／バグ管理システム）のチケットに割り当てて管理を行う開発スタイル[1]。細かな修正作業の多い従来開発の中で生まれたが、アジャイル開発との親和性が高い[2]ことから、エクストリーム・プログラミングをはじめとするアジャイル開発でも実践されている。 はじまり[編集] チケット駆動開発が提案された2007年ころはソフトウェア開発環境が充実し、Subversion、trac、ウィキを活用したプロジェクト運営が注目されていた[3]。そのような中で、たくさんの細かな修正を効率よく行う方法として「チケット駆動開発」が現場から生まれた。 チケット駆動開発は、まちゅ氏のITpro Challenge のライトニングトーク「もう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
