agileツール適合化分科会（issue tracking system）

1Copyright (C) Masanori Kataoka All Rights Reserved.

チケットベースの進捗管理システムITS(Issue Tracking System)

～Redmine, GitHub Issueを中心として～

２０１５年６月２３日

片岡雅憲

2015/6/241

Agileツール適合化分科会（第５回）資料


１．プロジェクト進捗管理とITS

２．BTS/ITSの歴史３．アジャイル開発とITS

４．ITSにおける電子化情報の共有５．アジャイル開発におけるRedmineの活用６．Redmineと関連ツールとの連携７．GitHub IssueによるITS機能＜付録１＞ ITSベース開発のプラクティス＜参考文献＞

＜内容＞


１．プロジェクト進捗管理とITS

アジャイル開発では、短期間のイテレーションを繰り返すことにより開発がすすめられる。開発対象の機能はストーリーと呼ばれる小さな機能に分割され、その開発が各イテレーションに割り当てられる。ストーリーは、ストーリーカードあるいはチケットに対応付けられてストーリーIDあるいはチケットIDにより管理される。システムの運用中に検出された不良あるいは課題に対してチケットが発行され、チケットＩＤにより進捗が管理される。このようにアジャイル開発では、新規開発項目も不良もその他の課題もIDを付与された課題として管理される。ITS(Issue Tracking

System)とは、このようなID付きの課題を管理することにより、プロジェクト管理を行うシステムのことである。アジャイル開発では、多くの作業において自動化ツールを活用していく。その作業および作業対象・成果のすべてがこの課題IDと対応付けられる。ITSは、このIDにより各種の自動化ツールと連携してプロジェクト管理の効率化を支援する。


２．BTS/ITSの歴史

2.1 BTS/ITSの歴史BTS(Bug Tracking System)/ITSの歴史を以下に述べる。１） Bugzilla：インターネットWebの草分け的存在であったNetscape

Navigator(Firefoxの元になっている)が内部で利用していたものを1998年にOSS化したものがベースになっている。BTSの先駆けであり、世界中で広く活用されている。プロジェクトの特性に応じ様々な属性を管理でき、例えば、カテゴリー別、コンポーネント別にバグを整理出来る。

２） Trac ：プロジェクト管理及びバグ管理のためのOSSである。バグ管理に限定せずに広く課題管理に利用されるために、ITS(Issue

Tracking System)と呼ばれることもある。SVN, Git, Mercurial などのバージョン管理システムとも連動する。また、TestLink等のテスト支援システムとも連動する。すなわち、Trac は、広く課題管理に利用でき、他のテスト関連支援ツールと連動することに特徴がある。2003年に登場した。wikiをベースにして開発されている。



2.1 BTS/ITSの歴史（続き）３） Mantis ：変更管理システムの機能を統合した小規模プロジェクト向けのBTSであり、OSSである。多様なレベルの人（素人でも）が使えることを目指していて、多様なOS上で稼働する。日本人（Kenzaburo Ito）が開発者であり、主として日本で使われている。2000年に登場した。

４） JIRA ：Atlassian社製のプロジェクト管理及び課題管理システムである。 SVN, Mercurial, ClearCase などのバージョン管理システムとも連動する．非営利団体に対しては、無料で提供されていることから、多くのOSSプロジェクトで利用されている。Java言語で記述されている。（注）JIRAの発音は「ジラ」

５） Redmine ：Ruby on Railsで作られたITSで、OSSである。Tracよりも新しく、豊富な機能を備えている。複数プロジェクトを扱うことが出来る。また、極めて拡張性に富んでいて。他の関連ツールとの連携が容易な仕組みになっている。2006年に登場した。



2.1 BTS/ITSの歴史（続き）６） Pivotal Tracker:アジャイル開発専用のITSであり、用語もアジャイル用語を用いている。アジャイルプロジェクト対象に、急速にユーザー数を伸ばしている。特徴は次の通り。日本語化されていない。①アジャイル開発管理をWebサービス化（インストール不要）②入力項目が少なく、シンプルなワークフロー③Webブラウザで、ドラッグ＆ドロップで操作できる高い操作性④外部APIから操作可能⑤公共機関、非営利団体、個人利用、教育機関の場合無償で利用可能

