プロジェクト管理サーバーとは
僕が考えているプロジェクト管理サーバーについて良い記事があったのでメモ。
【プロジェクト管理サーバーのイメージ】
そろそろプロジェクト管理ツール群について一言言っておくか - Talking Nonstop
プロジェクト管理サーバーの目的は、SW開発で必要なインフラを提供することにある。
基本は、タスク管理(Redmine・Trac)とバージョン管理(Subversion)。
タスク管理の目的は、プロジェクト内部の作業全てを見える化して、一元管理すること。
RedmineやTracの運用の鍵は、タスクをチケットにどこまで分割して、アジャイル開発のイテレーションへどのように落とし込むか、という点にある。
つまり、分割したチケットをリリース単位にまとめて、小規模リリースできるか、という観点が大事。
バージョン管理の目的は、プロジェクト内部で発生する全ての成果物を一元管理すること。
バージョン管理の本質は、エディタのように成果物のUndo/Redoができることにある。
対象は、ソースコードだけでなく、ExcelやWordなどの仕様書やビルドスクリプトなども含まれる。
仕様書を「画面定義書_yyyyMMdd.xls」と書いている時点で、バージョン管理すべき対象なのだ。
そして、ビルド&リリース管理のHudson。
ビルド作業やリリース作業は、ジョエルテストにもあるように、ワンクリックでビルドできてリリースできるべき。
TestLinkは、結合テスト以降のテスト、特に受入テストで使う。
僕の経験では、設計から、開発、単体テストまでの作業はRedmineのチケットで管理するが、リリース前の受入テストに入ると、TestLinkでテスト作業を一括管理する。
受入テストでは、テストケースの実施数が作業実績になるからだ。
他には、プロジェクト内部で出てくる業務用語や技術用語はMediaWikiで管理するとか、SVNリポジトリの統計を出力するstatSVNを使う。
他に試したいものは、HyperEstraierというMixiで使われているらしい検索エンジン。
Subversionにある成果物一式をいつでもWebで検索できるようにしたいから。
そうすれば、開発者自ら、仕様の不明点を探して、自力で設計書を作れるようになる。
【プロジェクト管理サーバーの作り方】
Vine Linux 4.2 で Trac + SVN + Hudson + TestLink 環境を簡単に構築するスクリプト - かおるんダイアリー
プロジェクト管理サーバーは、複数のオープンソースの管理ツール群を組み合わせたもの。
上記は、スクリプトで一式インストールする。
Trac + SVN + Hudson + TestLinkだけあれば、少なくともプロジェクト管理に困ることはあまりないだろう。
できれば、上記ツール群をVMwareイメージにしてくれると、初期設定込みになるから、より簡単になるだろう。
しかし、プロジェクト管理サーバーがあるからといって、それだけでプロジェクト管理が楽になるわけではない。
ツールに合わせた開発プロセスで運用する必要がある。
ツールの機能を十分に知り尽くして運用しなければ、逆に生産性が落ちることもあるだろう。
僕の経験では、プログラマやテスターは上記のツールにすぐに馴染んでくれて、プロセスを大幅に改善できた。
彼らは新し物好きだし、これらのツールによって、自分のタスクが見える化しただけでなく、自発的にバグをチケットへ登録するなど、自発的に作業するようになった。
しかし、従来のマネージャ職の人達がなかなか上記ツールに馴染んでくれない。
そもそもSubversionの使い方を知らなかったり、チケット駆動開発で現れるワークフロー管理、そしてアジャイル開発のタスク管理という概念に馴染んでいなかったりする。
どうやら、従来のExcelによるプロジェクト管理に固執しているみたい。
でも、僕は、プロジェクト管理サーバーは特にアジャイル開発のプロジェクト管理を補強してくれるはずと確信している。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- トランザクティブ・メモリーを使え~「プロジェクトをリードする技術 / Project Leading is Skill」の資料はプロジェクトリーダー初心者にお勧め(2021.02.13)
- 信頼度成長曲線の落とし穴(2021.02.12)
- SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説(2021.01.26)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 文化は組織構造に従う(2021.01.19)
「Redmine」カテゴリの記事
- 信頼度成長曲線の落とし穴(2021.02.12)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- RedmineをPJ管理ツールと呼ぶのは嫌いだ、Redmineはチケット管理ツールと呼ぶべきだ(2021.01.02)
「ソフトウェア工学」カテゴリの記事
- トランザクティブ・メモリーを使え~「プロジェクトをリードする技術 / Project Leading is Skill」の資料はプロジェクトリーダー初心者にお勧め(2021.02.13)
- 信頼度成長曲線の落とし穴(2021.02.12)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- 第73回 SEA関西プロセス分科会「モデルベースシステムズエンジニアリングの活用」の感想~モデルの検証を形式手法で自動テスト化する(2020.12.13)
「TestLink」カテゴリの記事
- テスト管理ツールに必要とされる機能要件は、欧米と日本で異なるのではないか(2020.11.02)
- TestLinkにExcelのテスト項目書をインポートする方法(2017.06.01)
- TestLink Tutorialのリンク(2016.03.12)
- TestLinkで手動テストや自動テストの結果を統合してレポートさせる手法(2016.01.31)
- エバンジェリストが訴求するのは製品や技術ではなく市場を開拓すること(2015.03.14)
「チケット駆動開発」カテゴリの記事
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
- ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説(2020.12.05)
- チケット管理ツールの用途が変わってきている(2020.10.28)
「Agile」カテゴリの記事
- TeamsとSlack、Zoomの違いは組織文化の違いを助長しているのではないか(2021.02.15)
- SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説(2021.01.26)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 文化は組織構造に従う(2021.01.19)
- 「ストーリーマッピングをはじめよう」本の感想~ストーリーによる企画や要件定義はSaaSと相性がいい(2021.01.17)
コメント
言及ありがとうございます
> プロジェクト管理サーバーは特にアジャイル開発のプロジェクト管理を補強してくれるはずと確信している。
これは、まさに私も同感です。
エントリ中でも述べられている通り、ツールの機能を知り尽くしておかないと逆効果になることもあり得るでしょう。
なので、今後もあきぴーさんをはじめ、様々な方の意見も取り入れながら、噛み砕いて自分の力にしようと思います!
投稿: ikikko | 2009/04/12 18:12