Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (14)
Destacado
Destacado (14)
Similar a チケット駆動開発導入のヒント - 自律と規律 -
Similar a チケット駆動開発導入のヒント - 自律と規律 - (20)
Más de Makoto SAKAI
Más de Makoto SAKAI (20)
チケット駆動開発導入のヒント - 自律と規律 -
- 2. 自己紹介 2 阪井誠：さかば、@sakaba37、 ㈱SRA、博士（工学） • ソフトウェアプロセス、チケット駆動開発(ＴｉＤＤ)、 アジャイル開発に興味を持つ「プロセスプログラマー」 • 仕事とコミュニティに刺激を受ける：RxTstudy、SEA関西 レビュー監訳 New：5/27 New： 6/22New： 6/30 New： 8/14
- 3. チケット駆動開発 現場から始まったシンプルな情報共有が特徴 • ITS（Issue Tracking System）チケットを用いて、障害、 課題、Q&Aのほか、タスクを管理する • チケットを構成管理と双方向に関連付ける – 修正に至る経緯を容易に知ること（トレース）ができる – 一つの理由から生じた複数の更新を束ねることができる • チケットを中心として、情報をリアルタイムに共有し、 プロジェクトを運営する – 現在の状況を共有できる – 今後のタスクを通してゴールを共有できる 3
- 5. 事例の分類 5 As is To be 文化の徹底 目的 作業漏れ防止 トレーサビリティ 計画、保守性向上 チケットの利用法 備忘録・情報共有 進捗・状況管理 タイムボックス管理 ITSの経験 障害管理のみ チケット駆動開発 チケット駆動開発
- 6. 6 As is To be 文化の徹底 目的 作業漏れ防止 トレーサビリティ 計画、保守性向上 チケットの利用法 備忘録・情報共有 進捗・状況管理 タイムボックス管理 チケットの経験 障害管理のみ チケット駆動開発 チケット駆動開発 モチベーション 向上 低下 変わらず 管理面の効果 中 大 中 コミュニケーション向上 大 中 中 強制 なし あり なし 負担感 小 大 なし 結果 作業量が明確でモ チベーション向上 効果あり。要件チ ケットの負担大 管理が容易。必要な 記録を自主的に実施 感想 危機感と目的意識 から効果的だった 面倒。Redmineなど 負担軽減が必要 報告が簡素化され 作業効率化 要望から実施 負担が少なく好評 管理的で負担が大 きく感じられた 自主性に任せた 効果も高かった 目指すべきゴール
- 7. 7 問題点を見極め るとうまくいく 管理的になり易い 準備が重要 文化の醸成に よる改善 AsIsとToBeの視点によるチケット駆動開発の事例の考察 - 坂本記念WorkShop - http://sakaba.cocolog-nifty.com/sakaba/2013/07/tidd-asistobe--.html
- 8. チケット駆動開発に関する相談 講演すると相談されることが少なくない • 管理者「チケットを更新してくれない」 – 進捗の管理がしたいのに更新してくれない – いくら言ってもなおらない • 開発者「面倒くさい」 – スピード感がない、リズムが乱れる – 良さがわからない => 安易に導入して、失敗している 8
- 10. プロセス改善として考える 改善とは技術導入ではなく、その実施によってメリットを得ること。 技術負債から技術資産への文化改革が必要 • P：収支計画を立てる（コンセンサスを得る） – 問題（技術負債）を明らかにする – 実施方法（ルール）を決める – 効果（収支あるいは利益）を示す • D:改善策を運用する – 改善策を推進し、データ（資産）を収集する • C:確認する – 計画をふりかえりって、効果（収支あるいは利益）を見える化する • A：改善策を見直す – 次の改善策を作成する ＝＞利益は単純ではない 10
- 11. 管理者の利益、開発者の利益 管理者と開発者の利益は必ずしも一致しない • 管理が楽になる改善策は規律(ルール）に従わせ ないといけない場合が多い – 開発者には負担になる場合が多い – 習熟すると負担を感じなくなる • 開発が楽になる改善策は自律的に実施できる – 効果を示すだけで導入が進む – 使い方を知らないと負担になる 11 ヒント：効果を知ること ヒント：習熟すること ヒント：使い方 ヒント：負担になる
- 12. 導入のヒント１：負担を減らす 開発者の負担を増やさない • ルールを明確にし、作業指示またはお願いする – 常に確認できるようにWikiなどを用いる – 自動化や集中処理で負担を軽減する • 入力は必要で明確な項目に限定する – 面倒に感じさせない – テンプレートプラグインなどで、入力を容易にする 12
- 13. 導入のヒント２：習熟を促す 継続的に実施されるような活動 • 指導 – 特に導入初期は細かにチェックして指導する – 納得してもらえるように説明する • フィードバック – 導入による成果を見つけ出してフィードバックする – 定量的でなくてもよいので、感謝・賞賛する – ふりかえりも利用する 13
- 14. 導入のヒント３：効果を伝える 効果を知ることから自律への道が始まる • 問題点を共有する – 同じ方向を向く • 期待される効果を示す – レクチャや個別指導などメンバーに応じて行う • 工夫の受け入れ – 改善のアイデアは積極的に取り入れる 14
- 15. 導入のヒント４：MVP(Minimum Viable Product) 最小の負担で効果を得る • スモールスタート – 障害管理から始める – No ticket, No commitのみ • ありものでレクチャーする – スライド • はじめる! Redmine (2015) http://www.slideshare.net/g_maeda/redmine-2015-54346755 – 書籍 • Redmine 実践ガイド、Redmineによるタスクマネジメント実践技法、 Redmine超入門、入門Redmine、ほか 15
- 16. 導入のヒント５：ピンチはチャンス プロジェクトのピンチは導入のチャンス • 危機感 – 現状の問題点を共有し、同じ方向を向く • 不安感を感じている – 情報共有、コミュニケーション、履歴の活用など、 安心できる理由を説明する • 閉塞感 – 協力すればより効率的になることを説明する 16
- 17. 導入のヒント６：プロセスの特徴 プロセスを実行するのは人 • 学習する – うまく指導すれば、効果的に経験を積める • リズム – 同じ作業を繰り返すとリズムが生まれ、負担が減る • 文化 – 組織的な行動により、標準化されていく 17
- 18. 未来へのヒント：ゴールは文化の徹底 プロセス改善はモデル重視と問題解決重視の間を 行き来しながら改善の経験値が上がるといわれる • モデル重視はTo beアプローチに相当する – 形骸化の壁と認証の壁がある • 問題解決重視はAs is アプローチに相当する – 制度化の壁がある ＊乘松聡「問題解決重視とモデル重視 ～組織に合ったプロセス改善モードを探す」 ,ソフトウェアプロセス改善カンファレンス2004. http://www.jaspic.org/event/2004/SepgJapan/proceedings/4A2.pdf 18
- 19. まとめ チケット駆動開発導入のヒントを示した – チケット駆動開発はプロセス改善 – 現場の負担を減らす – 習熟を促す – 効果を伝える – 効率的に導入する – ピンチはチャンス – プロセスを実行するのは人 =>改善する文化を育てよう 20