書籍「実践反復型ソフトウェア開発」へのフィードバック資料のリンク
「実践反復型ソフトウェア開発」の著者の方がフィードバックの資料をまとめていたのでメモ。
【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本」カテゴリの記事
- 「コーディングを支える技術」は良い本だ(2022.05.26)
- 「RubyやRailsは終わった」という記事のリンク(2022.01.09)
- 実践した後に勉強するのがエンジニアの本来の道(2022.01.09)
- OODAループの時代は、大事なのは使命であり、目標は使命達成のための手段に過ぎない(2021.08.01)
- INSPIRED 熱狂させる製品を生み出すプロダクトマネジメントの感想~日本に足りないのはプロダクトマネジャーだ(2021.08.01)
「Redmine」カテゴリの記事
- 第22回東京Redmine勉強会の感想 #redmineT(2022.05.29)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- オープンソースERPパッケージiDempiereに対する派生開発手法の提案の資料が興味深かった(2022.04.24)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- RedmineのWikiタグでタスクリストを書けるようになった(2022.03.21)
「構成管理・Git」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ(2022.01.09)
- チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine(2021.12.28)
- 第21回東京Redmine勉強会の感想 #redmineT ~Redmineは業務も組織も包み込む柔軟性がある(2021.11.28)
「チケット駆動開発」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
- Redmineにメンション機能が入るらしい(2022.01.15)
「Agile」カテゴリの記事
- 組織を芯からアジャイルにする対談の感想~今のアジャイルは先カンブリア時代なので何でもいい、アジャイル警察はいらない(2022.08.05)
- 製造業の業務にスクラムを適用できるのかという疑問~全てのビジネスモデルにスクラムを適用できるのか?(2022.07.31)
- 認定スクラムプロダクトオーナー研修の感想(2022.07.28)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
コメント