チケット駆動開発の背景 - プログラマの思索
下記の記事を読んで、チケット駆動開発が出てきた背景について考えたことをメモ。 【元ネタ】 TRICHORDの背景 TRICHORDの背景 - (1) 何故スケジュール管理が難しくなっているのか ◆ 大火事プロジェクトで自己組織化を促すために具体的にやったこと チケット駆動開発は、プロジェクトで発生した作業をチケットで管理し、バージョン単位にチケットをグループ化して小刻みにリリースしていくスタイル。 最近は、TracやRedmineのようなプロジェクト管理機能を持つBTSで運用することが多いだろう。 最近のビジネスの観点では、ITが業務のインフラとなっていて、機能がどんどん進化するのが前提になっている。 ビジネスの速さをシステム開発に応用しようとして、開発の現場が混乱しているようにも思える。 特に昨今のWebシステム開発は、数週間おきに小刻みにバージョンアップしていくのが普通。 開発者からす
チケット駆動開発の運用例 - プログラマの思索
チケット駆動開発の記事があったのでメモ。 【元ネタ1】 チケットで工数管理(Shibuya.trac 2009新年会 発表資料) - almost nearly dead kanu_orzさんによるTracのチケット管理の運用例。 インシデント管理や問題管理にTracを下記で運用していると思われる。 ・チケットをExcelで一括インポート ・Tracで工数を入力、集計 ・チケット集計結果をExcelで出力 特徴としては、Trac上で日々の作業の実績管理は行うが、作業の元ネタである大量のチケットはプラグインで一括インポートしたり、月次報告用の工数集計などの結果をExcelで出力している。 これは、いわゆるエンドユーザコンピューティングかもしれない。 つまり、Trac上に日々の作業と言うトランザクションを溜めていくが、マスタ(ここではチケット)の作りこみや、溜まったトランザクションから定期的に
Redmineを使って気付いたことpart8～チケット駆動開発の先にある世界 - プログラマの思索
チケット駆動開発やTestLinkなど各種ツールを運用して、SW開発とは一体何なのか？という疑問を感じた。 以下メモ書き。 Redmineでチケット駆動開発を実践すると、アジャイル開発における無駄な管理工数が減る。 TestLinkを導入すると、テスト工程における無駄なマネジメント工数が減る。 Hudsonによって、リリース作業の工数も減る。 では、それらでプロジェクトは楽になったのか？ 確かに、以前よりも進捗管理は制御しやすくなった。 でも、SW開発そのものの難しさは変わっていないように思う。 むしろ、顧客と要件定義に時間を費やしたり、設計時に仕様変更の履歴を辿って本来の要件を理解しようとしたり、実装を意識した設計に時間を費やす。 いわゆる前工程へのフロントローディングが自然に行われるようになり、設計工程で多くの時間を割くようになった。 つまり、開発時の進捗管理に自信があるからこそ、曖昧
Redmineの唯一の弱点～工数管理 - プログラマの思索
僕は、Redmineは現在、世界中で一番優れたBTSだと思っている。 何と言ってもプロジェクト管理機能が強力で、このおかげでチケット管理を更に活用できる。 しかし、唯一の弱点があると思う。 それは、工数管理。 Redmineチケットには、予定工数と実績工数を入力できる。 その実績工数は、レポート欄でログ検索のように検索できる。 しかし、使い勝手は正直悪い。 実績工数を単に表示するだけでは面白くないからだ。 また、Redmineの実績工数には作業分類という属性があり、デフォルトでは「デザイン作業」「開発作業」がある。 これは、Redmineでは作業トラッキング(タイムトラッキング)と呼ばれている。 つまり、実績工数を更新するたびに、実績工数を色づけできるから、後で、作業分類ごとに工数集計できる。 しかし、この作業分類を上手に使って集計する機能がない。 結局、MySQLへ直接SQLを発行して、
RedmineとTracの機能比較 - プログラマの思索
RedmineとTracの両方でチケット駆動開発を運用してみて、色んな気付きがあった。 以下メモ書き。 【比較対象】 ・Redmine0.8.0 ・Trac0.11.1.ja 【元ネタ】 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 【1】複数プロジェクトの扱い RedmineがTracよりも機能が優れている点の一つは、複数プロジェクトに対応していること。 Tracはプロジェクトに親子関係を入れることができないため、特に大規模プロジェクトではチケット駆動開発を実践しにくいだろうと思う。 複数プロジェクトを作りたい状況は、二つある。 【1-1】開発チームが複数のサブチームに分かれていて、それぞれでタスク管理したい場合。 RedmineやTracを運用してみると、一つのプロジェクトでメンバーが5人以上だとチケットが乱発されたり、放置されやすくなるようだ。
品質がスケジュールよりも優先される理由 - プログラマの思索
CMMIを作ったハンフリーが書いた本「ソフトウェアでビジネスに勝つ」を読んでいる。 mgさんのコメントを書きながら、考えたことをメモ。 【元ネタ】 アジャイル開発は受託開発の方が向いている: プログラマの思索 「ソフトウェアでビジネスに勝つ」の本は、経営者向けに書かれたソフトウェア管理に関する考察した本。 第1章に、SW管理の原則が3ついきなりあげられるが、その一つに「品質がスケジュールよりも優先する」という原則がある。 SW開発に従事している人ならば、この原則をいつも実感しているし、逆に、この原則に逆らうような仕事をしているのも事実だ。 設計や開発という工程よりも、テスト工程でこの原則を実行すべきかどうか判断に迷う。 仕様変更が来たけれど、バグ修正を優先すべきか？ バグ修正よりも、目先のタスクをこなすべきか？ 全てのテストをし尽くしてバグをたくさん出してから、バグ修正すべきか？ 今、僕は
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
