ついにRedmineのtrunkにSubtasking がコミットされた！ - プログラマの思索
ついにRedmineのtrunkにSubtasking がコミットされたのでメモ。 【元ネタ】 Twitter / yusuke-kokubo: #redmine ついにtrunkにSubtaking がコミットされた！ Twitter / yusuke-kokubo: #redmine 1.0ではチケットの親子関係がサポートされます。 Redmine - Feature #443: Subtasking - Redmine Redmine - リビジョン 3573 - Redmine (下記引用開始) Adds subtasking (#443) including: * priority, start/due dates, progress, estimate, spent time roll-up to parent issues * descendant issues tree d
Redmineチケットの関連リンク - プログラマの思索
Redmine.JP Blogに分かりやすい記事があったのでメモ。 【元ネタ】 チケット同士の関連づけ | Redmine.JP Blog Redmineチケットで「関連する」リンクはよく使し、分かりやすい。 例えば、trunkへのマージ作業の発生元がリリースブランチの障害修正の場合、リリースブランチのチケットNoを「関連する」に追加する。 そうすれば、何故マージ作業を行うのか、担当者も理解しやすくなる。 しかし、それ以外の「重複する」「先行する」「ブロックする」は分かりづらかった。 チケット同士の関連づけ | Redmine.JP Blogを読んで、ようやく完全に理解できた。 「重複する」機能は、Mantisにも同等の機能があるので分かりやすい。 「重複する」リンクを使う場面は、いわゆる同件(同類)バグの場合があるだろう。 例えば、発見したバグをチケットに登録したものの、実は以前のチケッ
XP祭り関西2010～元気が出るチケット駆動開発 - プログラマの思索
パッケージ製品開発でTracをシステムテストで使った時に、TiDDを導入した話で非常に参考になる。 興味深い点は2つ。 一つは、TiDDを適用した工程をシステムテストに限定したこと。 懇親会でも質問を受けたけれど、プロジェクトでいきなり全ての作業をチケットで管理する運用は難しい場合もある。 その場合は、まず障害管理の一つのツールとして導入して、テスト工程をコントロールするのに注力すればいいと思う。 昨今の開発でBTS無しでバグを管理するのは非常に難しいからだ。 また、バグ管理の運用にメンバーが慣れれば、開発の作業や問合せもチケットで管理したくなってくるだろう。 もう一つは、TiDDを導入したら、開発チームの風通しが良くなり、メンバーが自発的になってきたこと。 バグや技術ノウハウの情報がBTSに一元化されるので、コミュニケーションの材料になる。 更に、チケットをToDo管理のように扱えば、忘
課題管理システムの勘所(2) - 都元ダイスケ IT-PRESS
http://d.hatena.ne.jp/daisuke-m/20091202/1259769481 の続き。 さて、今回はJIRAにおけるJellyの使い方。技術屋としてこっちを書きたかったので、↑のは前振りだｗ 前述の「最終ログインから一定期間以上経過している人にアラートメールを送る」という機能をJIRAでどのように実現するのか。まず要件をまとめよう。 ログインアラート仕様 最終ログインからA日経過したら、アラートメールを送信する。 最終ログインからB日経過したら、1時間おきに何度もアラートメールを送信し続ける。 という極悪仕様である。 Jellyの有効化 さて、JIRAではJellyスクリプトを走らせる事ができる、という話だったが、実はデフォルトではこの機能はOFFになっている。誰しもが使う機能ではない*1上に、任意のコードが実行できる訳なので、セキュリティ上のリスクがある為だ。管
課題追跡システムの勘所(1) - 都元ダイスケ IT-PRESS
仕事の現場に、新規で課題追跡システム（ITS）を導入する場合、いくつかの障壁があります。これらは主に、システムを使う人の知識と意識の問題ですが、それを列挙して対策をまとめてみます。 ログインしてくれない まず超根本。「導入しました」「あっそ」でスルーのパターン。課題を投げても気づいてもらえない。ありがちです。 これはまずトップダウンで「見ろゴルァ」と指令を出す必要があります。これが業務の方針だよ、と。その決定が前提。しかしそれでも習慣にならないウチはみんなITSの確認をしません。ならばシステム的な解決を目論む。 「一定期間ログインしないとアラートのメールを飛ばす」という策に出ます。結構強引な策ですが。ひとまずこれで、全員の意識をITSに向けることができるんじゃないかな。（という試みを現在実行中ｗ） JIRAでは、Jellyスクリプト*1を使って任意のロジックを実行することができます。バッチ
第13回名古屋アジャイル勉強会発表資料『チケット駆動開発入門』 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
メトリクスの威力 - プログラマの思索
チケット駆動開発を上層部へアピールするのに最も効果的なことは、現場の数字を提示することだ。 社長や取締役、管理職は、数字が非常に好きな人達。 彼らは、いつも売上の数字とにらめっこしている。 彼らは月次売上のために、請け負ったプロジェクトの進捗や品質をすごく気にしている。 チケット駆動開発を実践すると、チケットに日々の作業状態がリアルタイムに入力されるため、進捗をリアルタイムに見ることができる。 RedmineやTracでは、生成されたガントチャートから、赤色のタスクが遅延しているのが分かる。 カレンダーを見ると、月別のタスクの一覧が表示され、取消線のないタスクは作業中であることが分かる。 ロードマップから、バージョン単位の進捗が出るので、マイルストーンまでの残日数と比較して間に合うのかどうか考えることができる。 チケット集計結果であるサマリから、バージョンやコンポーネント単位の残チケット数
【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」 - プログラマの思索
関西Ruby会議01＠関西-KOF2008講演資料「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」を公開します。 CC Attribution ライセンスとします。 【元ネタ】 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) チケット駆動開発は、まちゅさんが最初に提唱された。 しかし、チケット駆動開発の概念はまだ曖昧で、一部でしか注目されていない。 僕は、Redmineというプロジェクト管理機能を持つBTSがプロジェクト管理をIT化してくれて、プロジェクト運営が大きく変わったことを経験した。 その体験をチケット駆動開発(Ticket Driven Development)という概念へ昇華できないか、考えた内容が上記の資料です。 コメントがあれば嬉しいです。 【参考】 Rubyist
課題管理対決！Redmine vs. Trac
Redmineの機能と特徴 Redmineは、Ruby on Rails上で動作する、Webインタフェースの課題追跡（Issue Tracking）ツールです。原稿執筆時点（2008年9月現在）での最新のバージョンは0.7.3です。 Redmineが搭載している機能は、「マイルストン設定（ロードマップ）」「カレンダー／ガントチャートの表示（概要）」「作業時間の登録／集計（チケット、概要）」「作業履歴の閲覧（活動）」「課題の登録／追跡管理（チケット、新しいチケット）」「伝言板（ニュース）」「文書の登録／閲覧（文書、Wiki）」「ディスカッション（フォーラム）」「ファイルの共有（ファイル）」「ソース管理との連携（リポジトリ）」「ワークフロー定義」「メール通知」「RSS配信」「ユーザの管理/ロール・権限の設定」です。なお、かっこの中はRedmine画面上で対応する主なメニュー項目名です。 筆者の
ソフトウェア開発の必須アイテム、BTSを使ってみよう 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
アジャイル開発のインフラ - プログラマの思索
SIerはお客様の業務をIT化するのがお仕事なのに、自分たちの業務は意外とIT化しきれていない。 大量の印刷した紙、手作業の多い仕事に囲まれている。 ソフトウェア開発のインフラを考えると、最低3個の環境は必須だ。 一つは、ソースコード管理。 二つ目は、検証可能なビルド環境。 そしてBTS。 この3つについて考えてみる。 【1】ソース管理 プログラミングで仕事するならば、ソース管理(SCM)は必須だ。 ソース管理システムの本質は、前回のプログラムへUndoができること。 つまり、プログラムの履歴が残っているからこそ、前バージョンへUndo、Redoができる。 ソース管理は、MSならVSS、普通は、CVSかSubversionを使うのが普通だろう。 ソース管理で重要な作業はブランチやタグ付けができること。 ブランチは、枝分かれしたバージョンツリー。 タグは、ある時点でバージョン付けられたソース
プログラマの思索: オープンソースBTSはソフトウェア開発のベストプラクティス
ソフトウェア開発は3つのモードがあると思う。 最初は新規開発モード。 そしてソフトウェア開発の中で最も難しく、最もプロジェクトマネジメント能力を要求されるバグ管理モード。 最後は、運用保守モード。 BTS（バグ追跡システム）は、主にバグ管理モードで使われる。 つまり、各開発者のプログラムを繋ぎ合わせて正常に動かす結合テスト。 あるいは、色んなブラウザに対応しているか、とか、高負荷なアクセスに耐えれるか、などのようなシステムテスト。 BTSとは、そこで上がったバグを収集し、修正し、検証する一連の作業をフレームワーク化したもの。 主にWebシステムで作られている。 このBTSについて再考してみる。 【1】BTSに至るまでの歴史 一昔前。 結合テスト以降のバグ修正は、Excelベースだった。 バグを見つけた人が、Excelのバグ報告票に起票する。 そのExcelを修正担当者に渡し、修正してもらう
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
Papilio-バグトラッキングシステム-
- Eclipseプラグインで実現するバグトラッキングシステム(BTS) - 特徴 サーバ構築不要。接続している各端末がお互いに同期してデータを共有する。 インストールは簡単。Eclipseにプラグインを追加するだけ。 信頼度成長曲線などの充実したレポート出力機能 Eclipseを採用することで直感的操作が可能なインタフェースを実現。 完全フリー、オープンソース。 完全日本語対応 Eclipseのプラグインとして、多様な機能を搭載したBTSを実現。 従来のBTSと違い、Eclipseプラグインとして使用できるため導入・操作が非常に簡単です。 従来のBTSとの違い 主な機能 動作環境 スクリーンショット ダウンロード インストール・設定 リリース情報 従来のBTSとの違い 主な機能 基本的なBTSの機能 - バグ票の起票〜Closeまでのステータス管理 - 更新履歴の記録・閲覧 - メールに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
