Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (19)
Similaire à プロジェクトを成功させるチケット管理
Similaire à プロジェクトを成功させるチケット管理 (20)
Plus de Makoto SAKAI
Plus de Makoto SAKAI (20)
プロジェクトを成功させるチケット管理
- 3. チケット駆動開発関連の業務経験 • チケット駆動開発によるソフトウェア開発 – 請負開発での社内利用（事例1） – SESでの客先利用 • チケット駆動開発導入支援（コンサル） – ツール導入支援 – ワークフロー定義支援（レビュー、提案）（事例2） • チケットシステムの社内導入 – PC資産管理への応用* – Wikiによる情報共有 *日経SYSTEMS 2013年9月号「こうすれば必ず成功！Redmine導入の勘所」 [#47Redmine]ユーザコミュニティが盛り上がってきた - 第５回 品川Redmine – http://sakaba.cocolog-nifty.com/sakaba/2013/06/47redmine---red.html 3
- 4. 目次 • チケット駆動開発 – はじまり、バージョン管理とチケット – ツール連携とチケット・コミュニケーション支援 – チケット駆動開発の効果 – チケット駆動開発の形態とチケットの管理方法 • 事例 – 現場の自律によるリスク低減（文教パッケージのカスタマイズ） – 効果的なコミュニケーション（オフショア開発の支援） • プロジェクトを成功させるチケット管理 – うまくいかない話は意外と多い – 事例がうまくいった理由 – プロセスモデルに基づく支援 – まとめ • おまけ：サーバントリーダーシップ 4
- 5. ＴｉＤＤのはじまり • masuidrive的プロジェクトの方針(2007) http://blog.masuidrive.jp/index.php/2007/07/11/masuidrive-working-style/ • まちゅ, 「もうひとつのTDD」, ITpro Challenge のライト ニングトーク http://www.machu.jp/diary/20070907.html#p01 • Ｓｈｉｂｕｙａ.Ｔｒａｃキックオフ • XPJUG関西 TiDD勉強会発足 (2008) • 「Redmineによるタスクマネジメント実践技法」(2010) • RxTstudy、Ｓｈｉｎａｇａｗａ.Ｒｅｄｍｉｎｅ(2011) • 「チケット駆動開発」(2012) ： 5 Ｔｒａｃブーム チケット駆動開発 誕生 現Redmine大阪、 ｒedmine.tokyo
- 6. チケット駆動開発 • ＩＴＳ（ＢＴＳ）のチケットで障害、課題、タスクを 管理して個人のタスクとプロジェクトを管理する • 構成管理、Ｗｉｋｉ、継続的統合などツールを チケットに連携させて自動化する • プロジェクトの情報をチケットに関連付けて 管理することで、コミュニケーションを支援する 現場による、現場のための改善活動 プロジェクト関心事の電子化によるコミュニケー ション支援 6
- 7. バージョン管理とチケット（仕様変更） 7 仕様変更仕様変更 タスク１タスク１ タスク2タスク2 新規追加 更新 更新 タグ 競合チェックアウト アップデート 解決 関連タスク トレーサ ビリティ
- 9. ツール連携 9 ＩＴＳ バージョン管理 ツール コメント 作業内容、担当者、 ステータス、進捗 開始、終了 refs #チケット番号 fixes #チケット番号 表計算ソフトだと 縦や横に伸びる
- 16. チケット駆動開発の効果 ツールを有効活用してプロジェクトの負担を減らす • 過去： – 履歴の活用(経緯の確認、ノウハウの利用) • 現在： – 障害、課題、タスク、ツール実行の管理 – 情報共有、自動化、コミュニケーション • 未来： – 計画、備忘録、リスクの見える化 16
- 18. TiDDの形態 • 完全チケット方式(アジャイルTiDD、WF) o チケットですべての作業を管理する o 管理が集約される o プロセスを変更するので社内調整が必要 • 補完チケット方式（アダプタブルWF） o 既存の管理は変更しない o 計画外の作業をチケットで管理する o こっそり開始できる(でも報告は必要<=後述)
- 19. 19 チケットの管理方法 • ワークフロー型（事例2：ライトウィング） o 起票や終了には権限が必要 o 仕様の一貫性を保障できる • オープン型（事例1：レフトウィング） o 誰でも起票・終了できる o 機敏さ、自由がある ＊アダプタブルWFでは特に規定しないが オープン型が望ましい 技術・規律重視 チームワーク重視
- 20. 目次 • チケット駆動開発 – はじまり、バージョン管理とチケット – ツール連携とチケット・コミュニケーション支援 – チケット駆動開発の効果 – チケット駆動開発の形態とチケットの管理方法 • 事例 – 現場の自律によるリスク低減（文教パッケージのカスタマイズ） – 効果的なコミュニケーション（オフショア開発の支援） • プロジェクトを成功させるチケット管理 – うまくいかない話は意外と多い – 事例がうまくいった理由 – プロセスモデルに基づく支援 – まとめ • おまけ：サーバントリーダーシップ 20
- 22. TiDDによる自律とリスク低減の実現 • 開発時の履歴をその後の開発につなげます • 開発者の気付きをチケットに記録します • 協調作業を支援してプロジェクトを活性化します 22 ハーケン(釘) カラビナ(止め具) ザイル(ロープ)
- 23. 事例１の概要 • 文教パッケージのカスタマイズ(最大8人x1年) o 短納期 ＆ 仕様の決定遅れ・変更 o スキルは高いが経験者が少ない(リーダは途中交代) o オープンフレームワークの初めての組み合わせ （サブシステム、ミドルウェアのバージョン） o 義務感と不安、重苦しい雰囲気、閉塞感、、、 o 守りに入るので、コミュニケーションが悪い システムテストの時期になると、計画外の環境構築やリリース準備 作業が明らかになった（環境に関連するバグも、、、） ⇒ そうだ！チケット駆動開発をしよう！ 23
- 24. オープンなフレームワークの苦しみ 長所 • 同じようなコードが減る • 個別の業務要件に対する固有の開発だけでよい 短所 • お約束が多い複雑な作業で、気が抜けない • 工夫できる余地が少ない • 少人数で大規模なシステムが作れてしまう • セキュリティ対策で実行環境の構成は日々変化 ⇒ 煩雑なのに情報が少ない、、、大変！ 24
- 25. TiDDの実施方式 • アダプタブルウォーターフォール(補完型ＴｉＤＤ） • WBSと併用（と言っても更新作業は全てチケットあり） • オープンな運用 • だれでもチケットが作成できる • システムテスト以降 • システム全体 • メンバー全員 • trac（単独） ・・・ SRA共通開発環境（trac,subversion,mailmanの仮想環境） 現在のProjDepot
- 26. チケット駆動開発の導入 • 宣言と実行 「 バグだけではなく、ソースを触るときや、WBSにない作業をするとき は、チケットを登録してください！」 • 環境の準備 o レポート(チケットの一覧)の作成 bugのみ、 taskのみ、 その他、など o 権限の追加 tracの権限の設定が堅かったので、チケットを修正できるように 全ての権限を与えた（リスクを考慮して設定してください) • 教育 • パッケージチームとのＱＡの経験はあった 26 ハーケン(釘) カラビナ(止め具) ザイル(ロープ)
- 27. 結果 • チケットの数(BUG以外) o システムテスト：３１ o 本番環境構築：４２ データの準備、環境準備、BUG関連で増えた作業、 細かな仕様変更など、手順書にない1回だけの作業 • 作業漏れ減少！納期までに作業が完了！ (知らないこと、気付かないことはできませんでした、、、orz) それ以外にも、メンバーに変化が、、、 27
- 28. 目が輝いた！ サブリーダ(クラス)なのに遠慮をして いたメンバーが、生き生きしだした • 「チケットを切ってもいいですか？」 ⇒ 義務的な作業からの解放 • 「チケットを切っておかないと忘れてしまう！」 ⇒ すぐに使いこなしていた • 「ちゃんとクローズしてね」 ⇒ 他の人に指導をしていた！ • 「残っているチケットが多くてわかりにくいから整理 しますね」 ⇒ 今後のことも考えている
- 29. 事例１のまとめ • システムテスト以降にTiDDを導入 • 備忘録のつもりで気づいたことをチケット化した • 手順はＷｉｋｉにまとめた • 計画外の作業を管理できた • 作業を見える化することで コミュニケーションが向上した • メンバーが前向きになり、 プロジェクトが元気になった 29
- 30. 事例１からの学び • 新しい環境、実装方法、アプリケーションに挑戦 するには、以下の点を考慮しないといけない – 気づいたことが共有されること – 少ない経験が蓄積されること – 蓄積した経験が生かせること サーバーントリーダーシップを意識した チケット駆動開発の運用方法が必要 30
- 31. ポイント１： 気づいたことが共有されること • チケットが容易に起票できるようにする – 起票の権限をメンバーに与える – ワークフローの制限を少なくする • チケットの種類や属性を増やしすぎない – 考えなくて良い様にする – 記入項目を減らす • リアルタイムに共有してモチベーションを高める – メール、RSS、Eclipseとの連携 – コミュニケーションのタイムラグ減ると利用が増える 31
- 32. ポイント２： 少ない経験が蓄積されること • チケット駆動を習慣づける – 基本的な教育 – メリットを感じさせる – 備忘録としての利用 • 利用に向けた支援 – カスタムレポートの用意など環境整備 – アドバイスのための棚卸し – ルールの整備 (“No Ticket, No, Commit!!”をどこまで守るか、など) 32 ハーケン(釘) カラビナ(止め具) ザイル(ロープ)
- 33. ポイント３： 蓄積した経験が生かされること • 経験の種類に応じて整理する – 一度だけの作業はチケットを起票する – 手順やチェックリストはＷｉｋｉにまとめる • 書きっぱなしのチケットを防ぐ – 完了条件を明確にする – 適切な棚卸しをする • 発想力・提案力の向上 – 棚卸しの頻度を増やしすぎない – 自律的なチーム 33
- 35. 事例２：オフショアでの利用 • コミュニケーションが問題になりやすい – 状況が見えない – 履歴を確認したい場面が多い – ボトルネックが発生しやすい • 複数拠点 – プロトコルに制約 – メールは使いにくい 35
- 36. メールではうまくいかない – 情報の所在（ありか） • 個人的な分類・管理（本人以外は検索できない） • MLサーバーで管理（分類がないので検索が困難） • クローズドな情報(関係者が限定される) – 情報の関連付け • ソースとのリンクが困難（更新と理由） • Wikiなどにまとめても、メールと関連付けにくい – 情報の内容 • 承認ワークフローがなく、ステータスがわからない • 検索のキーがない 36 => チケットシステムを導入
- 37. ワークフローの検討 • メールを原則禁止、チケットを利用 – 質疑応答や議論の経緯を残す – カスタムクエリで状況を容易に確認できるようにした • チケットは基本的に発注側の責任者が閉じる – ボトルネックになるが、最終確認ができる – チケットの種類を工夫して作業を効率化 • 無駄に厳密にしない – ボールの持ち主は、ステータスでなく担当者 – 担当がいなくても情報共有、更新ができる 37
- 38. 事例２の結果 • メールとファイル共有による開発が一変 – 履歴の検索が容易になった – ファイル共有によるロックの問題が解消 – 安全に修正作業ができる => 「もっと早く使っておけばよかった！」 38
- 39. 目次 • チケット駆動開発 – はじまり、バージョン管理とチケット – ツール連携とチケット・コミュニケーション支援 – チケット駆動開発の効果 – チケット駆動開発の形態とチケットの管理方法 • 事例 – 現場の自律によるリスク低減（文教パッケージのカスタマイズ） – 効果的なコミュニケーション（オフショア開発の支援） • プロジェクトを成功させるチケット管理 – うまくいかない話は意外と多い – 事例がうまくいった理由 – プロセスモデルに基づく支援 – まとめ • おまけ：サーバントリーダーシップ 39
- 40. うまくいかない話は意外と多い • 面倒くさいと感じている – 義務的・管理的に感じている – 大量のチケット(細かい、コミットごと) • ITSを使いこなしていない – 「Wikiは使っていません」 – 同じ情報をエクセルと2重管理 • 混乱しているプロジェクトに役立っていない – チケットを書いてくれない、放置される – 閉じるタイミングがないチケット => 事例との違い（チケット駆動開発のツボ）を考える
- 41. ソフトウェアプロセスは文脈に依存する • （ソフトウェア）プロセスは人が実行する • プロセスは組織文化と業務の上に成り立っている • 例外は厳密なプロセスの機械的な実行 =>重いプロセスになり易い ※EASEプロジェクトのチケット属性
- 42. チケット駆動開発による改善 42
- 43. 43 うまくいった理由（事例1） 事例1： 現場の自律によるリスク低減 事例2： 効果的なコミュニケーション 問題が共有されていた 迫る納期、厳しい顧客、不安感 =＞情報共有がうまくいっていなかった メールによるコミュニケーションは難しい =＞ 情報共有の仕組みが必要 仕組みがある チケットシステム（trac） =>パッケージの障害管理に使っていた チケットシステム（Redmina） => ふさわしい運用方法を検討した 改善のモチベーション これ以上ひどくなったらヤバい =>ワラをもつかむ改善の考え方 開発を始めるまでに良い方法を作りたい =>サマリ機能を利用した
- 44. 44 • 問題を共有する 解決すべき問題が共有されないといけない • 仕組みを作る 環境を整えて必要なものを必要なだけ • 改善のモチベーション 自分ごととして実施する うまくいく方法 あとで出てきます
- 47. プロセスモデルの特徴 • 人間が実行する – 判断や調整など実行に時間がかかる – 学習コストがかかる – 個人差、モチベーションの差が大きい – 柔軟な判断が可能 現状を大きく変えず、負担を増やさないで 楽になるような改善・運用と組み合わせる
- 48. プロセスモデリングのゴール • 理解する事 • プロセス改善 • プロセス管理 • 自動実行 • 自動ガイド => ツボを押さえたモデリングが必要 * 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、スマホ メニュー: ワークフローの設定に応じたメニュー リマインダ: 期限が近付くとメールで通知
- 49. ツボその１：プロジェクトのゴール • 段階的に詳細化して実施を容易にする – プロジェクト • 全体のゴールを示す • 必要に応じて階層化する – バージョン • マイルストーンを示す • 直近のゴール＆管理単位 – チケット • 作業間の関係を示す – 制約を増やしすぎると使いにくくなる • 適切な作業粒度のゴールを示す ※アンダーライン部は後のページで説明します 青：先行、後続 赤：ブロック プロジェクトバー ジョン チケット（親子）
- 51. ツボその２：チケットの粒度 • 明確に、わかりやすく、リズムによる学習を考えて – チケットの単位 • 完了条件が明確な単位 – チケット一覧 • 一度に見る量が多すぎないように • 用途に応じたカスタムクエリを利用する – 作業のリズム • 2日に1度は完了するように • 階層化して細かくする =>プログラミングのモジュールと同様* * Leon J. Osterweil, “Software processes are software too,” ICSE , pp. 2-13, 1987. フィルタ条件を カスタムクエリにできる
- 52. ツボその３：規律 • 運用とのバランスを考えて – カスタムフィールド • 漏れ、間違いを防ぐ • 入力書式、必須など決める – ロール • 誤操作を防ぐ • デフォルトは厳しい（要変更） – ワークフロー • 遷移を限定しミスを防ぐ • 手順を示す • ボトルネックを生みやすい • トラッカー(種類)、ロール、ステータスで指定 => 厳密にするほど使いにくいので、運用回避も検討する 入力を必須にできる 入力書式の選択
- 55. データの見える化 利用シーンを考える • ロードマップ – バージョンごとの進捗を示す • チケット一覧 – 進捗と各フィールドを示す – クエリ、カスタムクエリ • 作業実績 – ユーザ、作業種別等の単位で集計 • ガントチャート – 予定・実績を線表で示す – イナズマ線、親子、関連 • チケットと更新 – No ticket, No commit ! – ロジカルカップリングを示す => 必要に応じて使い分ける バージョン単位で 進捗を示す 予実をイナズマ線 で確認できる
- 56. 作業実績
- 58. No ticket, No commit !
- 59. No ticket, No commit ! コミット時に「refs #チケット番号」とする とチケットに関連付けられる 複数のコミットをチケットに関連付けることで ロジカルカップリング（論理的なつながり）を 示せる。コミットごとに分けてはいけない
- 61. CSCW*によるチーム作り 全体のコーディネートを考える • 伝統的リーダーシップ – トップダウンによる指示・報告系統の確立 – 完了はリーダーのみとして、必ずレビューするなど制限を与える • サーバントリーダーシップ – 自律的なチーム作り – 誰でも完了できるなど、自由度の高い設定をする • Wiki – チケットよりも検索が容易 – ルールやTIPSなど、まとめとして利用する • フォーラム、ニュース、etc. – 最新情報の連絡に用いる – メールと連携していれば必須ではない * Computer Supported Cooperative Work
- 62. その他の失敗しないポイント • なぜチケット駆動開発をするのか考える – 楽をするため • あるものは使う • 便利な機能を知る • 良く考えないと負担が増える – 効率化 • 管理よりも現場の工数が大きい • 現場の効率化は効果が大きい • 管理はボトルネックになり易い – 新しいプロセス（文化）の導入 • ツールの導入ではない • より良い組織を目指す • 準備が重要（資料、説明会、ワークショップの開催）
- 63. まとめ • チケット駆動開発の3要素 – モデリング、見える化、チーム作りを設計する – ゴールの段階的詳細化、チケットの粒度、 規律を考慮してモデリングする – データの見える化は利用シーンを考える – チームのコーディネートが重要 => チケット駆動開発で解決すべき問題を よく考えて実施してください
- 64. 注意点 • 規模、文化、業務でやり方は変わる 有効性を確認しながら実施する – まずは障害管理から始めるのも一つの方法 • プロジェクトのチケット経験や体制で変える 味方を増やす（ただし、全員に目を配る） • なぜそれが必要かを話す（説明責任） – 説明会、ワークショップ • 人を見る（積極的な人、受け身な人） ルールは細かくしすぎず、運用で指導する – ピンチを演じてみる（孫子の兵法） • 自立を促して負担をかけない方法を模索する 本当にすごいのは誰にも気付かれずに結果を出すこと（孫子） – 利用者にメリットを与える。サーバントリーダーシップの考え方 64
- 65. 目次 • チケット駆動開発 – はじまり、バージョン管理とチケット – ツール連携とチケット・コミュニケーション支援 – チケット駆動開発の効果 – チケット駆動開発の形態とチケットの管理方法 • 事例 – 現場の自律によるリスク低減（文教パッケージのカスタマイズ） – 効果的なコミュニケーション（オフショア開発の支援） • プロジェクトを成功させるチケット管理 – うまくいかない話は意外と多い – 事例がうまくいった理由 – プロセスモデルに基づく支援 – まとめ • おまけ：サーバントリーダーシップ 65
- 66. 自律を支援するリーダーシップ • サーバントリーダーシップ – コマンドコントロールをやめ、 メンバーが能力を生かせるように支援する • マクロマネジメント – マイクロマネジメントをすると依存するようになり、 自律性が失われる • 濡れぞうきんはしぼらない – 本田宗一郎氏がＩＩＪ鈴木幸一社長(当時）に送った言葉 – ガチガチの管理からは柔軟な発想は生まれない 66
- 68. サーバントリーダーシップ • ロバート・グリーンリーフ（1904～1990）が1970年に提唱 – 「リーダーである人は、まず相手に奉仕し、 その後相手を導くものである」というリーダーシップ哲学 – サーバントリーダーは、奉仕や支援を通じて、 周囲から信頼を得て、主体的に協力してもらえる状況を作り出す • サーバントリーダーシップの10の特性 – 傾聴、共感、癒し、気づき、納得、概念化、先見力、執事役、 人々の成長への関与、コミュニティづくり • 「リーダーがするべき最も重要な選択は、奉仕することだ。それがな ければ、人々をリードする能力は恐ろしく限定されたものになる」 ＊NPO法人日本サーバント・リーダーシップ協会 http://www.servantleader.jp/index.html 日本人のイメージと違う
- 69. サーバント（僕）とリーダーシップ • 「お客様、よろしければ、どうか、僕のもとを通り過ぎないで ください」紀元前1800年頃創世記 18・3 （イサク誕生の予告） • 「僕は聞いております」紀元前11世紀頃 サムエル記上3・9（ユダヤの預言者・指導者） • 「上に立つ人は、仕える者のようになりなさい」 西暦30年頃ルカによる福音書 22・26 =>叙階式で画像検索 • 「一人称「僕」の普及は、吉田松陰が開いた私塾 「松下村塾」に由来する」1860年頃 人称代名詞「僕」は近代の始まり http://blog.livedoor.jp/t2250maeda/archives/54569732.html • アジャイル開発手法「スクラム」1993年 • W・ハンフリー「TSP ガイドブック：リーダー編」2007年 ＊聖書引用は日本聖書協会 新共同訳
- 71. サーバントリーダーシップの実際 71 W・ハンフリー「TSP ガイドブック：リーダー編」, 2007. – 「自律的なチーム」を構築 – 「その最大限の能力を最大限発揮できるようメンバー を動機付け、コーチし、後押しする」 – 「フィードバックとコミュニケーション」 – 「動的な負荷調整」 – 「管理することとリードすることは違います」 – 「人はリードされたいけれども管理されたくはない」 – 「リーダーは部下を動機付け」るなど、 「下からリード」して「ゴールを達成」する デブサミ運営事務局、100 人のプロが選んだソフトウェア開発の名著 君のために選んだ 1 冊, pp.20-21. 「リーダーに求められる大切なこと」 http://www.slideshare.net/MakotoSAKAI/ss-16581244
- 72. プロジェクトの成功に必要な考え方 サーバントリーダーシップとは 僕（しもべ）と言っても雑用係ではなく、 昔からある良いリーダー像 • 与えられたロール（役割）を認識し • みんなを支え • ゴールのためなら何でもする うまくいく方法と同じ • 問題を共有する • 仕組みを作る • 改善のモチベーション
- 73. 73 • 問題を共有する 解決すべき問題が共有されないといけない • 仕組みを作る 環境を整えて必要なものを必要なだけ • 改善のモチベーション 自分ごととして実施する うまくいく方法から考える チケット管理のチェックポイント 問題を解決しているか 負担は増えていないか 納得しているか （文脈の説明を忘れずに） ディスカッションに向けて