第3回品川Redmine勉強会の感想 #47redmine
本日開催された第3回品川Redmine勉強会をUstで見た感想をメモ。
第3回shinagawa.redmine勉強会 : ATND
shinagawa.redmine 第3回勉強会 - Togetter
【1】Redmineコミッタの@marutosijpさんが、RedmineをRuby1.8→1.9, Rails2.3→3.2へVerUpした経緯やその作業内容について解説してくれた。
僕としては、既存機能をデグレードさせずに環境周りをVerUpするいわゆるポーティング作業は地味だけれども難しい作業だと経験的に思う。
ポーティングとは【porting】(移植) - 意味/解説/説明/定義 : IT用語辞典
RedmineがVer2.0でRails3へ移行予定: プログラマの思索
ポーティング作業の難しさは、テスト工数と納期のバランスを取ること、OSやライブラリのバージョンアップによってソースの修正が発生するバージョン管理の2点にあると思う。
既存機能に影響がないことをテストするために回帰テストすればよいが、古いシステムほどテスト自動化などないので、手作業のテストになり、どこまでテストすれば良いのか、判断を下しづらい。
だから、この機能は既にテストされたので品質は担保されている、などといった「みなしOK」の判断を下して、テスト工数を削減したりする。
でも、みなしOKの判断を誤ってテスト漏れが発生したりするから、サジ加減が難しい。
また、バージョンアップ前と後のソースを別々にブランチ管理する作業があったり、バージョンアップ前のソースからどのソースを最新の環境に持っていくべきか精査する作業が発生するため、バージョン管理が面倒になる。
だから、前者ではベンダブランチのような並行開発が必要になってくる。
後者は手作業で逐一ソースを精査するしかない。
でも厄介なのは、既存バグを発見したけれども、VerUp後のソースで直してしまうと、既存のソースにもバックポートする作業が発生する時だ。
特に、古い環境と新しい環境を並行稼動するような業務システムの例では、バックポートの作業を忘れると、せっかく直したバグ修正をバグとみなされてしまい混乱してしまう。
だが、古い環境で本番運用されている場合、すぐにバックポートの作業ができるわけではないから、既存バグをきちんと記録しておき、並行運用中に直すというやり方を採用するときもあるだろう。
バックポートとは【backport】 - 意味/解説/説明/定義 : IT用語辞典
他に、下記のような意見もあり、僕はすべての現場を知らないので何とも言えない。
でも、他の言語やフレームワークなどのポーティング作業(例:CentOS、JDK、Apache、Androidなど)は、今はそんなに楽になっているのだろうか?
例えば、MSがWindowsOSの後方互換性の維持にこれだけ大きな手間をかけているのを見ると、ポーティング作業がそれほど楽なようには思えない。
最近では、AndroidOSのバージョンの違いや後方互換性で、スマートフォンメーカーが苦しんでいるように見える。
とは言え、RailsはVerUpで大きく変わりすぎたし、Redmineインストールに苦しんでいる人が多いのを見るとそうなのかもしれない。
【2】@tech_machiiさんのLotusNotesからRedmineへの移行作業の事例も興味深かった。
僕の感想は下記に書いた。
RedmineはOSSの割には高機能なので、何でもできそうなイメージがあるが、実際はどの業務をRedmineで代用し、他の業務を従来の手運用ないしExcel運用でカバーするか、という切り分けが難しい。
移行作業の工数は無限にあるわけでもないし、納期もあるから、いかに短期間で成果を出していくか、という戦略が大切になる。
似たような話として、ERP導入やCMMI導入では、導入や運用の失敗事例の話が山ほどある。
Redmine導入はERP導入に似ている #tidd: プログラマの思索
ポーティング作業や移行作業の事例を聞くと、業務システムの受託開発に似ているなあと思う。
案件は、いつも綺麗な新規開発ではなく、ポーティングやデータ移行などの地味でつまらない案件も多い。
でも、そのような案件は特にプロジェクト管理の質が良くないと失敗しやすいように思う。
【3】IPAの定量的プロジェクト管理ツールのお話もあった。
RedmineやTracを定量データの収集場所とみなし、データを集計してプロジェクト管理に役立てる発想として作られたらしい。
過去のソフトウェア工学やエンピリカルアプローチは、本来はこのようなツールを基盤として研究されるべきではなかったのか、と思う。
何故なら、RedmineやTracのようなツールがなければ、データ収集に工数がかかりすぎて肝心のプロジェクトの進捗に害があるからだ。
IPAの定量的プロジェクト管理ツール #redmine: プログラマの思索
チケット駆動開発の面白さは、アジャイル開発と相性が良い点だけでなく、マネージャをサポートするソフトウェアメトリクスの出力という一面もある。
メトリクスの分析や使い方は罠や癖があるけれども、見える化の一部として使えるだろうと思う。
メトリクスを使った品質管理の技法は、従来の日本の製造業が得意とする開発スタイルだ。
RedmineでWF型開発を行う場合、メトリクスを使う品質管理は相性が良いだろうと思う。
【4】@g_maedaさんのお話も興味深かった。
Redmine.jpにはいつもお世話になっています。
Twitter / @hell0_wor1d: 前田さんの優しい話し方、Redmine愛を感じる #47redmine
Twitter / @akipii: #47redmine OSSの貢献はソースコードの公開だけでなく、ツールの紹介や情報公開もあるというお話。実際に行動されているだけあって説得力あります。
Redmineが日本でこれだけ普及した理由の一つは、Redmine.jpがポータルサイトとなっていて、初心者から上級者まで誰もが参考に出来る情報が発信されていることだと思う。
単なるリンクの羅列、Wikiの日本語訳、VerUpされた内容の掲載だけでもとても役立つ。
Redmineコミュニティの利点は、日本人コミッタ(@marutosijpさん)がいることと有用な情報が一箇所に集まっているポータルサイト(Redmine.jp)があることだと思う。
コミュニティがツールの発展を支える良い事例の一つになっているのかなあと思う。
他にも@tkusukawaさん、@basyuraさんのお話も興味深かったです。
【5】個人的には、ChiliProjectがA Successful branch modelを採用して一部混乱した時があったという指摘、そして、Redmineではrebaseを多用してtrunkのリビジョンが一直線になるメインラインモデルを採用して混乱なくVer2.0をリリースできたという事実について、その背景を聞きたかった。
A Successful branch modelの考え方はgit-flowというGitツールで実装されている。
その考え方はとても面白かったので、いろいろ考えていた。
git-flow による構成管理とRedmineの関係: プログラマの思索
しかし、そのモデルは小規模プロジェクトでしか通用しないという理由がきちんと分かっていないので、経験者から聞いてみたかったなあと思う。
実際、GitHubにあるChiliprojectとredmineをクローンしてコミット履歴を見れば、その違いがよく分かる。
この点は資料を解読してみる。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
「コミュニティ」カテゴリの記事
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- 『世界一流エンジニアの思考法』が学べる環境を手に入れてかつ継続する方法の感想 #devboost(2023.12.10)
- 第25回東京Redmine勉強会の感想 #redminet(2023.11.05)
- パターンカタログよりもモンスターカタログの方が面白いね #jasstkansai(2023.06.24)
- デブサミ2023の感想(2023.02.11)
「Redmine」カテゴリの記事
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- Redmineで持ち株管理する事例(2024.04.21)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
「ソフトウェア工学」カテゴリの記事
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか(2024.01.02)
「廃止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)
「チケット駆動開発」カテゴリの記事
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
「Agile」カテゴリの記事
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- 概念モデリングや設計原則は進化しているのか(2023.10.21)
コメント