開発プロセスの型をツールで構築する #tidd
@daipresentsさんがRedmineを1000人のユーザで運用している事例をアップしていたのでメモ。
僕もこの規模まで運用したことはないので、とても参考になります。
【元ネタ】
受託開発でTracを導入してよかったことや失敗したこと | 世界 - daipresents!!
Redmineが1000人のエンジニアに使われるまでのこと | 世界 - daipresents!!
資料にもあるように、楽天で、9万個のチケット、900個のプロジェクト、1300人のユーザでRedmineを運用されている。
この記事で面白いのは、「開発プロセスの型をツールで構築する」ということ。
CMMIでもPMBOKでも開発プロセスやプロジェクトマネジメントの標準化が重視されている。
その理由は、開発チームごとの能力のばらつきを抑えて、平均の能力を上げることにあると思う。
しかし、プロセスの標準化の作業は実際はとても面倒だ。
標準化された手続きをこなすための膨大なマニュアルと大量の中間的ドキュメントが要求される。
更に、皆が決められた手続きを守るために、稟議書のような承認フローが必要とされる。
もっと身軽に開発したいのに、標準化を頑張るほど、開発の速度が遅くなっていく。
CMMIを推進する立場の品質管理部門やプロジェクトマネージャと開発チームを支援するPMOは、その標準化作業の先頭に立つけれども、普通は開発チームと利害が対立しがちだ。
開発チームにお仕着せのプロセスを押し付けるから、開発チームはそれを実際は嫌がる。
トップダウンで頑張るほど、現場は疲労していく。
Redmineのようなツールによるプロセス改善は、それとは逆でボトムアップによるプロセスの標準化を進める。
プロジェクト管理やソフトウェア開発の作業に必要なツールが用意されていれば、メンバーもチームもそのツールに合わせて作業すればいい。
鈴木雄介さんのスライド「Agile Japan 2010 「変化を受け入れるアジャイルなプロジェクトマネジメントと現場・ツール・環境篇」」にある主張「コトそのものではなく、コトの外側を標準化する」がそれを意味していると思う。
実際の作業(コト、トランザクション)ではなく、コトの外側(開発環境、プロジェクト管理に必要な環境)をツールで標準化することで、開発チームの手順をどのチームも同じようにする。
それによって、要員の流動化も可能だし、メンバーのスキルも底上げできる。
僕自身もチケット駆動開発を運用してみて、プロジェクト内部の作業が全てチケットにあがっていれば、そのチケットを引継するだけでいい。
新人はRedmineでのタスク管理やSubversionによるバージョン管理、障害管理のプロセスに慣れれば、ツールにはソフトウェア開発のベストプラクティスが実装されているので、自然にソフトウェア開発をチームで作業するスキルを身に付けてくれる。
又、@daipresentsさんの事例で面白いのは、アジャイル開発の概念をRedmineのプラグインでどんどん実現して実際の運用がスムーズだったこと。
特に、アジャイル開発は進捗管理のビューが優れていると言う指摘は面白い。
確かに、タスクボードは単なるガントチャートやチケット一覧よりも分かりやすいし、バーンダウンチャートはプロジェクトの現状を的確に指摘してくれる。
そして、アジャイルな開発をもっと実践するために、チケットをタスクカードからストーリーカードへ、ガントチャートからタスクボードへ昇華していったという言葉が意味深い。
タイムボックス的な開発を行うには、ある程度の粒度が揃った要件の束が必要だし、イテレーション単位の進捗を測るには精度の高い見積りが重要になる。
だから、タスク管理や要件管理の作業の精度が要求されてくるのだろう。
つまり、プロジェクト管理の質がどんどん上がっていったことを意味しているのだろう。
@daipresentsさんの事例では、史上最高のチーム、タスクボード、バージョンバーンダウンチャート、パーキングロットなどのプラグインが紹介されていて、非常に参考になる。
個人的には、Redmineのチケット集計機能はまだまだ不足していると思うので、もっと強化されていいと考えている。
もっとたくさんの種類のビューを用意して、現場リーダーは状況に応じてビューを使い分けてもいいはずだ。
進捗管理でもガントチャートだけではなく、バーンダウンチャートやカンバンもあるといいし、品質管理やリスク管理、要員管理でも色んなビューがあると便利なはず。
プロジェクト管理の各種の状況に応じて必要なビューは何があるのか、という問いを今一度精査し直す必要があるように思う。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- 初中級プロマネはIPAデータ白書の統計情報を見積り、生産性、品質の観点で活用せよ(2022.04.17)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
「Redmine」カテゴリの記事
- 第22回東京Redmine勉強会の感想 #redmineT(2022.05.29)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- オープンソースERPパッケージiDempiereに対する派生開発手法の提案の資料が興味深かった(2022.04.24)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- RedmineのWikiタグでタスクリストを書けるようになった(2022.03.21)
「ソフトウェア工学」カテゴリの記事
- テスト管理ツールTestRail、CAT、QualityForwardの感想(2022.07.30)
- メトリクス分析のコツは良いIssueを見つけること(2022.06.29)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
- 「大人の学びパターン・ランゲージ」の感想~知識と経験を行ったり来たりするタイミングを大切にする(2022.06.05)
- 「コーディングを支える技術」は良い本だ(2022.05.26)
「チケット駆動開発」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
- Redmineにメンション機能が入るらしい(2022.01.15)
「Agile」カテゴリの記事
- 組織を芯からアジャイルにする対談の感想~今のアジャイルは先カンブリア時代なので何でもいい、アジャイル警察はいらない(2022.08.05)
- 製造業の業務にスクラムを適用できるのかという疑問~全てのビジネスモデルにスクラムを適用できるのか?(2022.07.31)
- 認定スクラムプロダクトオーナー研修の感想(2022.07.28)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
コメント