７） GitHub Issue: GitHub専用のITS機能。Redmine, TracなどのIssue管理専用ツールに負けない機能を持つ。これらのIssue管理専用ツールよりも軽量で使い易いという人もいる。アジャイル開発との親和性が高い。



2.2 BTSとITS

BTSは、2.1 で前述したように、ソフトウェアの不良の解決のための管理システムとして発展してきた。一方、ITSの方は、元々はコールセンターの課題追跡・管理システムとして発展してきたものである。問い合わせ、クレーム、不良対策等、様々な案件の発生から解決までの処理状況を追跡・管理するためのシステムである。

このように考えてみると、ソフトウェア開発においても、追跡・管理すべきはバグだけでなく、機能追加要求、機能変更要求、問い合わせ等、多様な課題が起こりうる。特に、アジャイル開発においては、このような変更を積極的に受け入れることを方針にしているためにITSが必須となる。アジャイル開発では工期が短いためにプロジェクト管理も自動化することが必要であり、ITSの活用が欠かせない。


３．アジャイル開発とITS

アジャイル開発とITSは、元々は別の概念に基づいて生まれたものである。アジャイル開発はITS無しでも実現できるし、ITSはアジャイル開発だけでなくWF開発にも貢献できる。しかしながら、アジャイル開発とITSは非常に相性が良い。この両者を組み合わせることにより、大きな効果が期待できる。3.1 イテレーションの管理アジャイル開発においては、イテレーションを中心にして作業が進

められる。イテレーションは開発対象ソフトウェアのバージョンと対応付けられる。イテレーションは、ストーリー対応の作業で構成され、これはチケットで管理される。すなわち、

version－iteration－story(ticket)

