第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をクローンしてコミット履歴を見れば、その違いがよく分かる。
この点は資料を解読してみる。
| 固定リンク
「Agile」カテゴリの記事
- 「プロエンジニアになるための「アジャイル開発」再入門」が素晴らしい(2018.04.04)
- カイゼンジャーニーの感想~アジャイルサムライの再来かな(2018.03.22)
- アジャイル開発とウォーターフォール型開発の違いについて再考(2018.03.21)
- アジャイル開発にはモデリングや要件定義の工程はあるのか、という問題とその周辺(2018.01.01)
- AgileTourOsaka2016の感想~エバンジェリストは市場を作る人である(2016.12.05)
「Git・構成管理」カテゴリの記事
- チケット管理システムは作業の構成管理と同じ(2017.04.03)
- 気象庁の数値予報課におけるRedmine利用事例(2017.05.22)
- セマンティック・バージョニング、チームの依存関係のメモ(2017.08.20)
- ソフトウェアの複雑性は本質的な性質であって偶有的なものではない(2017.05.05)
- 第12回東京Redmine勉強会の感想 #redmineT(2017.05.14)
「Mercurial」カテゴリの記事
- ソフトウェア開発の諸問題はソフトウェアで解決する(2009.09.24)
- Mercurial以前と以後のチケット駆動開発(2009.12.15)
- ReviewBoardとMercurial+TiDDは相性が良い?(2009.12.09)
- Mercurialによるチケット駆動開発は強力だ!(2009.12.08)
- 【公開】第4.5回Shibuya.trac発表資料「RedmineとTracの機能比較~TiDDに必要な必須機能」(2009.09.12)
「Redmine」カテゴリの記事
- Redmineの直近の課題~競合ツールGitlabに対抗できるか(2018.04.25)
- AstahのRedmine連携プラグインが公開されました(2018.01.18)
- 複数Redmineの内容を一つのRedmineに集約して見る方法(2018.03.16)
- RedmineもOSLC規格を導入してトレーサビリティを強化すべきか(2018.03.12)
- Redmineをもっと強化できるポイントpart1~上流工程のトレーサビリティ強化(2017.11.30)
「コミュニティ」カテゴリの記事
- 第18回Redmine大阪の感想 #RedmineOsaka(2018.02.04)
- 第13回東京Redmine勉強会の感想~『Redmineの今と未来』 #redmineT(2017.11.19)
- AgileTourOsaka2016の感想~エバンジェリストは市場を作る人である(2016.12.05)
- 第18回Redmine大阪の見所~「チケット管理システムによるソフトウェア開発支援と今後の課題~気象庁のRedmine利用事例報告」(2017.12.26)
- 柔軟なソフトウェア設計はOSSコミュニティを活発化させる~OSSソフトウェアとOSSコミュニティの密接な関係(2017.10.14)
「ソフトウェア工学」カテゴリの記事
- SwaggerでWebAPIドキュメントをExcel仕様書から脱却するアイデア(2018.03.29)
- 製造業の品質管理の背後にあるSDCAという考え方をソフトウェア開発に適用できるのか(2018.03.23)
- 静的ジェネレータを使ってExcelマニュアルをWeb公開するアイデア(2018.03.21)
- 安全性解析手法STAMP/STPAセミナーの感想(2017.12.27)
- テスト消化曲線とバグ発生曲線のパターン診断(2010.02.28)
「チケット駆動開発」カテゴリの記事
- 第18回Redmine大阪の感想 #RedmineOsaka(2018.02.04)
- 気象庁の数値予報課におけるRedmine利用事例(2017.05.22)
- チケット駆動の罠~複雑さはチケットの粒度に関連している(2016.12.28)
- Redmineのアンチパターンは2種類に区別できるのではないか(2018.02.21)
- 第13回東京Redmine勉強会の感想~『Redmineの今と未来』 #redmineT(2017.11.19)
「プロジェクトマネジメント」カテゴリの記事
- チームの開発環境が開発プロセスの品質を向上させるのに導入されない理由(2018.03.09)
- 【公開】第30回IT勉強宴会「最近感じる日本企業のITの問題と展望~「ソフトを他人に作らせる日本、自分で作る米国」を読んで」(2014.03.07)
- プロジェクトリーダーやマネージャに問われる能力は何か?(2005.10.05)
- Redmineがいくら良くても会社の上司や経営者が見なければExcelがはびこってしまう事例(2016.07.23)
- TiDDをRubyで補強するアイデア(2009.12.26)
コメント