チケット駆動開発が進むべき道part2~プロジェクト管理サーバーは開発チームの資産
プロジェクト管理の歴史が書かれた記事から、チケット駆動開発に至っている現在を連想した。
又、「プロジェクト・マネジメントは組織としての能力である」という記事から、チケット駆動開発が進むべき道について考えたことをメモ。
ラフなメモ書き。
【元ネタ】
ECナビ エンジニアブログ : ECナビにおける案件管理の歴史 ~Excel/MS ProjectからRedmineまで~
プロジェクトマネジメント ワンポイント講義~プロジェクト・マネジメントは組織としての能力である
ECナビ エンジニアブログ : ECナビにおける案件管理の歴史 ~Excel/MS ProjectからRedmineまで~を読むと、Excel・MS Project→自作ツール→Trac・Redmineに至る流れの背景がよく分かる。
10年前まではオープンソースのプロジェクト管理ツールは存在せず、紙やExcelで障害報告してタスク管理してワークフロー管理していたのだ。
だが、今のように短期間にアウトプットを出さなくてはならない状況が多いと、もはやそのような作業をのんびりすることはできなくなっている。
特に、運用ルールの徹底が難しい。
何故なら、新規加入のメンバーや新人が運用ルールに慣れるために、大量のドキュメントを読まざるを得ないが、実際に実行してみると、プロセスを飛ばしていたり、ドキュメントに書かれていない運用ルールがあったりするからだ。
プロジェクトリーダーの仕事の一つは、運用ルールを作ることにあるが、チームに馴染まない運用ルールを提案して、メンバーに強制しても逆に混乱するだけだ。
チケット駆動開発の利点はいくつかある。
一つ目は、RedmineやTrac、Subversion、Hudson、Gitのようなツールに慣れれば、自然にソフトウェア開発のベストプラクティスが身に付くこと。
作業を開始する時はToDo代わりにチケットを自分で登録して、作業履歴を自ら残す習慣が身に付けば、自分自身で作業を振り返るきっかけになるし、メンバーと情報共有できる場にもなる。
コミットログにチケットNoを書く習慣を身に付ければ、コミットする目的を必ず自覚するようになるし、不用意なコミットもなくなる。
また、コミットログに残されたチケットNoから、過去の修正理由を探すことも楽になる。
あるいは、GitやMercurialのバージョン管理でブランチを状況によって使い分ける手法を身に付ければ、機能追加していくコードラインと品質重視のコードラインを別々に維持しやすくなるし、突然の仕様変更があったとしても、緊急リリースに対応出来るインフラもある。
特に、オープンソースのツールは世界中のたくさんの開発者が試してきて、良いと思われた機能を実装しているのだから、その機能に慣れた方がプログラミングの良い習慣が身に付く。
二つ目は、開発者や管理者の作業を透過的にサポートするインフラがあること。
ソフトウェア開発はバージョンアップが激しいため、元々変化しやすい。
そんなソフトウェア開発のプロセスで重要なのは、多種多様なバージョンアップ作業を変更管理プロセスで制御すること。
しかし、大量のドキュメントや申請・承認が厳格すぎる運用ルールは、開発の機動力を落とし、メンバーを無気力にさせる。
チケット駆動開発なら、チケットの種類をワークフローに紐づけることによって、メンバーにワークフローを意識させずに、一つの成果物を複数人でチェックすることが自然にできる。
また、チケットに予定・実績工数・ステータスなどを入力する運用ルールを徹底できれば、開発者は進捗報告を気にせずに作業に専念できるし、管理者はRedmineやTracのような優れたチケット集計機能によって、リアルタイムに進捗や品質をモニタリングできる。
以上の二つは、プロジェクトマネジメント ワンポイント講義~プロジェクト・マネジメントは組織としての能力である の記事にあるプロジェクト・マネジメント能の中層構造のうち、「プロジェクト遂行手順・WBS体系などの標準」に相当するだろう。
三つ目は、チケット駆動開発を運用するインフラが開発チームの資産になること。
チケット駆動開発を運用するインフラとしては、タスク管理(Redmine・Trac)、構成管理(SVN・Git)、ビルド管理(Hudson)、テスト管理(TestLink)、メトリクス出力(StatSVN)などがあげられる。
それらのツールからなるインフラは、開発チームのプロジェクト管理をサポートするプロジェクト管理サーバーそのものになる。
つまり、プロジェクト管理サーバーはPMBOKの言うPMIS(プロジェクトマネジメント・ソフトウェア)そのものになるはずだ。
アジャイル開発の弱点をプロジェクト管理サーバーが助ける: プログラマの思索
そのプロジェクト管理サーバーがあれば、日々の開発チームの活動のログが貯められる。
そのログはサーバー上で一括管理できるので、進捗や品質をいろんな観点で分析することによって、プロジェクトの現状を報告したり、プロジェクトの将来を予測することが可能になる。
いわゆるソフトウェア・リポジトリ・マイニングと同じ。
つまり、プロジェクト管理サーバーに溜まった過去の実績データは、開発チームの資産そのものだ。
過去の実績データがあるからこそ、開発や運用ノウハウが貯められるし、Web上にあるからこそ、メンバーは簡単に全文検索して探すこともできる。
更に、メンバー全員でKPTによるふりかえりを行えば、より有効な知見を見出すことができるだろう。
プロジェクト管理サーバーのメトリクスは教科書みたいだ: プログラマの思索
ソフトウェア・リポジトリ・マイニング~Web2.0をソフトウェア工学に応用する: プログラマの思索
BTSをBusiness Intelligenceとして使う: プログラマの思索
これは、プロジェクトマネジメント ワンポイント講義~プロジェクト・マネジメントは組織としての能力である の記事にあるプロジェクト・マネジメント能の中層構造のうちの「過去の実績データ」、あるいは「プロセス資産」に相当するだろう。
プロジェクト管理サーバーがプロセス資産であるという意味は重要だと思う。
ツールを使いこなすほど、作業の効率は増すし、運用ノウハウがたまり、更に開発チームに見合った運用ルールが生まれる。
プロセス改善で得られたノウハウは、まさに開発チームの資産だからだ。
チケット駆動開発によって、ソフトウェア開発のプロジェクト管理のハードルが下がって、もっとクリエイティブに開発できる。
そんな環境が誰でも容易に手に入る時代になったのだな、と思う。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- プロジェクトのリスクはコストの増減で管理する(2021.04.08)
- 沢渡さんの資料「テレワークに役立つ8つのスキル」はいいね(2021.04.04)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
「Redmine」カテゴリの記事
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
- Redmine 4.1.2がリリースされた(2021.03.21)
- 信頼度成長曲線の落とし穴(2021.02.12)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
「ソフトウェア工学」カテゴリの記事
- テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA(2021.04.10)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
- ソフトウェア開発のチームは人数が増えるとプロジェクトは失敗する経験則がある(2021.03.30)
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
「TestLink」カテゴリの記事
- テスト管理ツールに必要とされる機能要件は、欧米と日本で異なるのではないか(2020.11.02)
- TestLinkにExcelのテスト項目書をインポートする方法(2017.06.01)
- TestLink Tutorialのリンク(2016.03.12)
- TestLinkで手動テストや自動テストの結果を統合してレポートさせる手法(2016.01.31)
- エバンジェリストが訴求するのは製品や技術ではなく市場を開拓すること(2015.03.14)
「プロジェクトファシリテーション」カテゴリの記事
- プロジェクトのリスクはコストの増減で管理する(2021.04.08)
- 沢渡さんの資料「テレワークに役立つ8つのスキル」はいいね(2021.04.04)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
- プログラマとスクラムが社会実装を変えていく #Findy_GovTech(2021.03.02)
- トランザクティブ・メモリーを使え~「プロジェクトをリードする技術 / Project Leading is Skill」の資料はプロジェクトリーダー初心者にお勧め(2021.02.13)
「Mercurial」カテゴリの記事
- GitHubはオープンソースのプロセスを標準化した(2015.06.11)
- 「反復型ソフトウェア開発」はソフトウェア工学の良書(2013.02.09)
- Mercurialに取り込まれたコミュニティ由来の機能一覧(2013.01.12)
- WordやExcelから直接Mercurialへコミットできるアドオンmsofficehg(2012.12.07)
- RedmineでSubversion リポジトリ表示を高速化する方法(2012.11.23)
「Git・構成管理」カテゴリの記事
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
- YoutubeのCCNA講座が秀逸だった(2021.01.04)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- RedmineでGitのbareリポジトリにアクセスする方法(2020.10.22)
- 第16回東京Redmine勉強会の感想 #redmineT(2019.05.19)
「チケット駆動開発」カテゴリの記事
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
- ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説(2020.12.05)
コメント