の対応管理が重要である。これにより次のような改善が実現出来る。１） No Ticket, No Commit (チケット無しにコミット無し）。ソースコード変更のコミットに必ずチケットが要求される。従って、ソースコードのコミット単位が明確になり、目的が異なる修正による競合が防げる。


3．アジャイル開発とITS

3.1 イテレーションの管理（続き）

２）チケットにより、開発内容、変更内容の管理が容易になり、集計等の作業管理を合理化することが出来る。

３）あらゆる作業がチケットにより管理される。したがって、作業メンバの作業内容がチケットIDにより正確に把握される。例えば、毎朝会議での昨日の進捗状況や今日の作業予定はチケットIDで報告、管理することにより、正確で迅速な管理が出来る。

４）チケットをキイとして、変更歴管理ツール、テスト支援ツール等との連携の自動化が推進される。これにより、指標(Metrics)ベースでの作業の「見える化」が徹底される。


3.2 イテレーションの内容の見直しアジャイル開発では、イテレーションを単位として開発サイクルを繰り返す。イテレーションは、開発期間と工数（コスト）が固定になっていて、サイクルを回すリズムを作り出す。

そして、このリズムを壊すことなく、イテレーションの内容を見直しながら開発が進めれる。１）イテレーションでの開発項目の優先順位が見直される。この見直しにおいて、チケットを単位とした開発順位の入れ替えを行うことが出来る。

２）アジャイル開発は、既存の部品、パッケージ、フレームワークを活用して行われることが多く、開発を始めてみて問題に遭遇することが少なくない。変更は高頻度になりがちであり、チケットによる管理が極めて有効である。




3.3 変更歴管理と並行開発アジャイル開発では、一つのイテレーションが終了すると、その成果をリリースし、また、もう一方では次のイテレーションにとりかかり並行開発が行われる。Subversion, Git等の変更歴管理ツールでは、リリースしたイテレーションをブランチで、次のイテレーションをトランクで扱う。そして、次のイテレーションのリリース時に、旧ブランチはトランクにマージされる。

変更歴管理ツールは、このようなブランチの作成やトランクへのマージを容易に支援するものでなくてはならない。そしてまた、これらの作業が高頻度で行われるために「チケットIDと変更管理タグを対応付ける」

ことが作業効率と確実性を着実に改善する。



3.4 バックトラッキングアジャイル開発では、既存の部品、パッケージ、フレームワーク等をベースに開発することが多い。このために、WF開発と違って「下流工程から上流工程へと作業が遡る（バックトラッキングする）」ことが少なくない。

すなわち、上流では定義されていなかった多様な作業が下流で発生し、結果として上流にも影響を与える。このことが、結局はイテレーションの内容や既存の作業に変更を強いることになる。このようなバックトラッキング作業はチケットで管理するのが適している。すなわち、極めて動的な変更を伴うアジャイル開発の作業管理に適している。


アジャイル開発の本質は、高速開発、共同開発である。そこでは、電子化された情報の共有が重要な役割を演じる。

ITSでは、チケットをキイにして、ソフトウェア開発に関するあらゆる情報を電子的に統合管理する。これにより、プロジェクトの関係者が情報をリアルタイムに共有することが出来る。最近では、ソフトウェア開発において分散型開発、更にはオフショア開発を行うことが一般化してきている。このような状況下でITSは、その強みを発揮する。

ITSで共有される電子化情報として次の３通りがある。① チケットそのものに記述された情報② チケットからリンクされたドキュメント③ チケットに付随したチャット

上記のうち①のチケットそのものに記述する情報は簡潔にすることが望ましい。複雑な記述は、②のように別のドキュメントとして記述して、チケットからリンクするようにすべきである。

４．ITSにおける電子化情報の共有


チケットからのリンクで添付するドキュメントはどのような形式のものも自由にするべきである。例えば、バグに対応するチケットでは、不良が検出された画面を添付することにより、不良の内容が的確に伝えられることになる。また、プロジェクトやチームで共有する規則や規格等を共有ドキュメントとして管理することも効果的である。記述形式をwiki形式に標準化してチーム全員で共有・保守する。その変更時には、そのことが共有者全員にリアルタイムで報告される。異なるバージョンのドキュメントを各人が保有するよりもはるかに合理的である。Wikiは、その用途ごとの方言が用いられている。例えば、RedmineではＴｅｘｔｉｌｅ記法を、GitHub IssueではGFM(GitHub Flavored Markdown）記法を用いている。前記③のチャットをチケットと共に用いるのも有益である。関係者間の意見交換がリアルタイムに出来て、チケット処理を加速化する。いわば、ITSとSNSとの融合による機能を活用することになる。

４．ITSにおける電子化情報の共有


５．アジャイル開発におけるRedmineの活用

5.1 RedmineとはRedmineは、BTS(Bug Tracking System)あるいはITS (Issue

Tracking System)の代表的な存在として活用されているシステムである。すなわち、課題あるいはバグについてその発生から解決までの処理状況を追跡する。

ITS/BTSは、WF、アジャイル開発の両方において必要とされるが，管理の迅速性が大切なAgile開発においては必須のものとされる。アジャイルの繰り返し開発サイクルを、優れたリズム感を持って、着実に進めて行くために欠かせないツールとなっている。ITS/BTSの発展の歴史を経て、現在では、Redmineがもっとも使われている。

Redmineは、Rubyで記述されているが他の言語を用いるプロジェクトにおいても利用可能である。拡張性に富み、他の関連ツールとの連携機能も豊かである。



5.2 Redmineを用いたアジャイル開発フローRedmineは、アジャイル開発のための中核的な作業管理システムとして用いられる。図5.1は、その運用フローを示したものである。ここに見られるようにRedmineは、ソフトウェア作業管理用のワークフローシステムであると言うことが出来る。

１） PL(Project Leader)は、新しいバージョンを開始するに当たって、これをRedmineに登録する。

２） PLは、新しい作業を始める際に、そのためのチケットを作成して、これをRedmineに登録する。

３） PG（担当者）は、チケットに基づいて作業を行い、それが完了したら、その旨をRedmineに登録する。

４） PLは、そのバージョンを構成する全てのチケットの完了を確認したら、そのバージョンをリリースする。Redmine上では、そのバージョンはクローズ（閉鎖）される。



5.2 Redmineを用いたアジャイル開発フロー（続き）

５）開発チームは、バージョンが完了したところで、Redmineのデータを集計表示して、そのバージョンの振返り会議(Retrospective)を実施する。そして、改良すべき点があれば、次のバージョンにその改良案件を送る。

６）ユーザは、リリースされたバージョンを試用して、あるいは、Redmine上の情報を問合わせ・分析して、不良を検出した場合、あるいは改善要望がある場合は、それを次のバージョンでの対応案件として送る。



Redmine

バージョン作成

バージョンをリリース

チケット作成

チケット解決

改善要望・障害発生

バージョン振返り

PL(Project Leader)

チケット更新

PG(担当者)

バージョン管理

バージョンをクローズ

集計表示

ユーザ

開発チーム

問い合わせ

次バージョンへ

図5.1 Redmineを用いたアジャイル開発フロー



5.3 Redmineのチケット管理Redmineのチケット管理は、BTS用からITS用へと発展させたものである。その概要は、次に示すとおりである。１）チケットとは何か

Redmineのチケットは、ITSとしての案件（Issue)を管理するための「作業管理票」の役割を持っている。

BTSでは①バグ管理が作業の中心であったが、ITSでは、その他の ②問合わせ ③設計 ④開発 ⑤リリース等の全ての作業が対象となる。また、これらの作業に関連する仕様書、コード等はチケットからリンクされる。

したがって、チケットの概念には、アジャイル開発でのストーリーカードやタスクカードの概念が包含されている。



5.3 Redmineのチケット管理（続き）

２）チケットの粒度アジャイル開発に適用することを考えれば、チケットの作業粒度は、イテレーション（2~4week)よりも、十分に小さくなくてはならない。具体的には、半日～５日位に細分化される必要がある。そして、RedmineのTime Trackingを用いてチケットの進捗状況を管理することが出来る。３）非機能案件はチケット管理の対象となるかアジャイル開発では、顧客に見える機能に基づきチケットを管理するのが原則である。しかし、大きなプロジェクトになれば、複数機能にまたがる共通内部機能、性能評価、ビルド等の非機能作業の比率が高くなる。これらは「内部機能」「その他」等のタグを付けたチケットで管理するのが得策である。




