「チケット駆動開発」の感想を集めてみた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本」カテゴリの記事
- 「コーディングを支える技術」は良い本だ(2022.05.26)
- 「RubyやRailsは終わった」という記事のリンク(2022.01.09)
- 実践した後に勉強するのがエンジニアの本来の道(2022.01.09)
- OODAループの時代は、大事なのは使命であり、目標は使命達成のための手段に過ぎない(2021.08.01)
- INSPIRED 熱狂させる製品を生み出すプロダクトマネジメントの感想~日本に足りないのはプロダクトマネジャーだ(2021.08.01)
「ビジネス・歴史・経営・法律」カテゴリの記事
- 戦前の日本人の気質はまだ成熟していない青年期と同じだった(2022.06.14)
- 「大人の学びパターン・ランゲージ」の感想~知識と経験を行ったり来たりするタイミングを大切にする(2022.06.05)
- 経済学や心理学の実験で得られた理論は再現性があるのか?~内的妥当性と外的妥当性の問題点がある(2022.06.04)
- 中国人の価値観の考え方(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
「チケット駆動開発」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
- Redmineにメンション機能が入るらしい(2022.01.15)
「Agile」カテゴリの記事
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 超高速開発でアジャイル開発を実現する話に違和感がある(2022.05.06)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
コメント