★テーマ
チケット駆動開発の本質
●スピーカー
小川 明彦 氏
阪井 誠 氏
●挑戦の道具としてのチケット駆動開発
○TiDDの基本
・アダプタぶるWF開発
・テーラリング
○ソフトウェア開発は常に挑戦
・環境、フレームワーク、ビジネスは日々進化している
・開発中にノウハウ、アイデア、気付きを蓄積し、共有し、活用しないといけない
・モチベーション
┗挑戦時の履歴をその後の開発につなげる
┗開発者の気付きをチケットに記録する
┗協調作業を支援してプロジェクトを活性化する
○チケット駆動開発
・チケットで障害、課題、タスクを管理する
・構成管理、Wiki、継続的統合などツールをプロジェクト管理で利用してコミュニケーション
・レポート、ロードマップ、ガントチャート等で管理出来る
○ツール連携とチケット
・構成管理、Wiki、CIツールなどをチケットに連携
○チケット駆動開発の効果
・ツールを有効活用してプロジェクトの負担を減らす
過去：
履歴の蓄積(経緯の確認、ノウハウの利用)
現在：
障害、課題、タスク、実行結果の管理
情報共有、自動化、コミュニケーション
未来：
計画、備忘録、リスクの見える化(ガントチャートを使ったり、マイルストーン毎にロードマップを作ったり)
○挑戦の道具としてのチケット駆動開発
・新しい環境、実装方法、アプリケーションに挑戦するには
┗気付いたことが共有されること
┗少ない経験が蓄積されること
┗蓄積した経験が活かせること
を考慮しないといけない
○テーラリング①
・気付いたことが共有されること
┗チケットが容易に起票出来るようにする
┗起票の権限をメンバーに与える
┗ワークフローの制限を少なくする
・チケットの種類や属性を増やしすぎない
┗考えなくていいようにする
┗記入項目を減らす
・リアルタイムに共有してモチベーションを高める
┗メール、RSS、Eclipse用のMylynpuraguin
┗コミュニケーションのタイムラグを減らす(書いてもなかなか読まれない・・・とかだとモチベーションも落ちるので)
○テーラリング②：
・少ない経験が蓄積されること
┗チケット駆動を習慣付ける
┗基本的な教育
┗メリットを感じさせる
┗備忘録としての利用(Redmineでプライベートに設定すると、自分だけに見えるチケットになる)
・利用に向けた支援
┗カスタムレポートの用意など環境整備(タスクだけ見えるようにする等)
┗アドバイスを目的としたチケットの棚卸し
┗ルールの整備
┗No Ticket, No, Commit!!をどこまで守るか、など
○テーラリング③
・蓄積した経験が生かされること
┗経験の種類に応じて整理する
┗一度だけの作業はチケットを起票する
┗手順やチェックリストはWikiにまとめる
○自律的なチーム
・サーバントリーダーシップ
┗コマンドコントロールを辞め、メンバーが能力を活かせるように支援する
・マイクロマネジメント
┗マイクロマネジメントを依存するようになり、自立性が失われる
┗ぬれぞうきんは絞らない
┗ガチガチの管理からは柔軟な発想は生まれない
○注意すべき点
・ルーチンワークで登録やチェックを忘れがち→粒度を小さくしてリズムを生む
・棚卸で実施漏れが防げるが自主性も大切
・クローズしにくいもの
○チケット駆動開発は
・プロジェクトの情報を集中管理
・自動化をコミュニケーション
●チケット駆動開発のフレームワーク
○チケット駆動で良く聴かれる質問
・似たような質問が多い
┗チケットの粒度
┗複数チームのタスク管理
・判断基準が暗黙値なので明確でない
┗現場のノウハウが形式値として共有されていない
1.体系化の方針
・ツールの説明を排除
┗ツールに依存しない
2.プラクティスをパターン言語の形式で表現
・現場の経験値を再利用出来る形にする
3.原則、価値観、プラクティスでまとめる
・開発フレームワークの作業仮説として提示
○Tiddの原則
・最初にチケットありき
┗SW開発の作業も課題も障害もチケットへ
┗チケットなしの作業不可(No Ticket, No Work)
○成果物は構成管理に従う
・プログラムや仕様書は構成管理へ
・議事録や報告書はWikiやチケット集計へ
○チケットとは
・タスク障害、課題、問い合わせ、要望
・製品の変更時に管理すべき対象プロセス
・チケットはワークフローで制御される
・チケットは成果物や仕様ではない
○構成管理とは
・ソフトウェア資産を記録する仕組み
┗バージョンは、ソフトウェア資産を確定させる日時
┗チケットはリリースされるまでのコミット履歴
○プラクティスとは
・現場で実証された実践技法
・パターン言語で表現してみる
○パターンの適用例 ～チケットの粒度に関する問題～
・あいまいなチケット
┗チケットがタスクではなく仕様書になっている
┗作業がよく分からない
・肥満児チケット
┗タスク分割が不十分
┗当初の見積もりよりも倍以上の工数がかかる
・放置されたチケット
┗チケットを細かくすればチケットは乱発されやすい
┗期日やリリースのバージョンが不明の物は今すぐ
○TiDDによるパラダイムシフト
・WFの場合は品質、コスト、納期は固定
・TiDDではスコープ(チケット)が出てくる
┗チケットの取捨選択でタスク管理する
○TiDDの運用サイクル
・チケットを出す→収集→実行→フィードバック→実行の反復
○小規模リリース
・小刻みに機能拡張しながら定期的にリリースして行く
・Velocity(開発速度)=イテレーション単位の平均消化チケット数
○開発のリズム
・チケットの作業に集中
┗割り込み作業はしない
・コミットのリズム
┗コミットと同時にチケットを閉じる
・定期的なリリース
・毎日の朝会
○開発謝意自己管理する勇気の基盤を与える
・作業の見える化がメンバー間の信頼関係を強化する
・リーダーは管理者から支援者へ変わる
No Ticket, No Work
No Ticket, No Commit
Iteration is Version
●まとめ
○パターン言語で現場の経験値を表現出来そう
・状況と問題によってプラクティスを使い分ける
・パターンで経験値の本質を取り出したい
○TiDDとAgile開発の親和性を説明出来そう
・透明性、小規模リリース、持続可能な開発ペース等
○プラクティスが生成的な特徴を表現したい
・単独のプラクティスから「品質」「効率」は出現しない
●感想
現在のプロジェクトでもRedmineを使用しているが、チケットを利用するとこれだけのことが出来るというのを再認識した。
本格的に実践するにはプロジェクト全体でしっかりと意識統一が必要だが、少しずつでも有効な部分は取り入れていきたい。
まずは個人でチケットの使い方を見直し、良く出来そうな部分は提案していってみようと思う。
アジャイルな開発において重要な要素だと思うので、参考にしたい。
チケット駆動開発の本質
●スピーカー
小川 明彦 氏
阪井 誠 氏
●挑戦の道具としてのチケット駆動開発
○TiDDの基本
・アダプタぶるWF開発
・テーラリング
○ソフトウェア開発は常に挑戦
・環境、フレームワーク、ビジネスは日々進化している
・開発中にノウハウ、アイデア、気付きを蓄積し、共有し、活用しないといけない
・モチベーション
┗挑戦時の履歴をその後の開発につなげる
┗開発者の気付きをチケットに記録する
┗協調作業を支援してプロジェクトを活性化する
○チケット駆動開発
・チケットで障害、課題、タスクを管理する
・構成管理、Wiki、継続的統合などツールをプロジェクト管理で利用してコミュニケーション
・レポート、ロードマップ、ガントチャート等で管理出来る
○ツール連携とチケット
・構成管理、Wiki、CIツールなどをチケットに連携
○チケット駆動開発の効果
・ツールを有効活用してプロジェクトの負担を減らす
過去：
履歴の蓄積(経緯の確認、ノウハウの利用)
現在：
障害、課題、タスク、実行結果の管理
情報共有、自動化、コミュニケーション
未来：
計画、備忘録、リスクの見える化(ガントチャートを使ったり、マイルストーン毎にロードマップを作ったり)
○挑戦の道具としてのチケット駆動開発
・新しい環境、実装方法、アプリケーションに挑戦するには
┗気付いたことが共有されること
┗少ない経験が蓄積されること
┗蓄積した経験が活かせること
を考慮しないといけない
○テーラリング①
・気付いたことが共有されること
┗チケットが容易に起票出来るようにする
┗起票の権限をメンバーに与える
┗ワークフローの制限を少なくする
・チケットの種類や属性を増やしすぎない
┗考えなくていいようにする
┗記入項目を減らす
・リアルタイムに共有してモチベーションを高める
┗メール、RSS、Eclipse用のMylynpuraguin
┗コミュニケーションのタイムラグを減らす(書いてもなかなか読まれない・・・とかだとモチベーションも落ちるので)
○テーラリング②：
・少ない経験が蓄積されること
┗チケット駆動を習慣付ける
┗基本的な教育
┗メリットを感じさせる
┗備忘録としての利用(Redmineでプライベートに設定すると、自分だけに見えるチケットになる)
・利用に向けた支援
┗カスタムレポートの用意など環境整備(タスクだけ見えるようにする等)
┗アドバイスを目的としたチケットの棚卸し
┗ルールの整備
┗No Ticket, No, Commit!!をどこまで守るか、など
○テーラリング③
・蓄積した経験が生かされること
┗経験の種類に応じて整理する
┗一度だけの作業はチケットを起票する
┗手順やチェックリストはWikiにまとめる
○自律的なチーム
・サーバントリーダーシップ
┗コマンドコントロールを辞め、メンバーが能力を活かせるように支援する
・マイクロマネジメント
┗マイクロマネジメントを依存するようになり、自立性が失われる
┗ぬれぞうきんは絞らない
┗ガチガチの管理からは柔軟な発想は生まれない
○注意すべき点
・ルーチンワークで登録やチェックを忘れがち→粒度を小さくしてリズムを生む
・棚卸で実施漏れが防げるが自主性も大切
・クローズしにくいもの
○チケット駆動開発は
・プロジェクトの情報を集中管理
・自動化をコミュニケーション
●チケット駆動開発のフレームワーク
○チケット駆動で良く聴かれる質問
・似たような質問が多い
┗チケットの粒度
┗複数チームのタスク管理
・判断基準が暗黙値なので明確でない
┗現場のノウハウが形式値として共有されていない
1.体系化の方針
・ツールの説明を排除
┗ツールに依存しない
2.プラクティスをパターン言語の形式で表現
・現場の経験値を再利用出来る形にする
3.原則、価値観、プラクティスでまとめる
・開発フレームワークの作業仮説として提示
○Tiddの原則
・最初にチケットありき
┗SW開発の作業も課題も障害もチケットへ
┗チケットなしの作業不可(No Ticket, No Work)
○成果物は構成管理に従う
・プログラムや仕様書は構成管理へ
・議事録や報告書はWikiやチケット集計へ
○チケットとは
・タスク障害、課題、問い合わせ、要望
・製品の変更時に管理すべき対象プロセス
・チケットはワークフローで制御される
・チケットは成果物や仕様ではない
○構成管理とは
・ソフトウェア資産を記録する仕組み
┗バージョンは、ソフトウェア資産を確定させる日時
┗チケットはリリースされるまでのコミット履歴
○プラクティスとは
・現場で実証された実践技法
・パターン言語で表現してみる
○パターンの適用例 ～チケットの粒度に関する問題～
・あいまいなチケット
┗チケットがタスクではなく仕様書になっている
┗作業がよく分からない
・肥満児チケット
┗タスク分割が不十分
┗当初の見積もりよりも倍以上の工数がかかる
・放置されたチケット
┗チケットを細かくすればチケットは乱発されやすい
┗期日やリリースのバージョンが不明の物は今すぐ
○TiDDによるパラダイムシフト
・WFの場合は品質、コスト、納期は固定
・TiDDではスコープ(チケット)が出てくる
┗チケットの取捨選択でタスク管理する
○TiDDの運用サイクル
・チケットを出す→収集→実行→フィードバック→実行の反復
○小規模リリース
・小刻みに機能拡張しながら定期的にリリースして行く
・Velocity(開発速度)=イテレーション単位の平均消化チケット数
○開発のリズム
・チケットの作業に集中
┗割り込み作業はしない
・コミットのリズム
┗コミットと同時にチケットを閉じる
・定期的なリリース
・毎日の朝会
○開発謝意自己管理する勇気の基盤を与える
・作業の見える化がメンバー間の信頼関係を強化する
・リーダーは管理者から支援者へ変わる
No Ticket, No Work
No Ticket, No Commit
Iteration is Version
●まとめ
○パターン言語で現場の経験値を表現出来そう
・状況と問題によってプラクティスを使い分ける
・パターンで経験値の本質を取り出したい
○TiDDとAgile開発の親和性を説明出来そう
・透明性、小規模リリース、持続可能な開発ペース等
○プラクティスが生成的な特徴を表現したい
・単独のプラクティスから「品質」「効率」は出現しない
●感想
現在のプロジェクトでもRedmineを使用しているが、チケットを利用するとこれだけのことが出来るというのを再認識した。
本格的に実践するにはプロジェクト全体でしっかりと意識統一が必要だが、少しずつでも有効な部分は取り入れていきたい。
まずは個人でチケットの使い方を見直し、良く出来そうな部分は提案していってみようと思う。
アジャイルな開発において重要な要素だと思うので、参考にしたい。