第12回 「自動化」と「可視化」でプロジェクトを管理、進捗や品質が一目瞭然に ソフトウエア開発の自動化（6）プロジェクト管理の自動化 ビジネスを取り巻く環境の変化が速くなり、それとともにソフトウエア開発プロジェクトの短期間化が進んでいます。このような中では、プロジェクトの一部に数日の遅延が発生しただけで、プロジェクト全体の進行に影響する大きなダメージとなりえます。 このためシステム開発プロジェクトの進捗や品質を管理するプロジェクト管理では、「プロジェクトの見える化」そして「リアルタイムなプロジェクト管理」が非常に重要になります。「プロジェクトの見える化」によって、遅延や遅延しそうな傾向にあるチームの状態を把握できるようになります。「リアルタイムなプロジェクト管理」によって、その遅延を早期に検知でき、素早くアクションをとることで、フィードバックの高速化を実現できます。 「プロジェクトの見える
「プロジェクト管理（PM）ツールや情報共有ツール、継続的インテグレーション（CI）ツール、継続的デリバリー（CD）ツールの導入状況は、どうなっているのか？」。 この実態を明らかにすべく、日経SYSTEMS編集部では3月15日から4月18日にかけて「開発支援ツール徹底調査2013」を実施した。同調査は以前の記者の眼で協力をお願いしたものだが、結果が出そろったので、ここに詳細を報告したい。 なお、調査ではカテゴリーを「PM/情報共有ツール」「CI/CDツール」の2つに分けて、カテゴリーごとに利用状況や利用しているツール名、利用開始時期などを尋ねている。有効回答件数は1532件となった。 PM/情報共有ツールは使い分けが進む まずは、PM/情報共有ツールの調査結果から見ていこう。直近2年間でPM/情報共有ツールを利用したことがあるという回答は、846件に当たる55.2％だった。回答者の2人に1人
Download and Source SVN Trac 1.0 branch. SVN Trac 1.0 branch with permissions. Zipped source for plugin for Trac 1.0. Zipped source for plugin for Trac 1.0 with permissions. When downloading these files then either the extension is lost or the filename corrupted. A simple rename to filename.zip seems to resolve it and the contents remain intact. Note: Email Notifications are currently unaffected b
初めに。 Timing and Estimationプラグインをインストールするにあたっては下記のサイトを参考にさせていただきました。 trac + TracBurndownプラグインでスクラム開発のすすめ Timing and Estimationプラグインは、Tracのチケットに対する作業時間を入力し、その作業実績を管理する為のプラグインです。 チケットに着手する際に、そのチケット解決までの見積り時間を設定し、それに対して日々どれだけの作業をしたかを入力する事で、チケットの作業割合が確認できます。 まぁ、この辺はプラグイン利用の際のルールをきちんと整備し、そのルールを如何にメンバーに守らせるかなど運用の方が重要になってくると思いますが・・・。 Timing and Estimationプラグインをインストールする為には、Trac0.10以上のバージョンが必要です。 要件を満たしていない
Kanon LABへようこそ Kanonは、プロジェクト管理のための総合ソリューションです。チケット(Trac)、バージョン管理(Git,Subversion,Mercurial,Bazaar)、CI(Jenkins)の3つの機能を統合して提供しています。 名前の由来 カノンとは、キリスト教の聖書教典のことで、クラシック音楽のカノン (同じ旋律が繰り返し演奏される輪唱)のことでもあります。クラシック音楽のカノンの 中でも有名なパッヘルベルのカノンは、本来弦楽器のために書かれたものですが、 ピアノ独創やポップ、ロックなど、様々な分野でそのメロディはモチーフとして使われ ています。Kanonは みなさんのプロジェクトの教典になるように プロジェクト毎にアレンジして使えるように カノンの用にメロディを変化させながら何度も詠唱できるように という意味をこめて名づけました。 インストール方法 # h
Trac上でプロジェクトを管理する上での基本操作は、Wikiによるページの編集と、チケットの登録、そのチケットの受取り（確認）・ステータス変更などが主なものです。 Wikiの編集作業と、「Browse Source」メニューでソースを確認する方法は、ここでは触れません。 Trac上のチケットとは、作業依頼書や報告書のようなものです。 チケットをTrac上に登録し、そのチケットを担当する人（チケット登録時に指定可能）がそのチケットを受け取って作業をします。 チケットを登録する前に、まずはTracにログインして見ましょう。 ログインは、右上の「Login」メニューから行えます。 Loginメニューをクリックするとエラーが出る場合は、ログイン方法の設定が正しく出来ていない可能性がありますので、前回のTracインストール編 を参照してみてください。 Basic認証でログインする場合は、Loginメ
Trac is distributed with a powerful command-line configuration tool. This tool can be used to configure and customize your Trac installation to better fit your needs. Some of the configurations can also be performed via the web administration module. Usage For nearly every trac-admin command, the first argument must be the path to the TracEnvironment: The only exception is for the help command, bu
B787の翼の接合部分の過重テストです。これを見ていると、ソフトウェアのテスト工程なんか楽な仕事な気がします。 ソフトウェアの製作方法だが、特にウェブ方面はここ15年間で進化した気がする。統合開発環境、バージョン管理システム、バグ管理システムなどのツール群もかなり整備されたし、MVCやO/Rマッピングやテスト等のフレームワークも積極的に採用されるようになってきた。しかしながら、RDBの正規形やデザインパターン等のソフトウェア構築技法的な点は、重要性が認識されている一方で、あまり一般化していない気がする。2000年問題のときに将来のことを考えないシステム構築が問題になっていたが、今でも便利なものは取り入れつつも、将来性や拡張性を考えたプログラミングが十分に普及していないのが現実か。 確かにツール群は、それを取りれる事で得られるメリットは明確なのだが、技法的な点は、それを学習するコストの大きさ
以前から個人的にLDAPを導入しているのですが、意外と忘れがちなので備忘をかねてメモります。 昔のメモなので今と挙動が違うかもしれませんがご了承ください。OSはCentOS 5です。 まずはOpen LDAPのインストールと設定をします。 関連パッケージのインストール $ yum -y install openldap openldap-servers openldap-clients openldap-devel ディレクトリマネージャのパスワードを生成する $ /usr/sbin/slappasswd -h {SSHA} New password: Re-enter new password: slapd.confの設定 /etc/openldap/slapd.conf ...snip... access to attrs=userPassword by self write by a
最小限の管理コストで最大の「見える化」を 近年「開発の見える化」が話題となっていますが、いざやろうとするとなかなか難しいものです。 模造紙を壁に張り付ける「タスク看板」などを利用してタスクの「見える化」を行っても、肝心のタスクの実行状況が見えなかったり……。そんなことはないでしょうか？ 本当にチームメンバーのタスクを把握できているでしょうか？ そもそも「タスク」とは、コーディングやテストといった純然たる作業や、故障処理、管理、仕様変更などの副次的な作業も含みます。開発を見える化する際に基本となる1つの単位です。 今回紹介するMylynとTracを利用すると、タスク取得→コミット、タスク取得→コミット、……というリズムに乗った開発で、作業履歴（ログ）を残しながら各開発担当者の作業内容を明確にできます。最小限の管理コストで最大の見える化を。世にも不思議なMylynマジック、とくとご覧ください。
【プロジェクト管理術】徹底比較！OSS管理ツール 第2回：課題管理対決！Redmine vs. Trac 著者：北岸 隆史 公開日：2008/10/14（火） さて、RedmineとTracの機能を見てきましたが、両者とも広義の「課題管理ツール」であり、その観点から見ればRedmineの課題（Issue）、Tracのチケット（Ticket）の内容を比較しても両者に大きな差は特にありません。 Redmineの方はお手軽に導入してすぐに使い始められるツール、Tracの方は自分でチューンナップして、使いやすいものへと仕上げていくツールというイメージです（導入に関して言えば、Trac Lightningは、Redmineよりさらにお手軽感が高くなっています）。 ところで、プロジェクトで発生する課題の記録やトラッキングであれば、Excelやメールなどを使って行うことも可能です。そこへ、オープンソ
少し前の話になりますが、バグトラッキングシステムを刷新する機会があり Trac と Redmine について調べ、両方とも導入してみました。他の人の記述とかぶるため、基本的な部分は以下のサイトをご覧ください。 プロジェクト管理ツール比較表 TracとRedmineの比較 redMineを使ってみた tracとredmine tracの代わりにredMineを使う5つの理由 上記サイトに載っている以外で、 Trac と Redmine を使ってみた感想を簡単にまとめます。 (なお、以下の感想は、 Windows をサーバ環境として利用した場合を想定しています。そのため、構築の容易さなどは、 Linux を使用する場合の評価と異なるためご注意ください。) Trac のメリット インストールが容易 Trac Lightning が非常に便利 プラグインを一括導入できるので、機能も豊富 Trac
“泥”開発に対する最終兵器「Trac」とは？ 誰もが必ず1度はイライラしたことがある「情報の囲い込み」問題 情報の共有はプロジェクトを円滑に進めるうえで重要な課題です。極端な例ですが、例えば、図1の例で見てみましょう。 分かりやすいよくある例で示すと、各開発者の作業状況はメールや手帳上に記されています。検討やヒアリングした結果は、メールでほかの人に問い合わせたならメールボックス上にたまっていきます。打ち合わせなどで相手に会ってヒアリングしたなら、手帳やノート上にメモとして残っていきます。こうして、各開発者が自分のタスクの情報をメールやメモ、あるいは頭の中で“囲い込み”ながら開発が進んでいきます。 ここで、開発者がある機能を実装するために、「別の作業の状況や進捗（しんちょく）を把握したい」とします。 「誰が情報を持っているのか分からない」 まず、誰が情報を持っているのか分からないので、ヒアリ
Redmineの機能と特徴 Redmineは、Ruby on Rails上で動作する、Webインタフェースの課題追跡（Issue Tracking）ツールです。原稿執筆時点（2008年9月現在）での最新のバージョンは0.7.3です。 Redmineが搭載している機能は、「マイルストン設定（ロードマップ）」「カレンダー／ガントチャートの表示（概要）」「作業時間の登録／集計（チケット、概要）」「作業履歴の閲覧（活動）」「課題の登録／追跡管理（チケット、新しいチケット）」「伝言板（ニュース）」「文書の登録／閲覧（文書、Wiki）」「ディスカッション（フォーラム）」「ファイルの共有（ファイル）」「ソース管理との連携（リポジトリ）」「ワークフロー定義」「メール通知」「RSS配信」「ユーザの管理/ロール・権限の設定」です。なお、かっこの中はRedmine画面上で対応する主なメニュー項目名です。 筆者の
SubversionとTracでファイル管理の“迷宮”から脱出：ユカイ、ツーカイ、カイハツ環境！（2）（1/4 ページ） プロジェクトで修正／仕様変更が“迷宮”入りする理由 ソフトウェア開発を行ううえで、設計書やソースコードのバージョンをきちんと管理することは非常に重要です。構成管理（ファイル管理）を行っていないプロジェクトでは、例えば次のような問題が発生します。 2人以上の開発者が同時に成果物を編集した場合、後に編集を始めた開発者がすでに編集を行った開発者の編集内容を上書きしてしまう。結果として、修正したはずのバグや変更したはずの仕様が、設計書やソースコードに反映漏れするという事態が発生 設計書やソースコードのレビューを行って修正したはいいが、どこをどう修正したのか分かりにくく、レビュー内容の反映の確認を行っても修正漏れや修正誤りに気が付かない ソースコードを変更すると、動かなくなってし
The Trac Ticket Workflow System よく見たら、TracのTicket Workflowって、0.10の場合と0.11のデフォルトは若干異なっているんですね（acceptedの状態が増えている）。まぁ、それはそれとして、Tracのワークフローのカスタマイズを試してみました。 設定方法に関しては、上記URLに詳細が記載されていますが、今後のためにも簡単にまとめてみました。0.11b1での内容となりますが、おそらく0.11正式版でも同様ではないかと（ただし、将来的にはさらに機能が追加されるかもしれません）。 trac.iniの [ticket-workflow] セクションにて定義します。 (key) = (value)とのみ記載されている行 (key)の部分がAction名、(value)の部分が「変更前のステータス -> 新しいステータス」。 Ticketのステ
Trac導入前に、何年かSVNが運用されていました。そして、リポジトリはプロジェクトごとに分割していましたとさ。現在20ぐらいリポジトリがあったりしています。 サーバーが古くて、OSがMiracle3.0で、Tracとか入れられなくて悔しい思いを。 やっと新しいサーバーをGetしてリポジトリ移行して、それで後からTrac入れましたよ。やったー。やっぱりTracいいな。 けれどさ、なんかたくさんのTracプロジェクトがあって見通し悪いなぁ。 みんなはどうしているのだろう。ググる。 ・・・ん。 TraMとか、便利そうなものがあるみたいですけど、プロジェクトのURLを開いても真っ白。 あらら。 うーん。とりあえず、TracのTimeLineのRSSをまとめて、時系列で見れるようにしておけば、直近の動きは、まあまあ見えるのかなぁ。個別のRSSだと全体のタイムラインの把握は無理だぁ。あのライブラリの
システム開発を進めるにあたり、バグやタスクなどを管理して、現在発生しているバグの数や担当者といったステータスを把握する必要があります。また、ある程度以上の規模のWebアプリケーションを開発する場合、数人のチームで開発を進めるケースが多く、開発を円滑に進めていくためにスタッフ間での情報共有が重要になってきます。 「Bug Tracking System（以下、BTS）」は、これらの問題を解決するためにプロジェクトのバグを管理し、修正状況を追跡できるよう可視化を行うシステムです。現在、BTSとして様々なソフトウェアが公開されており、ソフトウェアを開発する上での必須アイテムになりつつあります。 BTSの多くはWebブラウザ経由でアクセス可能なソフトウェアで、その中から今回はウノウで採用している「Trac」について説明します。 Tracは、BTSとWiki、Subversionリポジトリビューワー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
