「チケット駆動開発」の感想を集めてみた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本」カテゴリの記事
- 「システム開発・刷新のためのデータモデル大全」を読み直した感想~親子頻出アンチパターンは初心者モデラーに多い(2024.08.31)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- 『世界一流エンジニアの思考法』が学べる環境を手に入れてかつ継続する方法の感想 #devboost(2023.12.10)
「ビジネス・歴史・経営・法律」カテゴリの記事
- ビジネス書の名著はどれ?(2023.09.18)
- 営業は顧客の”購買代理人”である(2023.08.16)
- 第85回IT勉強宴会の感想~概念データモデルからビジネスモデルを構築すべきという考え方(2023.05.13)
- 令和4年度春期試験のITストラテジスト試験第4問をastahでモデル化してみた(2023.04.15)
- ChatGPTで起きている事象の意味は何なのか(2023.04.02)
「チケット駆動開発」カテゴリの記事
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
「Agile」カテゴリの記事
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- 概念モデリングや設計原則は進化しているのか(2023.10.21)
コメント