４）チケットの主要な管理項目（作業の性質により使い分ける）a) トラッカー：チケットの種類（バグ、機能、サポート）b) ステータス：チケットの作業状態、管理画面で設定。c) 優先度：チケットの優先順位、管理画面で設定。d) 担当者：作業の担当者、プロジェクト設定画面で設定。e) カテゴリ：システムの機能やコンポーネント。f) バージョン：リリースするバージョン。g) 開始日、終了日：作業の開始日、終了日。h) 予定工数：見積もり工数、時間単位。i) 進捗：作業の進捗率。j) 作業時間：実績工数、時間単位。k) 作業分類：作業の種類。例えば、設計、テスト、レビュ等




５）ステータス管理トラッカー（バグ、機能、サポート）の区分ごとにステータス（状態）が定まり、ワークフローも定まる。例えば、バグ（障害）管理チケットのステータスは次のとおり。

a) 新規（New):障害の発生を受け付けた、担当者を割当て。b) 担当（in Progress):担当者が原因究明中。c) 解決(Resolved)：障害の原因が判明、対応作業が終了。d) フィードバック(Feedback)：確認作業で問題が発生、

再度、対応作業を行う。e) 終了(Closed)：確認作業が完了。f) 却下(Rejected)：仕様通りの動作であったなどの理由で

対応せずに終了。




６）ロールとワークフロープロジェクトを開始するに当たって、最初に「ロール（役割）」と「トラッカー（作業分類）」を定める。・ロールのデフォルト：管理者、開発者、報告者・トラッカーのデフォルト：バグ、機能、サポート

ロールとトラッカーが定まると、その組み合わせに対応したチケットのステータスが決まり、ステータス間の状態遷移としての「ワークフロー」が定まる。



