
Tracには「wiki」しかなかったのに、Redmineでは他に「フォーラム」なる仕組みも用意されていてややこしい。目的に応じて使い分けよ、とは確かに一つのアドバイスだとは思うけど、初めて使う人にそんなことを言っても通じないだろう。そんな訳である程度の指針や具体例が必要になるわけだが、今のところ、次のように使い分けている。 フォーラム 一度掲載したら変更しない文書用。具体的には、メールの共有保管場所だ。一度送ったメールはもう2度と変わらない(変えようが無い)し、スレッドごとにまとめて掲載できるので、後からの参照も容易だ。これで、チーム内に「情報共有」と称した無駄なメールの展開を減らせるようになる。 Wiki 何度も情報を更新する文書用に使っている。具体的には、チーム内の作業手順や障害の発生例と対策事例、ツールの手順や仕様書の類だ。これは一度書いたら終わりというものでも無いし、その履歴が実は
開発の現場では毎日様々な問題が発生するし、対外的な打合せや非定型業務、割り込み作業も多くて、リーダと言えども、開発チームの進捗状況を必ずしも全て把握出来ているとは限らない。自分が逐次作業指示を出してメンバを動かすのが仕事とはいえ、指示を受けないと自ら動いてくれないという人はいるし、各作業間の優先順位付けや方針を決めるのはやっぱりリーダの判断に基づくものだから、どうしても自分の存在が不可欠になってしまう。 そんな時に考えるのが「自分がもう一人欲しい」という願望だったりする。決して2倍の仕事量をこなしたいという意味ではないのだけど、自分自身の仕事を進めつつも、チームの面倒を見ることが出来るのなら、それは有り難いことだ。何と言っても判断するのはあくまでも自分自身だから、期待通りの結果に導くのは容易なはずだ。他人任せにしたばかりに、予期せぬ結果になってしまったという悲惨な状況を避けられるのはかなり
next49 @next49 @yukihiro_matz 私は大学で助教をしているのですが、今年の卒論生は配属当初「プログラムが不得意で、嫌いです」と全員言っていました。ですが、RubyとRailsを使ってWebアプリケーションを作るテーマで開発をさせたところ、意見が変わっていました。 2012-03-23 01:09:04 next49 @next49 @yukihiro_matz 全員が「結構、プログラミングって面白い」「Rubyならプログラム嫌じゃない」というようになったのです。そこで、彼らにどうしてプログラムが嫌いだったのか聞いたところ、入学当初にならったC言語が難しくて、それから嫌になったとのことでした。 2012-03-23 01:10:51
お疲れ様です。ウェブサービス本部開発2室のスエヒロです。 普段はプログラマとしてサービス開発に携わっておりますが、ライブドアキャプテンブログ(旧ライブドア社長ブログ)の代打執筆や、テキスト系妄想メディア「ワラパッパ」の編集など、プログラマ職以外の活動もさせて頂いております。サッカー以外もオシャレにこなすヒデみたいなポジションを目指したいところです。ヒデと言っても日出郎さんじゃないですよ。どうぞ宜しくお願いします。 さて。 皆様、サービス開発や運用を効率よく進める上で「プロジェクト管理ツール」をお使いでしょうか?新しいサービスの開発進捗の管理、運用フェーズにおけるタスク管理、バグ・不具合解消のためのやりとりなど、様々なフェーズで利用されるプロジェクト管理ツール。実際業務で使われている方も多いかと思います。 livedoorのサービス開発においてもいくつかの管理ツールが利用されています。代表的
Kanon LABへようこそ Kanonは、プロジェクト管理のための総合ソリューションです。チケット(Trac)、バージョン管理(Git,Subversion,Mercurial,Bazaar)、CI(Jenkins)の3つの機能を統合して提供しています。 名前の由来 カノンとは、キリスト教の聖書教典のことで、クラシック音楽のカノン (同じ旋律が繰り返し演奏される輪唱)のことでもあります。クラシック音楽のカノンの 中でも有名なパッヘルベルのカノンは、本来弦楽器のために書かれたものですが、 ピアノ独創やポップ、ロックなど、様々な分野でそのメロディはモチーフとして使われ ています。Kanonは みなさんのプロジェクトの教典になるように プロジェクト毎にアレンジして使えるように カノンの用にメロディを変化させながら何度も詠唱できるように という意味をこめて名づけました。 インストール方法 # h
Python温泉にて「チケットがたくさん山になっているとヤル気がそがれたりどれからやったらいいか悩むのに時間を使ったりしてしまうので、オススメのチケットを選んでくれるシステムがあったらいいんじゃないの?」って話題になったのでコンセプトプルーフを実装した。 とりあえずRubyのRedmineからチケットを適当に取ってきて実験。recommend()ってやるとオススメのチケットを1つ教えてくれる。 In [2]: recommend() Windows環境で日本語を含むパスに対して、File.expand_path が存在しないパスを返すパターンが存在する。これはちょっとなー、自分向きじゃないなぁ(OS依存だし)、別のがいいなぁ、と思ったのでno()と答える。すると別のチケットを提案してくれる。 In [3]: no() Please backport r33556 (Bug #5243)うん
以前、オーム社開発部の出版体制を取材しましたが、今回、私自身がそのシステムを使って本を書きました。 Subversionでバージョン管理をしつつLaTeXで本を書く形式です。 複数人で本を書く時にバージョン管理ツールを使わないと、誰がどこをどういじったのかがわからなくなったり編集箇所が競合する場合が多いのですが、Subversionを使うことでそれらが解決可能です。 さらに、筆者か編集者のうちの誰かがsvn commitを行って最新版を更新すると、それに連動して最終原稿として印刷所に入稿されるものと同じ形のPDFが自動的に生成され、DTP作業がゼロになるとともに、筆者がアウトプットを細かく確認ができるという特徴もあります。 しかも、Subversionのコミットメールを編集者側も見ていて、該当部分に対する編集やコメントがすぐに投入され、こちらが文章を書いた数分後に編集側意見が含まれるPDF
「Hudson」改め「Jenkins」で始めるCI(継続的インテグレーション)入門:ユカイ、ツーカイ、カイハツ環境!(21)(1/4 ページ) CIツール「Hudson」改め「Jenkins」とは 「Jenkins」とは、CI(継続的インテグレーション)ツールとして有名な「Hudson」の開発者たちにより開発されているCIツールです。Hudsonは商標上などの問題によりJenkinsと名前を変えて継続することが発表されたので、記憶に残っている方も多いと思います。現在では落ち着いて開発されているようです。 本稿では、今話題のJenkinsの使い方を紹介します。本記事の想定読者は、Java開発を行っている方で、「今までCIを導入していなかったけどこれから導入しよう」「Jenkins(Hudson)は使えそうだけど、難しそうだなぁ」と思っている方を対象としています。本稿を読めば、10分程度でJe
それぞれのBTSのワークフローはなかなか特色があるね。 Tracのワークフローは以下のようになります。 new(新規) → assigned(アサイン済み) → accepted(受け入れ済み) → closed(クローズ) TracWorkflow – The Trac Project TracはResolution(解決状況)がある。 解決状況についてはこちらが参考になる。 BTSの解決状況(Resolution)は障害管理の名残り: プログラマの思索 Tracの後発のRedmineのワークフローは以下のようになります。 New(新規) → Assigned(担当) → Resolved(解決) → Closed(終了) 課題管理システム - Redmineガイド Redmineは解決状況は無いですが、Redmine本家のサイトはカスタムフィールド作ってやっているようです。 Seasa
多分コレが一番致命的なんだろうけど、Tracはチケットの作り方が分かりづらい。Redmineならプロジェクト作って新しいチケット(New issue)選べばいいだけなのに。Tracはどこ選択するんだろ?→ログインしたら新規チケットのアイコン出てきた。 少なくともコマンドでプロジェクト作れ、とかない。 Tracはサブプロジェクトの切り替えがめんどい。 チケットの表示はまず未解決のやつを一覧で表示→そっからフィルタ、みたいなことしてほしい Tracはチケットの親子関係が持てない? UIの統一がされてない。Mac風アイコンと青◇とか、青い方は横に伸ばすとかできないかなぁ。 だからTracは嫌い!っていうよりもRedmineのこう行った面をTracが取り入れてもらえるといいかなぁとか思うのです。特にTracは開発が熱心みたいですし。なにより私自身python使いなので頑張ってほしいとこです。 あと
Home インストールガイド Redmineのインストール » メールの設定例 アップグレード Redmineのバックアップとリストア 他システムからの移行 Trac Mantis その他のシステムからの移行とサードパーティーのスクリプト システム管理者向けガイド プロジェクトに対する管理操作 ユーザに対する管理操作 グループに対する管理操作 ロールと権限 課題管理システム カスタムフィールド 選択肢の値 アプリケーションの設定 システム管理者向けガイド — 高度な設定 リポジトリ メールによるチケット登録 リマインダメールの送信 LDAP認証 ユーザーガイド 始めましょう アカウント ログイン 登録 検索 マイページ 「概要」 活動 チケット » チケット一覧 »» チケットのサマリー » ロードマップ »» バージョンの概要画面 時間管理 » 作業時間の記録: 詳細 » 作業時間の記録
9月4日 XP祭り2010 ~ アジャイル学園祭~(東京都)(#xpjug) で @shimizukawa さんの 「Pythonでアジャイル開発サイクル2010ver.」 というセッションに参加させて頂きました。 その場で、実行委員の@shibukawaさんが、「セッションに来られなかった人のために、レポーターをやる人」を募集していたので、それくらいならお手伝いできるかと思い、手を挙げさせて頂きました。 ということで、清水川さんのセッションのレポートを書かせて頂きます。 スライドについての補足的な話と個人的な感想等を添えながら纏めたいと思います。 セッションのスライドはこちらです。 清水川さんのセッションスライド スライドは、id:amachangさんが作成したs6というHTMLプレゼンテーションツールを使って作られています。 使い方は、とりあえず←→↑↓ボタンを押せば大体分かると思いま
「チケットは開発を救う」と考え,2007年のITpro Challenge!にてチケット駆動開発を提唱した。Tracを使う最大の利点はチケットとリポジトリ・ブラウザを連携できることだと考えている。 前回(第2回~第3回)までの連載で,Tracのインストールと基本的な設定が終わりました。これからの連載では,Tracを上手に運用するためのコツをご紹介していきます。 Tracの主な機能には,Wikiとリポジトリブラウザ,それにチケットによるタスク管理システムがあります。Wikiとリポジトリブラウザは使っていても,チケットは使っていないという方は意外に多いのではないでしょうか。そこで第4回では,チケットの一番の用途である「バグ管理」について説明します。今回の説明には,Trac 0.11(日本語版)が含まれるTrac Lightningのバージョン2.0.4を使用しますが,基本的な考え方は以前のバー
こんにちは、そろそろ花粉のシーズンが近づいてきて戦々恐々としている金子です。 今年も花粉対策グッズの CM に注目しているのですが、花粉鼻でブロックがいいんじゃないか?と思っています。 花粉症のくしゃみ鼻水は、本人が辛いのはもちろんですが周囲にとっても気分の良いものではありませんよね。エチケットとしても花粉対策は怠らないようにしたいものです。 チケットついでに今回はチケット駆動開発の話をします。想定読者は Trac をリポジトリブラウザとして利用しているがチケットは使ったことがない人です。Trac、 Issue Tracking System という用語に馴染みのない方は、それぞれ関連リンクを用意しましたのでそちらをご覧ください。 以下、僕の経験に基づき「チケット駆動開発とは何か」「何が目的か」「どう実践したか」「結果が出たか」についてレポートします。だいたいここ二週間くらい、チームではな
アクセンスのおまけ 「オープンソースとも呼べない程度の何か」を提供します。ソースコードなら、1000行いかないくらいの小さいやつ。何か役に立ったらいいなという程度のものです。オープンソースだなんて恥ずかしくて言えませんが、それなりの、オープンソース・ライセンスを適用します。ライセンスの詳細については、それぞれのプロジェクトまたはソースコードをご覧下さい。その他、ウィキというよりブログ気味に、何やらつらつらと書いています。うちの仕事とは直接には関係ないことばかりです。誰かの役に立つかというよりは、自分用のメモだったりします。くだらないバグとかでつまずいても、しばらくすると忘れちゃうもので。 雑多 Go言語でイテレータが欲しかった(要らなくなった) Python関係 Cythonのドキュメントを翻訳しました Jinja2 の for ループ内にブロックを定義する SQLAlchemyドキュメン
最近、プロジェクト管理の手法が急激に変化しつつあるのを感じる。 以前は、ExcelやMS Projectで進捗管理や要件管理をプロジェクトリーダーが取り仕切り、メンバーに節目ごとに展開していた。 そこでよく出る症状として、プロジェクト全体の進捗や各メンバーの役割がメンバーに見えにくいことがあった。 だから、「見える化」と称して、XPやPFの手法が使われた。 最近は、Trac(Python)やRedmine(Ruby on Rails)のようにWikiベースのFreeのプロジェクト管理ツールを導入するケースが多くなった。 その特徴や感想について書いてみる。 【1】TracやRedmineの特徴は下記があるように思う。 1・Wikiに、技術上のアイデア、開発環境の構築方法、リリース作業手順、日報などを書き込み、皆で情報共有する 2・カレンダーにプロジェクトのマイルストーン、各自の作業納期を書き
システム開発を進めるにあたり、バグやタスクなどを管理して、現在発生しているバグの数や担当者といったステータスを把握する必要があります。また、ある程度以上の規模のWebアプリケーションを開発する場合、数人のチームで開発を進めるケースが多く、開発を円滑に進めていくためにスタッフ間での情報共有が重要になってきます。 「Bug Tracking System(以下、BTS)」は、これらの問題を解決するためにプロジェクトのバグを管理し、修正状況を追跡できるよう可視化を行うシステムです。現在、BTSとして様々なソフトウェアが公開されており、ソフトウェアを開発する上での必須アイテムになりつつあります。 BTSの多くはWebブラウザ経由でアクセス可能なソフトウェアで、その中から今回はウノウで採用している「Trac」について説明します。 Tracは、BTSとWiki、Subversionリポジトリビューワー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く