第9回RxTstudy勉強会の感想~Redmineとチケット駆動開発の今後の課題 #RxTStudy
第9回RxTstudy勉強会の感想をラフなメモ。
【元ネタ】
第9回RxTstudy : ATND
第9回RxTstudy Redmineやタスク管理を考える勉強会@大阪 - Togetter
Lychee Gantt Chart Plugin | Lychee Enterprise
【1】井垣先生の講演は、Tracによるチケット駆動開発を教育に適用した事例。
4日間の合宿で、学生にソフトウェア開発だけでなく、ソフトウェア工学やアジャイル開発も経験してもらう目的があるみたい。
プロジェクトベースの教育(PBL:Project Based Learning)では、成果物やプロセスの評価が難しい点と、一部の学生に負荷が集中して学生全員に教育の機会が均等にならないという課題があった。
チケット駆動開発を導入すると下記2点が解決される。
一つは、チケットに作業情報が記録されるため、リアルタイムないしその日のうちに、成果物やプロセスのメトリクスを計測でき、フィードバックできる。
2つ目は、受講記録がチケットに残るため、早めにフィードバックすることで、学生に的確に指導できる。
たとえば、チケットに見積り工数、実績工数、タスクの種類、ステータスが記録されるので、バーンダウンチャートで即座に残タスク量を出力できる。
ソフトウェアメトリクスがチケット駆動開発で簡単に計測できる点を上手く利用している感想を持った。
興味深かったのは、Scrumというアジャイル開発フレームワークがPBLという教育スタイルにとても合っている点。
その理由は、Scrumはフレームワークとしてプロセスが定義されているので教えやすいことと、スプリントレビューやふりかえりという活動がフレームワークとして定義されているので教員や学生がフィードバックできる機会がある点があげられた。
チケット駆動開発を教育に適用した事例としてとても興味深かった。
【2】@daiskyさんの講演は、Gitの続きのお話。
Gitを正しく使いこなせなかったために、GitHubにおけるブランチの絵が東京メトロ線のように複雑になってしまっていた。
質問で聞いたら、masterとプライベートブランチをPullで同期せず、そのままPushしてコンフリクトが起きてしまい、一括マージ(sqush)やさくらんぼ摘みマージ(cherry-pick)で修正しようとして逆に被害が拡大したらしい。
そこで、「入門Git」を全員で読みなおして、Gitをまともに使えるようになったら、GitHubのブランチの絵もかなりすっきり綺麗になったらしい。
資料にある複雑なマージの絵は、再現できないものもあったらしい。
確かに複雑過ぎる。
質問タイムで聞いて印象に残ったのは、チケット駆動開発の観点では、Gitを使うと過去のコミット履歴が改変できてしまうため、No Ticket, No Commitの運用ルールが使えなくなること。
ブランチにコミットしてチケットNoを残しても、最後に一括マージしたり、つまみぐいマージしたり、リベースしたりしたら、コミットログに過去のチケットNoを書き足さないといけない。
また、チケット単位にトピックブランチを作る運用(No Ticket, No Fork)もそこまで手間をかけるほどの理由がなかったとも言っていた。
つまり、GitとRedmineを組み合わせた場合、チケット駆動開発の根本的な運用ルールであるNo Ticket, No Commitを活かしづらい場面がある。
この点は、今後のチケット駆動開発の課題となるだろう。
現実的な解決方法としては、git-svnを使って、masterは中央集権管理としてチケットNoを残すようにする方法も考えられる。
トレーサビリティという利点をいかに生かすか、という観点で、Gitの運用方法は再考する必要があると思った。
【3】川端さんのスポンサーセッションでは、RedmineのガントチャートのUIを大幅改良した機能が公表された。
Lychee Gantt Chart Plugin | Lychee Enterprise
RedmineのガントチャートをMSProjectのように使えるように、Redmine上でタスクを移動できたり編集できたりするように改良したらしい。
このような機能が売れる理由としては、大企業でMSProjectのライセンスを一括導入する場合、数十万~100万円もかかることがあげられる。
MSProjectはガントチャートだけでなく、PERT図やリソースグラフ、リソースの平準化などの豊富な機能があるけれど、おそらく普通のマネージャはガントチャートぐらいしか使いこなせていない。
だから、Redmine上でガントチャートを自由自在に編集できれば、開発者のタスク管理と連動しているので、作業しやすくなる利点があるのだろう。
勉強会のデモで興味深かったのは、EVM PluginとAssociation Chart Pluginだ。
Redmineのチケット集計機能を使えばEVMを実現できることについては、僕のBlogで何度も書いてきた。
【公開】未発表資料「チケット駆動開発におけるEVMの考え方」 #RxtStudy: プログラマの思索
【公開】講演資料「Redmineの運用パターン集~私に聞くな、チケットシステムに聞け」 #tidd: プログラマの思索
マネージャとしては、スケジュール管理だけでなくコスト管理もとても重要な仕事だ。
EVMをRedmine上で実現できれば、コスト管理も行えるだけでなく、スケジュール管理はガントチャート、リスク管理はチケットによる課題管理を使うことで、プロジェクト管理に関わる全ての作業をRedmine上で一括作業できる。
ExcelやMSProjectに進捗データをインポートして、残業しながらシコシコ作業する必要はないのだ。
また、とAssociation Chart Pluginは、関連チケットの関係をグラフ化した機能を実現している。
Association Chart Pluginプラグインを入れると、「親子」「関連」「先行」「後行」などのチケットの関係をグラフ化できる。
例えば、親子チケットで要件と作業をWBSとして階層化した場合、一つの要件から発生した作業の漏れがないか、と言うチェックにも使えるだろう。
Association Chart Pluginの今後の使い方としては、「先行」「後行」のチケットの関係がグラフ化されるので、MSProjcectのPERT図のように表現して、クリティカルパスを見つけるという使い方にも発展できる。
すなわち、ガントチャートというビューは、PERT図と同値であるので、ビューを切り替えることで、色んな観点で進捗を分析できるはずだ。
そのアイデアについては、以前Blogで書いた。
チケット駆動開発にPMBOKの概念を導入してみる: プログラマの思索
Redmineのガントチャート機能改善の要望チケット: プログラマの思索
以前のBlogでは、チケットの先行・後行関係をGraphvizで変換してグラフ表示するアイデアを披露したが、上記のプラグインでかなり綺麗に実現できている。
Association Chart Pluginが更に良い点は、Association Chart Plugin画面上でチケットの関連を編集できるので、クリティカルパスを考えたり、WBSの詳細化を考えながら、PERT図やWBSを修正できる点だ。
RedmineでWF型開発を行う場合、Association Chart PluginやEVM plugin、ガントチャートを使いこなせれば、Redmine上でプロジェクト管理の作業の殆どを操作できるだろう。
つまり、Web上でプロジェクト管理の作業を全て実現できる可能性を秘めている。
以前のBlogで書いたように、MSProjectの全ての機能はRedmineで実現できると確信している。
RedmineのガントチャートはMS ProjectのWeb版になりうるか?: プログラマの思索
MSProjectとRedmineの機能比較、フィットギャップ分析は今後の主要な課題になるだろうと思う。
Redmineが日本で普及していくうえで、重要なきっかけであると考えているからだ。
久しぶりのRedmine勉強会だったが、今後のRedmineやチケット駆動開発の課題に気づかせてくれて面白かったと思う。
| 固定リンク
「プログラミング」カテゴリの記事
- Javaのモジュールシステムの考え方をまとめてみた(2022.10.21)
- Javaのモジュールシステムは複雑性をより増している(2022.09.10)
- Javaはなぜ関数型言語になろうとしているのか(2022.09.02)
- Javaのラムダ式の考え方(2022.08.10)
- Javaはオブジェクト指向言語ではなく関数型言語だった~「[増補改訂]関数プログラミング実践入門」はお勧めの本だ(2022.08.06)
「プロジェクトマネジメント」カテゴリの記事
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
「Redmine」カテゴリの記事
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
「ソフトウェア工学」カテゴリの記事
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか(2024.01.02)
「構成管理・Git」カテゴリの記事
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ(2022.01.09)
「チケット駆動開発」カテゴリの記事
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
「Agile」カテゴリの記事
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
コメント