Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

16,726 views

Published on

第13回 RxTstudy 講演資料(2015年8月29日)

Published in: Software
  • Be the first to comment

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

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

×