ITの地殻変動はどこで起きているのか?~チケット駆動開発が進むべき道
2011年になって、ITの地殻変動がどこに起こっているのか?を改めて考えてみる。
ラフなメモ書き。
【元ネタ】
チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07)
チケット駆動開発が進むべき道part1~ソフトウェア開発のベストプラクティスをオープンソースのツールで実現する: プログラマの思索
チケット駆動開発が進むべき道part1~ソフトウェア開発のベストプラクティスをオープンソースのツールで実現する: プログラマの思索
Agile開発が指摘したソフトウェア開発の特徴: プログラマの思索
【ソフトウェア開発の課題】
ソフトウェアは変化するのが宿命。
ハードがこれだけ日進月歩で進化しているのに、VerUpしないソフトウェアは価値がない。
しかし、SW開発はとても繊細。
たった1行のソース修正でシステムはすぐに動かなくなる。
ハードやOS、ブラウザを安易にバージョンアップすると、システムは不安定になる。
ソフトウェア開発は製造業よりもはるかに繊細だ。
だから、変更管理が重要。
どのコンポーネント、どのソースをどのように直したのか、どのモジュールをリリースしたのか、をきちんと記録して、あらかじめ作業手順をレビューして承認していくフローが必要になる。
だが、そのワークフローは大量のドキュメントとたくさんの承認フローによって、すぐに重厚長大となり、ソフトウェア開発の速度を落とす。
開発案件が大規模になるほど、承認フローや意思決定が複雑になる。
サブシステム間の課題や作業のやりとりをチームレベルではなく、もう一つ上の層で意思決定する場が必要になってくる。
従来の課題管理会議では、開発チームのリーダークラスが集まって、チーム間の課題やプロジェクトの方向性について議論して、組織としての方針を決定する。
しかし、大規模化するほど、会議は長引き、決まるのが遅くなり、組織そのものの進捗も遅くなる。
だが、ソフトウェア開発の本質から生じる上記の諸問題に対し、アジャイル開発は過激な主張を持って解決しようとしている。
「変化を抱擁せよ」のキャッチフレーズ通り、アジャイル開発の最大の特徴は変化に強いこと。
XPが提唱するソースの共同所有、テスト駆動開発、継続的インテグレーション、小規模リリースなどのプラクティスによって、開発者が作業するインフラが整う。
そして、Scrumが提唱するバックログ、スプリントなどの諸概念によって、アジャイル開発のプロジェクト管理のフレームワークも整った。
しかし、アジャイル開発の最大の弱点は、従来の環境のままでは変化が激しいタスク管理やイテレーション管理を制御するのが難しいこと。
そして、アジャイル開発の事例は小規模プロジェクトが多かったため、つい最近まで、大規模プロジェクトではアジャイル開発は適用しにくい、アジャイル開発は設計や品質の作り込みが弱い、と言われ続けてきた。
【チケット駆動開発の意義】
チケット駆動開発はTracのチケット管理から生まれた。
発端はまちゅさんが提唱されている。
チケット駆動開発の特徴は、BTS(バグ管理システム)のチケットを障害だけでなく、仕様変更やリリース作業などあらゆるタスクを管理する方向へ拡張した点にある。
これがいわゆるIssue Trackingと呼ばれる特徴だ。
だから、TracやRedmineはBTS(Bug Tracking System)ではなく、ITS(Issue Tracking System)と呼ばれている。
そして、チケット駆動開発の最大の意義は「BTSチケットをXPのタスクカードのように扱う」ことによって、アジャイル開発のプロジェクト管理に応用できる点にある。
#この発想はさかばさんが提唱された。
TracやRedmineでは、単にチケットを障害管理に使えるだけでなく、ガントチャートやカレンダーなどの進捗管理機能、ロードマップやリリース履歴などのリリース計画機能、チケットの種類(トラッカー)に応じた柔軟なワークフロー管理、構成管理との連携によるトレーサビリティ、チケットの集計機能を使った品質管理機能など、各種の機能が豊富にある。
BTS(ITS)の優れたプロジェクト管理機能を使って、アジャイル開発のプロジェクト管理を容易に構築して、更にブラッシュアップすることも可能になった。
この発想は、生物進化の前適応の話を連想させる。
前適応とは、ある適応された形質が形作られる場合に、以前から存在した別の機能を持つ形質が用いられたことを指す。
前適応の例は、恐竜から鳥へ進化した経緯が分かりやすい。
恐竜は、数億年前、生物の大絶滅で酸素が急激に減った環境から生まれた。
そのため、恐竜は低酸素の環境でも生存できるように、気嚢と呼ばれる優れた酸素ガス交換機能を持つようになり、その機能が鳥にも引き継がれた。
実際、鳥を解剖してみると、気嚢とよばれる器官が肺から体中に伸びていて、新鮮な酸素を体中に行き渡らせることができているらしい。
その機能のおかげで鳥は、ヒマラヤの高山の空という低酸素の空間でも飛ぶことができる。
更に、小型化した恐竜は体温を維持するために、羽毛を持つようになった。
その羽毛が翼に進化して、鳥は飛べるようになったという説がある。
つまり、鳥が持つ気嚢や羽毛は、本来恐竜が生存していくために作り出した機能だったが、鳥はそれらの機能の目的を変えて、自分たちの都合の良い機能へ意味を変えたわけだ。
だから、鳥は生きた恐竜の化石とも呼ばれているらしい。
前適応の話を聞いて、障害管理からチケット駆動開発へ発展した話と全く同じ構造を持っているような印象を持った。
チケット駆動開発の特徴であるプロジェクト管理機能(チケット管理、進捗管理、構成管理やビルド管理との連携によるトレーサビリティ機能、強力なワークフロー管理など)は、本来は障害管理に必要な機能として発展してきたのだが、目的を変えるだけで、アジャイル開発のプロジェクト管理にも使える、と世界中の人達が気付いたわけだ。
そして、世界中の開発者が、アジャイル開発のプロジェクト管理を実現するツールをどんどん作り出している。
その可能性はとてつもなく大きいと思っている。
【チケット駆動開発の可能性】
僕が今後試してみたいのは、Redmine上でチケット駆動開発を行う事によって、アジャイル開発の運用のハードルを下げるだけでなく、アジャイル開発の新しい運用方法も提唱してみたいことだ。
チケット駆動開発にXP・Scrum・CMMI・PMBOK・ITIL・SW工学・原価計算・PFなどの知識を詰め込んで、チケット駆動開発を理論として強化していきたい。
Redmineを単なるプロジェクト管理ツールだけでなく、SW開発の全ての業務を支援するツールへ高めたいのだ。
つまり、XP・Scrum・CMMI・PMBOK・ITIL・SW工学・原価計算・PFなどの理論や概念は本来それぞれの目的があるだろうが、チケット駆動開発を支援するための手段や道具とみなして、チケット駆動開発をソフトウェア開発の体系的な理論として骨付して肉付けしていきたいのだ。
ラフなイメージは下記の通り。
以下は書きかけ。
少しずつ考えていきたいと思っている。
【1】ロードマップによるリリース計画作り
小規模リリース
イテレーションとリリース予定バージョンを同一視する
タイムボックス的な開発
漸進型開発と反復型開発の違い
【2】バックログによる要件管理
要件のイテレーション管理
チケットの親子関係
RedmineのSubstasking
期限の無いリリース予定バージョンで管理する方法もある
チケットをイテレーション間で移動する
サスペンドリンク
要件変更の影響範囲
仕様変更の工数を予測可能になる
【3】SCM連携によるトレーサビリティ
レコメンドエンジンの実装
ソース修正時に過去に修正した関係ソースやチケットを表示する
同類バグの調査
設計漏れをなくす
分散バージョン管理との連携
構成管理パターン
ブランチ管理
マージ機能
イテレーションとコードラインの関係性
【4】テスト管理ツールとの連携、ビルド管理ツール、コードレビュー管理ツールとの連携
メトリクスの使い方
信頼度成長曲線
SRATS
テスト消化曲線
TestLinkCnvMacro
品質管理の考え方
ブロックやみなしバグの影響範囲を示唆する
同類バグの範囲を自動的に示唆する
移植性
再利用性
ソフトウェアプロダクトライン
派生開発
XDDP
保守性
リファクタリング
変更容易性
コードレビュー
ビルド管理
並行ビルド
本番環境の仮想化
RestfulAPI
外部ツールと連携
エンドユーザコンピューティングのためのクライアントツールと連携
【5】ワークフロー管理
変更管理の考え方
自然なペア作業
チケットをCloseする時は必ず二人の目を通す
ITILの考え方
サーバー監視ツールが障害を検知したら、メール送信する時にチケットも自動登録
Hudsonがビルドエラーを検知したら、メール送信する時にチケットも自動登録
トラッカー単位に集計してプロセス改善
オペレータが対処できないチケットは、上位管理職へエスカレーションする
ワークフローの可視化
【6】大規模アジャイルの運用方法
アジャイルリリーストレイン
スクラムオブスクラム
アーキテクチャ助走路
分散開発は?
プロジェクトファシリテーションを分散開発のチームビルディングへ拡張する
【7】PMBOKのEVM、活動基準原価計算(ABC)
予定・実績工数の管理から原価管理
プロジェクトの製造原価、コスト、利益をシミュレーションする
【8】PMBOKの応用
クリティカルパスの計算
ボトルネックの探索
PMIS
アジャイル開発のプロジェクト管理の概念をPMBOKで支援する
【9】PF(プロジェクトファシリテーション)のプラクティスと連携
朝会
KPTによるふりかえり
プロセス資産
ニコニコカレンダー、かんばんをデジタル化
オフショア開発のように場所が離れた場合のチームビルディング方法
オープンソースでは当たり前
【10】Excelをエンドユーザコンピューティングとして使う
マネージャや顧客が欲しいデータはCSVで渡せばいい
好きなようにカスタマイズしてくれればいい
何も全ての機能をRedmineで実現する必要は無い
業務システムが全帳票を作る必要はなく、CSVでデータ提供する機能を実装しておくのと同じ
| 固定リンク
« 連関エンティティと関連クラス | トップページ | TestLinkを運用して気付いたことpart11~お試しテスト、フールプルーフテスト、探索的テスト、モンキーテスト、フェイルセーフテスト、ラッシュテスト »
「プロジェクトマネジメント」カテゴリの記事
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
「Redmine」カテゴリの記事
- 「Redmineハンドブック」は良い本です(2022.12.17)
- 第23回東京Redmine勉強会の感想~コミュニティは仲間から生まれて続く #redmineT(2022.11.06)
- 第22回東京Redmine勉強会の感想 #redmineT(2022.05.29)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- オープンソースERPパッケージiDempiereに対する派生開発手法の提案の資料が興味深かった(2022.04.24)
「ソフトウェア工学」カテゴリの記事
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- プロジェクト管理やソフトウェアアーキテクチャの問題の背後にはトレードオフが隠れているのではないか(2023.02.18)
- デブサミ2023の感想(2023.02.11)
- ChatGPTにEclipseでEclEmmaとJaCoCoからカバレッジを出力する方法を聞いた(2023.02.01)
- DDPは品質管理に役立つのか(2022.12.13)
「TestLink」カテゴリの記事
- TestLinkの要件管理にUSDMを適用する方法(2023.01.22)
- TestLinkのテストケースはクラスとインスタンスの考え方で区別する(2023.01.22)
- テスト管理ツールCAT、TestRail、QualityForwardのオンラインのマニュアルのリンク(2022.09.24)
- テスト管理ツールTestRail、CAT、QualityForwardの感想(2022.07.30)
- TestRailの感想(2021.06.23)
「プロジェクトファシリテーション」カテゴリの記事
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 「世界を動かすプロジェクトマネジメントの教科書」の概念図(2022.01.16)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- 昭和の管理者の承認処理は判子押印、令和の管理者の承認処理はいいねボタンを押すこと(2021.12.31)
- チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine(2021.12.28)
「構成管理・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」カテゴリの記事
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- DDPは品質管理に役立つのか(2022.12.13)
- UMTPモデリングフォーラムのパネル討論の感想(2022.11.29)
- XPエクストリームプログラミングは偉大だ~時代がその設計思想に追いついた(2022.11.16)
コメント