書籍「実践反復型ソフトウェア開発」へのフィードバック資料のリンク
「実践反復型ソフトウェア開発」の著者の方がフィードバックの資料をまとめていたのでメモ。
【1】「実践反復型ソフトウェア開発」は、アジャイルな開発環境作りに興味のある開発者にお勧めだと思う。
理由は、構成管理・チケット管理・ビルド管理・テスト管理に必要な概念が整理されてまとまっているからだ。
SIの現場では、「実践反復型ソフトウェア開発」に書かれているような概念が暗黙知になっており、本来はベストプラクティスないし守るべき規律としてチームが実践すべきルールが徹底されていない場合が多い。
あるいは、10年以上も以前の古い技術に固執しすぎて、アジャイルな開発を阻害している原因になっている時も多い。
だから、そんな現場には、構成管理・チケット管理・ビルド管理・テスト管理に必要な概念や、ベストプラクティスから得られた形式知をチームで共有して実践すべきだと思う。
僕の感想は以前書いた。
実践反復型ソフトウェア開発を読む part1~ブランチの戦略: プログラマの思索
実践反復型ソフトウェア開発を読む part2~マージの戦略: プログラマの思索
実践反復型ソフトウェア開発を読む part3~再現可能なビルド管理: プログラマの思索
「反復型ソフトウェア開発」はソフトウェア工学の良書: プログラマの思索
【1】「実践反復型ソフトウェア開発」の良い所の一つは、ブランチ管理のポリシーやメインラインモデル、マージ手法について一通りの説明がされていることだ。
構成管理はソフトウェア開発者なら誰もが必要とするお作法なのに、構成管理に関する本は「実践反復型ソフトウェア開発」以外には「パターンによるソフトウェア構成管理
」ぐらいしかまともな本がない。
【2】また、「実践反復型ソフトウェア開発」では、チケット駆動開発という言葉は明示していないが、チケット駆動開発に必要な概念やプラクティスが暗黙的に紹介されている点も良い。
例えば、障害管理の下記の運用ルールは、チケット駆動開発のプラクティスにそれぞれ対応している。
・バグを発見したらすぐに起票する→バグをタスク全般に拡張すれば、「Ticket First」
・一件一葉の原則(バグ1件に対し1枚のバグ票を起票する)→「One Matter, One Ticket」
・バグ報告票というボールでキャッチボール→「ペア作業」
・コミットして完了にするタスクは、そのチェンジ番号をタスク票に記入して閉じる→「No Ticket, No Commit」
・バグ報告票がなければ作業を開始しない→「No Ticket, No Work」
【3】個人的には、バグ追跡システム(BTS)が仕掛けかんばんの構造に似ている(P.204)という指摘が一番役立った。
「かんばんがなければ部品の製造を開始しない」「かんばんを通じて、部品や工程の作業実績と追跡する」という仕組みは、まさにチケット駆動開発そのものだ。
とはいえ、仕掛けかんばんがBTSと全く似ているわけではない。
TPSの仕掛けかんばんが、かんばんの流通量で在庫を制御するのに対し、BTSでは、障害票はふやしたくもないのに、いくらでも後から湧き出てくるから、障害の件数を人為的に制御することはできない。
だから、障害票の優先順位付けやチケットのトリアージ、担当者のアサインポリシーで制御する必要がある、という指摘は全く同意する。
トヨタのかんばん方式とバグ追跡システムの密接な関係: プログラマの思索
| 固定リンク
「IT本」カテゴリの記事
- チームトポロジーにおける4チームのインタラクションをUMLで整理してみた(2025.01.12)
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システム開発・刷新のためのデータモデル大全」を読み直した感想~親子頻出アンチパターンは初心者モデラーに多い(2024.08.31)
「Redmine」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
「構成管理・Git」カテゴリの記事
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ(2022.01.09)
「チケット駆動開発」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
「Agile」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- チームトポロジーにおける4チームのインタラクションをUMLで整理してみた(2025.01.12)
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
コメント