« 2015年8月 | トップページ | 2015年10月 »

2015年9月

2015/09/22

ドメイン駆動設計はアジャイル開発の弱点を補完する技法ではないか

増田さんのドメイン駆動設計の公開資料が素晴らしいのでリンクしておく。
ドメイン駆動設計はアジャイル開発の弱点を補完する技法ではないか、というアイデアをメモ。
ラフなメモなので、ロジカルでない。

【参考】

(引用開始)
エヴァンスが取り組んだ技術 「オブジェクト指向」と「XPスタイル」の設計 に、現場で取り組んだ成功と失敗の物語。
そこから学んだ教訓をまとめたものが 「ドメイン駆動設計」
オブジェクト指向分析設計の参考にすべき文献は多いが、現場で使える実践的なガイドが 意外と少ない
現在、DDDコミュニティの一部は、「クラウド時代のドメイン駆動設計」への挑戦と実験を盛 んに行っている
(引用終了)

「XPやScrumの母体であるアジャイルコミュニティでは、オブジェクト指向の分析設計は当たり前の手法であり、スキルだった」のに、いつの間にか、その設計技法が忘れ去られて、設計技法そのものが軽視されてしまった。
しかし、それでよいのか?

ファウラーなど、アジャイルコミュニティを引っ張ってきた人達を見ると、ビジネスモデリングもシステムの設計能力もすごく高い。
その前提が忘れられている。
実は、ドメイン駆動設計は、アジャイル開発コミュニティが忘れてきた設計技法の教訓やノウハウを集大成したもの、という指摘はすごく分かりやすい。

ドメイン駆動設計はアジャイル開発の弱点である設計技法を補完する技法と見なせば、最近すごく注目されている背景も分かるような気がする。
マイクロサービス、イベントソーシングなどの概念が次々に現れているのは、昨今のような「多産多死のWebサービス開発」で必要な技法だからだろう。

興味深いのは、昨今のドメイン駆動設計のスコープは、エヴァンズが語ってきた従来のドメイン駆動設計ではなく、クラウドに合わせたドメイン駆動設計へ進化しようと盛んに研究されている点だ。

確かに、エヴァンズのドメイン駆動設計の本の内容は、2004年頃までの内容の集大成であり、昨今のクラウド・モバイル・ビッグデータ・IoTなどの技術を前提とした設計技法ではない。
以前のノウハウや文脈では、実際の現場ではなかなか使えないのが現実だろうと思う。

個人的な直観としては、マイクロサービスのような機能の再利用性、イベントとメッセージングのようなUIの再設計が重要になるのでは、と思う。

前者は、SOAが思想として優れていてもなかなか普及しにくかった問題は、RESTやJsonの普及によって、いかに既存のWebAPIを再利用して、変更に耐えうるように、素早く開発するか、という観点に変わった。

後者は、PC時代のUIではなく、圧倒的に普及したスマートフォンに合わせたUIはアジャイルUXみたいな考え方に発展している。
そして、多数のスマートフォンが操作している背後では、Webサーバーがそれらのデータをやり取りし、プッシュ通知の仕組みを持っていたりする。

しかし、例えば、プッシュ通知の仕組みを実現するには、各スマートフォンの個人情報を保持する必要があり、状態に応じてプッシュ配信しなくてはいけない。
つまり、大量の個人情報を保持するセキュリティの仕組み、いかに大量のメッセージをさばくか、というサーバー上の仕組みが必要なのでそう簡単な設計ではないはずだ。
大手企業のように、大量のサーバーをデータセンターに持つか、クラウド環境でサーバーをスケールしやすいように設計するなどの技法が必要になってくるのだろう。

もちろん、これ以外にもドメイン駆動設計が今後深掘りすべきテーマや分野はたくさんある。
実践ドメイン駆動設計」でもその内容は少しは触れられているので、読んでみたい。
どこかで勉強会をやっていないだろうか?

| | コメント (0)

モダンPMの3大技法~CPM、WBS、EVMS

モダンPMの技法とプロジェクトの制約条件に関する記事をメモ。
改めて参考になる。

【元ネタ】
海外プロジェクト・マネジメントにおけるシステムズ・アプローチとは ?化学工学会展望講演(9/09)から : タイム・コンサルタントの日誌から

