第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をクローンしてコミット履歴を見れば、その違いがよく分かる。
この点は資料を解読してみる。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- トランザクティブ・メモリーを使え~「プロジェクトをリードする技術 / Project Leading is Skill」の資料はプロジェクトリーダー初心者にお勧め(2021.02.13)
- 信頼度成長曲線の落とし穴(2021.02.12)
- SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説(2021.01.26)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 文化は組織構造に従う(2021.01.19)
「コミュニティ」カテゴリの記事
- デブサミ2021の感想~コミュニケーションスタイルがオフラインからオンラインに激変している(2021.02.25)
- みんなのPython勉強会#65の感想~社会変革の鍵はIT技術者にあるのかもしれない(2021.01.14)
- 第73回 SEA関西プロセス分科会「モデルベースシステムズエンジニアリングの活用」の感想~モデルの検証を形式手法で自動テスト化する(2020.12.13)
- 増刷記念「ここはウォーターフォール市、アジャイル町」の裏話の感想~日本人はフレームワークが苦手でいつも振り回されている(2020.11.19)
- 第19回東京Redmine勉強会の感想 #redmineT(2020.11.14)
「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)
「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・構成管理」カテゴリの記事
- 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)
コメント