3月末が期限だったtracのマイルストーンをクローズする。「チケットキーパーという存在」として、未解決のチケットについてはマイルストーンの変更（要するに先送りだ）や、担当者にチケット更新の催促を行う。幾つかのチケットはクローズ出来たものの、中にはクローズを認められないものも有る。例えば、こんなチケットだ。 やるやる詐欺型 「次回はレビューを行います」「確実なチェックを実施します」なんて書かれているけれど、今までそんなことが実際に行われて成果を上げているなんて聞いたことがないし、そもそも次回の開発時には、こんな回答すら忘れられていることが多い。だから、作業手順書を改訂する、チェックリストに確認項目を追加する、実際にレビューを行うなど具体的なアクションが完了するまでチケットはクローズ出来ない。 フィードバック欠如型 障害の修正だけで作業が終わってしまい、再発予防策とか未然防止策が実施されていな
XP祭り2010のチケット駆動開発(TiDD)パネルで、倉貫さんがgoogleスプレッドシートでTiDDをされていたことに、あきぴーさんはあきぴーさんは納得されていない様子です。 個人的には作業を見える化してコミュニケーションを図るという意味で、「あり」だと思いますが、あきぴーさんのこだわりの中ににTiDDを整理するヒントがありそうなので、BTSだとなぜ良いかを考えてみました。 1) 個人のビュー＝ひとりスクラム TiDDでは毎朝、あるいは作業が終わったときなどに、担当している作業の一覧を確認し、今後の進め方を計画します。作業開始後はその作業に集中して実施します。この一連の流れは、スクラムと非常に似ています。 スクラムでは、チームが要求されている作業の一覧があり、プロダクトオーナによってその優先順位がみめられます。次にスプリントの作業を決めるために、スプリントミーティングによって対象のプロ
![[TiDD] BTSがチケット駆動開発に向いている理由 - ソフトウェアさかば](https://cdn-ak-scissors.b.st-hatena.com/image/square/cb3189f8cb55f68fc5c2b0270b2e8657e0d2eb43/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttp%2Fsakaba.cocolog-nifty.com%2F.shared-cocolog%2Fnifty_managed%2Fimages%2Fweb%2Fogp%2Fdefault.png)
XP祭り関西2010で、「ひとりチケット駆動開発は楽しくなかった」と述べましたが、訂正します。 「ひとりチケット駆動開発にBTSは向かない。メールを使うべきだ」 発表の後で、色々な人に「昔からやっているんですけど、忘れないように自分にメールする方が便利なんですよね」と言っていました。でも、倉貫さんがスプレッドシートでチケット駆動開発(TiDD)と言われていたことを思い出して、メールによるものもTiDDであると考えます。 すると私は、ひとりTiDD歴がかれこれ4半世紀になります(チョット自慢<-おじさんなだけですorz)。 まじめな話、メールはひとりTiDDに最適です。こんな感じです。 1) 忘れてはいけない作業が発生したときに、自分にメールします。 2) 必要なら、専用のフォルダを作成してメールを振り分けます。 3) 優先順位の高い作業にはタグなど目印をつけます。 4) 完了していない作業
ソフトウェア開発のタスクをチケットに登録すると、作業を始めるチケット管理をメインに、進ちょく管理、問題管理などができる。 バグ管理システムだけでなく課題管理システム（ITS：Issue Tracking System）で運用する開発プロセスは、チケット駆動開発（TiDD：Ticket Driven Development）と呼ばれ、最近注目されている。 Ruby1.9の開発はRedmineで管理されているように、近ごろは事例も増えている。 Redmine運用前の問題点 筆者がRedmine運用前に持っていたプロジェクト管理の問題点は下記2点だった。 1．Excelでのタスク管理の限界 従来からプロジェクトマネージャやプロジェクトリーダーの多くは、進ちょく管理やタスク管理をExcelで行ってきた。 プロジェクト管理では顧客へ進ちょく報告するために、残工数と残タスク数を計算する必要がある。だが
書籍「実践バグ管理」執筆体験記（1） - 執筆の開始と出版社への提案
【1】管理者は、プロジェクトの進捗報告のためのくだらない作業が必要になる。 まず、初期段階で、WBSとして必要な成果物、作業を洗い出す。 そこから、工数を見積もり、MSProjectやExcelでスケジュールを作っていく。 しかし、実際に作業していくと、そのスケジュールの保守は面倒きわまりない。 当初は分からなかったタスクを追加したり、仕様変更で対応すべきタスクを入れたり、実際は不要になったタスクを削除するなどを、逐一スケジュールへ反映しなければならない。 スケジュールで、先行・後行の関係まで考慮したり、工数の標準化などを行おうとすると、もはやExcelで手作業で管理するのはもはや人間の手を超える。 MSProjectでは、そのような作業をアプリでやってくれるが、だからと言って、スケジュール保守が楽になるわけではない。 そのスケジュールを管理者が常に保守し続けなければならない理由は二つある
Canonicalは29日 (英国時間)、オープンソース開発プロジェクトのホスティングシステム「LaunchPad 2.0」をリリースした。Webサイトでは、LaunchPad 2.0の新機能を紹介するツアーの公開が開始されている。 メジャーアップデートとなる今回のリリースでは、新たにインターネットサービスAPI (β版) を提供。外部アプリケーションによる認証や、LaunchPad上のデータベースを対象とした検索 / 修正の実行に対応する。懸案とされていたメーリングリストの運用も可能になったほか、Webインターフェイスの改良も実施されている。 バグトラッキングシステムの「Bugzilla」と「Trac」との連携も可能になり、不具合情報の管理が効率化された。分散バージョン管理システム「Bazzar (bzr)」も強化され、大規模なコードへの対応が容易になったほか、コードの変更に伴うバージョ
【バグ管理の作法】バグ管理のノウハウ 第3回：バグの優先順位はこう付けろ！ 著者：TIS 栗栖 義臣 公開日：2007/12/18（火） バグレベルを定義する 「第2回：紙か？ Wordか？ Excelか？ BTSか？」では、バグ管理におけるバグ情報を集約する重要性について解説した。 管理者のもとに集められたバグは、「バグかどうかの確認」を行い、バグと認められたものについて「バグ対応の優先順位付け（バグのレベル定義）」を行う。 バグかどうかの確認 報告されたバグは、まずバグ票の記載に従い再現するかどうかの確認を行う。もし、この再現性の確認で、バグ票に記載されている動作が再現しなければ、そのバグはステータスを「再現待ち」もしくは「VOID」にしておく。 ここでバグ票の内容が再現されても、バグとして判断されない場合がある。それは「確認した環境に問題があった」「データに問題があった」「仕様であっ
こんにちは！やまもと＠テスト番長です。 最近TEF(Testing Engineer's Forum)-ソフトウェアテスト技術者交流会 の有志によって日本語化されたTestLinkというオープンソースのテストケース管理ツールがあるのですが、同じくオープンソースのBTSであるMantisと連携させる方法が紹介されています。 TestLinkとバグ管理システムMantisの統合http://swproject.g.hatena.ne.jp/keyword/TestLink%e3%81%a8Mantis%e3%81%ae%e7%b5%b1%e5%90%88 BTSは導入していても、テストケースは管理されていないか、Excelなどでリストを編集しているケースは非常に多いと思います。 テストケース管理システムは使い慣れないと煩雑に感じる反面、ある程度以上テスト項目を洗練させるには是非導入したいツ
なんかこのエントリが好評だったので、みなさんプロジェクト管理ツールに興味があるのかと思い、とりあえずTracとredMineの比較表を作ってみました。 Google Docs & SpreadSheet で作ってますので、間違いがあったらちょいちょい修正するかもしれません。 ↓sheetのURLはこちら http://spreadsheets.google.com/pub?key=piV-xE0pxQrgxSmrLXZf_ZA PJで実際にTracを使った経験と、redMineを触ってみた感触から考えると、Tracはプログラミング中心のチーム向きで、redMineは作業系のタスクが多いチーム向きなのかなぁと思います。 後は、自分でごりごりカスタマイズしていきたい人はTrac、プラグインのインストールとかめんどくさいって人はredMineという棲み分けもあるかも。
2006年12月07日 TypePadのテストで使っている3つのツール こんにちは、主に TypePad の QA を担当している山口と申します。今回は生粋の文系人間の私のどきどき Tech Talk を初体験をお伝えします。いろんな意味でなぜ？・・と疑問に思う方もいらっしゃると思いますが、私も同じ気持ちです。Tech Talk とは、毎週金曜日に弊社内で行われているエンジニアの情報共有や、ゲストを迎えて様々なお話を聞いたりする会で、普段は現役のエンジニアが Tech Talk を担当するのですが、ひょんなことから私がスーパーなエンジニアの前で話すことになってしまったのです！ 事件の始まり それは一つのブックマークが始まりでした。シックス・アパートのエンジニアでは、情報共有用の del.icio.us アカウントが存在します。アカウントそのものを共有するのではなく、個人の del.icio
Menu 総合情報 Wiki Top Page Official web site 配布元 バグ報告 はじめての Momonga Linux OmoiKondaraQuickStart OmoiKondara-HOWTO SVNレポジトリ Subversionメモ リリース版情報 Momonga Linux 7 Release Note Momonga Linux 7 FAQ Momonga Linux 6 Release Note Momonga Linux 6 FAQ Momonga Linux 6 Update情報 開発情報 Trunk情報? Bug Tracking System ビルド状況集計システム gcc メモ glibc メモ rpm メモ 検索 最新の20件 2021-08-22 TeXメモ 2019-10-12 Crystal言語 2015-10-23 Momonga
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
