Remineを活かしたプロセス支援 - 失敗しないプロセス支援 -

Redmineを活かしたプロセス支援 - 失敗しないチケット駆動開発 -

株式会社SRA 阪井誠 <sakai ＠ sra.co.jp>

自己紹介

2

阪井誠：さかば、@sakaba37、㈱SRA、博士（工学）

• ソフトウェアプロセス、チケット駆動開発(ＴｉＤＤ)、アジャイル開発に興味を持つ「プロセスプログラマー」

• 仕事とコミュニティに刺激を受ける：RxTstudy、SEA関西

レビュー監訳

New：5/27 New： 6/22 New： 6/30

New： 8/14

SRAホールディングスグループ

3

株式会社SRAホールディングス

• 株式会社SRA • 株式会社ソフトウエア・サイエンス

• 株式会社SRA西日本

• 株式会社SRA東北

• 株式会社AIT

• 株式会社SRAプロフェッショナルサービス

• 株式会社クレディスト

• SRA AMERICA, INC.

• SRA OSS, Inc. • Cavirin Systems, Inc.

• SRA(Europe)B.V.

• SRA India Private Limited

• SRA IP Solutions (Asia Pacific) Pte. Ltd.

• 愛司聯發軟件科技（上海）有限公司

1968年創業 1980年日本初UNIXを商用で導入 ProjDepot：チケット管理のTrac、構成管理、メーリングリストWebDAV 共有、自動ビルド、メトリクス、各機能を統合

2005年7月設立。オープンソースソフトウェアを対象に、OSからミドルウェアを中心に、導入支援コンサルティング、サポート、トレーニング等。 OSSの普及・発展を目指す。 Redmineのサポートサービスあり

チケット駆動開発(TiDD)

• ＩＴＳ（ＢＴＳ）のチケットを障害、課題だけでなく、個人とプロジェクトのタスクを管理する

• 構成管理、Ｗｉｋｉ、継続的統合などツールをチケットに連携させて自動化する

• 構成管理などのプロジェクトの情報をチケットに関連付けて、コミュニケーションを支援する

現場から始まった改善活動

4

統率の

とれた

組

織

の

特

性

自律的

小変更量大

チケット駆動開発による開発法の拡張アダプタブルウォーターフォール

アジャイル開発

ウォーターフォール型開発

TiDD

TiDD

TiDD

アジャイルチケット駆動開発

うまくいかない話は意外と多い

• ITSを使いこなしていない – 「Wikiは使っていません」 – 同じ情報をエクセルと2重管理

• 混乱している – 閉じるタイミング(ゴール)のないチケット – 大量のチケット(細かい、コミットごと)

• プロジェクトに役立っていない – 放置されるチケット – 面倒くさい(管理的、義務的)

できることや目的が不明確なままにツールを導入した

=> チケット駆動開発を失敗させないツボが存在する

概要

• チケット駆動開発はツールの導入だけではない

• プロセスを変更して新しい文化を作り上げる

• どのような可能性があるかを知る

• 改善ポイントを決める

• 運営方針を決める

• 考えないといけないことは多い

設定や運用のツボを説明します

7

チケット駆動開発の3要素

• モデル、見える化、チームづくりの設計が必要 8

チケットシステム開発チーム

プロセスモデルに基づく支援

CSCWによるチームづくり

履歴、バージョン管理、Wiki

リポジトリ

データの見える化


9





リポジトリ


プロセスモデルの特徴

• 人間が実行する

–判断や調整など実行に時間がかかる

–学習コストがかかる

–個人差、モチベーションの差が大きい

–柔軟な判断が可能

現状を大きく変えず、負担を増やさないで

楽になるような改善、運用と組み合わせる

プロセスモデリングのゴール

• 理解する事

• プロセス改善

• プロセス管理

• 自動実行

• 自動ガイド

=> ツボを押さえたモデリングが必要

* Bill Curtis, Marc I. Keller and Jim Over, Process Modeling, Communications of the ACM (Impact Factor: 2.86). 09/1992; 35(9):75-90

プロジェクト: 概要、バージョン、サブプロジェクト作業: 作業の概要、担当者、期限、重要度、ステータスメンバー: アカウント、名前、ロール、

作業品質: カスタムフィールド. テンプレートプラグインプロダクト品質: 優先度別カスタムクエリ, CIとの連携管理の効率化: 進捗報告, 作業時間、サマリ

作業漏れ防止：未完了のクエリ、ワークフロー(トラッカー、ロール、ステータス)

進捗の集計: ロードマップツール連携: バージョン管理、メール、rss、CI、スマホ

メニュー: ワークフローの設定に応じたメニューリマインダ: 期限が近付くとメールで通知

ツボその１：プロジェクトのゴール

• 段階的に詳細化して実施を容易にする – プロジェクト

• 全体のゴールを示す

• 必要に応じて階層化する

– バージョン • マイルストーンを示す

• 直近のゴール＆管理単位

– チケット • 作業間の関係を示す

– 制約を増やしすぎると使いにくくなる

• 適切な作業粒度のゴールを示す

