« 2018年11月 | トップページ

2018年12月

2018/12/10

チケット駆動開発のアイデアがRedmineへ与えた影響は何か

この記事は Redmine Advent Calendar 2018 の12月25日分です。

Redmine Advent Calendar 2018 - Adventar

チケット駆動開発というアイデアがRedmineに与えた影響を改めて考察してみる。
以下はラフなメモ書き。

【1】チケット駆動開発の発端とは?

Redmineを導入運用する時、「チケット駆動開発」という言葉を使う場面がある。
既に、さかばさんがチケット駆動開発の由来と経緯について書かれている。

TiDD:チケット駆動開発: ソフトウェアさかば

必然から生まれたチケット駆動開発 - XP祭り関西2009 その3-: ソフトウェアさかば

チケット駆動開発の概念は、2007年にTracのチケット管理から生まれた。
その素朴なアイデアは、「チケット無しのソースコミット不可」「No Ticket, No Commit」。

2008年頃、そんなチケット駆動開発のアイデアをRedmineで試してみたら、XPに基づいたアジャイル開発に適用できることに気づいた。
そんな僕の経験を熱く語っていたら、さかばさんが「チケットはXPのタスクカードと同じ」と上手くまとめてくれた。
この言葉がヒントになって、Redmineによるチケット駆動開発を運用した時のPJ管理の技法、チームビルディングの技法に対し、既存の専門知識を片っ端から適用してみた。
たとえば、アジャイル開発、ソフトウェア工学、PMBOK、ITIL、品質管理、など。
そういうアイデアを専門知識で補強することで、より理解が深まる一方、理論はそのまま適用できず、効果を出すには前提条件や制約条件が色々あることにも気づいた。

【2】チケット駆動開発はどのように定義されているのか?

【2-1】Redmineでチケット駆動開発を実践した時のプロセスをフレームワーク化する試みは、下記から始まった。

脱Excel! Redmineでアジャイル開発を楽々管理 (1/5):エンジニアがお薦めする 現場で使えるツール10選(3) - @IT

【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する~チケットに分割して統治せよ」: プログラマの思索

【2-2】チケット駆動開発をアジャイル開発プロセスとみなした時の運用サイクルは以下になる。

1・プロジェクトで発生するタスク、課題、障害は、「XPのタスクカード」とみなし、全てチケット化する(Ticket First)。
チケットは作業指示書であり、課題管理票、障害管理票でもある。

2・それらチケットは、リリースするタイミングで、Redmineのバージョン単位にグループ化する。
Redmineのバージョンは、XPのイテレーション、Scrumのスプリントに相当する(Iteration is a version)。

3・リリースまでのPJ管理は、Redmineの優れたチケット集計機能、構成管理ツール連携機能でリアルタイムにモニタリングすることで実現する。
「No Ticket, No Commit」で、ソース修正履歴は全て、チケットで把握できる。

4・Redmineのバージョンの進捗が100%になったらリリースする。

5・リリース後、チームはふりかえりを行うし、顧客からの改善要望を収集して、次のイテレーション計画へフィードバックして再修正する。

【2-3】上記によって、チケット駆動開発によって明確になったプロジェクト運営のやり方は2つある。

一つは、プロジェクト内で発生するあらゆる作業や課題などをチケットに記録することで、プロジェクト運営はチケットのライフサイクルに置き換えられること。
もう一つは、RedmineバージョンをXPのイテレーション、Scrumのスプリントと同一視することで、Redmineのロードマップ機能は、長期のリリース計画と短期のイテレーション計画に置き換えられること。

つまり、プロジェクト運営の日々の作業は全てチケットでリアルタイムに追跡できるし、それらチケットはRedmineのロードマップ機能など数多くの優れた機能で、プロジェクトの長期の計画づくりにも使えるようになった。
すなわち、チケット駆動開発の概念をRedmineに導入することで、プロジェクト運営の全ての管理プロセスをコントロールできるようになるメリットがある。

【2-4】では、このメリットによって、PJ管理技法がどのように変化するのか。
僕がチケット駆動開発で運用した時に、プロジェクトリーダーとして一番意識したことは「チケットの取捨選択」だった。

