TestLinkのVer1.8を使ってみて、隠れ機能を見つけたので書いてみる。 【1】Ver1.8以降では、下記のドキュメントに従うと、予定工数、実績工数の合計表示をテスト結果画面で集計できると書かれている。 testlink\docs\customfields_for_computing_times.txt 上記に従って、Ver1.8.2とVer1.8.4のTestLinkで、下記の手順を行ってみた。 【TestLink1.8.2】 １・4個のSQLを実行 ２・テスト仕様で、テストケースを作り、予定工数を入力 ３・テスト実行で、テストケースに実績工数を入力して「成功」にする ４・テスト結果で、「カスタムフィールド情報とテストケース」画面で実績工数が表示される。 しかし、同じテストケースをグルーピングして実績工数を合計表示してくれない。 ５・テスト結果で、「カスタムフィールド情報とテスト計

要求や要件管理に関する本「要求開発と要求管理―顧客の声を引き出すには」「成功する要求仕様 失敗する要求仕様」を読んで、アジャイル開発との関係についてメモ。 【1】IBMでは、「要求」と「要件」の言葉を意識的に使い分けていると聞いた。 「要求」とは、ユーザの生の要望。粒度が荒く、MECEでもない。 「要件」とは、SIが要求を咀嚼して、顧客が分かるレベルの要望にしたもの。 「要件」には3種類あると言う。 一つ目は、ユーザ企業の経営層の観点から見る事業要件。ビジネス要件とも言われる。 2つ目は、ユーザ企業の現場層の観点から見る業務要件。顧客の実際の業務フローのレベルに相当する。 3つ目は、システムの観点から見た機能要件。非機能要件は、性能や信頼性などに関わる要件として区別される。 我々技術者が見る要件は、システム要件に相当する。 しかし、顧客と話す場合、業務要件でなければ会話ができない。 更に、

児玉公信さんの本「システム開発の見積りのための実践ファンクションポイント法」を読んで、ファンクションポイント法を業務モデルの計測に使えないか、考えてことをメモ。 ＃まとまっていないので、あくまでもメモ書き。 ファンクションポイント法(FP法)は、機能の規模の見積もりとして古くから知られている。 しかし、計算が複雑で、見積もりの根拠となるモデルが曖昧なため、普及しているとはいえない。 「システム開発の見積りのための実践ファンクションポイント法」で興味深いと思った点は下記の通り。 【1】業務設計やシステム提案という早い段階で、概算の工数見積もりを出す道具として、FP法を使うこと。 FP法を使うタイミングとしては、RFPによる提案やシステム化構想、業務設計など、プロジェクト計画書を作る段階を想定している。 実際の業務設計では、顧客の現行業務と新業務の二つのモデルを作り、システム化の利点をアピール

TestLinkでテスト管理を運用してみて、ベストプラクティスを自分なりにまとめてみた。 あくまでも下記は僕が経験したこと、理解できたことに過ぎないので、間違っていたらコメント下さい。 【元ネタ】 脱Excel！ TestLinkでアジャイルにテストをする － ＠IT自分戦略研究所 TestLinkのFAQ: プログラマの思索 テスト手法の概念をTestLinkで説明する: プログラマの思索 TestLinkを運用して気付いたことpart8～みなしバグ、ブロッキングバグ、周辺テスト、そしてクリティカルパス: プログラマの思索 TestLinkを運用して気付いたことpart9～後追いテスト: プログラマの思索 TestLinkを受入テストで運用する方法: プログラマの思索 【1】ブロック テストケースの事前条件が、失敗したテストケースに依存しているためにテスト不能になった状態を指す。 ブロッ

テスト消化とバグ発生曲線(バグ収束曲線)をパターン分けした素晴らしい記事があったのでメモ。 【元ネタ】 山浦恒央の“くみこみ”な話（16）：テスト消化曲線とバグ発生曲線の7パターン診断 - MONOist（モノイスト） テスト消化曲線は、未実施テストケース数を時系列に表示したグラフで、普通は右肩下がりになる。 バグ発生曲線(バグ収束曲線)、累積バグ数を時系列に表示したグラフで、普通は右肩上がりになる。 テスト消化とバグ発生曲線は密接に関係している。 理由は、ブロッキングバグがたくさん出るほど、ブロックするテストケースが増えてしまってテストの進捗は遅れるからだ。 実際にTestLinkでテスト管理してみると、ブロッキングバグが出るたびに、テストに失敗するだけでなく、ブロックするテストケースも増える。 例えば、テストに1回失敗すると、10個ぐらいのテストケースはテスト不能になってしまう。 僕の

