Tracベースの「Apache Bloodhound 0.4」がリリース | OSDN Magazine
Tracをベースとしたプロジェクト管理システム「Apache Bloodhound」開発チームは1月28日、最新版となる「Apache Bloodhound 0.4」をリリースした。 Apache BloodhoundはTrac 1.0をベースとするプロジェクト管理システム。ソフトウェアの開発成果やバグの追跡、レポジトリのブラウズ、プロジェクト統合や情報保存のためのWikiといったソフトウェア開発プロジェクト向け機能を提供する。Trac向けのプラグインを統合することで、複数プロジェクトのサポート、直感的な操作性、容易なインストールといった機能の提供を目指す。Apache Bloodhoundは2012年よりApache Software Foudatioin（ASF）のインキュベータープロジェクトとして開発が進められている。 Apache Bloodhound 0.4では、チケットのエディ
ついに公開、話題の無償PMツール - ツール開発者が活用法を解説：ITpro Active
大和田 裕＝情報処理推進機構（IPA） 技術本部 ソフトウェア・エンジニアリング・センター（SEC） エンタプライズ系プロジェクト 研究員 日々の進捗やメンバーの負荷などプロジェクトの状態を数値でつかむ。そんな定量的マネジメントの無償ツールが登場し、話題を呼んでいる。ツール開発者が活用法を解説する。 高い品質や新技術へのチャレンジを求められるが、予算も工期もギリギリで余裕はない。そんな難しいプロジェクトが増えるに伴い、プロジェクトマネジャー/プロジェクトリーダー（以下プロマネ）には、緻密なマネジメントが求められている。 利用部門からの仕様変更の要求を受け入れるかどうか、納期を守るために何人のメンバーを補充するか、どのサブチームを重点的にテコ入れするか――。そうした判断が不適切だったり遅れたりすると、プロジェクトの成功はおぼつかない。ITの現場を率いるプロマネの責任は重大である。 筆者は業務
【資料公開】チケット管理システム大決戦 第二弾
みなさんこんにちは。@ryuzeeです。 2011年6月30日にShibuya.tracの第12回勉強会として、チケット管理システム大決戦第二弾を実施しました。 僕はモデレータ役として登壇させていただきました。普段講演者として発表する機会は多いのですが、モデレータは初体験でしたので段取りが悪かった点もあるかと思いますがご容赦ください。 以下に当日利用した資料を公開します。 手前味噌ですが、このレベルの内容が揃った資料はなかなか無いと思いますし、資料的価値もあると思いますので、参加された方もそうでない方も是非ご覧ください。 質問等がある場合は#shibutraタグをつけてつぶやいて頂ければと思います。(また各資料の左端に作成者のIDを記載しておきました) ご登壇頂いた池田さん、中村さん、山本さん、大貫さん、関さん、藤原さん、原田さん、かぬさん、ご参加頂いた皆さん、事前準備に奔走してくださった
Trac系プロジェクト管理ツールの選定メモ - 虎塚
チームでプロジェクト管理ツールを使おうという話になり、ツールを探しました。結果、KanonをUbuntuで動かすことに決めました。 Twitterで色々アドバイスを頂いて大変参考になったので、まとめておきます。次にKanonを選ぼうとする人の参考になるかもしれないので・・・ [twitter:@sinsoku_listy]さん、[twitter:@kanu_]さん、[twitter:@LightningX]さん、[twitter:@kimukou_26]さん、ありがとうございました。 [Trac系プロジェクト管理ツールの選定メモ] 呟きまとめ - Togetter (kimukou_26さんがまとめてくれました。感謝です） 当初の選択肢 次のどちらにするかで迷っていました。 TracLightning on Windows Server Trac on Linux OS まず、TracLi
なぜITS導入は失敗したか？あるいは僕のがっかりメモ - ハードコイルド・ワンダーランド
出張してもどってきたら社内Tracが残念なことになっていた 最近、もともと所属していたチームをはなれて外で開発をしていた。 久しぶりにもどってきてTracを覗いたところ、非常に残念な感じなっていて、有り体に言えばゴミタメになる寸前だった。 （今現在も解決していない） ほかのチームでRedmineを展開してそこそこ上手くいっていたので、 なんでこんなことになったのか？どうすれば防げたのかをいろいろ考えた。 個人的なメモ。 何がいけなかったのか 個人的に思うところは以下の３点 ・マイルストーンの役割を誰も理解していない ・バグ表を作る人（≒リーダー）がTracを使えない、使う気がない ・求められる機能とTracの機能に乖離があった マイルストーンの役割を誰も理解していない 「ソフトウェアのリリースとITSのマイルストーン、リポジトリのブランチはそれぞれ同期する」なんて ITS使ってる人には常識
Kanon LAB: Kanon Allegro
Allegro(アレグロ)とは、イタリア語で「陽気に」、音楽用語では、「速く」を意味する言葉です。Kanon Allegroはスクラムをベースとしたアジャイル開発をサポートするチケットシステムで、アジャイル開発者は一般的に陽気で、素早くリリースするというイメージから名づけました。 また、ソナタ形式のクラッシックの第1楽章の多くはアレグロで構成されていますが、アジャイル開発を行う人のとっかかり(第1楽章)をサポートするという意味も込められています。 Kanon Allegroはバックログの管理、バーンダウンチャートの作成(全体、チーム個別)、Excelからのストーリー、タスクのインポートを行うことができます。 Kanon Allegroの使い方の詳細については、Shibuya.trac第11回で発表しましたをご覧ください。 バックログの管理 ストーリーとタスクで、プロダクトバックログとスプリ
Agile開発の肝はイテレーションにあり - プログラマの思索
Redmineでチケット駆動開発を運用するまで、Agile開発を体で理解できていなかった。 XPを実践したいと思っていても、本当のAgile開発は何か違うのでは？と思っていた。 何故、僕はTracではなくRedmineを使ってAgile開発を発見できたのだろうか？ RedmineがAgile開発と相性が良いのは、Redmineの「バージョン」の概念がAgile開発の「イテレーション」「スプリント」と自然に一致するからだ。 Redmineでは、バージョンに紐づくチケットが全て完了ステータスになって、進捗率が全て100％になれば、いつでもそのバージョンをリリースできる仕掛けが入っている。 つまり、バージョンをイテレーションと見なせば、各バージョンを次々にリリースしていけば、自然に小規模リリースを実現できる。 小規模リリースこそが漸進型開発、つまりインクリメンタル型開発の最大の特徴なのだ。 Ag
HugeDomains.com
Captcha security check coolcoding.com is for sale Please prove you're not a robot View Price Processing
Agilo ファーストインプレッション - Natural Software
Ryuzee さんが翻訳してくれていた、 Trac の scrum プラグインである Agilo を公開してくれたので、さっそく試してみた Agilo日本語版を公開しました | Ryuzee.com plugins/Agilo_ja - Shibuya.trac Wiki - Shibuya.trac - OSDN Agiloを導入してみた | Ryuzee.com http://www.ryuzee.com/contents/blog/2864 AgiloのちょっとしたTips(1) | Ryuzee.com かわぐちさんのレポート（性能測定付き）も合わせてどうぞ Scrum用にTracを大胆カスタマイズしてしまう agilo プラグイン をいれてみた in SourceRepo - kawaguti の日記 (id:wayaguchi) Agilo入れたサイトと、入れてないサイトで速度
チケット駆動開発のアンチパターンpart2 - プログラマの思索
チケット駆動開発のアンチパターンで気付いたものを更に追記しておく。 【元ネタ】 チケット駆動開発のアンチパターン: プログラマの思索 チケット駆動開発のFAQ: プログラマの思索 【再考】TiDDのプラクティス集: プログラマの思索 【1】メトリクスの罠 RedmineやTracでは、いくらでもチケット集計結果からメトリクスを得られる。 管理者はついつい、そのメトリクスで実績評価して、メンバーのモチベーションを下げてしまいがち。 メトリクスは万能ではない。 メトリクスだけではプロジェクトの現状を把握できないのが現実だ。 メンバーの表情、各種の成果物、など色んな観点から、プロジェクトの現状が定まっている。 いくらメトリクスが悪くても今改善途中かもしれないし、メトリクスが良くても実はメトリクスを改ざんしているのかもしれない。 メトリクスはバッドノウハウの塊。過信しない方がいい。 【2】問合せは
RedmineやTracを上手に活用する6つのポイント
photo credit: Mackトラ ソフトウェア開発プロジェクトの現場では課題やバグ、タスクを管理するために、RedmineやTracなどのIssue Trackin System(課題追跡システム。以下ITSと表記)を使っていることが多いと思います。 ITSを使えばこれらの情報を一元化しプロジェクトメンバ間で共有できるため、うまく使えばとても役立ちますよね。 しかし、あまり深く考えずに導入すると、 「入力が大変だし余分な手間が増えただけだよ…」というメンバーからの不満の声 「この課題って本当に終わってるの？」といった疑心暗鬼 「このタスク、誰も進めてなかった！」という驚愕の事実が期限前日に判明 などといった状況に陥りがちです。 ここでは、いくつかのプロジェクトへ導入した経験から得た、ITSを運用する上で重要(と考える)な6つのポイントを紹介します。 ポイント1 チケット項目はマ
agile42 | Agilo™
Try Hosted Agilo Try Agilo as a hosted service 30 days for only 29 euro Agile processes need a flexible tool Agilo™ for Scrum. Requirements, User Stories, Scrum planning, integrated Wiki, Subversion integration and issue tracking. Download Agilo as a Virtual Machine Try Agilo without configuring a local install. The appliance contains a fully configured Linux machine with Agilo installed. Require
チケット駆動開発のベストプラクティスを収集したい - プログラマの思索
チケット駆動開発を実践して、色々考察してきて、ベストプラクティス集を作りたいと思っている。 理由は、チケット駆動開発とアジャイル開発の密接な関係を明確にして、アジャイル開発を簡単に運用できるノウハウとして公開したいからだ。 僕は、チケット駆動開発には下記4個のプラクティスが最低限必要だと思っている。 但し、XPのプラクティスと同じだがTiDDの言葉で言い換えているものもあるので注意。 １・チケット・ファースト(Ticket First) 【説明】 基本は、プロジェクトの作業はチケットを受け取ってから始める。 チケット無しで作業はしない。 また、SVNコミット時に、チケット無しのコミットも不可。 【効用】 チケットがタスクカード(作業指示書)のため、コミュニケーションロスがなくなるし、作業履歴がチケットのコメントとして残る。 進捗情報は全てチケットに書くから、BTSのチケット集計機能でリアル
第13回名古屋アジャイル勉強会発表資料『チケット駆動開発入門』
【16-E-4】残業ゼロで開発スピードが10倍に！もう元の開発体制には戻れないデンソー流のアジャイル開発
チケット駆動開発の運用例 - プログラマの思索
チケット駆動開発の記事があったのでメモ。 【元ネタ1】 チケットで工数管理(Shibuya.trac 2009新年会 発表資料) - almost nearly dead kanu_orzさんによるTracのチケット管理の運用例。 インシデント管理や問題管理にTracを下記で運用していると思われる。 ・チケットをExcelで一括インポート ・Tracで工数を入力、集計 ・チケット集計結果をExcelで出力 特徴としては、Trac上で日々の作業の実績管理は行うが、作業の元ネタである大量のチケットはプラグインで一括インポートしたり、月次報告用の工数集計などの結果をExcelで出力している。 これは、いわゆるエンドユーザコンピューティングかもしれない。 つまり、Trac上に日々の作業と言うトランザクションを溜めていくが、マスタ(ここではチケット)の作りこみや、溜まったトランザクションから定期的に
アジャイル開発のためのプロジェクト管理·Agilo MOONGIFT
アジャイル開発にとって重要なのは、スクラムを組み、一気通貫で開発してしまう勢いだ。手間のかかるタスクの登録やステータスの更新その他諸々の面倒ごとをやっていたら時間はあっと言う間に過ぎ去ってしまう。 タイムライン 例えばTracは素晴らしいプロジェクト管理だが、少々画面が素っ気ない。そこでもっと便利に使えるAgiloを紹介しよう。 今回紹介するオープンソース・ソフトウェアはAgilo、アジャイル開発を進めるためのプロジェクト管理だ。 Agiloはアジャイル開発を基本としたプロジェクト管理だ。VMWareのアピアランスも提供されているので、すぐに試すことができる。また、Tracのプラグインとしても提供されている。Wiki、タイムライン、ロードマップ、チケット、検索といった一般向けの機能に加え、チーム管理、グラフといった管理機能がある。 グラフ 何よりインタフェースがボタンを中心になっている。こ
第1回 Tracの紹介とプロジェクト管理 | gihyo.jp
はじめまして、広部と申します。本連載では、開発プロジェクト管理ツールとして人気の高いTracについて解説していきます。 初回は、開発者から管理者になったばかりの新米管理者になったを対象に、「Tracを使うことで情報共有がやりやすくなり、開発者がプロジェクトの状況・情報に詳しくなることで、結果としてプロジェクトの管理が上手くいくようになる」ということを説明したいと思います。 Excel管理は過去の話 少し前までは、プロジェクト管理といえばExcelの表編集機能を使った管理が当たり前でした。お客様の要求事項をExcelで一覧化し、作業タスク、ソースの改版履歴、障害情報を一覧化する。この方法は簡単なため、広く使われていました。 しかし、Excelファイルは複数人で編集するのに向いているとはいえません。Excelファイルは同時に二人で編集できないだけでなく、下手に扱うと自分が編集した内容が消失す
第2回 Trac Lightningの紹介 | gihyo.jp
Trac Lightningは、Windows環境用のTracのオールインワンパッケージです。Tracは、Webサーバやバージョン管理ソフトといった複数のソフトウェアと組み合わせて使う必要があるため、サーバ環境を構築するための敷居が高いといわれていましたが、Trac Lightningを使えば、簡単に動く環境を構築できます。 Trac Lightningに含まれるもの Trac Lightningには、Tracを使うために必要なソフトウェアが一通り含まれています。Trac Lightningに含まれるソフトウェアには、Tracの日本語版であるTrac-jaをはじめとして、Apache HTTPサーバ、Python、バージョン管理ソフトSubversionといったTracを動かすために必要となるソフトウェアが挙げられます。さらに、Tracを便利に使うための数多くの有用なプラグインも含まれてい
RedmineとTracの機能比較 - プログラマの思索
RedmineとTracの両方でチケット駆動開発を運用してみて、色んな気付きがあった。 以下メモ書き。 【比較対象】 ・Redmine0.8.0 ・Trac0.11.1.ja 【元ネタ】 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 【1】複数プロジェクトの扱い RedmineがTracよりも機能が優れている点の一つは、複数プロジェクトに対応していること。 Tracはプロジェクトに親子関係を入れることができないため、特に大規模プロジェクトではチケット駆動開発を実践しにくいだろうと思う。 複数プロジェクトを作りたい状況は、二つある。 【1-1】開発チームが複数のサブチームに分かれていて、それぞれでタスク管理したい場合。 RedmineやTracを運用してみると、一つのプロジェクトでメンバーが5人以上だとチケットが乱発されたり、放置されやすくなるようだ。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Something went wrong.