プロジェクト運営では、日々数多くのチケットが発生し、計画当初のタスク以外に、納期までに収まらないタスクが発生する。
それらチケットを1つずつ精査し、対策を打ち、1つずつ潰していかなければならない。
見て見ぬふりして放置しても、悪い状況は何も変わらないから。

すると、ガントチャート保守という面倒な作業が必ず発生し、その作業に多大な管理工数を取られて、悪循環に陥る。
一方、チケット駆動開発では、ガントチャートは所詮、1個のビューに過ぎない。
ロードマップ、チケット一覧、カレンダー、かんばん、EVM、リソースヒストグラムなどのビューをチケット集計機能として実現できるし、それらでモニタリングすればよい。
1個のビューにこだわらず、必要な状況で必要なビューを使い、手を打てばよいのだ。

それら機能を使っていくと、バージョン単位にグループ化したチケット群を精査して、優先度の高いチケットから一つずつ潰していくようになる。
もちろん、それらチケットは時々刻々変わるが、Redmineの優れたチケット集計機能で把握できるので、プロジェクトリーダーの意思決定を支援できる。
すると、チケットを分割して次バージョンへ延期したり、捨てる意思決定が多くなると思う。
「直近の納期までに何が必要なのか」をプロジェクトリーダーに徹底的に考えさせる基盤をチケット駆動開発は提供してくれるからだ。

つまり、PJ運営を「チケットの取捨選択」というミクロな意思決定に落とすことが、実はマクロな観点のPJ運営を実現しているわけだ。

【3】チケット駆動開発の具体的な特徴は何か?

チケット駆動開発をRedmineで実装すると、下記の3つの特徴が見えてくる。

チケット駆動開発の戦略: プログラマの思索

【3-1】Redmineの優れた構成管理連携により、要件からソースコードまでのトレーサビリティのインフラが整う。これにより、Redmineは本来の(真の)構成管理ツールとして実現される。

「チケット無しのコミット不可」の運用ルールにより、チケットとソースが密関係で相互リンクされる。
つまり、チケットが作業指示書であれば、チケットを発生させた要件や仕様書からソースやビルドモジュールまで、相互にリンクで遷移でき、追跡可能になる。
よって、要件からビルドモジュールまでのトレーサビリティを理論上は実現できる。

過去のソフトウェア工学の書籍を読むと、トレーサビリティの重要性は謳っているが、その実現方法はExcel台帳でソースやバージョンを管理するなど非常に面倒に思えた。
他方、Redmineであれば、事実上、トレーサビリティを実現できる「真の」インフラになりうる。

また、Redmineはツール連携できるI/Fを持っているので、GitやJenkinsなど数多くのツールと連携すれば、「プロジェクト管理サーバー」なるものを実現できる。
つまり、PMBOKの言う「PMIS(プロジェクト管理システム)」を初めて実現できる。
僕は、PMBOKが目指していたものは、たぶん、こういうインフラが前提であって初めて理解できるのではないか、と思った。

そして、このアイデアは、ソフトウェアプロダクトライン(SPL)にもつながっていく。

さらに、チケット管理システムはソース管理と同じように、作業のUnDo、ReDoを行う為のリポジトリとみなすこともできる。

チケット管理システムは作業の構成管理と同じ: プログラマの思索

【3-2】Redmineの優れたワークフロー管理機能により、プロジェクト管理のフレームワークへ昇華・汎用化できる。

Redmineのワークフロー設定画面が意味するものは、三位一体論だ。
つまり、業務フローというアクティビティ図、ワークフローの状態遷移図、ワークフローの状態遷移表という3つの機能は、Redmineの1つの機能として実現される。

よって、PJ運営に出てくる全ての業務フロー、開発プロセスは、事実上、Redmine上で全て実装できる。
このアイデアにより、Redmineでは、WF型開発も、Agile開発も共存して運用できるメリットが出てくる。
もちろん、PMBOK、ITIL、サポートデスク、会議体管理、PC資産管理など、ソフトウェア開発以外の業務にも適用できるようになる。
ここが、Redmineの運用で一番面白く、そしてホットな部分だろうと思う。

