« アジャイル開発のルネサンス | トップページ | チケット無しでフォークやプルリクエストは許さないというチケット駆動の新しい運用方法 »

2012/09/17

「チケット駆動開発」の感想を集めてみたpart4

チケット駆動開発」の感想を見つけたのでメモ。
感想ありがとうございます。

【元ネタ】
チケット駆動開発を読んだ

(引用開始)
付箋の数と良書度は比例する(脳内調べ)。

アジャイルとウォーターフォールという二元論的な考え方は、その概念が普及する段階では役に立ちましたが、もうその次代は終わりつつあると思います。様々な開発法があるなかで、どのようなプロセスで開発するか、具体的な実践技術が求められているでしょう。

僕のチケット駆動に対する期待は、創薬研究への応用なので、チケット駆動開発の背景にある考え方がぎっしり詰まった本書は、色々な発見や再発見があったり、今の仕事のアナロジーを見つけたりとかなり満足度の高い本だった。ただ、redmineをある程度使っているとか、アジャイルサムライ読んだとかそういいう基礎知識は必須なので、いきなり本書を読むよりは前作を読んだりしておいたほうがいいかなと思う。
処理手順
障害管理ツールの処理手順(p.24)を創薬探索系に重ねると、

障害発見者: アッセイ担当
BTS: BTS
担当者: 合成担当
という感じになるかな。そうすると障害とは何か?という話になるが、創薬系だと予想外の結果ということになるだろう。

予想外というのは仮説駆動開発の文脈だったら、なんのために合成するのか?という最初の目的が達成されたかどうかで判断するところだろうが、明確な目的を持って合成されることは少ないので、MMPに照らし合わせてcliffかどうかで判断してもいいかもしれない。結局cliffは予測外の事象だからね。

リポジトリマイニング
創薬系だとリポジトリにあたるものは既に存在するので、そこから今後の予測を行う技術は非常に興味がある。本書では詳しく解説されてないので、他の文献をあたろうと思った。

バージョン
本書を読んでredmineのバージョンの使い方を理解した。だが、創薬系だと多次元で並行的に進めていくので、ソフトウェア開発だと2系と3系を同時に開発するみたいな感じかなあ。ちょっと難しい。

バージョンの概念は、単なるタグだけでなく、合意というマネジメント要素も含んでいるのです。
p.295のバージョンの概念が欠落する理由も参考になった。
(引用終了)

ソフトウェア開発ではなく、製薬業界でチケット管理を使おうとされているそうです。
上記の疑問について、私の独断で回答してみます。

Q.創薬系の障害とは何か?
A.薬を購入したユーザやメーカーからの問合せないしクレームが相当するでしょう。
 クレームが来たらチケットに登録し、そのクレームを解決できる担当者を決定します。例えば、研究チーム、あるいは、オペレータがすぐに回答できるかも知れません。
 その後、その回答をユーザに返して、問題なければCloseされます。
 つまり、問合せの評価(障害の検証)はユーザが担当していることになります。

Q.創薬系のプロジェクトのバージョンとは何か?
A.プロジェクトのマイルストーンに相当します。
 学会で報告する、創薬研究の開発が完了する、などのチェックポイントが大きなマイルストーンになりますが、たぶん1ヶ月単位で意味ある成果物を出せるように、マイルストーンの目的を明確にすればいいでしょう。

Q.多次元で並行的に進めていく場合の管理方法は?
A.最終成果物の単位でプロジェクトに分割し、プロジェクト単位にバージョン(マイルストーン)を定期的に作って、チケット管理するといいでしょう。
 最終成果物とは、ソフトウェア開発なら、納品対象のシステムないしリリース対象のソフトウェアになります。
 
Redmine入門 - プロジェクト | プログラマーズ雑記帳では、Redmineプロジェクトの観点がとても分かりやすく説明されています。

(引用開始)
後で説明するバージョン管理システムとの連携もあり、バグはソースに対して管理した方がよいため、 なるべくソースの構成に基づいたプロジェクトにした方が管理しやすいです。
例えば、あるプログラムが Windows 版、 Linux 版または Standard 版、 Professional 版といったように別々のプログラムになっていたとしても、 ソースコードが一元管理されているのならば、同一プロジェクトするか もしくは 同一プロジェクト内でサブプロジェクトで分けるようにした方が管理しやすいと思います。
(引用終了)

上記から、「チケットはバージョン管理リポジトリに従う」というプラクティスを導出できるでしょう。
つまり、バージョン管理リポジトリは製品の構成とまさに対応していて、バグはソースに対して管理するために、バージョン管理リポジトリの変更管理がチケット管理に相当するからです。
製薬業ならば、アウトプットである薬の単位でプロジェクトを作り、その薬の開発に関する作業が発生すれば、該当する薬のプロジェクトでチケット管理することになるでしょう。

|

« アジャイル開発のルネサンス | トップページ | チケット無しでフォークやプルリクエストは許さないというチケット駆動の新しい運用方法 »

IT本」カテゴリの記事

ビジネス・歴史・経営・法律」カテゴリの記事

チケット駆動開発」カテゴリの記事

Agile」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



« アジャイル開発のルネサンス | トップページ | チケット無しでフォークやプルリクエストは許さないというチケット駆動の新しい運用方法 »