Redmineを使って気付いたことpart8~チケット駆動開発の先にある世界
チケット駆動開発やTestLinkなど各種ツールを運用して、SW開発とは一体何なのか?という疑問を感じた。
以下メモ書き。
Redmineでチケット駆動開発を実践すると、アジャイル開発における無駄な管理工数が減る。
TestLinkを導入すると、テスト工程における無駄なマネジメント工数が減る。
Hudsonによって、リリース作業の工数も減る。
では、それらでプロジェクトは楽になったのか?
確かに、以前よりも進捗管理は制御しやすくなった。
でも、SW開発そのものの難しさは変わっていないように思う。
むしろ、顧客と要件定義に時間を費やしたり、設計時に仕様変更の履歴を辿って本来の要件を理解しようとしたり、実装を意識した設計に時間を費やす。
いわゆる前工程へのフロントローディングが自然に行われるようになり、設計工程で多くの時間を割くようになった。
つまり、開発時の進捗管理に自信があるからこそ、曖昧な要件定義や設計工程にギリギリまで時間をかけることができる。
設計に時間を費やし、実装やテストはバグ無しで一発で通すようにする。
すなわち、リーンソフトウェア開発につながる。
SW開発ではビッグバン統合は失敗しやすい。
ウォーターフォール型開発や大規模案件が失敗しやすいのは、結合テストで初めて欠陥が人前にさらされるからだ。
もっと前工程で欠陥に気付けばいいのに、実際にシステムが初めて動く工程が結合テストだからだ。
IT業界は、結合テストでプロジェクトが火を噴くパターンを何度も繰り返している。
アジャイル開発の本質は、XPのプラクティスである小規模リリースに尽きると思う。
短期間の繰り返し型開発。
小刻みなVerUpで機能拡張していく。
小規模リリースはリスクが少ない。
「MS製品はVer3.0で使い物になる」とよく言われるが、MSのやり方もアジャイル開発に近いのではないか?
リリース当初は評判が悪くても、じきに市場を席巻する。
アジャイル開発のソース管理は、本番運用中と開発中の並行開発が基本だ。
いわゆるソフトウェアプロダクトラインに近い。
つまり、2本のコードラインで品質維持と最新ソースの同期を取る。
マージ作業は分散バージョン管理の方が楽な傾向がある。
GitやMercurialを使えば、ソース管理はもっと楽になるだろう。
チケット駆動開発は、プロジェクト管理や構成管理を全自動化する。
進捗管理、ソース管理、リリース作業の工数はそもそも不要。
PGがプログラムを作れば、即システムが出来上がる。
チケット駆動開発がなければ、従来通り、Excelの進捗管理やリスク管理しかない。
限られた工数のうち、マネジメント工数が実はかなりかかってはいないか?
アジャイル開発のような短期間の繰り返し型開発は、チケット駆動開発のように作業ステータスを自動集計する機構を必要としている。
KPTによるふりかえりで、イテレーション単位でリリース後の集計結果をメンバー全員に見せている。
それは、自分たちの開発チーム、そして各メンバーの成績表。
チームの開発速度、メンバーの貢献度が一目で分かる。
メトリクスの威力は恐ろしい。
チケット駆動開発がメンバーに根付くと、ワークフローと言う概念が自然に現れる。
どうやら、一つのチケットを他人に渡す時にステータスを変更して、他人に通知したいらしい。
バグ修正とバグ検証も然り。
課題の問合せと回答も然り。
それらのワークフローを集めたら、自然にそのチームの開発プロセスになっている。
Redmineならトラッカー、Tracならチケットの種類がワークフローに相当する。
ソフトウェア開発に必要なワークフローは一体どれだけ存在するのか?
それが分かれば、Redmineはソフトウェア開発のERPになりうる。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
「Redmine」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
「ソフトウェア工学」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
「廃止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」カテゴリの記事
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ(2022.01.09)
コメント