5.4 Redmineでの階層構造管理プロジェクトがある程度以上の大きさになった場合には、プロジェクトの階層構造を管理し、Redmineでの管理もこれに対応しなければならない。階層分割自体は、WBS (Work Breakdown Structure)等の方法（注）によるとして、Redmineでの階層構造は次のように管理される。プロジェクトーサブプロジェクトーバージョンーチケット

もしも、上記で階層が不足する場合は、次で対処出来る。プロジェクトが大きくなった場合は、①を進める必要がある。① サブプロジェクトに階層を持たせる（Redmine0.9以降）② チケットを階層化（Redmineのsubtasking機能）

（注）組織―その成果物―成果物を実現するタスクを管理。



5.5 Redmineによるバージョン管理と並行開発管理新しいバージョンをリリースした場合には、このリリースに対応したブランチを作り、リリースに関連する更新はこのブランチで行う。継続する次期のバージョンは、トランクで開発する。そして、ブランチは、次期バージョンがリリースされる時にトランクへマージされる。このようにして、並行開発が管理される。

ブランチとしては、次のものがある。① リリースブランチ：上記で説明済み② リリース準備ブランチ：リリース準備作業が大きい場合③ ベンダーブランチ：第３者のソースをトランクと別に管理④ タスクブランチ：メインへ大影響を及ぼす変更に対応⑤ トピックブランチ：分散開発においてチケット対応開発


６．Redmineと関連ツールとの連携

6.1 関連ツールとの連携アジャイル開発では、Redmineが中心に、次のツールと連携する。

１）変更歴管理ツール：Subversion等の変更歴管理ツールと連携して、チケットと変更内容を対応付ける。２）ビルドツール、CIツール：Maven, Rake, Jenkinsなどのツールと連携して、チケットとビルド、CIの生産物とを対応付ける。３）テスト管理ツール：TestLink等のツールと、テストの状況、テストの結果についての情報を共有する。４）チケットのCSVインポート：Redmineの外部で作られたチケットの内容をCSV形式で一括してRedmineに取り込む。５）上述したようにツール間で次のように作業分担し、かつ連携する。

―Redmine: チケット番号を含めたアジャイル開発作業の管理―Subversion: リビジョン番号を含めたソースコード変更歴の管理―Jenkins: ビルド番号を含めたビルド作業とその成果物の管理―TestLink:テスト作業の進捗状況の管理



6.1 関連ツールとの連携（続き）

７）以上のツール間の連携の結果、次のような関連付けが実現されて、総合的なプロジェクト管理が可能になる。

ストーリー－チケット－ソースコード－ビルド－テスト（機能）or バグ



6.2 REST API

Redmine1.0.1（２０１０年８月リリース）でサポートされた新機能として、REST(Representational State Transfer)APIがある。これは、他のツールとRedmineとの間で情報を授受することを可能にする機能である。例えば、ビルドの結果、テストの結果をRedmineに連絡することが出来る。この機能により、Redmineでソフトウェア開発に関する全ての情報を一括管理して、Redmineをソフトウェア開発管理の中核ツールとして機能させることも視野に入りつつある。



6.3 Redmine対Trac

ITSとして、Tracは２００４年にリリースされ、着実にユーザ数を伸ばしていった。一方、Redmineは、２００６年にリリースされ、Tracよりも後輩である。しかし、Redmineは急速にユーザ数を伸ばし、２００９年か、２０１０年にはTracのそれを抜いたと言われる。

Redmineは、Tracと比べて次の点で優れている。１）ユーザインタフェースが全てWebベース（Tracは一部、コマンドインタフェースを使わざるを得ない）２）複数のプロジェクトを管理可能（Tracは複数は不可）３）Subversion以外の多様な変更歴管理システム（例えば、CVS,Git

他）に対応している（Tracは当初Subversionのみに対応し、その後Git等への対応を拡大した）


6.4 Redmine対新興ITS