青：先行、後続赤：ブロック

プロジェクトバージョンチケット（親子）

プロジェクトのツボ識別が容易な名称共有すべきゴール

プロジェクトの階層化限定して利用法を明確に

混乱させない様にシンプルに

ツボその２：チケットの粒度

• 明確に、わかりやすく、リズムによる学習を考えて

– チケットの単位 • 完了条件が明確な単位

– チケット一覧 • 一度に見る量が多すぎないように • 用途に応じたカスタムクエリを利用する

– 作業のリズム • 2日に1度は完了するように • 階層化して細かくする

=>プログラミングのモジュールと同様* * Leon J. Osterweil, “Software processes are software too,” ICSE , pp. 2-13, 1987.

フィルタ条件をカスタムクエリにできる

ツボその３：規律

• 運用とのバランスを考えて

– カスタムフィールド • 漏れ、間違いを防ぐ • 入力書式、必須など決める

– ロール • 誤操作を防ぐ • デフォルトは厳しい（要変更）

– ワークフロー • 遷移を限定しミスを防ぐ • 手順を示す • ボトルネックを生みやすい • トラッカー(種類)、ロール、ステータスで指定

=> 厳密にするほど使いにくいので、運用回避も検討する

入力を必須にできる

入力書式の選択

ワークフローの設定

ロールとトラッカーごとに指定

例：終了のチェックを外すと開発者はチケットを終了できなくなる（要承認）

フィールドの更新権限を設定

作成者、担当者用のワークフロー


17



リポジトリ




データの見える化利用シーンを考える • ロードマップ

– バージョンごとの進捗を示す

• チケット一覧 – 進捗と各フィールドを示す – クエリ、カスタムクエリ

• 作業実績 – ユーザ、作業種別等の単位で集計

• ガントチャート – 予定・実績を線表で示す – イナズマ線、親子、関連

• チケットと更新 – No ticket, No commit ! – ロジカルカップリングを示す

=> 必要に応じて使い分ける

バージョン単位で進捗を示す

予実をイナズマ線で確認できる

作業実績

作業実績

チケット編集画面からも入力できる

フィルタや集計単位を指定できる

No ticket, No commit !

No ticket, No commit !

コミット時に「refs #チケット番号」とするとチケットに関連付けられる

複数のコミットをチケットに関連付けることでロジカルカップリング（論理的なつながり）を示せる。コミットごとに分けてはいけない


23



リポジトリ




CSCW*によるチーム作り

全体のコーディネートを考える

• 伝統的リーダーシップ – トップダウンによる指示・報告系統の確立 – 完了はリーダーのみとして、必ずレビューするなど制限を与える

• サーバントリーダーシップ – 自律的なチーム作り – 誰でも完了できるなど、自由度の高い設定をする

• Wiki – チケットよりも検索が容易 – ルールやTIPSなど、まとめとして利用する

• フォーラム、ニュース、etc. – 最新情報の連絡に用いる – メールと連携していれば必須ではない

* Computer Supported Cooperative Work

その他の失敗しないポイント

• なぜチケット駆動開発をするのか考える – 楽をするため

• あるものは使う • 便利な機能を知る • 良く考えないと負担が増える

– 効率化 • 管理よりも現場の工数が大きい • 現場の効率化は効果が大きい • 管理はボトルネックになり易い

– 新しいプロセス（文化）の導入 • ツールの導入ではない • より良い組織を目指す • 準備が重要

まとめ

• チケット駆動開発の3要素

–モデリング、見える化、チーム作りを設計する

–ゴールの段階的詳細化、チケットの粒度、規律を考慮してモデリングする

–データの見える化は利用シーンを考える

–チームのコーディネートが重要

=> チケット駆動開発する理由をよく考えれば、失敗しません

おわり

Redmineを活かしたプロセス支援 - 失敗しないチケット駆動開発 -

プロセスモデルに基づく支援(1/2)

• 理解する事 – プロジェクト: 概要、バージョン（マイルストーン）、サブプロジェクト

– 作業: 作業のゴール（タイトルと概要）、担当者、期限、重要度、ステータス

– メンバー: アカウント、名前、ロール、

• プロセス改善 –作業品質の向上: カスタムフィールド. テンプレートプラグイン

–プロダクト品質の向上: 作業の優先度に合わせたカスタムクエリ, CI（継続的統合との連携）

–管理作業の効率化: 進捗報告, 作業時間、ワークタイムプラグイン

プロセスモデルに基づく支援(2/2)

• プロセス管理

– ワークフロー: トラッカー、ロール、ステータス

• 自動実行

–進捗の集計: ロードマップ

–ツール連携: バージョン管理、メール、rss、CI、スマホ

• 自動ガイド

– メニュー: ワークフローの設定に応じたメニュー

– リマインダメール: 期限が近付くとメールを出す

まとめ

• チケット駆動開発で考えるべきことは多い

–まずは障害管理から始めよう

–改善ポイントを見極めよう

–運営方針を決めよう

• 準備も必要

– カスタムフィールド

–ワークフロー

– カスタムクエリ