WindowsのキラーアプリExcel
チケット駆動開発におけるExcelの役割についてメモ。
#あくまでもメモ書き。
受託開発では顧客の業務のうちExcelで手運用している業務をIT化、Web化することで狙い撃ちにしているのに、自分たちのSW開発ではExcelが幅を利かせている。
つまり、SW開発の業務そのもののIT化は遅れているのが現状だろう。
なぜ、Excelによるプロジェクト管理は良くないのか?
その理由は下記で書いた。
Excelのプロジェクト管理は何故良くないのか: プログラマの思索
一言で言えば、ExcelのドキュメントはSVN・Mercurialなどでバージョン管理すべきか、RedmineのチケットやTestLinkのテストケースなどで代用できるか、使い分けることが肝心。
では、チケット駆動開発は何をもたらしているのか?
その理由は下記で書いた。
Excelのプロジェクト管理から脱却せよ~SW構成管理を見直そう: プログラマの思索
つまり、頻繁にリリースできる開発インフラを開発者へ提供することによって、無駄な管理工数を極限まで削減して、本来のソフトウェア開発プロセスそのものの品質を高めることだ。
頻繁にリリースできるインフラがなければ、アジャイル開発は絵に描いたもちに過ぎない。
では、Excelの本来の役割は何か?
Excelはエンドユーザコンピューティング(End User Computing)のためのWindowsクライアントとして使うべき。
つまり、プロジェクトマネージャや顧客が自分のPCで、自分が欲しいと思う情報へ自分で加工すること。
その元ネタをITシステムが提供すべきであり、全ての顧客の要求をITシステムが実現する必要はないこと。
エンドユーザコンピューティングとは【EUC】 - 意味/解説/説明/定義 : IT用語辞典
例えば、Redmineのチケット管理で進捗管理をしていたら、毎晩、今日のチケットの進捗をCSV出力して、Excelマクロで加工して、上司に進捗報告書を送る。
CSV出力してMS Projectへインポートして、PMBOKのEVMでコストを計算してもいい。
又は、MS Projectでガントチャートを書き直してもいい。
あるいは、結合テストのバグ管理をRedmineで行っていたら、毎晩、今日のバグのチケットをCSV出力して、バグ累積数やバグ消化数をカウントして、信頼度成長曲線(バグ収束曲線)をExcelマクロで生成する。
SRATSというExcelマクロを使えば、ソフトウェアのMTBFも計算可能だ。
あるいは、TestLinkでテスト実績を管理していたら、毎晩、今日のテスト実績をCSV出力して、TestLinkCnvMacroでテストの予定と実績の進捗報告を作ったり、曜日別・時間帯別・テスト実行日別のテストケース消化数をグラフで出力すればいい。
Redmineで進捗報告を作ったり、TestLinkでテスト仕様書を作ったりするのは、会社のフォーマットに合致していなかったりする。
だから、元ネタとなるCSVやXMLを出力しておいて、マネージャや顧客がExcelに取り込んで自分たちの好きなように整形した方がいい。
個人的に欲しいExcelマクロは下記の通り。
誰か作ってくれないだろうか?
【Redmine】
1・Excelで作ったWBSをRedmineのチケットへ新規インポート
→Redmine CSV Import Pluginで一応、対応可能。
Redmine CSV Import Pluginの使い方: プログラマの思索
2・RedmineのチケットをExcelで出力して、Excel上で修正して、チケットに上書きインポート
→Redmine CSV Import Pluginで一応、対応可能。
3・Redmineのバージョン単位にチケットの予定と実績を比較した進捗報告書をExcelで生成
→実現されていない。
【TestLink】
4・Excelのテスト仕様書で作ったテストケースをTestLinkへ一括インポート
→TestLinkCnvMacroでは、Ver1.7.xもVer1.8.xも可能。
TestLinkのテストケースを一括変換するマクロ: プログラマの思索
5・TestLinkのテストケースを出力して、Excel上で一括修正して、TestLinkのテストケースを上書きインポート
→TestLinkCnvMacroでは、Ver1.7.xはOKだが、Ver1.8.xはNG。
6・TestLinkのテスト実績を出力して、Excelへコンバート
→TestLinkCnvMacroでは、Ver1.7.xはOKだが、Ver1.8.xはNG。
7・Excelのテスト仕様書と要件定義書とそれらの紐付けを作り、TestLinkの要件として一括インポート
→TestLinkCnvMacroでは、Ver1.7.xはOKだが、Ver1.8.xはNG。
8・TestLinkのテスト実績の管理から、要件カバレッジをExcelでグラフ出力する
→TestLinkCnvMacroでは、Ver1.7.xはOKだが、Ver1.8.xはNG。
9・TestLinkの要件で仕様変更が発生したとき、要件の影響箇所をリンクで一覧表示する(サスペンドリンク)
→実現されていない。
10・TestLinkからテスト消化曲線、Redmineからバグ収束曲線の元ネタとなるCSVを出力して、Excelでテスト消化曲線とバグ収束曲線をグラフ化する
→実現されていない。イメージは下記の記事。
テスト消化曲線とバグ発生曲線のパターン診断: プログラマの思索
RedmineとTestLinkという優れたプロジェクト・テスト管理ツールに予定と実績データは一括管理されているので、直接SQLを実行してもいいし、CSV出力してもいい。
そして、その元ネタとなるCSVから、Excelで色んな観点でプロジェクトの進捗や品質を考察してみたいのだ。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
「Redmine」カテゴリの記事
- 第24回redmine.tokyo勉強会の感想 #redmineT(2023.06.03)
- 「Redmineハンドブック」は良い本です(2022.12.17)
- 第23回東京Redmine勉強会の感想~コミュニティは仲間から生まれて続く #redmineT(2022.11.06)
- 第22回東京Redmine勉強会の感想 #redmineT(2022.05.29)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
「ソフトウェア工学」カテゴリの記事
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- QAエンジニアの役割は開発チームのガードレールみたいなものという考え方(2023.08.21)
- テストアーキテクチャ設計モデルとJSTQB概念モデルの比較(2023.07.02)
- パターンカタログよりもモンスターカタログの方が面白いね #jasstkansai(2023.06.24)
- 「ゲームをテストする バグのないゲームを支える知識と手法」の感想(2023.06.10)
「TestLink」カテゴリの記事
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.26)
- TestLinkの要件管理にUSDMを適用する方法(2023.01.22)
- TestLinkのテストケースはクラスとインスタンスの考え方で区別する(2023.01.22)
- テスト管理ツールCAT、TestRail、QualityForwardのオンラインのマニュアルのリンク(2022.09.24)
- テスト管理ツールTestRail、CAT、QualityForwardの感想(2022.07.30)
「チケット駆動開発」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
- Redmineにメンション機能が入るらしい(2022.01.15)
コメント