Redmineを活かしたプロセス支援 - 失敗しないチケット駆動開発 -
株式会社SRA 阪井 誠 <sakai @ sra.co.jp>
自己紹介
2
阪井誠:さかば、@sakaba37、 ㈱SRA、博士(工学)
• ソフトウェアプロセス、チケット駆動開発(TiDD)、 アジャイル開発に興味を持つ「プロセスプログラマー」
• 仕事とコミュニティに刺激を受ける: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)
• ITS(BTS)のチケットを障害、課題だけでなく、個人とプロジェクトのタスクを管理する
• 構成管理、Wiki、継続的統合などツールを チケットに連携させて自動化する
• 構成管理などのプロジェクトの情報をチケットに関連付けて、コミュニケーションを支援する
現場から始まった改善活動
4
統率の
とれた
組
織
の
特
性
自律的
小 変更量 大
チケット駆動開発による開発法の拡張 アダプタブル ウォーターフォール
アジャイル開発
ウォーター フォール型開発
TiDD
TiDD
TiDD
アジャイル チケット駆動開発
うまくいかない話は意外と多い
• ITSを使いこなしていない – 「Wikiは使っていません」 – 同じ情報をエクセルと2重管理
• 混乱している – 閉じるタイミング(ゴール)のないチケット – 大量のチケット(細かい、コミットごと)
• プロジェクトに役立っていない – 放置されるチケット – 面倒くさい(管理的、義務的)
できることや目的が不明確なままにツールを導入した
=> チケット駆動開発を失敗させないツボが存在する
概要
• チケット駆動開発はツールの導入だけではない
• プロセスを変更して新しい文化を作り上げる
• どのような可能性があるかを知る
• 改善ポイントを決める
• 運営方針を決める
• 考えないといけないことは多い
設定や運用のツボを説明します
7
チケット駆動開発の3要素
• モデル、見える化、チームづくりの設計が必要 8
チケットシステム 開発チーム
プロセスモデルに基づく支援
CSCWによるチームづくり
履歴、バージョン管理、Wiki
リポジトリ
データの見える化
プロセスモデルに基づく支援
9
チケットシステム 開発チーム
プロセスモデルに基づく支援
CSCWによるチームづくり
履歴、バージョン管理、Wiki
リポジトリ
データの見える化
プロセスモデルの特徴
• 人間が実行する
–判断や調整など実行に時間がかかる
–学習コストがかかる
–個人差、モチベーションの差が大きい
–柔軟な判断が可能
現状を大きく変えず、負担を増やさないで
楽になるような改善、運用と組み合わせる
プロセスモデリングのゴール
• 理解する事
• プロセス改善
• プロセス管理
• 自動実行
• 自動ガイド
=> ツボを押さえたモデリングが必要
* 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、スマホ
メニュー: ワークフローの設定に応じたメニュー リマインダ: 期限が近付くとメールで通知
ツボその1:プロジェクトのゴール
• 段階的に詳細化して実施を容易にする – プロジェクト
• 全体のゴールを示す
• 必要に応じて階層化する
– バージョン • マイルストーンを示す
• 直近のゴール&管理単位
– チケット • 作業間の関係を示す
– 制約を増やしすぎると使いにくくなる
• 適切な作業粒度のゴールを示す
青:先行、後続 赤:ブロック
プロジェクトバージョン チケット(親子)
プロジェクトのツボ 識別が容易な名称 共有すべきゴール
プロジェクトの階層化 限定して利用法を明確に
混乱させない様にシンプルに
ツボその2:チケットの粒度
• 明確に、わかりやすく、リズムによる学習を考えて
– チケットの単位 • 完了条件が明確な単位
– チケット一覧 • 一度に見る量が多すぎないように • 用途に応じたカスタムクエリを利用する
– 作業のリズム • 2日に1度は完了するように • 階層化して細かくする
=>プログラミングのモジュールと同様* * Leon J. Osterweil, “Software processes are software too,” ICSE , pp. 2-13, 1987.
フィルタ条件を カスタムクエリにできる
ツボその3:規律
• 運用とのバランスを考えて
– カスタムフィールド • 漏れ、間違いを防ぐ • 入力書式、必須など決める
– ロール • 誤操作を防ぐ • デフォルトは厳しい(要変更)
– ワークフロー • 遷移を限定しミスを防ぐ • 手順を示す • ボトルネックを生みやすい • トラッカー(種類)、ロール、ステータスで指定
=> 厳密にするほど使いにくいので、運用回避も検討する
入力を必須にできる
入力書式の選択
ワークフローの設定
ロールとトラッカーごとに指定
例:終了のチェックを外すと開発者はチケットを終了できなくなる(要承認)
フィールドの更新権限を設定
作成者、担当者用の ワークフロー
データの見える化
17
履歴、バージョン管理、Wiki
チケットシステム 開発チーム
リポジトリ
プロセスモデルに基づく支援
CSCWによるチームづくり
データの見える化
データの見える化 利用シーンを考える • ロードマップ
– バージョンごとの進捗を示す
• チケット一覧 – 進捗と各フィールドを示す – クエリ、カスタムクエリ
• 作業実績 – ユーザ、作業種別等の単位で集計
• ガントチャート – 予定・実績を線表で示す – イナズマ線、親子、関連
• チケットと更新 – No ticket, No commit ! – ロジカルカップリングを示す
=> 必要に応じて使い分ける
バージョン単位で 進捗を示す
予実をイナズマ線で確認できる
作業実績
作業実績
チケット編集画面からも入力できる
フィルタや集計単位を指定できる
No ticket, No commit !
No ticket, No commit !
コミット時に「refs #チケット番号」とするとチケットに関連付けられる
複数のコミットをチケットに関連付けることで ロジカルカップリング(論理的なつながり)を 示せる。コミットごとに分けてはいけない
CSCWによるチームづくり
23
履歴、バージョン管理、Wiki
チケットシステム 開発チーム
リポジトリ
プロセスモデルに基づく支援
CSCWによるチームづくり
データの見える化
CSCW*によるチーム作り
全体のコーディネートを考える
• 伝統的リーダーシップ – トップダウンによる指示・報告系統の確立 – 完了はリーダーのみとして、必ずレビューするなど制限を与える
• サーバントリーダーシップ – 自律的なチーム作り – 誰でも完了できるなど、自由度の高い設定をする
• Wiki – チケットよりも検索が容易 – ルールやTIPSなど、まとめとして利用する
• フォーラム、ニュース、etc. – 最新情報の連絡に用いる – メールと連携していれば必須ではない
* Computer Supported Cooperative Work
その他の失敗しないポイント
• なぜチケット駆動開発をするのか考える – 楽をするため
• あるものは使う • 便利な機能を知る • 良く考えないと負担が増える
– 効率化 • 管理よりも現場の工数が大きい • 現場の効率化は効果が大きい • 管理はボトルネックになり易い
– 新しいプロセス(文化)の導入 • ツールの導入ではない • より良い組織を目指す • 準備が重要
まとめ
• チケット駆動開発の3要素
–モデリング、見える化、チーム作りを設計する
–ゴールの段階的詳細化、チケットの粒度、規律を考慮してモデリングする
–データの見える化は利用シーンを考える
–チームのコーディネートが重要
=> チケット駆動開発する理由をよく考えれば、 失敗しません
おわり
Redmineを活かしたプロセス支援 - 失敗しないチケット駆動開発 -
プロセスモデルに基づく支援(1/2)
• 理解する事 – プロジェクト: 概要、バージョン(マイルストーン)、サブプロジェクト
– 作業: 作業のゴール(タイトルと概要)、担当者、期限、重要度、ステータス
– メンバー: アカウント、名前、ロール、
• プロセス改善 –作業品質の向上: カスタムフィールド. テンプレートプラグイン
–プロダクト品質の向上: 作業の優先度に合わせたカスタムクエリ, CI(継続的統合との連携)
–管理作業の効率化: 進捗報告, 作業時間、ワークタイムプラグイン
プロセスモデルに基づく支援(2/2)
• プロセス管理
– ワークフロー: トラッカー、ロール、ステータス
• 自動実行
–進捗の集計: ロードマップ
–ツール連携: バージョン管理、メール、rss、CI、スマホ
• 自動ガイド
– メニュー: ワークフローの設定に応じたメニュー
– リマインダメール: 期限が近付くとメールを出す
まとめ
• チケット駆動開発で考えるべきことは多い
–まずは障害管理から始めよう
–改善ポイントを見極めよう
–運営方針を決めよう
• 準備も必要
– カスタムフィールド
–ワークフロー
– カスタムクエリ
Top Related