Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
チケット駆動開発の
知っておくべき大切な事
株式会社SRA
阪井 誠
2013年9月2日
関西事業部移転
自己紹介
• 阪井誠(さかば、Twitter: @sakaba37)
• ソフトウェアプロセス、チケット駆動開発(TiDD)、
アジャイルに興味を持つ「プロセスプログラマー」
• 現場からコンサル・研究まで、論文、書籍、雑誌など
2
レ
ビ
ュ...
ソフトウェア開発の大切なこと
• 技術のコンテキスト(背景)を考える
– パラダイムシフト(生産性の向上、リスクの変化、etc.)
– 弁証法的な視点(補完関係・対立構造、揺り戻し)
• 現実の問題のバランスをとる
– 管理と自律
– 組織とチ...
目次
• ソフトウェア開発の大切なこと
• コンテキスト
– パラダイムシフト
– 日本のソフトウェア管理・開発の歴史
• チケット駆動開発
– はじまり、バージョン管理とチケット
– ツール連携とチケット・コミュニケーション支援
– 事例
•...
見
積
も
り
の
ば
ら
つ
き
時間
パラダイムシフト
• 期間が短くばらつきが大きくなった
不確実性コーンの変化
ソフトウェア業界のパラダイムシフト
• 1990年代に始まった
• ネオダマという標語によってソフトウェアハウスは
SI erに変わった
• 高機能ソフトの開発が容易になり、自由度が増し
た反面、リスクが増えた
• 技術者の守備範囲はソフトから...
阪井,松本,鳥居, "ダウンサイジング時代のプロセス改善モデル", ソフトウェアシンポジウム'95論文集,1995.
1995年の発表より
技術者の責任範囲
• 開発の効率化とともに責任範囲は広がった
– ビジネスは広がったが純粋なソフトウェア開発が
減少した
8
ソフトウェア
ハードウェア
ビジネス
ネットワーク
ネオダマ Web クラウド
要求の不安定さ
• ハンフリーは機能・インタフェース・環境の変更は
管理されないと開発は不安定になるとした
• Watts S. Humphrey, ソフトウェアプロセス成熟度の改善, 日科技連, 1991.
未知の要求
知っているつもりが、
...
日本のソフトウェア管理・開発の歴史
– 日本の従来企業では組織的な管理活動が普及したが、
チームの開発支援が遅れている
– ゲーム・Webサービスなど新規ビジネスを中心にアジャイ
ル開発の導入が進んでいる
10
組織的管理 プロジェクト管理 現...
日本のソフトウェア産業の特徴
• ビジネスとの距離が離れている
– 1990年代のRADのスキップにより、ビジネス価値、プロトタイ
プ、マルチリリースへの対応が遅れた
• 既存の業務で実現している細かな要望が多い
– 新規開発が少ない。リプレス...
日本のソフトウェア管理・開発の歴史
求められるもの
• ビジネスへの適応力(変化への対応、自律性)
• 組織とチームの全体最適(オープンなプロジェクト運営)
12
組織的管理 プロジェクト管理 現場の自律性
1980s 成果物標準化 メトリクス...
具体的な課題
• プロセス改善がレベル3(定義されたプロセス)で
止まり、チームの自律性が低い
– チームの能力が生かせていない
– 情報共有に基づく、チームの自律的な行動が必要
• アジャイル開発が組織的に可視化されていない
– チームの個別...
統率の
とれた
組
織
の
特
性
自律的
小 変更量 大
チケット駆動開発による開発法の拡張
アダプタブル
ウォーターフォール
アジャイル開発
ウォーター
フォール型開発
TiDD
TiDD
TiDD
アジャイル
チケット駆動開発TiDD
15
変更リスクへの対応力
* [#TiDD] アジャイル風開発ラフシミュレーション(ソフトウェアさかば)
http://sakaba.cocolog-nifty.com/sakaba/2013/03/tidd-14ae.html
16
変化する仕様と作業の
管理が必要
目次
• ソフトウェア開発の大切なこと
• コンテキスト
– パラダイムシフト
– 日本のソフトウェア管理・開発の歴史
• チケット駆動開発
– はじまり、バージョン管理とチケット
– ツール連携とチケット・コミュニケーション支援
– 事例
•...
TiDDのはじまり
• masuidrive的プロジェクトの方針(2007)
http://blog.masuidrive.jp/index.php/2007/07/11/masuidrive-working-style/
• まちゅ, 「もう...
チケット駆動開発
• ITS(BTS)のチケットで障害、課題、タスクを
管理して個人のタスクとプロジェクトを管理する
• 構成管理、Wiki、継続的統合などツールを
チケットに連携させて自動化する
• プロジェクトの情報をチケットに関連付けて
...
バージョン管理とチケット(仕様変更)
20
仕様変更
タスク1
タスク2
新規追加 更新 更新 タグ
競合チェックアウト アップデート
解決
関連タスク
トレーサ
ビリティ
バージョン管理とチケット(バグ)
21
バグ
更新
更新
ブランチ
ツール連携
22
ITS
バージョン管理
ツール
コメント
作業、担当、
ステータス、進捗
開始、終了
refs #チケット番号
fixes #チケット番号
チケットによる管理
チケットシステム(ITS)
親チケット
障害・課題・タスク
継続チケット
関連チケット
プロジェクト
ステータス
種類とロール毎のワークフロー
レポート、カスタムクエリ、
ロードマップ、ガントチャート
等で参照できる
ツール連携とチケット
リビジョンリビジョンリビジョンリビジョン
バージョン管理
CIツール チケットシステム(ITS)
親プロジェクト
親タスク/ストーリー
タスク
継続タスク
関連タスクWiki
プロジェクト
ステータス
チケットの種類とロー...
チケットによるコミュニケーションの支援
リビジョンリビジョンリビジョンリビジョン
バージョン管理
CIツール チケットシステム(ITS)
親プロジェクト
親タスク/ストーリー
タスク
継続タスク
関連タスクWiki
プロジェクト
ステータス
チ...
TiDDの
事例
26
現場の自律とリスク低減への道
チケット駆動開発の事例
パラダイムシフトを生き抜くには
• 環境、フレームワーク、ユーザーインタフェース、ビジ
ネスは日々変化している
• ソフトウェア開発は、常に挑戦!
• 開発中にノウハウやアイデア、気づきを蓄積し、共有
し、活用しないといけない
チケット駆動開発...
TiDDによる自律とリスク低減の実現
• 開発時の履歴をその後の開発につなげます
• 開発者の気付きをチケットに記録します
• 協調作業を支援してプロジェクトを活性化します
28
ハーケン(釘)
カラビナ(止め具)
ザイル(ロープ)
チケット駆動開発の効果
ツールを有効活用してプロジェクトの負担を減らす
• ツールが想定するプロジェクトに近づく
• 過去:
– 履歴の蓄積(経緯の確認、ノウハウの利用)
• 現在:
– 障害、課題、タスク、実行結果の管理
– 情報共有、自動化...
事例の概要
• 文教パッケージのカスタマイズ(最大8人x1年)
o 短納期 & 仕様の決定遅れ・変更
o スキルは高いが経験者が少ない(リーダは途中交代)
o オープンフレームワークの初めての組み合わせ
(サブシステム、ミドルウェアのバージョン...
オープンなフレームワークの苦しみ
長所
• 同じようなコードが減る
• 個別の業務要件に対する固有の開発だけでよい
短所
• お約束が多い複雑な作業で、気が抜けない
• 工夫できる余地が少ない
• 少人数で大規模なシステムが作れてしまう
• セ...
TiDDの実施方式
• アダプタブルウォーターフォール(補完型TiDD)
• WBSと併用(と言っても更新作業は全てチケットあり)
• オープンな運用
• だれでもチケットが作成できる
• システムテスト以降
• システム全体
• メンバー全員...
チケット駆動開発の導入
• 宣言と実行
「 バグだけではなく、ソースを触るときや、WBSにない作業をするとき
は、チケットを登録してください!」
• 環境の準備
o レポート(チケットの一覧)の作成
 bugのみ、 taskのみ、 その他、な...
結果
• チケットの数(BUG以外)
o システムテスト:31
o 本番環境構築:42
 データの準備、環境準備、BUG関連で増えた作業、
細かな仕様変更など、手順書にない1回だけの作業
• 作業漏れ減少!納期までに作業が完了!
(知らないこ...
目が輝いた!
サブリーダ(クラス)なのに遠慮をして
いたメンバーが、生き生きしだした
• 「チケットを切ってもいいですか?」
⇒ 義務的な作業からの解放
• 「チケットを切っておかないと忘れてしまう!」
⇒ すぐに使いこなしていた
• 「ちゃん...
事例のまとめ
• システムテスト以降にTiDDを導入
• 備忘録のつもりで気づいたことをチケット化した
• 手順はWikiにまとめた
• 計画外の作業を管理できた
• 作業を見える化することで
コミュニケーションが向上した
• メンバーが前向き...
事例からの学び
• 新しい環境、実装方法、アプリケーションに挑戦
するには、以下の点を考慮しないといけない
– 気づいたことが共有されること
– 少ない経験が蓄積されること
– 蓄積した経験が生かせること
ふさわしいチケット駆動開発の運用方法...
テーラリング1:
気づいたことが共有されること
• チケットが容易に起票できるようにする
– 起票の権限をメンバーに与える
– ワークフローの制限を少なくする
• チケットの種類や属性を増やしすぎない
– 考えなくて良い様にする
– 記入項目を...
テーラリング2:
少ない経験が蓄積されること
• チケット駆動を習慣づける
– 基本的な教育
– メリットを感じさせる
– 備忘録としての利用
• 利用に向けた支援
– カスタムレポートの用意など環境整備
– アドバイスのための棚卸し
– ルー...
テーラリング3:
蓄積した経験が生かされること
• 経験の種類に応じて整理する
– 一度だけの作業はチケットを起票する
– 手順やチェックリストはWikiにまとめる
• 書きっぱなしのチケットを防ぐ
– 完了条件を明確にする
– 適切な棚卸しを...
課題と可能性
• CBR(Case Based Reasoning)の経験による問題
解決する際にはインデックスが重要とされている
– 現状では日々の情報整理が必要
– チケット駆動開発の事例報告が少ない
– より多くの事例を集めて整理したい
...
目次
• ソフトウェア開発の大切なこと
• コンテキスト
– パラダイムシフト
– 日本のソフトウェア管理・開発の歴史
• チケット駆動開発
– はじまり、バージョン管理とチケット
– ツール連携とチケット・コミュニケーション支援
– 事例
•...
バランスと戦略
• 全てのモデルは単純化されている
– 単純化できないことに気を付ける
– 多様性のない開発は脆弱で非効率
– 全体主義でも部分最適でもなく、全体最適のバランスを
目指す
• 能力を最大限に発揮させる*
– 管理だけではリスクを...
対立から協調へ
• 組織とチームには、管理の都合と開発の都合の
せめぎあいがある
– 開発標準は肥大化する傾向にあり、テーラリングの
許容範囲は狭くなりがち
– プロジェクトはゴールに向かって暴走しがち
– 情報共有に基づく合理的な判断、組織内...
対立から協調へ
• 防水透湿性素材
– チームを守る防火壁*は途中経過も隠ぺいする
– チケットシステムや途中の成果物を公開することで、
組織的な活動とのバランスをとる
* James O. Coplien他,組織パターン,2013.
45
組...
自律と支援
リーダーシップは国により異なる*
• 目標達成リーダーシップ
– 日本では「部下が最大限に働くことを要求」
– アメリカでは「契約を順守することを要求」
• 人間関係円滑化リーダーシップ
– 日本では「個人的な問題にも気を使う」
–...
自律的なチーム作り
• サーバントリーダーシップ
– コマンドコントロールをやめ、
メンバーが能力を生かせるように支援する
• マクロマネジメント
– マイクロマネジメントをすると依存するようになり、
自律性が失われる
• 濡れぞうきんはしぼら...
実践のバランスと視点
• バランス
– パラダイムシフト・効率化
• 大きく変えるか、小さく変えるか
• 大きく変えるときは一つずつ成功体験を積み上げる
– 暗黙知・形式知
• 暗黙知だけでは再利用が難しい
• 形式知だけでは伝わらない(TiD...
実践のバランスと視点
• 平準化とリズム
– 平準化により作業が安定すればリズムが生まれ、習
熟と効率化が可能になる
• 能力発揮:負担軽減・情報共有
– 無駄をなくし、負担を軽減することで、より高度な作業
が可能になる
– 情報共有はノウハウ...
例:放置されるチケット
• チケットがルーチンワークでないと登録を忘れがち
• メリットと必然、チケットへの依存、リズム
• 他のチケットがないときにチェックを忘れて実施漏れ
• 粒度の大きいチケットの後で発生
• 粒度が小さいとリズムが生まれ...
おわりに
• 多様性のない開発は脆弱で非効率
– バランスと戦略がポイント
• パラダイムシフトによりリスクは増え続けている
– 自律的なチーム作りが重要
• チケット駆動開発
– プロジェクトの情報を集中管理
– 気づきや経験を蓄積して活用
...
エンジニアは、身につけた理論と経験を基礎に、
各種制約を考慮して工夫することで成長します。
良さそうな開発方法だからとそのまま取り入れて、
工夫しないのでは進歩しません。
チケット駆動開発は、より良いプロジェクトを目指す
際の礎(いしずえ)にな...
チケット駆動開発の
知っておくべき大切な事
おわり
Prochain SlideShare
Chargement dans…5
×

チケット駆動開発の大切なこと(バランス編)

11 262 vues

Publié le

2013年8月24日GxP様 無料セミナー『SIの現場で使えるチケット駆動開発』での講演資料

Publié dans : Sports
  • Soyez le premier à commenter

チケット駆動開発の大切なこと(バランス編)

  1. 1. チケット駆動開発の 知っておくべき大切な事 株式会社SRA 阪井 誠 2013年9月2日 関西事業部移転
  2. 2. 自己紹介 • 阪井誠(さかば、Twitter: @sakaba37) • ソフトウェアプロセス、チケット駆動開発(TiDD)、 アジャイルに興味を持つ「プロセスプログラマー」 • 現場からコンサル・研究まで、論文、書籍、雑誌など 2 レ ビ ュ ー NEW NEW NEW
  3. 3. ソフトウェア開発の大切なこと • 技術のコンテキスト(背景)を考える – パラダイムシフト(生産性の向上、リスクの変化、etc.) – 弁証法的な視点(補完関係・対立構造、揺り戻し) • 現実の問題のバランスをとる – 管理と自律 – 組織とチーム • 戦略的に全体最適をねらう – 防水透湿性素材 – サーバントリーダーシップ – 実践のバランスと視点 3
  4. 4. 目次 • ソフトウェア開発の大切なこと • コンテキスト – パラダイムシフト – 日本のソフトウェア管理・開発の歴史 • チケット駆動開発 – はじまり、バージョン管理とチケット – ツール連携とチケット・コミュニケーション支援 – 事例 • バランスと戦略 – 対立から協調へ(防水透湿性素材) – 自律と支援(サーバントリーダーシップ) – 実践のバランスと視点 4
  5. 5. 見 積 も り の ば ら つ き 時間 パラダイムシフト • 期間が短くばらつきが大きくなった 不確実性コーンの変化
  6. 6. ソフトウェア業界のパラダイムシフト • 1990年代に始まった • ネオダマという標語によってソフトウェアハウスは SI erに変わった • 高機能ソフトの開発が容易になり、自由度が増し た反面、リスクが増えた • 技術者の守備範囲はソフトからシステムになり、 今、ビジネスに広がりつつある • 常に新しい分野へのチャレンジが求められるよう になった 6
  7. 7. 阪井,松本,鳥居, "ダウンサイジング時代のプロセス改善モデル", ソフトウェアシンポジウム'95論文集,1995. 1995年の発表より
  8. 8. 技術者の責任範囲 • 開発の効率化とともに責任範囲は広がった – ビジネスは広がったが純粋なソフトウェア開発が 減少した 8 ソフトウェア ハードウェア ビジネス ネットワーク ネオダマ Web クラウド
  9. 9. 要求の不安定さ • ハンフリーは機能・インタフェース・環境の変更は 管理されないと開発は不安定になるとした • Watts S. Humphrey, ソフトウェアプロセス成熟度の改善, 日科技連, 1991. 未知の要求 知っているつもりが、 使ってみて違いに気 づく 誤解された要求 実現するために必 要な詳細を理解して いない 不安定な要求 大体わかっているか もしれないが、詳細 は流動的 • プロトタイプ、分離、段階的な開発など、アジャイル やオブジェクト指向につながる提案をしている
  10. 10. 日本のソフトウェア管理・開発の歴史 – 日本の従来企業では組織的な管理活動が普及したが、 チームの開発支援が遅れている – ゲーム・Webサービスなど新規ビジネスを中心にアジャイ ル開発の導入が進んでいる 10 組織的管理 プロジェクト管理 現場の自律性 1980s 成果物標準化 メトリクス QCサークル 1990s CMM/CMMI ISO9000 PMBOK (TSP) (People CMM) (PSP) 2000s (アジャイルと規律) XP、ファシリテーション (他のアジャイル開発) 2010s (ISO/IEC29110) スクラム リーン
  11. 11. 日本のソフトウェア産業の特徴 • ビジネスとの距離が離れている – 1990年代のRADのスキップにより、ビジネス価値、プロトタイ プ、マルチリリースへの対応が遅れた • 既存の業務で実現している細かな要望が多い – 新規開発が少ない。リプレスは一括 (バグまで同じに、) • DOAの普及によるオブジェクト指向普及の遅れ* – アジャイル開発向きでない組織構造 (「善は急げ」より「急がば回れ」) *児玉,UMLモデリングの本質 第2版 11
  12. 12. 日本のソフトウェア管理・開発の歴史 求められるもの • ビジネスへの適応力(変化への対応、自律性) • 組織とチームの全体最適(オープンなプロジェクト運営) 12 組織的管理 プロジェクト管理 現場の自律性 1980s 成果物標準化 メトリクス QCサークル 1990s CMM/CMMI ISO9000 PMBOK (TSP) (People CMM) (PSP) 2000s (アジャイルと規律) XP、ファシリテーション (他のアジャイル開発) 2010s (ISO/IEC29110) スクラム リーンチケット駆動開発
  13. 13. 具体的な課題 • プロセス改善がレベル3(定義されたプロセス)で 止まり、チームの自律性が低い – チームの能力が生かせていない – 情報共有に基づく、チームの自律的な行動が必要 • アジャイル開発が組織的に可視化されていない – チームの個別性が高く、複数プロジェクトを一貫して 管理することが困難 – 電子化された可視化情報が必要 =>チケット駆動開発なら解決できます! 13
  14. 14. 統率の とれた 組 織 の 特 性 自律的 小 変更量 大 チケット駆動開発による開発法の拡張 アダプタブル ウォーターフォール アジャイル開発 ウォーター フォール型開発 TiDD TiDD TiDD アジャイル チケット駆動開発TiDD
  15. 15. 15 変更リスクへの対応力 * [#TiDD] アジャイル風開発ラフシミュレーション(ソフトウェアさかば) http://sakaba.cocolog-nifty.com/sakaba/2013/03/tidd-14ae.html
  16. 16. 16 変化する仕様と作業の 管理が必要
  17. 17. 目次 • ソフトウェア開発の大切なこと • コンテキスト – パラダイムシフト – 日本のソフトウェア管理・開発の歴史 • チケット駆動開発 – はじまり、バージョン管理とチケット – ツール連携とチケット・コミュニケーション支援 – 事例 • バランスと戦略 – 対立から協調へ(防水透湿性素材) – 自律と支援(サーバントリーダーシップ) – 実践のバランスと視点 17
  18. 18. TiDDのはじまり • 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 • Shibuya.Tracキックオフ • XPJUG関西 TiDD勉強会発足 (2008) • 「Redmineによるタスクマネジメント実践技法」(2010) • RxTstudy、Shinagawa.Redmine(2011) • 「チケット駆動開発」(2012) : 18 Tracブーム チケット駆動開発 誕生
  19. 19. チケット駆動開発 • ITS(BTS)のチケットで障害、課題、タスクを 管理して個人のタスクとプロジェクトを管理する • 構成管理、Wiki、継続的統合などツールを チケットに連携させて自動化する • プロジェクトの情報をチケットに関連付けて 管理することで、コミュニケーションを支援する  現場による、現場のための改善活動  プロジェクトの関心事の電子化 19
  20. 20. バージョン管理とチケット(仕様変更) 20 仕様変更 タスク1 タスク2 新規追加 更新 更新 タグ 競合チェックアウト アップデート 解決 関連タスク トレーサ ビリティ
  21. 21. バージョン管理とチケット(バグ) 21 バグ 更新 更新 ブランチ
  22. 22. ツール連携 22 ITS バージョン管理 ツール コメント 作業、担当、 ステータス、進捗 開始、終了 refs #チケット番号 fixes #チケット番号
  23. 23. チケットによる管理 チケットシステム(ITS) 親チケット 障害・課題・タスク 継続チケット 関連チケット プロジェクト ステータス 種類とロール毎のワークフロー レポート、カスタムクエリ、 ロードマップ、ガントチャート 等で参照できる
  24. 24. ツール連携とチケット リビジョンリビジョンリビジョンリビジョン バージョン管理 CIツール チケットシステム(ITS) 親プロジェクト 親タスク/ストーリー タスク 継続タスク 関連タスクWiki プロジェクト ステータス チケットの種類とロール毎のワークフロー 参照 実行結果 チケット参照 連携 参照 連携 構成管理、Wiki、 CIツールなどを チケットに連携
  25. 25. チケットによるコミュニケーションの支援 リビジョンリビジョンリビジョンリビジョン バージョン管理 CIツール チケットシステム(ITS) 親プロジェクト 親タスク/ストーリー タスク 継続タスク 関連タスクWiki プロジェクト ステータス チケットの種類とロール毎のワークフロー 参照 実行結果 チケット参照 連携 参照 連携 議論や更新を メール、RSS、 プラグインで 通知できる
  26. 26. TiDDの 事例 26 現場の自律とリスク低減への道 チケット駆動開発の事例
  27. 27. パラダイムシフトを生き抜くには • 環境、フレームワーク、ユーザーインタフェース、ビジ ネスは日々変化している • ソフトウェア開発は、常に挑戦! • 開発中にノウハウやアイデア、気づきを蓄積し、共有 し、活用しないといけない チケット駆動開発を活用して、現場の自律とリスクの低 減を実現した事例を紹介します 27
  28. 28. TiDDによる自律とリスク低減の実現 • 開発時の履歴をその後の開発につなげます • 開発者の気付きをチケットに記録します • 協調作業を支援してプロジェクトを活性化します 28 ハーケン(釘) カラビナ(止め具) ザイル(ロープ)
  29. 29. チケット駆動開発の効果 ツールを有効活用してプロジェクトの負担を減らす • ツールが想定するプロジェクトに近づく • 過去: – 履歴の蓄積(経緯の確認、ノウハウの利用) • 現在: – 障害、課題、タスク、実行結果の管理 – 情報共有、自動化、コミュニケーション • 未来: – 計画、備忘録、リスクの見える化 29
  30. 30. 事例の概要 • 文教パッケージのカスタマイズ(最大8人x1年) o 短納期 & 仕様の決定遅れ・変更 o スキルは高いが経験者が少ない(リーダは途中交代) o オープンフレームワークの初めての組み合わせ (サブシステム、ミドルウェアのバージョン) o 義務感と不安、重苦しい雰囲気、閉塞感、、、 o 守りに入るので、コミュニケーションが悪い システムテストの時期になると、計画外の環境構築やリリース準備 作業が明らかになった(環境に関連するバグも、、、) ⇒ そうだ!チケット駆動開発をしよう! 30
  31. 31. オープンなフレームワークの苦しみ 長所 • 同じようなコードが減る • 個別の業務要件に対する固有の開発だけでよい 短所 • お約束が多い複雑な作業で、気が抜けない • 工夫できる余地が少ない • 少人数で大規模なシステムが作れてしまう • セキュリティ対策で実行環境の構成は日々変化 ⇒ 煩雑なのに情報が少ない、、、大変! 31
  32. 32. TiDDの実施方式 • アダプタブルウォーターフォール(補完型TiDD) • WBSと併用(と言っても更新作業は全てチケットあり) • オープンな運用 • だれでもチケットが作成できる • システムテスト以降 • システム全体 • メンバー全員 • trac(単独) ・・・ SRA共通開発環境(trac,subversion,mailmanの仮想環境)
  33. 33. チケット駆動開発の導入 • 宣言と実行 「 バグだけではなく、ソースを触るときや、WBSにない作業をするとき は、チケットを登録してください!」 • 環境の準備 o レポート(チケットの一覧)の作成  bugのみ、 taskのみ、 その他、など o 権限の追加  tracの権限の設定が堅かったので、チケットを修正できるように 全ての権限を与えた(リスクを考慮して設定してください) • 教育 • パッケージチームとのQAの経験はあった 33 ハーケン(釘) カラビナ(止め具) ザイル(ロープ)
  34. 34. 結果 • チケットの数(BUG以外) o システムテスト:31 o 本番環境構築:42  データの準備、環境準備、BUG関連で増えた作業、 細かな仕様変更など、手順書にない1回だけの作業 • 作業漏れ減少!納期までに作業が完了! (知らないこと、気付かないことはできませんでした、、、orz) それ以外にも、メンバーに変化が、、、 34
  35. 35. 目が輝いた! サブリーダ(クラス)なのに遠慮をして いたメンバーが、生き生きしだした • 「チケットを切ってもいいですか?」 ⇒ 義務的な作業からの解放 • 「チケットを切っておかないと忘れてしまう!」 ⇒ すぐに使いこなしていた • 「ちゃんとクローズしてね」 ⇒ 他の人に指導をしていた! • 「残っているチケットが多くてわかりにくいから整理 しますね」 ⇒ 今後のことも考えている
  36. 36. 事例のまとめ • システムテスト以降にTiDDを導入 • 備忘録のつもりで気づいたことをチケット化した • 手順はWikiにまとめた • 計画外の作業を管理できた • 作業を見える化することで コミュニケーションが向上した • メンバーが前向きになり、 プロジェクトが元気になった 36
  37. 37. 事例からの学び • 新しい環境、実装方法、アプリケーションに挑戦 するには、以下の点を考慮しないといけない – 気づいたことが共有されること – 少ない経験が蓄積されること – 蓄積した経験が生かせること ふさわしいチケット駆動開発の運用方法が必要 37
  38. 38. テーラリング1: 気づいたことが共有されること • チケットが容易に起票できるようにする – 起票の権限をメンバーに与える – ワークフローの制限を少なくする • チケットの種類や属性を増やしすぎない – 考えなくて良い様にする – 記入項目を減らす • リアルタイムに共有してモチベーションを高める – メール、RSS、Eclipseとの連携 – コミュニケーションのタイムラグ減ると利用が増える 38
  39. 39. テーラリング2: 少ない経験が蓄積されること • チケット駆動を習慣づける – 基本的な教育 – メリットを感じさせる – 備忘録としての利用 • 利用に向けた支援 – カスタムレポートの用意など環境整備 – アドバイスのための棚卸し – ルールの整備 (“No Ticket, No, Commit!!”をどこまで守るか、など) 39 ハーケン(釘) カラビナ(止め具) ザイル(ロープ)
  40. 40. テーラリング3: 蓄積した経験が生かされること • 経験の種類に応じて整理する – 一度だけの作業はチケットを起票する – 手順やチェックリストはWikiにまとめる • 書きっぱなしのチケットを防ぐ – 完了条件を明確にする – 適切な棚卸しをする • 発想力・提案力の向上 – 棚卸しの頻度を増やしすぎない – 自律的なチーム 40
  41. 41. 課題と可能性 • CBR(Case Based Reasoning)の経験による問題 解決する際にはインデックスが重要とされている – 現状では日々の情報整理が必要 – チケット駆動開発の事例報告が少ない – より多くの事例を集めて整理したい • チケットシステムの活用でリスクが低減できる 可能性がある – ソフトウェア開発は常に挑戦だと認識する – チケット駆動開発を活用する – 発想力・提案力のあるチーム作りをする 41
  42. 42. 目次 • ソフトウェア開発の大切なこと • コンテキスト – パラダイムシフト – 日本のソフトウェア管理・開発の歴史 • チケット駆動開発 – はじまり、バージョン管理とチケット – ツール連携とチケット・コミュニケーション支援 – 事例 • バランスと戦略 – 対立から協調へ(防水透湿性素材) – 自律と支援(サーバントリーダーシップ) – 実践のバランスと視点 42
  43. 43. バランスと戦略 • 全てのモデルは単純化されている – 単純化できないことに気を付ける – 多様性のない開発は脆弱で非効率 – 全体主義でも部分最適でもなく、全体最適のバランスを 目指す • 能力を最大限に発揮させる* – 管理だけではリスクをカバーできない – 早期発見と戦略的解決には、自律を促す管理が必要 • 実践のバランスと視点が重要 * W・ハンフリー, TSP ガイドブック:リーダー編,翔泳社, 2007. 43
  44. 44. 対立から協調へ • 組織とチームには、管理の都合と開発の都合の せめぎあいがある – 開発標準は肥大化する傾向にあり、テーラリングの 許容範囲は狭くなりがち – プロジェクトはゴールに向かって暴走しがち – 情報共有に基づく合理的な判断、組織内での協調、 チームの保護が必要 44 組織 チーム マネージャ SEPG、SQA、 PO リーダー (SQA) SM 開発者 集合性(かや) P.30* 私たちが、何かを行動に移 すとき、実は、「かや」の行 動の一部を演じている *杉万,「グループ ダイナミックス入門」 , 世界思想社,2013.
  45. 45. 対立から協調へ • 防水透湿性素材 – チームを守る防火壁*は途中経過も隠ぺいする – チケットシステムや途中の成果物を公開することで、 組織的な活動とのバランスをとる * James O. Coplien他,組織パターン,2013. 45 組織 チーム 成果物 チケット 進捗 メトリクス(尺度) トレーサビリティ ・門番 ・プロダクトの主導者 ・防火壁 ・プライベートな パージョニング ・スタンドアップ ミーティング ・スケジュールを 小分けにする ・ワークキュー・聴衆の参加
  46. 46. 自律と支援 リーダーシップは国により異なる* • 目標達成リーダーシップ – 日本では「部下が最大限に働くことを要求」 – アメリカでは「契約を順守することを要求」 • 人間関係円滑化リーダーシップ – 日本では「個人的な問題にも気を使う」 – アメリカでは「上司が首を突っ込んではいけない」 • 良きリーダー – 日米では、上記2種類のリーダシップが必要 – 中国では「徳(仁徳)のリーダーシップが必要」 *杉万,「グループダイナミックス入門」 , 世界思想社,2013. 46 ゴールを示して、 能力を最大限に 発揮させる 細かなことは 言わないで、 気を使う 責任を持つ 親分肌
  47. 47. 自律的なチーム作り • サーバントリーダーシップ – コマンドコントロールをやめ、 メンバーが能力を生かせるように支援する • マクロマネジメント – マイクロマネジメントをすると依存するようになり、 自律性が失われる • 濡れぞうきんはしぼらない – 本田宗一郎氏がIIJ鈴木幸一社長に送った言葉 – ガチガチの管理からは柔軟な発想は生まれない 47
  48. 48. 実践のバランスと視点 • バランス – パラダイムシフト・効率化 • 大きく変えるか、小さく変えるか • 大きく変えるときは一つずつ成功体験を積み上げる – 暗黙知・形式知 • 暗黙知だけでは再利用が難しい • 形式知だけでは伝わらない(TiDDには長い朝会が必要) – ツールによる自動化・ 人中心の支援 • ツールによる自動化は、手段が目的化しやすい • 人中心の支援は無駄な作業に注意し、自動化も考える 48
  49. 49. 実践のバランスと視点 • 平準化とリズム – 平準化により作業が安定すればリズムが生まれ、習 熟と効率化が可能になる • 能力発揮:負担軽減・情報共有 – 無駄をなくし、負担を軽減することで、より高度な作業 が可能になる – 情報共有はノウハウを蓄積し、再発明を防止する • ジャストインタイム – 不要な情報は管理の負担。情報は必要最低限に絞る – 選択肢を残すべく、決定をなるべく遅らせることも必要 49
  50. 50. 例:放置されるチケット • チケットがルーチンワークでないと登録を忘れがち • メリットと必然、チケットへの依存、リズム • 他のチケットがないときにチェックを忘れて実施漏れ • 粒度の大きいチケットの後で発生 • 粒度が小さいとリズムが生まれて、発生しにくい • 棚卸のバランス • 防げるが自主性も大切!「チケット見てる?」 • クローズしにくいもの (担当がない、チェックリスト的) • 課題、リスクに多い。棚卸し、 Wikiを利用する • 気が付かないことはチケットにできない • 自由な雰囲気、経験者への依頼、情報収集が必要 50
  51. 51. おわりに • 多様性のない開発は脆弱で非効率 – バランスと戦略がポイント • パラダイムシフトによりリスクは増え続けている – 自律的なチーム作りが重要 • チケット駆動開発 – プロジェクトの情報を集中管理 – 気づきや経験を蓄積して活用 – 自動化やコミュニケーションの支援ができる – バランスと戦略が大切 => ぜひ皆さんも活用してください 51
  52. 52. エンジニアは、身につけた理論と経験を基礎に、 各種制約を考慮して工夫することで成長します。 良さそうな開発方法だからとそのまま取り入れて、 工夫しないのでは進歩しません。 チケット駆動開発は、より良いプロジェクトを目指す 際の礎(いしずえ)になってくれるでしょう。 52
  53. 53. チケット駆動開発の 知っておくべき大切な事 おわり

×