【3-3】チケット集計結果をソフトウェア・リポジトリ・マイニングによって、色んな角度からメトリクスを採取して、プロセス改善の材料にできる。

Redmineに蓄積された過去の大量のチケットは、データマイニングの宝庫だ。
PMOや品質保証部にとって、ソフトウェア工学のメトリクスを実際に研究できる元ネタになりうる。
信頼度成長曲線というメトリクスも、こうやって作るのか、ということも初めて体験できた。

しかし、実際は、チケットの内容が詳細に記載されていないと、なかなか理論通りのメトリクスが得られないことも分かった。
他方、PMBOKのEVMやリソースヒストグラムは、こうやって実装できるのか、ということも体験できた。

チケットと言う一つのデータが蓄積できれば、PJ管理で使われるビューのうち、既存の理論をRedmineで簡単に実装できる。
さらに、Redmineは柔軟でカスタマイズしやすい特徴を活かせば、新たな観点のPJ管理のビューを生み出す可能性があるはずだ。

【4】チケット駆動開発で最も面白い特徴は、「チケットはストックとフローの二重性を持つ」ことだ。

Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索

ストック型チケットは記憶媒体、フロー型チケットは流通媒体: プログラマの思索


Redmineのチケット駆動開発では、チケットに複数の意味を持たせて運用した方が上手く回る: プログラマの思索

チケットはタスクカードであるから、フローとして流れる「流通媒体」。
一方、チケットは障害管理票、課題管理票でもあるから、ストックとして蓄積される「記憶媒体」でもある。

この2つの特徴が混在しているので、チケットの粒度を標準ルールでガチガチに定めるのは難しくなる。
なぜなら、流通媒体のチケットは細かくなるし、記憶媒体のチケットはどうしても大きくなりがちだから。

また、1つのチケットという実体は、ステータスが変更されるたびに、流通媒体と記憶媒体に性質が変わる特徴も持つ。
たとえば、タスクのチケットはフローとして流れるが、途中で仕様変更やらソース修正の内容など、ストックの内容が蓄積される。
他方、障害管理票のチケットは、当初は障害内容や対策を詳細に書いてストックとして蓄積されるが、テスターと開発者の間でやり取りする時、チケットはフローとして流れる。
そのおかげで、チケットはキャッチボールのような雰囲気になる。

つまり、チケットは障害や仕様変更の内容をストックして持つ一方、チケットで進捗管理でき、ワークフロー設定に沿って変更管理が自然に行われる。
すなわち、チケットは、データマイニングの元ネタやナレッジ基盤となる「記憶媒体」の側面と、進捗管理や変更管理などを回す「流通媒体」の側面が既に埋め込まれている。
よって、チケットの粒度に悩むよりも、このチケットの二重性を意識して運用したり、その特徴を活かすように知恵を絞る方が良いと思っている。

【5】チケット駆動開発の今後の課題は何か?

課題は3つあると思う。
一つ目は、チケットの粒度、チケットの完了条件について、考え方を整理すること。
チケットの粒度は、ソフトウェアの本質的な複雑性に由来すると考えているので、それを逆手に取って、ソフトウェアの本質をチケット駆動開発で探ることもできるはず。

チケット駆動の罠~複雑さはチケットの粒度に関連している: プログラマの思索

TiDD初心者から必ず聞かれる質問~「チケットの粒度」と「チケットの完了条件」 #47redmine #redmine: プログラマの思索

チケットの粒度と進捗ビューの関係: プログラマの思索

2つ目は、チケット駆動開発で実装できるプロセス基盤の種類を整理し、それらプロセスの特徴・メリット・デメリット・プラクティス・アンチパターンを明確にすること。
たとえば、WF型開発、Agile開発、PMBOK、ITIL、サポートデスク、PC資産管理、など。

Redmineが今後発展する方向のアイデア: プログラマの思索

Redmineが今後発展する方向のアイデアpart2: プログラマの思索

3つ目は、チケット駆動開発と組織の関係を整理し、「組織がチケット駆動開発をどのように複雑化させるのか」「チケット駆動開発は組織にどんなメリットをもたらすのか」を明確にすること。