面白い記事があったのでメモ。 明鏡止水: 今年のサーバーの楽しみ 僕が今年注目するツールは下記の通り。 Redmineは0.9.2が出て、使い易くなった。 プラグインが対応すれば、OSSのプロジェクト管理ツールの中でもかなり良い部類に入ると思う。 TestLinkも1.9beta2が出て、今年中に1.9が出るだろう。 要件管理、レビュー管理ができるそうなので、楽しみ。 特にTestLinkは使い辛い部分が多いので、どんどん改善して欲しいと思っている。 TestLinkによるテスト管理、要件管理は、かなりのポテンシャルがあると思っている。 個人的には、Review Boardを使いこなしたいと思っている。 コードレビューは重要と分かっているにも関わらず、結局実践出来ていない。 それから、教育管理システムMoodleにも注目している。 IT技術者にとって使う機会は少ないけれど、教育もWeb化で

Redmineを大規模プロジェクトで使っている例を見たのでメモ。 【元ネタ】 複数プロジェクトとワークフローの設定について - Redmine Users (japanese) | Google グループ 上記のメールでは、下記の規模まで使っているらしい。 例1： プロジェクト：12 ロール　　　： 8 ステータス　：25 トラッカー　：12 例2： プロジェクト：200～400ぐらい ロール　　　： いまのところ６個にしぼっているけど今後は２０ぐらいになりそう ステータス　：６ぐらい トラッカー　：２０以下 正直な感想は、すごい！の一言。 Redmineはおそらくこんな規模まで運用するとは想定していないと思う。 上記の問題点は、Redmineによるチケット駆動開発のスケールアップにある。 サブチームの数が無制限でも運用に耐えれるのか？という問題。 スケールアップはプロセスの標準化と密接に

小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

昨日、ＸＰ祭り関西２０１０が無事に終了した。 多分150人近い参加者だったと思うので、大成功だった。 東京から長瀬さん、AgileJapanのebackyさんやミルズさん、日経BPの井上さん、XPJUGの倉貫さん、岡山からてつさん、福井から岡島さん。 東京や名古屋など遠方から結構な数の人が来てくれた。 関西はアジャイル開発のマーケットが十分にある手応えを感じた。 チケット駆動開発セッションも、懇親会で感想を聞くと評判が良かったみたい。 TiDDの事例や試行錯誤を聞けて興味深かったらしい。 実際にBTSを使っている人もいれば、今から試そうとしている人もいて、色んな観点で聞いていたようだ。 僕はWeb系開発でRedmine、さかばさんはパッケージ製品開発でTrac、小枝さんは組込製品開発でManitsを使って、TiDDを実践した事例を三者三様で話した。 僕も、二人の話は既に聞いていたけど、改め

小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

