マネジメントのスピードが開発のスピードに直結する - プログラマの思索
倉貫さん(XPJUG代表)の記事を読んで、システム開発に関する洞察が優れている点についてメモ。 【元ネタ】 アジャイル開発のボトルネック - Social Change! (中略) つまり、発注側のかけるコスト（工数）の限界が、ソフトウェア開発における速度の限界点なのだ。プロジェクトが成功するかどうかの分水嶺と言える。 これは実はアジャイル開発に限らず、一般的なウォーターフォールのソフトウェア開発でも、まとめて要件定義や検収テストをしているだけで、結局、同じくらいの工数がかかっていたのではないだろうか。もちろん、要件定義の前のビジネスや業務検討のフェーズを含めれば、である。 アジャイル開発では発注側が行う作業へのコミットが細分化されて見えるので、開発と同程度の工数が必要だという傾向が顕著に見えるだけかもしれない。発注側と開発側にかかる工数比があるように思わせたのは、そうしないと儲からないS
コミットコメントの書き方 - wyukawa's diary
ソースコードのコメントの書き方についてある程度情報が出回っているように思うが、コミットコメントの書き方についてはあまり情報が無い気がするのでちょっと書いてみる。自分が出来ているかはおいといてｗ で、これはリポジトリとバグ管理システムとセットで考えなくちゃいけないと思っている。まあ要するにTracやRedmineを使ったチケット駆動開発前提の話です。つまりコミットコメントにはチケット番号を書け。以上、って話でもあるｗ コミットにはタグやブランチ作成のコミットを除くと大きく分けて２種類あると思う。１つ目はバグ修正のためのコミットで２つ目は機能追加のためのコミット。リファクタリングは２つ目に属するとする。 コミットはバグ修正、機能単位つまりチケット単位で行うべきだと思ってる。複数のバグ修正のためのコミットを１回でやられるとどのコミットがどのバグ修正に関連付いているのかわからない。こうなっちゃうと
チケット駆動開発のベストプラクティスを収集したい - プログラマの思索
チケット駆動開発を実践して、色々考察してきて、ベストプラクティス集を作りたいと思っている。 理由は、チケット駆動開発とアジャイル開発の密接な関係を明確にして、アジャイル開発を簡単に運用できるノウハウとして公開したいからだ。 僕は、チケット駆動開発には下記4個のプラクティスが最低限必要だと思っている。 但し、XPのプラクティスと同じだがTiDDの言葉で言い換えているものもあるので注意。 １・チケット・ファースト(Ticket First) 【説明】 基本は、プロジェクトの作業はチケットを受け取ってから始める。 チケット無しで作業はしない。 また、SVNコミット時に、チケット無しのコミットも不可。 【効用】 チケットがタスクカード(作業指示書)のため、コミュニケーションロスがなくなるし、作業履歴がチケットのコメントとして残る。 進捗情報は全てチケットに書くから、BTSのチケット集計機能でリアル
チケット駆動開発のFAQ - プログラマの思索
チケット駆動開発についてのFAQをまとめてみた。 他に聞きたい質問があれば、コメントして下さい。 チケット駆動開発のFAQを集めれば、チケット駆動開発を普及させるのに役立つと思うから。 【元ネタ】 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) TiDD：チケット駆動開発: ソフトウェアさかば RedmineとTracの機能比較: プログラマの思索 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 Tracのワークフロー: プログラマの思索 ワークフロー機能のカスタマイズ方法 - かおるんダイアリー そろそろTracのワークフローについて語っておくか - almost nearly dead チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索
Redmine -もっと手軽にプロジェクト管理! - kuranukiの日記（移転しました）→ http://kuranuki.sonicgarden.jp
「プロジェクト管理」という仕事は、ソフトウェア業界において、非常に重要な位置を占めるようになってきています。階層型の組織構造と違い、プロジェクト型の組織では情報はフラットにやりとりされて、プロジェクトのスタッフは目的達成のために有機的に動きます。 その時に、行うべき作業が見えていなかったり、スタッフ同士で共有できていなかったらどうでしょう。行うべき作業が重複していたり、手戻りが発生したり、やるべき作業が抜け落ちたり・・・ そこで、多くのプロジェクトでは、そのプロジェクトで行うべきタスクや課題について、一覧で管理していると思います。まずは、それがプロジェクト管理の第１歩です。 しかし、多くのプロジェクトでは、その課題やタスクの管理の一覧化に使っているのが表計算ソフトのExcelだったりします。タスクや課題の一覧化と共有が、プロジェクト管理のキモであることはわかりつつも、その管理ツールといえば
第13回名古屋アジャイル勉強会発表資料『チケット駆動開発入門』 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
There are No Perfect Redmine
There are No Perfect Redmine - Presentation Transcript Redmine Junya Ogura <juno@sooey.com> Jun 12, 2009 Saturday, June 13, 2009 Redmine 18 projects 1,696 tickets 22 users 2008.10 Saturday, June 13, 2009 • Junya Ogura ( ) • • PHP, Ruby, Java id:juno sooey.com twitter.com/junya github.com/juno Saturday, June 13, 2009 • Trac • • Textile • CSV • • Saturday, June 13, 2009 Trac Saturday, June 13, 2009
RedmineとTracの機能比較 - プログラマの思索
RedmineとTracの両方でチケット駆動開発を運用してみて、色んな気付きがあった。 以下メモ書き。 【比較対象】 ・Redmine0.8.0 ・Trac0.11.1.ja 【元ネタ】 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 【1】複数プロジェクトの扱い RedmineがTracよりも機能が優れている点の一つは、複数プロジェクトに対応していること。 Tracはプロジェクトに親子関係を入れることができないため、特に大規模プロジェクトではチケット駆動開発を実践しにくいだろうと思う。 複数プロジェクトを作りたい状況は、二つある。 【1-1】開発チームが複数のサブチームに分かれていて、それぞれでタスク管理したい場合。 RedmineやTracを運用してみると、一つのプロジェクトでメンバーが5人以上だとチケットが乱発されたり、放置されやすくなるようだ。
Redmineを使って気付いたことpart7～イテレーションで追跡する - プログラマの思索
チケット駆動開発でアジャイルに開発しながら、「チケットではなくイテレーションで進捗やリスクを追跡する」意味が何となく分かってきた。 それについてメモ。 【1】チケット駆動開発の基本は、チケットファースト。 チケットがXPのタスクカードに相当する。 担当者は、チケットへ作業内容を記入してから、作業を開始する。 開発者は実際、チケットをToDoカードのように用いている。 SW開発のタスクは単にプログラミングだけではない。 お客様へ納品する設計書を作ることも必要だし、テスト仕様書を作ることも必要。 更には、ビルド環境を作ることも必要だし、テストデータを準備することも必要。 すると、チケットは終了するペースよりも登録する方がどんどん増える。 何もしなければ、チケットは乱発されて、放置状態になり、収拾が付かなくなる。 僕が初めてTracを運用した時、マイルストーンやバージョンが曖昧なままチケットを登
Redmineを使って気づいたことpart5～イテレーションの概念 - プログラマの思索
XPのイテレーションの概念はTracとRedmineで微妙に異なる。 それについてのラフなメモ書き。 【元ネタ】 Redmine.JP | プロジェクトの設定 バージョン Trac Lightningで始めるチケット式開発「電撃」入門 (3/4) - ＠IT マイルストーンの設定、バージョンの設定 【1】XPやScrumを代表とするアジャイル開発で最も重要な概念は、イテレーションだと思う。 理由は、イテレーションがあるからこそ、繰り返し型開発が可能になり、そのイテレーションのサイズを小さくすることによって、XPのプラクティスの一つである小規模リリースも可能になるから。 イテレーションは、大ざっぱに喩えるならば、PDCAサイクルのプロセス。 イテレーションは、XPでは2～4週間、Scrumなら4週間のサイズで、計画からリリースまでのプロセスを含む。 TracやRedmineによるチケット駆動
メトリクスの威力 - プログラマの思索
チケット駆動開発を上層部へアピールするのに最も効果的なことは、現場の数字を提示することだ。 社長や取締役、管理職は、数字が非常に好きな人達。 彼らは、いつも売上の数字とにらめっこしている。 彼らは月次売上のために、請け負ったプロジェクトの進捗や品質をすごく気にしている。 チケット駆動開発を実践すると、チケットに日々の作業状態がリアルタイムに入力されるため、進捗をリアルタイムに見ることができる。 RedmineやTracでは、生成されたガントチャートから、赤色のタスクが遅延しているのが分かる。 カレンダーを見ると、月別のタスクの一覧が表示され、取消線のないタスクは作業中であることが分かる。 ロードマップから、バージョン単位の進捗が出るので、マイルストーンまでの残日数と比較して間に合うのかどうか考えることができる。 チケット集計結果であるサマリから、バージョンやコンポーネント単位の残チケット数
【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」 - プログラマの思索
関西Ruby会議01＠関西-KOF2008講演資料「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」を公開します。 CC Attribution ライセンスとします。 【元ネタ】 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) チケット駆動開発は、まちゅさんが最初に提唱された。 しかし、チケット駆動開発の概念はまだ曖昧で、一部でしか注目されていない。 僕は、Redmineというプロジェクト管理機能を持つBTSがプロジェクト管理をIT化してくれて、プロジェクト運営が大きく変わったことを経験した。 その体験をチケット駆動開発(Ticket Driven Development)という概念へ昇華できないか、考えた内容が上記の資料です。 コメントがあれば嬉しいです。 【参考】 Rubyist
プログラマの思索: ツールが開発プロセスを改善する
Redmineでチケット駆動開発(TiDD)を運用して気付いたことは、開発プロセスが大きく改善されただけでなく、従来の開発プロセスの弱点が浮き彫りになったこと。 下記の記事を読んで考えたことを書いてみる。 【元ネタ】 ケント ベック氏のアジャイル開発における開発支援ツールの役割についてのホワイトペーパー 元請SIerがTracのような環境を提供できない３つの理由 - なからなLife 元請け企業が用意すべきもの - T/O 【1】強力な構成管理ツールが無い時代はライブラリアンが独裁者 構成管理の基本は、任意のバージョンのシステムを再現できること。 今時、Subversionのようなバージョン管理ツールの無いSW開発プロジェクトはありえないだろう。 CVSやVSSが無かった頃は、構成管理ツールなど存在せず、構成管理を人手でやるしかなかった。 今でも、Excelなどの設計書はバージョン管理で制
プログラマの思索: 構成管理は誰のためのものなのか？
気になる記事を見つけた。その感想を書く。 【元ネタ】 構成管理は誰のためのもの？ 意外と知らない構成管理の正体～第1回 ファイルバージョンの管理だけで十分ですか？ 【1】最近のSW構成管理は、単なるバージョン管理、ビルド管理だけでなく、変更理由を追跡できる変更管理の観点を含む時が多い。 その分、構成管理の難易度が上がっているように思う。 単にSubversionやCVSでソースのみをバージョン管理できているだけでは、構成管理できているとは言えない。 そこで、気の利いたチームは、Rational製品のような重厚なプロセス付きの構成管理を導入する時があるだろう。 管理者は構成管理をしたがる。リリース作業がスムーズになるとか、デグレが減るなどの利点があるからだ。 しかし、逆に生産性が落ちる時が多い。 「意外と知らない構成管理の正体～第1回 ファイルバージョンの管理だけで十分ですか？」のように、構
課題管理対決！Redmine vs. Trac
Redmineの機能と特徴 Redmineは、Ruby on Rails上で動作する、Webインタフェースの課題追跡（Issue Tracking）ツールです。原稿執筆時点（2008年9月現在）での最新のバージョンは0.7.3です。 Redmineが搭載している機能は、「マイルストン設定（ロードマップ）」「カレンダー／ガントチャートの表示（概要）」「作業時間の登録／集計（チケット、概要）」「作業履歴の閲覧（活動）」「課題の登録／追跡管理（チケット、新しいチケット）」「伝言板（ニュース）」「文書の登録／閲覧（文書、Wiki）」「ディスカッション（フォーラム）」「ファイルの共有（ファイル）」「ソース管理との連携（リポジトリ）」「ワークフロー定義」「メール通知」「RSS配信」「ユーザの管理/ロール・権限の設定」です。なお、かっこの中はRedmine画面上で対応する主なメニュー項目名です。 筆者の
Redmineインストールメモ - プログラマの思索
Redmineのインストールや設定に関するメモ。 【1】Passengerをインストールすると、RailsをApache単独で稼動できる。 http://redmine.jp/tech_note/apache-passenger/ gem install passenger passenger-install-apache2-module 後は、httpd.confの設定だけすればいい。 Passengerの利点は、RailsがPerlやPHPと同じ感覚で運用できることだ。 今後のビジネスを考えると、RailsをJRubyで動かすか、Apacheで動かすか、どちらかが重要になるだろう。 要注目の技術だと思う。 【2】Wikiを使うには、下記を実行。 gem install RedCloth 但し、活動欄に表示されるチケット内容は、Wikiのシンタックスがそのまま表示されてしまう。 【3】日
プログラマの思索: チケット駆動開発の戦略
【1】チケット駆動開発は、まちゅさんが最初に提唱されている。 チケット駆動開発 ITpro Challenge のライトニングトーク 上記では「チケット無しのSVNコミットは不可」という思想が強調されている。 これは、本番リリースしたモジュールはチケット無しの場合修正不可、あるいは、プロジェクト内部の作業はチケットを作ってアサインして初めて稼動する、とも言い換えられる。 つまり、チケット駆動開発をプロジェクト管理の基本とすると、チケットに作業プロセスと作業担当者をアサインするのが前提条件になる。 そして、このチケットをバージョン単位にグループ化し、小刻みにリリースするのがチケット駆動開発。 僕がこの手法を運用して、強く意識するものは、チケットの取捨選択だ。 実際のプロジェクトでは、当初の計画した時のチケットの枚数と同じぐらい、バグ修正作業時にチケットが発生する。 つまり予期しない作業が、納
Redmineを運用するためのイロハを身につけよう：第7回 Javaプラットフォームでの運用｜gihyo.jp … 技術評論社
前回は軽量WEBサーバであるlighttpdを利用することでRedmineをより良いパフォーマンスで動かすための方法を紹介しました。今回はRedmineをJava EEのアプリケーションサーバで運用するための方法を紹介します。 読者の方には既にJava環境で他システムを運用している方もいらっしゃるかと思います。そのような場合に、Java EEのアプリケーションサーバとJRubyを利用することで、既存の環境に出来るだけ手を加えずにRedmineを運用したいという要望を実現することができます。 Java EEのアプリケーションサーバは数多く存在しますが、今回はその中でも多くの機能を兼ね備えており、注目度が高いオープンソース・プロダクトであるGlassfishで運用するための方法を解説します。 Glassfish以外にもRailsアプリケーションを運用することができるアプリケーションサーバには以
プロジェクト管理＝ソフトウェア構成管理 - プログラマの思索
最近思うのは、ソフトウェア開発のプロジェクト管理とは、ソフトウェア構成管理と表裏一体ではないか、ということ。 プロジェクトリーダーの仕事を見てみよう。 彼らの実際の仕事は、ガントチャートを作って、日々の進捗をガントチャートに反映するのに半日以上かける。 結合テスト以降は、業務シナリオ単位でテストケースを作成し、仕様変更や仕様漏れに対しテストケースを何度も保守する。 そして、テストで出てきたバグに対し、優先順位と期限を決めて、修正担当者・テスト担当者・検証担当者をアサインして回す。 それらのプロセス管理のために、進捗状況やバグ情報、バグが発生した要件を手作業で情報収集している。 プロジェクトリーダーの仕事は本来マネジメント業務なのに、マネジメントの判断材料をそろえる作業に1日の90％以上をかけていないだろうか？ 日本人はプロセス改善が大好きだ。 製造業の影響を受ける組み込み系の人達は、プロセ
XPを実現するCaseツールは？→Redmineだ！ - プログラマの思索
JaSST関西2008で出た質問。 アジャイル開発を現場で使っているが、イテレーションが短くて多いから管理しにくい。 イテレーションを管理できる良いCaseツールはありますか？ XPJUG関西代表の細谷さんは立場上曖昧に答えたけれど、僕の回答は、Redmineを使って下さい、だな。 RedmineこそXPを実現する開発インフラです。 Redmineでチケット駆動開発を実践すれば、XPの計画ゲームを実現できます。 と。 Redmineを2ヶ月使ってみて、プロジェクトリーダーの本来の仕事である、タスクの優先順位付けやリスク管理に時間を費やせるようになった。 【1】もう一度おさらい。 Redmineでプロジェクト作成後にまず設定するものは下記の通り。 1-1.バージョン マイルストーンと同値。 XPのイテレーションに相当する。 1-2.カテゴリ システムの機能別の単位。 XPのストーリーカードの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