(引用開始)
1)プロジェクトの『スコープ』はどうなっているのか。WBSを見せろ。
2)このプロジェクトの『クリティカル・パス』は何か? アクティビティ・ネットワークの上で示せ。 主要なリスクは何か?
3)現在までのPV, AC, そしてEVはいくらか。完成時のCost EACを予測せよ!

(中略)

モダンPMで用いられている三大技法であるCPM、WBS、そしてEVMSの原理を、簡単にご説明しました。
この3つはちょうど、プロジェクトを取り囲む三大制約である『スケジュール』『スコープ』そして『コスト』に対応しています。
この三大制約は別名、「鉄の三角形」とも呼ばれ、プロマネは日夜その中で苦労しながら進んでいるのです。
だからこそ、これを押さえるための手法が真っ先に発達してきたのでしょう。
(引用終了)

プロジェクトの三大制約は、スコープ、スケジュール、コスト。
これに対応するように、モダンPMの三大技法は、WBS、CPM、EVMS。

つまり、プロジェクトのアクティビティを網羅したWBS。
WBSが無ければ、スケジュール管理もコスト管理もできない。

WBSとは|作業分解図|ワークブレークダウンストラクチャー - 意味/解説/説明/定義 : IT用語辞典

プロジェクトの最長経路であるクリティカルパスとクリティカルパス・メソッド。
クリティカルパスはスケジュール管理に直結する。
更に発展した技法としては、CCPMもあるだろう。

クリティカルパスとは|critical path - 意味/解説/説明/定義 : IT用語辞典

プロジェクトのコスト管理技法の中で、最も有名なEVM。

EVMとは|アーンドバリューマネジメント|EVA - 意味/解説/説明/定義 : IT用語辞典

製造業や建設業、あるいはWF型開発でも、こういうプロジェクト管理技法が必要だろう。
既に理論として確立しているので、頭の整理にもなる。

| | コメント (0)

2015/09/20

【公開】SQIP2015講演資料「チケット駆動開発の運用パターン集~問題はチケットに分割して統治せよ」 #Redmine

SQIP2015チュートリアルの講演資料「チケット駆動開発の運用パターン集~問題はチケットに分割して統治せよ」をCC Attribution ライセンスで公開します。

【参考】
併設チュートリアル 講演テーマ・講演者紹介「チケット駆動開発入門 ~基礎から応用まで~」 | ソフトウェア品質シンポジウム 2015

