Wikiを使う
著者: Adrian WibleWiki はプロジェクト情報へのアクセスを集中させるのに、すばらしい仕組みを提供してくれます。うまく活用できれば、1 日に何度も更新されて、チームメンバーのデスクトップに常時開かれるようになるはずです。
プロジェクトの実作業に必要となる貴重な脳細胞をムダ使いしないよう、Wikiに入れておくと便利なページについて紹介しましょう。以下に挙げたものは一般的な例なので、自分のソフトウェアプロジェクトに合わせてカスタマイズしてください。
- ステークホルダー:最新のプロジェクト状況、短期的課題、長期的課題、リスク、予算管理、マイルストーン実績などを書く場所を作りましょう。
- 開発者:QA データベースに接続するためのコネクション文字列といった情報を書いておきましょう。そうすれば同僚のプログラマが手当たり次第にソースコードをあさって、時間をムダにするようなことはなくなります。コーディング標準、ビルドおよびデプロイ手順、よくはまる落とし穴、DI(Dependency Injection)など進んだコーディングテクニックなどに関する情報も共有しましょう。
- 一般情報:プロジェクト・マネジャーはここに、ヘルプデスクの電話番号、チームの役割と責任、個々のチームメンバーの連絡先といった役立つ情報を書いておくべきです。
- チームのカレンダー:ここにはチームのカレンダーを貼っておきましょう。iFrame を使ってGoogle カレンダーを埋め込むというテクニックもあります。
- ミーティング議事録:ミーティング議事録を保管しておきましょう。そうすれば、過去のミーティングで話された詳細について、簡単に記憶を呼び起こすことができます。また、将来のミーティングに向けた調査や準備をするために、過去の議事録をすばやく参照することもできます。
- ミーティング議題:ステークホルダーが今後の議題をオンラインで提案できる仕組みを提供しましょう。もちろん、プロジェクト・マネジャーの承認、チーム全員への提示、次回のミーティング議題の締め切りにしたがってください。
- ビジネスアナリスト:ビジネスアナリストは開発者の仕事場に同席していないことが多いでしょう。ここは複数の場所からアクセスでき、作業中のドキュメントとドメイン成果物をまとめておくのにふさわしい場所です。
- テスター:組織によっては、テスト責任をプログラマから分離しているかもしれません。ここはテスターとプログラマ、2 つのチームの情報センターとして機能します。Selenium、QTP、Quality Center といったテスティングツールの使い方などを載せておきましょう。オンラインでバグトラッキング手順を検討、議論し、その最終結論を載せておいてもよいでしょう。
Wiki を使うときのコツをいくつか挙げておきます。
- 情報をコピーしてはいけません。情報がほかのところにあるなら、Wiki にコピーするのではなく、その情報へのリンクにしましょう。
- 情報が古くなっていないかどうか確認するために、適宜更新されているか目を光らせましょう。Wiki にある情報が古いと、みんな使うのをやめてしまいます。
- できれば情報をリアルタイムデータ駆動にしてみましょう。実際のプロジェクトデータからチャートやステータスが生成できるようなWiki インターフェイスをもつプロジェクトマネジメントツールを探しましょう。こうしたツールを利用すれば、進行中の作業についてリアルタイムのステータスが得られます。
また、メール経由で情報を送るとき、特に添付ファイル(ドキュメント、プロジェクト計画、予算情報など)を送るときには、Wiki を使った方がよくないか必ず検討すべきです。