以上に見てきたように、ITS分野においてRedmineは先輩を追い抜き、先頭を走っている。しかし、クラウド化が進展する中で新興のITSがユーザー数を急速に伸ばし、Redmineを追いかけている。１）Redmineは、汎用的なITSツールであり、その概念も用語もＩＴＳに適合するようになっている。この点において、アジャイル開発で用いられる用語とずれがある。２） Pivotal Tracker, GitHub Issue などの新興ツールはアジャイル専用に開発されており、概念も用語もアジャイルに合わせてある。３）新興ツールは、操作性において直観的で簡易である。４）新興ツールはクラウド上のWebサービスとして実現されており、インストールをすることなく容易に利用が開始できる。５）現時点においては、機能的にはRedmineの方がカバレッジが大きい。しかし、新興ツールも急速に機能を充実してきており、今後の経緯を着目していく必要がある。



７．GitHub IssueによるITS機能

7.1 GitHubサービスの概要GitHubは、Gitを利用するプロジェクトのためのホスティングサービスである。GitHubは、Logical Awesome社が運営しており、2008年からサービスが開始された。

GitHubを利用すれば、設備の準備に気を使うことなく、グローバルな分散開発が出来る。このために、Eclipse等の多くのOSSプロジェクトがGitHubに移行していて、現状ではOSSプロジェクトの半数を超えているという。OSSプロジェクトは、GitHubを無料で利用出来る。主要なOSSプロジェクトがGitHubに移行していること、また、GitHub

専用の最新ツールが拡充されてきていることから、GitHubは新しい世界標準としての地位を獲得しつつある。

Gitは、コマンドベースのツールであるが、GitHubでは、Gitインタフェースを内部に隠ぺいし、全てをWebインタフェースで利用できるようにしている。



7.1 GitHubサービスの概要（続き）GitHubが提供している主な機能は次の通りである。

１）OrganizationアカウントGitHubをグループで利用することが出来る。ソースコード情報だけでなくイベント情報や管理情報もグループで共有できる。２）Issue管理機能バグや改善要求などの課題とその処理状況をIssueとして管理する。

Redmine, TracなどのIssue管理専用ツールに負けない機能を持つ。これらのIssue管理専用ツールよりも軽量で使い易いという人もいる。３）Pull Request機能機能追加やバグ修正などの結果をGitHubリポジトリに登録（push)

したものを、他の開発者が取り込む（pull)ための要求を発行する。この機能によりGitHubでは、いわゆる「ソーシャルコーディング」が可能となる。


7.1 GitHubサービスの概要（続き）４）hubコマンド

Gitコマンドをラップしてさらに高度の機能を付け加えて使い易くしたCLI(Command Line Interface)機能である。Git + hub = GitHub との説明がされているように、GitHubの代表的な機能である。GitHub

では初心者はGUIを、上級者はCLIを利用するものと想定している。５）Git Flow機能リリースを中心に据えたバージョン管理を支援する（図7.1参照）。図7.1における各ブランチは次の役割を分担している。①master:常に正常に動作する状態のブランチ②develop：開発の中心となるブランチ。開発者がこれを直接に更新することはなく、featureブランチからマージする。③feature: developを起点としてfeatureで開発作業を行う。④release: リリース用のテストとバグ修正を行い、masterにマージ⑤hotfixes: 運用中に検出されたバグの修正、確認を行う



図7.1 A successful Git branching model （参考文献7)を参照）



7.2 GitHub Issue機能GitHub Issueは、GitHub内のITS機能を提供するものである。

Redmine のように独立したITSではないのでコンパクトに作られていて、GitHubとの連携機能に優れている。