[#TiDD]ウォーターフォール開発をアダプタブルにする(チケット駆動開発) - SQiP2015チュートリアル -: ソフトウェアさかば

【1】講演の目的と内容

@sakaba37さんと「チケット駆動開発入門 ~基礎から応用まで~」を話してきました。
参加者は14人と少なかったですが、2人で4時間も講演できて、とても中身の濃い話ができたかなと思います。

僕としては、チケット駆動開発を実現するツールであるRedmineを用いて、どんな利用シーンに適用できるか、その時のメリットや課題は何があるか、という観点で話しました。
具体的には、BacklogsプラグインによるScrum開発、構成管理パターン、EVMや要員管理におけるプロジェクト管理技法、事務処理の申請承認フローの5つの運用パターンをまとめてみました。

つまり、運用パターンの観点としては、アジャイル開発やWF型開発への適用方法という観点と、SW開発とSW開発以外への適用方法という2つの観点です。
今までに実際に自分が考えて、現場で試してみた内容をまとめてみました。

したがって、「Redmineの運用パターン集~私に聞くな、チケットシステムに聞け」の続きの講演イメージになります。

この話がしたかった理由は、僕がSQIP2009で講演した当時に比べると、Redmineなどのチケット管理ツールを用いてチケット駆動開発を運用するのは当たり前の状況であり、今までの知見を整理してみたかったからです。

ソフトウェア開発に適用した場合のノウハウ・メリット・デメリットはかなり出尽くしていると思いますし、ソフトウェア開発以外にRedmineのようなチケット管理を適用すると、どんな利用シーンで効果が出るのか、という試行錯誤した事例も見受けられます。
僕の資料が全てのパターンを網羅しているとは思いませんが、一つの参考事例になると思います。

【2】印象に残った質疑応答

参加者に聞いた所、全員がRedmineユーザでした。
なので、Redmineは知っている、あるいは既に運用していて、色んな問題意識を持っているようでした。
講演中や講演後の質疑応答で印象に残った内容を記載しておきます。

【2-1】チケットとバージョン管理ツールの連携機能がよく分からない。

【A】Redmineの構成管理ツールの連携は、変更理由(チケット)→成果物の後方追跡性と成果物→変更理由(チケット)への前方追跡性というトレーサビリティを実現した機能です。

【2-2】現在、ソースはGit、設計書などのドキュメントはSubversionで構成管理を行なっている場合、Redmineでは、チケットと成果物の連携をどのようにすれば効果的か?

【A】ソースやドキュメントを別々のリポジトリ(Git、SVN)で管理している場合の運用はどうすべきか?という質問でした。
Redmineのマルチリポジトリ機能を使えば、1プロジェクトに複数のバージョン管理リポジトリを設定できるので、それで解決できるでしょう。

Redmine 1.4新機能紹介: 一つのプロジェクトで複数のリポジトリに対応 | Redmine.JP Blog

Redmineの複数プロジェクト機能を使って、別々に管理して運用することも可能ですが、一つのシステムや製品に関する作業情報は、一つのRedmineプロジェクトにまとめた方が後の保守でも運用しやすいからです。
Conwayの法則を連想するといいと思います。

【2-3】親チケットに書いた予定日は、子チケットを作ると消えてしまって困る。
 当初の計画情報は消えて欲しくない。

【A】Ver3.1から、Redmineの親チケットの値に子チケットをロールアップさせない設定が可能になりました。

Redmine 3.1新機能紹介: 親チケットの値(優先度・期日など)を子チケットと連動させない設定 | Redmine.JP Blog

下記の記事にも書きましたが、WF型開発を運用していて、当初のWBSの計画情報を修正したい場合、過去の計画情報が消えてしまうと困る状況があるようです。

Redmineの親チケットの値に子チケットをロールアップさせない設定方法: プログラマの思索

また、下記の記事のように、親チケットや子チケットだけを抽出するクエリも発行できるので、チケットをWBSのように管理する場合は少しは便利になってきています。

Redmine 3.1新機能紹介: 親チケットおよび子チケットによるフィルタ | Redmine.JP Blog

Redmineの親チケット検索機能とCSVインポーター機能: プログラマの思索

【2-4】チケットの粒度はどうあるべきか?
 現場でプロジェクト管理をRedmineでやっているが、Redmineのガントチャートは顧客にそのまま提出できない。
 今の運用では、現場の開発者はRedmineの運用があまり嬉しくなさそうだ。

【A】顧客や上司が見たい管理の観点と、プロジェクトリーダーや開発者が見たい管理の観点は、そもそもチケットの粒度は異なります。
以前書きましたが、親子チケットを上手く使って、顧客や上司には集計された親チケットの情報を見せて、チームでは子チケット全ての情報を見る、という使い分けが必要になると思います。

チケット駆動開発は進捗報告作りをどのように解決しようとするか?: プログラマの思索

但し、実際のチケット管理の運用はそんな理想どおりになかなか上手くいかず、結構煩雑になると思います。
@sakaba37さんの言う通り、顧客向けにはMSProjectやExcelの線表を見せて、その元ネタはチケットにある、という使い分けの方が現実的でしょう。

【2-5】WBSをチケットにすると、複数の担当者の予定が入力できない。
要件単位にチケットを作った場合、一つのチケットに複数の担当者の予定を入力できないのは困る。

【A】問題の本質は、例えば、「画面Aを実現する」という作業をチケットでどのようにマッピングすべきか、という問題に置き換えられます。
やり方は2つあります。

一つは、基本設計→詳細設計→製造→単体テストの流れを1個のチケットでまとめる。
もう一つは、親チケットに要件を書き、子チケットに基本設計~単体テストまでの作業を分割して管理する。

前者はアジャイル開発の観点と同じで、1個のチケットを複数の担当者がキャッチボールのように作業を連携するやり方。
これはチケット管理の基本で、推奨するやり方。

しかし、このやり方では、質問者の言う通り、複数の担当者を一つのチケットにアサインできないし、複数の担当者の開始予定日・終了予定日・予定工数をそれぞれ記録することができない。
WF型開発で、WBSがあらかじめ決まっていて、作業者の予定もほぼ確定している場合は、このやり方は使いにくい。

後者は、WF型開発のWBSの観点と同じで、子チケットにWBSの最下層である作業(成果物)をマッピングする。
すると、子チケットは必ず一担当者が結びつき、子チケットで担当者の作業管理ができる。
親チケットには、子チケットの情報がロールアップされるので、進捗情報をリアルタイムに見れる。

しかし、Redmineのチケットは実績管理の設計思想なので、予定日がデフォルトで保持されていないから、カスタムフィールドで別途作成する必要がある
また、1チケット=1担当者の場合、「担当者固定」というアンチパターン(松谷さん@redmine.tokyo)が発生しやすいので注意すべき。

講演1 Redmine導入のアンチパターン

WF型開発でWBS管理したい場合は、親子チケットで運用するしかないでしょう。

【2-6】今、Redmineをソフトウェア開発者だけでなく営業担当者にも使ってもらおうと導入を計画している。
 営業担当者にRedmineを使ってもらうにはどうすればよいか?
 運用以外にRedmineの機能で注意すべき点はあるか?

【A】運用上の注意としては、説明会は必須だろう。
営業マンならば、Redmineも知らないだけでなく、Webやパソコンすら慣れていない人も多いので、運用の目的や方法、メリットも十分に説明すべき。

その場合、Wikiにマニュアルを書いておくと便利。
運用マニュアルをWikiで公開しておけば、誰でもアクセスして読める。
また、実際に運用したら、運用方法はコロコロ変わりやすいので、ExcelでまとめるよりもWikiに記載する方が素早く対応できるし、保守もしやすい。
RedmineのWikiなら履歴管理もできる。

Redmineの機能で注意すべき点は、カスタムクエリとウォッチャー機能だろう。
チケット管理を始めたものの、大量のチケットがチケット一覧で出力されるだけでは、誰も使ってくれない。
利用シーンを考慮したカスタムクエリを10個以上事前に登録しておき、運用マニュアルに、どんな運用の時にどのクエリを使ってチェックすべきか、という内容を記載するといいだろう。

例えば、担当者=自分の未完了チケット、期日遅延の未完了チケット、報告用の全チケットなどのカスタムクエリを事前に登録するといいのでは。

また、申請したチケットを担当者以外にも共有したい時がある。
その時は、ウォッチャー機能がメールのCcに相当するので、使って下さい、と事前に説明するといいだろう。

【3】上記の質問を聞くと、@sakaba37さんの感想である[#TiDD]ウォーターフォール開発をアダプタブルにする(チケット駆動開発) - SQiP2015チュートリアル -: ソフトウェアさかばの通り、参加者は大規模受託開発にRedmineを導入して運用しようとしており、その背景の元に色んな問題や課題を持っているように思いました。

その辺りもまとめてみたいと思います。

| | コメント (0)

2015/09/19

Redmineの親チケットの値に子チケットをロールアップさせない設定方法


Redmineの親チケットの値に子チケットをロールアップさせない設定方法の良いWebページがあったのでメモ。

【元ネタ】
Redmine 3.1新機能紹介: 親チケットの値(優先度・期日など)を子チケットと連動させない設定 | Redmine.JP Blog

RedmineではVer1.0からSubtasking機能があり、チケットの親子関係を無限の階層で操作可能になった。
このおかげで、WBSをそのままチケットの階層構造にマッピングすることができる。
WF型開発が主流の日本のSIでは、とても重要な機能になっているのが現状だろう。

Redmineでは、親チケットの開始日・期日・予定工数・実績工数・進捗率に、子チケットの情報が自動的にロールアップされる。
つまり、最下層のWBSと子チケットを対応付けて、子チケットに計画と実績の情報を入力する運用を徹底できれば、親チケットに自動的にロールアップされるので便利。

このルールは、Redmine 3.1新機能紹介: 親チケットの値(優先度・期日など)を子チケットと連動させない設定 | Redmine.JP Blogの記載通り、WBSにおける「100%ルール」に相当する。
親のWBSに子のWBSが100%網羅されるべき、というプロジェクト管理の思想に由来する。

しかし、親チケットに子チケットの情報がロールアップされると不便だ、という要望もよく聞く。
親チケットの属性は消えて欲しくない場面があるらしい。
話を聞くと、当初は親チケットに計画情報を入力していたが、プロジェクト進行中にWBSを詳細化する必要が出てきて、子チケットを作っていくと、親チケットの計画情報が消えて困るらしい。
つまり、当初の計画情報は残しておき、子チケットに詳細化・分割した時に、改めて計画情報を最新化したいのだ。

そういう場合では、Ver3.1の新機能である「親チケットの情報は子チケットから独立」という設定を行うと良いだろう。

実際の利用場面としては、WF型開発で当初のWBSを作っていたものの、顧客要望による仕様変更や顧客の予算の都合で要件削減が発生した場合、WBSを見直さざるを得ない時がある。
その時に、WBSにあるプロジェクト計画時の計画情報が全て消えてしまうのは困る。
なぜなら、ベースライン管理がやりたいので、仕様変更や要件変更があるたびに、ベースラインを履歴管理しながら、当初の予算や予定工数がどのように変化したのか、も追跡していきたいからだ。

SQiP2015のチュートリアル「チケット駆動開発」で@sakaba37さんと一緒に講演した後、参加者から質疑応答を受けた時、WBSとチケットのマッピング方法に関する質問が多かった。
その中でも、親チケットの情報が子チケットの情報を集計して表示されるRedmineの仕様が不便、という声が2件もあった。

そんな質問を受けると、日本でRedmineを利用している現場では、アジャイル開発よりもWF型開発で運用している会社が多く、いかにプロジェクトの予実管理をRedmineで実現すべきか、という課題を持っているのだろう。

この辺りの話を受けて、考えていることは今後まとめていきたい。

| | コメント (0)

2015/09/13

チケット駆動でソフトウェア開発のメトリクス分析を行うアイデア

チケット駆動開発でソフトウェア開発のメトリクス分析を行うアイデアをメモ。
以下はラフなメモ書き。
アイデアをラフに書いているだけなので、ロジカルではない。

【参考】
Cumulative Flow Diagram(CFD):タスク全体の推移を「見える化」する - THE HIRO Says

完了率:本当に完了・リリースできた機能を「見える化」する - THE HIRO Says

割込率:作業の割り込みを「見える化」する - THE HIRO Says

【1】問題意識

Redmineでソフトウェア開発に関する作業管理を運用すると、チケットで見える化されるが、何か物足りない点がある。
RedmineにチケットやSVNリポジトリの情報が溜まっているのだから、それらデータを分析して、目の前のプロジェクト、目の前の開発チームに何が足りないのか、何が悪いのか、を探りたい。
しかし、今のRedmineでは、チケットというデータは溜まっているが、どんなメトリクスが役立つのか、どんな分析方法が役立つのか、が分からない。

その問題点は、二つあると思う。
一つは、ソフトウェア開発のメトリクスに必要な作業情報をそもそも収集するのが難しい、あるいはコストがかかり過ぎること。
もう一つは、メトリクスや分析手法などの理論の前提と、実際のソフトウェア開発の制約条件が一致しているとは限らないこと。

ソフトウェア工学の歴史が短いと言っても、既に40年近くの蓄積があり、CMMIやPMBOK、アジャイル開発などではそれなりの情報があると思う。
しかし、実際の現場で使われているとは言いがたい。
その理由は、ソフトウェア開発が汎用機、クラサバ、Web、モバイル、クラウドなどへどんどん変化していくために、それら開発のデータを収集したとしても、理論が前提とする制約条件に合致しない状況が多いのではないか?

CMMIは理論としては良いことは言っているにも関わらず、なかなか現場で身に付かないのは、現場の制約条件に合わせて落としこむ部分が難しいのだろうと想像する。

そんなことを考えると、Redmineに溜まったチケットデータがあったとしても、それを上手く使う方法や、分析の前提条件をきちんと整理しなければ、使いものにならない。
本当は、ソフトウェア・リポジトリ・マイニングのように、せっかく溜まったRedmineチケットを有効活用したいのに、メトリクスや分析手法、その効果がきちんと整理されていないように思う。

【2】損益計算書・貸借対照表から経営分析する手法の事例

チケット駆動開発でソフトウェア開発のメトリクス分析を行うアイデアとしては、損益計算書・貸借対照表から経営分析する手法に似たようなものになるのではないか、と思う。

例えば、経営分析では、企業が四半期ごとに提出する損益計算書・貸借対照表を元に、各種の経営分析のメトリクス(経緯指標:KPI)は既に知られている。

経営分析指標

決算書の読み方・財務分析のしかた

総資本利益率(ROA)が経営分析指標の重要な数値で、ROA=売上高利益率/総資本回転率になる【どもども遠田幹雄BLOG】

経営分析では、収益性・安全性・生産性・返済性などの観点の指標があり、この企業は本当に儲かっているのか、将来も安全なのか、効率的な経営がされているのか、投資したお金や借金の利息をきちんと返してくれるのか、を見る。

銀行や株主、投資会社は、企業のPL・BSを元に、各種の経営指標を計算し、自分たちの投資に対して十分な利益(リターン)が出ているか、を調べる。
中小企業診断士のような経営コンサルタントは、もし、利益が低ければ、どの指標が悪いのか、を洗い出し、どこを改善すべきか、を診断してくるだろう。

すなわち、経営指標は、飛行機の操縦室にある数多くの計測器と同じであり、飛行機が安定飛行できているか、どこに異常が発生しているか、を検知するために存在する。
同様の発想をソフトウェア開発のメトリクス分析にも適用できないか?

【3】チケット駆動のメトリクス分析の観点

例えば、経営指標と同じような観点でソフトウェア開発を考える場合、収益性・安全性・生産性の観点を応用できないか?
経営指標は下記の観点がある。

収益性・・・投資した資本に対し、どれだけの収益が出ているか?
安全性・・・借金を返す能力はあるか?
生産性・・・労働者1人当りの生産性は高いか?

経営指標の観点をソフトウェア開発に適用した場合、下記のイメージになるだろうか。

収益性・・・投下した工数に対し、どれだけのアウトプットを作り出し、リリースできたか?
安全性・・・潜在バク、リファクタリングすべきソース、古くなったアーキテクチャを改善する能力はあるか?
生産性・・・労働者一人当たりの生産性は高いか?

従来のソフトウェア開発のメトリクスの場合、安全性と生産性の観点はすごく多い。
信頼度成長曲線、バグ密度、テスト密度などの品質、EVMなどのコスト管理のメトリクスは既に知られている。
しかし、収益性という観点が不足していないか?
確実にリリースできているか、リリースしたソフトウェアが売上に貢献しているか、という観点では弱いのではないか?

その弱点を補充するかのように、最近のアジャイル開発では、収益性という観点で、各種のメトリクスが提唱されているように思える。
メトリクスによる「見える化」のススメ: エッセンシャル・リーンでは、CFD、スループット、サイクルタイム、リードタイムが、アジャイル界隈では人気のあるメトリクスだ、と言っている。
チケット駆動のメトリクスとして有効である例としては、Velocity、サイクルタイム、リードタイム、チケット完了率(スループット)が挙げられるだろう。

収益性という観点では、Velocityやチケット完了率、生産性という観点ではサイクルタイム、リードタイムが挙げられるかもしれない。
でも、個人的にはこれだけでは不十分。
もっと色んなメトリクスが欲しいし、それらのメトリクスをどの場面で、どのように使うと効果的なのか、が知りたいのだ。

【4】チケット駆動のメトリクス分析による効果とは

チケット駆動のメトリクス分析による効果として、不十分かもしれないが、SQIP2014で@akahane92さんが発表された経験論文が参考になると思う。

SQIP2014の論文「「効率、品質、統制」の共通課題に着目した現場主導によるITS導入の効果検証」がすごい #redmine: プログラマの思索

この経験論文が優れていると思う点は、Redmineを内部統制で運用するツールとして用いることで、Redmineチケットの精度や品質がかなり良いという前提があること。
また、品質の良いRedmineチケットから、「チケット完了率,チケットスループット(完了所要日数の平均と分布),添付ファイル指数,説明欄文字数(平均),チケット密度」という定量的メトリクスを抽出できたこと。
さらに、それらメトリクスの動きから、各プロジェクト・各開発チームの作業効率や投資対効果がよく分かってくることだろう。

本当は、Redmineを使って、上記のような定量分析をもっと緻密に、理論化したいのだ。

【5】Redmineによるチケット駆動のメトリクス分析の可能性

先に、従来のメトリクス分析の問題点を2つ挙げた。

1・ソフトウェア開発のメトリクスに必要な作業情報を収集・集計するのが難しい。
2・メトリクスや分析手法などの理論の前提と、実際のソフトウェア開発の制約条件が一致させるのが難しい

僕の直観としては、この2つは、Redmineという柔軟なチケット管理ツールを用いることで解決できるだろうと思う。
1番目の収集・集計のコスト高の問題は、Redmineというチケット管理ツールのおかげで、チケット入力の運用ルールさえ徹底できれば解決できる。
チケット集計は、Redmineの一機能に置き換えできる。

2番目の、メトリクス分析の理論的前提と実際の現場の乖離の問題は、例えば、WF型開発の案件もアジャイル開発の案件も、同時に一つのRedmineで別々に管理でき、かつ、一つのRedmineで横串で集約・集計できることで解決できる。
実際、Redmineの複数プロジェクト機能、柔軟なワークフロー管理やカスタムフィールドの割り当てを使えばいいだろう。

すなわち、Redmineの機能がそれぞれの現場の開発プロセスや運用ルールを吸収できれば、それぞれの現場の特異性はなくせる。
理論的な観点では、Redmineという一つの箱にあるデータを見れば良い、という状況に置き換えられるはずだ。

つまり、柔軟なチケット管理ツールを用いることで、従来のソフトウェア工学にあるメトリクス分析の問題点は解決できるだろう。
また、本来のソフトウェア工学がやりたかった「メトリクスによるソフトウェア開発プロセスの分析」をチケット管理ツールを用いることで、注力できるはずだ。

このアイデアを元に、経営指標のような分析のアイデアを付け加えれば、Redmine上で色んなメトリクス分析を試せるのではないか、と思う。
さらに、現在のアジャイル開発が色んなメトリクス(KPI)を提案しているアイデアを流用すれば、アジャイル開発をRedmineで補強できるのではないか、と思ったりする。
つまり、Redmineをアジャイル開発の作業管理ツールだけでなく、アジャイル開発を支援するメトリクス収集ツールとして用いるわけだ。

このアイデアを実際に色々試してみたいと思う。

| | コメント (0)

2015/09/05

Redmineで共有ファイルサーバーへリンクするプラグインredmine_wiki_unc

Redmineで共有ファイルサーバーへリンクするプラグインredmine_wiki_uncをメモ。

【元ネタ】
redmine_wiki_unc/README.rdoc.ja at master ・ bearmini/redmine_wiki_unc ・ GitHub

bearmini.com ≫ [Redmine][Plugin] UNC Link

ブラウザで UNC パスのリンクをオープンする方法 | プログラマーズ雑記帳

Redmine/Redmine 2.6にプラグイン「Wiki UNC Link」を導入する?|?Tipi

「RedmineのWikiで、共有ファイルサーバーのリンクを押したら、ファイルを開いてくれる機能はないか?」と質問を受けた時があった。
textileでは、HTTPのリンクなら問題ないが、社内の共有ファイルサーバーのリンク「file:////~」は動作してくれない。
ネットワーク上の共有 PC へのパスはUNC パスと呼ばれるらしい。

利用シーンとしては、共有ファイルサーバーにあるドキュメントや、環境整備のためのツール(相当ファイルサイズが大きい)へのリンクを付けたいのだ。
RedmineのWikiに添付すると、ドキュメントやツールのバージョンアップのたびにアップロードし直す手間もかかる。

調べてみたら、redmine_wiki_uncというプラグインを入れると、UNCパスに対応してくれるらしい。
「{{unc(\\server-name\dir\to\file)}}」というWikiマクロが使えるようになる。
たしかにこれは便利だ。

そう言えば、前回のRxTStudy勉強会でも、ある工場のRedmineで使っているプラグインとして紹介されていた。

マイグレーションも不要なので、たぶんどのバージョンのRedmineでも動くのではないか。
今度試してみる。

| | コメント (0)

Excel管理台帳から今時の開発環境へ

大規模SIerの今時の開発環境の記事があったのでメモ。
すごく参考になる。

【元ネタ】
これが大規模SIerな弊社のデファクトスタンダードな開発スタイルだ!! - そこに仁義はあるのか(仮)

受託開発でGitとmavenを使って開発をしている - そこに仁義はあるのか(仮)

はてなブックマーク - これが大規模SIerな弊社のデファクトスタンダードな開発スタイルだ!! - そこに仁義はあるのか(仮)

バージョン管理はファイル名に日付つけて残しといて、デプロイは紙の申請書に10個ぐらい判子もらって水曜日までに提出すると翌週には反映される。課題管理はもちろんEXCEL。これが大規模SIerの実際の開発スタイル はてなブックマーク - hobbiel55 のブックマーク - 2015年9月3日

【1】はてぶが1千以上も付いていて、皆の興味が向いているのが分かる。
環境は、GitBucket+Jenkins+Redmine+SonarQube+Artifactory。

GitHub Enerpriseを使わないなら、自社サーバーでこんな開発環境を作るのだろうと思う。
MS製品なら、TFSでほとんどカバーされるのだろう。
Jiraなら、アトラシアン製品でほとんどカバーされるのだろう。

以前の僕は、Redmine+Subversion+TestLink+StatSVNの環境を作っていたが、今なら、こういう環境の方がはるかに開発効率もいいだろう。
全てオープンソースなので、社内にサーバーさえ用意できれば、開発者自身で開発環境を全て構築できる。

【1-1】developブランチをニアショア・オフショアの開発チームごとに任せて、プルリクで日本拠点のチームが受入するやり方は確かに良い。

今までなら、このやり取りをExcel管理台帳にCVSやSVNリビジョンを指定して、ライブラリアンが管理台帳を参照してマージし、タグ付けする作業が必要だった。
そういう手作業が全てGit上でオンライン化されることで、作業履歴も残るし、プルリクがコードレビューや受入れ検査も兼ねるようになる。

【1-2】SonarQubeというツールも初めて知ったが、昔のSonarのグレードアップ版みたいなものかな。
ソフトウェアのメトリクスは、自動収集・自動集計して、いつでも開発者が見れる状態にした方がいい。
自分のコードがどのように客観的に見られているのか、と日本人の開発者は意外に意識するから。

SonarQubeでプログラムの品質管理をはじめる(概要) - Qiita

ユカイ、ツーカイ、カイハツ環境!(17):コード探知機「Sonar」でプロジェクトの深海を探れ! (1/4) - @IT

【2】もはやチケット駆動は当たり前であり、ソフトウェア開発の3種の神器も全てオープンソースで揃えることもできる。

こういう開発環境のネタは個人的に好き。
なぜなら、アジャイル開発の基本精神は、サーバーントリーダーシップのようなマネジメントよりも、現場でいかにプログラミングしやすくするか、という環境整備にあるような気がするから。

Excelのプロジェクト管理から脱却せよ~SW構成管理を見直そう: プログラマの思索にも書いたけれども、頻繁にリリースできる開発インフラがあれば、プロジェクト管理を意識せずにコーディングだけに専念すればいい。

XPが生み出したソフトウェア技術のプラクティスは、オープンソースの各種ツールの一機能に実装され、最終的には、一つのプロジェクト管理サーバーのようなものに実現されるのだろう。

つまり、ソースの共同所有、継続的インテグレーション、ペアプログラミングによるコードレビュー、コーディングルールの標準化などは、上記の開発環境の一部に含まれることで、開発者はプラクティスを意識しなくても、ツールに慣れることで自然に良い習慣が身に付く。

よりアジャイルに開発していくために、そういう開発基盤が必要。
そこにアジャイル開発が概念的に生み出したプラクティスを注入することで、プログラマにプロジェクト管理が不要な環境を提供する。
Excel管理台帳による煩雑なコミュニケーションはそもそも不要。

その辺りもまとめてみたい。

| | コメント (0)

« 2015年8月 | トップページ | 2015年10月 »