Redmineの各機能から眺めたチケット駆動開発の課題についてメモ。 ラフなメモ書き。 【プロジェクト】 「Redmineのプロジェクトはどんな単位で作るべきか？」という質問は良く出る。 僕がTiDDをアジャイルに運用した経験から言えば、二つある。 一つ目はブランチのライフサイクルに合わせる。 二つ目はITILの運用保守プロセスに合わせる。 前者は、RedmineのプロジェクトがSCMリポジトリと1対1に対応している思想から、自然に扱える。 例えば、本番リリースしたソースは本番ブランチとして作られて、trunkとは別のコードラインで保守される。そして、次のメジャーバージョンが出たら、古い本番ブランチは廃止されて、以後は保守されなくなる。 つまり、プロジェクトとブランチが1対1に対応する状態遷移になる。 プロジェクト：新規作成→使用中→非公開→終了 ブランチ：新規作成→使用中→廃止(以後保守

ITILにRedmineを導入したソリューションサービスを展開している会社があったのでメモ。 【元ネタ】 Redmine for ITILの特長｜ホロンテクノロジー[Holon Technology]--サービス＆ソリューション-- サーバー監視ツールHinemosでエラー検知後、Redmineでインシデント管理するらしい。 OSSで固めているのが面白い。 統合運用管理ツール「Hinemos」が検知した事象発生から対処までの運用プロセスを一元管理します。 システムでの事象発生から対処、対処状況の管理までを一元管理が可能です。 ITILサービスサポートの各プロセス（インシデント管理、問題管理、変更管理）に基づいた運用プロセスの統制により、確実で正しい業務運用を支援します。 作業手順の標準化や役割を明確にすることで、IT運用プロセスの統制を図ることができます。 説明を読むと、下記の流れでRed

Redmine.JP | Redmine on Twitterで、OpenPNE3が何故Trac＋SVNからRedmine＋Gitへ変更したのか、その理由と運用例が書かれていたのでメモ。 内容がとても素晴らしいので、共有する為に書く。 #下記は僕の想像の部分も含む。 【元ネタ】 【提案】OpenPNE3 の BTS と SCM を Trac + SVN から Redmine + Git に変更する ([Suggestion] Switch the BTS and the SCM that are used for OpenPNE3, from Trac + SVN to Redmine + Git) - openpne-dev | Google グループ OpenPNE 3 - Ticket Workflow (ja) - OpenPNE Issue Tracking System Ope

小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

RedmineのVer0.8.4、0.8.6に入れたプラグインのうち、使っているものを公開してみる。 1年前に比べると、プラグインが充実していて楽しい。 結局10個以上も入れていた(^^;) 【コードレビュー】 r-labs - Code Review - Redmine Redmineのプラグインが充実している: プログラマの思索 リポジトリ画面からコードレビューのチケットを発行して、レビューをワークフロー管理できる。 お手軽にコードレビューできるのがいい。 レビューもチケットにするから、ワークフローのカスタマイズも可能。 【Hudson】 r-labs - Hudson - Redmine Redmineのプラグインが充実している: プログラマの思索 Hudsonと連携して、ビルド管理する。 SimpleCIプラグインよりもはるかに機能が充実している。 【Wiki拡張】 r-labs

Redmine.JP BlogにあるRedmine0.9xの機能の解説が素晴らしい。 Redmine 0.9 新機能紹介(6): プロジェクトのコピー | Redmine.JP Blog プロジェクトのコピー機能を使いたい場面は、以前のプロジェクト設定をテンプレート化しておきたい時だ。 例えば、Ph1のプロジェクトが終わって、Ph2のプロジェクトを開始する時、前回のプロジェクト設定をそのまま使えると楽になる。 特に大規模プロジェクトでは、サブチームのタスク管理の構造は殆ど同一だろうから、テンプレートを引継ぎできると、すぐにタスク管理を始められる。 Redmine 0.9 新機能紹介(7): チケット一覧画面の改善 | Redmine.JP Blog チケットのグルーピングができるようになったのが良い。 これによって、ステータス単位でグルーピングすれば、PFのかんばんと同等の画面になる。 つ

ユーザ企業の情報システム部門がチケット駆動開発を運用する場合の注意点を考えてみた。 以下メモ書き。 情報システム部門は、その企業の業務を遂行するために必要なシステムに関する仕事を担当している。 現代では、業務システムは企業のインフラ。 電気や水道が止まったら家で生活できないように、業務システムが止まったら会社で仕事できない。 だから、CIOはCEOに次ぐ重要な役割を担っているはず。 しかし、日々の雑務に追われている割には、他部署からコストセンターと思われて大変だと思う。 情報システム部門は、企業規模や担当範囲によって、その役割は大きく異なる。 想像すると、次の3つのパターンに分けられると思う。 １・業務システムの運用保守以外に、内製(自社開発)も行っている ２・業務システムの運用保守だけ。 ３・運用保守すらアウトソーシングし、企画・発注のみ行っている １は、自社に開発部隊があるので、かなり

チケット駆動開発にEVMの概念を導入できるか考えた事をメモ。 #間違っているかもしれないので、あくまでもイメージを書く。 【元ネタ】 [ThinkIT] 第2回：EVMの基本値から導出される値の説明と練習問題 (1/4) チケット駆動開発にPMBOKの概念を導入してみる: プログラマの思索 Redmineの集計プラグイン、statSVN諸々: プログラマの思索 チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索 プロジェクト実績の測定とコントロール 【1】以前のように、システムの検収が終わった後に丼勘定で収支のつじつまを合わせる工事完成基準は、もはやできない。 2009/4から、SW開発も他業界と同様に工事進行基準で会計報告が必須になったため、四苦八苦しているプロジェクトは多いだろう。 EVMは、SW開発のプロジェクト管理における工事進行基準の仕組みと言って

小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le