第15回東京Redmine勉強会の感想~Redmineの2つの顔が相異なる2つのユーザ層を生み出している #redmineT: プログラマの思索

大規模組織におけるRedmineを巡る諸問題~組織構造がRedmineに与える影響: プログラマの思索

Redmineインスタンスとプロセスの関係~Redmineは組織に従うのか、Redmineに合ったチームを作るべきか: プログラマの思索

Redmineインスタンスはチームの組織文化や慣習を表す: プログラマの思索

Redmineは戦略に従う。そして、Redmineは組織に従う~システム運用フローの背後にある組織構造の影: プログラマの思索

Redmineとチケット駆動開発は表裏一体と思っているので、Redmineを使うことで、色んな実験ができると思う。
それらアイデアを試してみたい。


| | コメント (0)

2018/12/06

Redmineの新機能開発チケットの記事のリンク


石川さんが書かれたRedmineの新機能開発チケットの記事がとても参考になるのでリンクしておく。

【参考】
いま注目しているRedmineの新機能開発チケット - ファーエンドテクノロジー株式会社

Redmine Advent Calendar 2018 - Adventar

直近のVer4.0に入っていない機能の紹介でいくつか気になるチケットはある。

【1】「プロジェクト一覧画面の改善」は実現して欲しいチケットだ。

Patch #29482: Query system for Projects page - Redmine

Redmineの運用が長くなると、プロジェクトが100個以上に増殖するので、必要なプロジェクトのみ選定して、その内容を見たい、というニーズが多くなる。
特に、現場マネージャの一つ上の経営者層がRedmine上で、複数の案件を一覧で見たい、というニーズが多い。
上記の改善ができれば、経営者層の不満となるニーズを多少緩和してくれる。

【2】「トラッカーの日本語訳変更」は、議論が活発で読んでいて面白い。

Patch #29045: Change Japanese translation for Tracker - Redmine

Redmine初心者は、トラッカーという言葉に慣れていないので、いつもトラブルの元になりやすい。
一方、「トラッカーをなくすと、Issue Trackingという概念が消えてしまう」という意見も確かに納得する。

Redmineのトラッカーは、ワークフローそのものであり、帳票そのものでもある。
トラッカーという言葉には数多くの意味が込められているので、そのニュアンスを消さずに修正するのは本当に難しい。

Redmineの「トラッカー」を「チケット種別」へ変更するチケットが提案されている: プログラマの思索

【3】「トラッカーの説明を追加する」チケットも確かにその通りだ。

Feature #442: Add a description for trackers - Redmine

Redmineを触ったことがないユーザには、トラッカーの意味を説明した後で、現場で定めたトラッカーという業務のワークフローを説明する場合が多い。
その時に、Redmine上で、このトラッカーはこういう意味で運用しているよ、という説明文があると、ユーザは勝手に参照してくれるので、システム管理者は楽になる。

【4】「プロジェクト毎にデフォルトのカスタムクエリを設定できるようにする」チケットもニーズが多い。

Feature #7360: Issue Custom Query: Default Query - Redmine

朝一番にプロジェクトを開いた時、メンバーに見て欲しいチケット一覧をデフォルトにしたい。
そうすれば、マネージャが逐一指示を出さなくても、メンバーは自身の残チケットに着目して作業し始めるはず。

【5】チケットにタグづけ機能は、ぜひ欲しい機能だ。

Feature #1448: Add tags to issues - Redmine

ハッシュタグのように、#をつけてタグ付けして、そのタイムラインを読むのは今は当たり前。
チケットのフィルタリングとして、カテゴリやバージョン等、数多くの方法はあるが、タグ付け機能があれば、より柔軟にチケットの分別ができるようになる。

【6】上記の記事には記載がなかったけれど、下記の機能改善も期待している。

・「@名前」でリンクする
・WikiからODTファイル出力
・マイページの画面改善
・添付ファイルの全文検索

新たな機能改善がマネージャの潜在ニーズを呼び起こし、新しい運用方法の提案や新たな機能改善につながる、という議論のやり取りが楽しい。
そこがRedmineの一番面白い点。


