第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やチケット駆動開発の課題に気づかせてくれて面白かったと思う。
| 固定リンク
「プログラミング」カテゴリの記事
- Ruby技術者認定試験の感想(2020.05.08)
- 前処理大全の良いところ~SQLとRとPythonで対比できる(2019.07.10)
- WinSCPでトンネリングする方法のリンク(2018.09.09)
- 仕様書にもExcel脱却が求められている(2017.12.23)
- ソフトウェアの複雑性は本質的な性質であって偶有的なものではない(2017.05.05)
「プロジェクトマネジメント」カテゴリの記事
- トランザクティブ・メモリーを使え~「プロジェクトをリードする技術 / Project Leading is Skill」の資料はプロジェクトリーダー初心者にお勧め(2021.02.13)
- 信頼度成長曲線の落とし穴(2021.02.12)
- SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説(2021.01.26)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 文化は組織構造に従う(2021.01.19)
「Redmine」カテゴリの記事
- 信頼度成長曲線の落とし穴(2021.02.12)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- RedmineをPJ管理ツールと呼ぶのは嫌いだ、Redmineはチケット管理ツールと呼ぶべきだ(2021.01.02)
「ソフトウェア工学」カテゴリの記事
- トランザクティブ・メモリーを使え~「プロジェクトをリードする技術 / Project Leading is Skill」の資料はプロジェクトリーダー初心者にお勧め(2021.02.13)
- 信頼度成長曲線の落とし穴(2021.02.12)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- 第73回 SEA関西プロセス分科会「モデルベースシステムズエンジニアリングの活用」の感想~モデルの検証を形式手法で自動テスト化する(2020.12.13)
「Git・構成管理」カテゴリの記事
- YoutubeのCCNA講座が秀逸だった(2021.01.04)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- RedmineでGitのbareリポジトリにアクセスする方法(2020.10.22)
- 第16回東京Redmine勉強会の感想 #redmineT(2019.05.19)
- 第19回Redmine大阪の見所 #redmineosaka(2019.01.26)
「チケット駆動開発」カテゴリの記事
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
- ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説(2020.12.05)
- チケット管理ツールの用途が変わってきている(2020.10.28)
「Agile」カテゴリの記事
- TeamsとSlack、Zoomの違いは組織文化の違いを助長しているのではないか(2021.02.15)
- SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説(2021.01.26)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 文化は組織構造に従う(2021.01.19)
- 「ストーリーマッピングをはじめよう」本の感想~ストーリーによる企画や要件定義はSaaSと相性がいい(2021.01.17)
コメント