以下では、GitHub IssueのITSとしての基本的な機能は省略し、特徴的な機能について紹介する。１） Issueに関する文書をwikiの一種であるGFM(GitHub Flavored

Markdown）記法で記述する。修得し易い標準記法になっている。２） Issueに分類わけのラベルを張り付けられる。分類わけは各プロジェクトで自由に設定できる。色分けが出来るので、どの分類に属するのかが一目で分かる。また、ラベルごとの選別検索が出来る。

３） Milestoneが設定できる。これにより Issueの日程管理が出来る。４）このIssueを、チームメンバーのだれに割り当てるかを選択することが出来る。




7.2 GitHub Issue機能（続き）

５） Pull Request 機能と連携する。Pull Request 機能は、GitHubの代表的な機能の一つであり、いわゆるチームコーディング、ソーシャルコーディングを可能とする。すなわち、プログラマーが一人でコーディングの完成を判断するのでは、チームで、あるいはプログラマーコミュニティーの助けを借りて、コーディングを完成していく。

GitHubは、Pull Requestが発行されると同時にこれに対応したIssueを発行して、このPull Requestがどのように処理されているかをフォローしていく。

６）チャット機能と連動する。例えば、Gitterというチャット機能をIssue

機能と一緒に用いることにより、関係者がリアルタイムで連携しながらIssueの処理を加速化することが出来る。


＜付録１＞ ITSベース開発のプラクティス

ITSベースの開発における重要なプラクティスを、以下にあげる。P1: チケットファースト

チケットが全ての作業の入力となる。逆に、チケットを見れば、どのような作業が行われているかが分かる。

P2: 分割統治（Divide and Conquer)

複雑な作業は、より小さな単純な要素に分割して統治することが大切である。次の３つの観点がある。

P2.1: チケットで分割統治（機能分割他）P2.2: イテレーションで分割統治（バージョン分割他）P2.3: プロジェクトで分割統治（サブプロジェクトに分割他）

P3: チケットはシンプルにチケットの入力項目やワークフローはシンプルに。

P4: No Ticket, No Commit ! （チケット無しに、コミット無し）修正、追加の意図が不明なコミット（コード変更）は認めない。



P5: ペア作業(Pair Work)

Redmineのワークフロー機能を使って、一つのチケットは、原則的に二人の関与を経由して完了させるようにする。これにより作業の信頼性を上げる。

P6: 小規模リリース小さいサイズで、短いサイクルで、小刻みなリリースを進める。

P7: 棚卸し休眠チケットが無いか、チケットを統合した方が良くないか、等を棚卸しする。特に、大規模プロジェクトでは重要である。

P8:見える化ITSベース開発では、チケットがプロジェクト全体の情報のハブになっている。チケットを中核のキイとして、プロジェクトに関するどのような情報も「見える化」していくこと。



P9: 朝会コミュニケーションの場としての朝会には、次の３つの役割がある。チケットをキイとして、これらの作業を管理する。－各メンバーのその日のタスクを全員で確認する－直近のリリース予定を全員で確認する－隠れ作業等、問題点やリスクを摘出する、嗅ぎ取る

P10: 振り返り（Retrospective)

リリース後の反省会。K（良かったので続けること）、P（悪かったので止めること）、T（試したいこと）を明確化。


１） “Continuous delivery: reliable software releases through build, test, and

deployment automation” Jez Humble, David Farley 2010 Addison-Wesley

２） “The ThoughtWorks Anthology-Essays on Software Technology and

Innovation” R. Singham, M. Fowler, et al.2005 by O’Reilly「ThoughtWorks

アンソロジー」（訳）オージス総研２００８年オライリー・ジャパン３）「Redmineによるタスクマネジメント実践技法」（著）小川明彦、阪井誠

２０１１年１月翔泳社４）「入門 Redmine 第２版 Linux/Windows対応」（著）前田剛

２０１０年８月秀和システム５）「いまアツいアジャイルプロジェクト管理ツール9選＋Pivotal Tracker入門」

佐藤聖規, 岡本隆史２０１２http://www.atmarkit.co.jp/ait/articles/1205/14/news150.html

６）「Git&GitHub入門」岡本隆史、大塚弘記（著） Software Design ２０１５年６月号技術評論社

７） “A successful Git branching model” By Vincent Driessen Jan 2010

http://nvie.com/posts/a-successful-git-branching-model/

８）「GitHub実践入門」大塚弘記（著）２０１４年技術評論社

http://www.atmarkit.co.jp/ait/articles/1205/14/news150.html

http://nvie.com/posts/a-successful-git-branching-model/