| | コメント (0)

2018/12/04

2018年もRedmine Advent Calendarをやってます

@yassanの発案で、2018年もRedmine Advent Calendarを今年もやってます。
まだ空きはあるので、ぜひご参加下さい。
@yassan、ありがとうございます。

【参考】
Redmine Advent Calendar 2018 - Adventar

【参考2】
Redmine Advent Calendar 2017 - Qiita

Redmine Advent Calendar jp 2011とRedmine1.3に向けての感想: プログラマの思索

お勧めの記事は、前田剛さんの下記の記事かな。
なぜ、Redmineでは「Issue」を「問題」「課題」と訳さず、「チケット」になったのか、その経緯が書かれている。

Redmineの「Issue」の日本語訳はいかにして「チケット」になったか | Redmine.JP Blog

他のチケット管理ツールでは、「チケット」という言葉ではなく「課題」「問題」と訳されている場合が多い。
しかし、Redmineでは、日本語訳がチケットになったおかげで、「チケット駆動開発」という概念が生まれて、日本特有の普及推進になったのだろうと思う。
僕も以前、色々考えていた。

チケット駆動開発の理想と現実: プログラマの思索

Redmineの背景にある「チケット駆動開発」という概念は結局何なのか、もっと考えてみたいと思っている。

チケット駆動開発の原点の記事のリンク: プログラマの思索

| | コメント (0)

2018/12/03

ソフトウェア開発に心理学や行動経済学の概念を適用した記事のリンク

ソフトウェア開発に心理学や行動経済学の概念を適用した記事がとても素晴らしいので、リンクしておく。
このアイデアを育ててみたくなった。

【参考】
ソフトウェア開発に役立つ 心理学的現象、行動経済学の概念など 15題 - Qiita

ソフトウェア開発に、製造業や生産管理のベストプラクティスを適用しても、あまり有効でない。
むしろ、認知心理学や行動経済学の知見を適用して、開発者の心理や開発チームの行動に着目した方が、うまくコントロールできるのではないか。
そんな感触をずっと持ち続けてきた。

上記の記事はまさにピッタリ。
そう、こういう記事が読みたかった。

現場の開発者や開発チームは、独自の存在であり、全ての存在が同じではないけれど、それらの行動を現象として見ると、驚くほど共通的な特徴が見つかる場合も多い。
そういうバラバラな共通的な現象を、的確な概念でその本質を表現できればいいのに、と思っていた。

たとえば、認知心理学の概念として、認知的不協和、グループシンク(集団浅慮)、リスキーシフト(リスク志向の集団極性化)、コーシャス・シフト(安全志向の集団極性化)、有能性の罠(competency trap)、訓練された無能、などがある。
それらを実際にソフトウェア開発に適用してみれば、当てはまる事例は多いのではないか?

具体的には、要件定義で数多くの利害関係者の意向を取り入れると、本来は業務を刷新する革新的なシステムを導入するはずだったのに、現状の業務の焼き直しに過ぎないリプレース案件になってしまった、という事例は、コーシャス・シフトの一例ではないか、とか。

僕は、認知心理学の概念の適用も面白いと思うが、行動経済学の概念を適用する方が面白いと思っている。
経済学の基本理念「限られた資源を有効活用する」ことは、ソフトウェア開発でもまさに同じだ。
優れた開発者、優れた開発チームという唯一無二の資源をいかに有効活用して、ビジネス価値を作り出すか、という目的と一致するからだ。

たとえば、技術的負債やリファクタリングは、時間割引や割引価値の観点で説明できるだろう。
犠牲的アーキテクチャは、埋没価値(サンクコスト)や機会原価の観点で説明できるだろう。
意固地な言動は、バイアスで説明できるかもしれない。

アドレナリンジャンキー」にあるプロジェクト管理のアンチパターンも、認知心理学や行動経済学の知見で整理して説明し直すと面白いかもしれない。

プロジェクト管理のアンチパターン集~アドレナリンジャンキー: プログラマの思索

| | コメント (0)

« 2018年11月 | トップページ