スクエア・エニックスのCTOが書いたプロジェクトマネージメントの資料がとても良かったのでリンクしておく。 【元ネタ】 スクエア・エニックスのCTOが書いたプロジェクトマネージメントの資料がスゴイ！ at ミネルヴァの梟は黄昏とともに飛び始める 【1】ゲーム業界のソフトウェア開発案件を元にしているが、仕様・納期・人員・品質などの要素が当初見積りよりもわずかに増えるだけで、実績工数が10倍以上に膨れ上がることを簡単な例で説明している。 更に、10倍に膨れ上がった工数は、仕様を減らし、納期を延ばし、人員を大量投入し、品質を落とし、更に開発者の労働時間を80％増やせば帳尻が合うという話から、簡単にデスマーチに陥ると説明しているのが分かりやすい。 実際は簡単なモデルでは説明できないだろうが、感覚的にはフィットする。 プロジェクトがデスマーチに陥るきっかけは、各要素の些細なギャップから生まれる。 それ
TiDD初心者が陥りやすいアンチパターンを実際に見つけたのでメモ。 【1】チケット駆動開発の概念に慣れておらず、Redmineでタスク管理をまず始めた人に多い特徴がある。 それは、バージョンが設定されておらず、ロードマップが空っぽないし非表示な状態。 話を聞くと、Redmineのバージョンの意味や使い方が理解できないらしい。 だから、彼は、Redmineのチケット一覧画面でタスク管理を実施している。 彼のチケット一覧画面を見ると、スクロールできないくらい、たくさんのチケットが無造作に一覧表示されている。 どうやら、必要なタスクはチケットに登録しているが、彼のチケット管理を見ていると、チケットの納期が意識されていない。 そのチケットはいつリリースするのか？の観点が漏れているみたい。 何故なら、チケットがたくさんありすぎて、どのチケットが必要なのか、チケット一覧画面では分かりにくいからだ。 だ
チケット駆動開発を運用してみて、チケット駆動開発と朝会・ふりかえりは相性がよいことに気付いた。 以下メモ書き。 【元ネタ】 朝会について - sakuramateo. 朝会のパターン：立ってるだけじゃないよ プロジェクトファシリテーション実践編：朝会ガイド 初めてのプロジェクトリーダー（6） 「ふりかえり」でプロジェクトを改善する オブジェクト倶楽部の「プロジェクトファシリテーション 実践編 ふりかえりガイド」 【1】駄目な開発チームは、コミュニケーションが無い。 例えば、開発者はPCに座ったまま、一言も喋らずに黙々と作業するだけ。 設計から開発と単体テストまで順調であっても、結合テストで必ず火を噴く。 その時に、お互いのプログラムのインターフェイスが合っていないことが判明して、たくさんのバグが出て、そして収拾がつかなくなる。 責任のなすりあいに陥ったりする。 そういうチームは、フィードバ
営業の人がRedmineでチケット駆動開発を実践した記事があったのでメモ。 【元ネタ】 redMineで仕事のディレクション・進行管理 | 陽のあたらない美術館 -人間再生- 上記Blogを見ると、下記の内容のようだ。 ・Redmineのバージョンは、0.6.4。 ・Web制作のタスク管理にRedmineを運用している。 ・バージョンには、「受注フェーズ」「企画・仕様」「ベータ版公開」「正式公開」が登録されている。 つまり、マイルストーンを工程単位にしている。 ・チケットには「見積書提出」「契約」「企画書提出」「仕様詳細検討」「開発１」「動作確認１」「サーバ設定」「調整」などのタスクが登録されている。 これらのチケットを工程であるバージョン単位にまとめている。 ・ガントチャートやカレンダー、ロードマップでチケットの進捗を管理している。 ・ステータスは「新規→担当→解決→終了」のため、Red
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
RedmineとTracの両方でチケット駆動開発を運用してみて、色んな気付きがあった。 以下メモ書き。 【比較対象】 ・Redmine0.8.0 ・Trac0.11.1.ja 【元ネタ】 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 【1】複数プロジェクトの扱い RedmineがTracよりも機能が優れている点の一つは、複数プロジェクトに対応していること。 Tracはプロジェクトに親子関係を入れることができないため、特に大規模プロジェクトではチケット駆動開発を実践しにくいだろうと思う。 複数プロジェクトを作りたい状況は、二つある。 【1-1】開発チームが複数のサブチームに分かれていて、それぞれでタスク管理したい場合。 RedmineやTracを運用してみると、一つのプロジェクトでメンバーが5人以上だとチケットが乱発されたり、放置されやすくなるようだ。
Tracを使い始めて、Redmineと異なる視点を感じる所があったのでメモ。 【1】RedmineやTracを障害だけでなく要望も含めてタスク管理する発想は、Issue Trackingと呼ばれる。 元々、チケット駆動開発(Ticket Driven Development)は、バグ管理システム(Bug Tracking System)を汎用化した課題管理システム(Issue Tracking System)から発生した開発プロセス。 すると、障害管理で使われるステータスだけでは管理しにくい場面が出てくる。 例えば、ITILではシステム運用保守で、問題管理、インシデント管理、変更管理、リリース管理の4つの視点を提供する。 BTSのバグ管理は、問題管理と同じ。 問題管理のワークフロー(チケットの状態遷移図)は下記が普通だろう。 新規→担当→解決→検証中→検証完了→終了(リリース完了) このパ
Redmineでチケット駆動開発を運用し始めてから、自然にふりかえりを取り入れることが多くなった。 ふりかえりでは、KPTという思考フレームワークを使うことが多い。 このKPTという手法で、開発チームと開発プロセスを大きく改善できた経験をしたので、振り返ってみる。 ＃ラフなメモ書き。後でまとめる。 【元ネタ】 初めてのプロジェクトリーダー（6） 「ふりかえり」でプロジェクトを改善する オブジェクト倶楽部の「プロジェクトファシリテーション 実践編 ふりかえりガイド」 【1】ふりかえりが無いチームは成長しない 成果物の品質が悪く、納期がズルズルと遅れる開発チームでは、同じ失敗を何度も繰り返す症状が多いだろう。 例えば、デグレ。 デグレが何度も起きると、その成果物そのものの信頼性が損なわれ、最終的には人間関係の信頼まで壊れてしまう。 そんな症状を見ると、駄目なチームはフィードバックプロセスが無い
Redmineを運用して気づいたことを書いてみる。 【元ネタ】 ソフトウェア開発の必須アイテム，BTSを使ってみよう：第6回 運用の開始｜gihyo.jp … 技術評論社 ソフトウェア開発の必須アイテム，BTSを使ってみよう：第9回 BTSの運用データを解析して役立てる｜gihyo.jp … 技術評論社 [redMine] 最近の redMine 05/02-05/06 - Don'tStopMusic (2007-05-06) 【1】チケットのステータスは、トラッカー(チケットの種類)に応じて異なる Redmineによるチケット管理で重要な概念はトラッカー。 Redmineのトラッカーは、チケットの種類を意味する。 デフォルトでは、バグ(defect)・機能(feature)・サポート(support)の3種類がある。 バグ修正、機能追加、その他のタスク(例えば、環境構築など)で使い分け
気になる記事を見つけた。その感想を書く。 【元ネタ】 構成管理は誰のためのもの？ 意外と知らない構成管理の正体～第1回 ファイルバージョンの管理だけで十分ですか？ 【1】最近のSW構成管理は、単なるバージョン管理、ビルド管理だけでなく、変更理由を追跡できる変更管理の観点を含む時が多い。 その分、構成管理の難易度が上がっているように思う。 単にSubversionやCVSでソースのみをバージョン管理できているだけでは、構成管理できているとは言えない。 そこで、気の利いたチームは、Rational製品のような重厚なプロセス付きの構成管理を導入する時があるだろう。 管理者は構成管理をしたがる。リリース作業がスムーズになるとか、デグレが減るなどの利点があるからだ。 しかし、逆に生産性が落ちる時が多い。 「意外と知らない構成管理の正体～第1回 ファイルバージョンの管理だけで十分ですか？」のように、構
最近、Tracの情報がネットで溢れている。 Tracはプロジェクト管理機能を持つBTSとして一番有名なので、数々のプラグインが作られている。 その中で、Tracにはあるものの、Redmineには無い優れた機能についてメモしておく。 ＃誰か実装してくれないかな。 【元ネタ】 trac + TracBurndownプラグインでスクラム開発のすすめ バグ収束曲線やバーンダウンチャートを描画するQuery Chart マクロ Tracでコードレビュー メールをTracに蓄積 - MailArchiveプラグイン 【1】バグ収束曲線、バーンダウンチャート バグ収束曲線は、累積バグ数と累積バグ解決数を日別にグラフ化したもの。 ソフトウェアメトリックスの中ではおそらく最も有名だろう。 特に、組み込み系の開発チーム、品質保証部の人達がよく使っているだろう。 バグをたくさん出した後にバグが減ると品質の歩溜り
Redmineの使い方は下記を見よ。 http://www.redmine.org/projects/show/redmine 【1】以下、Redmineを使った感想を書いてみる。 1-0.ガントチャートがリアルタイムに表示される。 こいつに一番感動した。 プロジェクトリーダーは、ガントチャート保守に、彼の作業時間の殆どを費やす。 その理由は、プロジェクトのリスクがガントチャートでしか把握できないからだろう。 考えてみれば、作業の開始日と終了日、作業状態さえ入力すれば、リアルタイムにガントチャートは計算できるはず。 殆どのITプロジェクトのガントチャートは、手作業でかなりの時間を浪費して作っているか、MSProjectのように保守しても理解しにくいか、どちらかだ。 ソフトウェア開発のプロジェクト管理で最もIT化されていない部分と言える。 1-1.SVNリポジトリとチケットが相互リンクできる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
