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.
ウォーターフォール開発における
チケット駆動開発
-ウォータフォール開発をアダプタブルにする-
株式会社SRA
阪井 誠
<sakai @ sra.co.jp>
古き良きウォーターフォール型開発
社会の変化によってウォータフォール型開発でも
アジャイル開発の要素を意識しないといけなくなった
2
成功パターン 難しくなった理由
納期に向けた最適な開発
プロセス
作らないとわからないことが増えた
ので、一度...
ウォータフォール開発をベースにした
チケット駆動開発のアプローチ
しかし、アジャイル開発への移行は容易ではない
• 大規模開発や平行開発などでは、一定の計画性が
求められる
• 監査の観点
• 人材の有効活用の観点
• 契約の都合、など
=> ...
統率の
とれた
組
織
の
特
性
自律的
小 変更量 大
チケット駆動開発による開発法の拡張
アダプタブル
ウォーターフォール
アジャイル開発
ウォーター
フォール型開発
TiDD
TiDD
TiDD
アジャイル
チケット駆動開発
ウォータフォールをアダプタブルにする
3+1のポイント
1. マルチリリース
– 複数回のリリースで変化への対応を容易にします
2. リスクベース
– リスクが小さくなるように開発順序を調整します
3. 補完型チケット駆動開発
– 計画にない作...
マルチリリース
• UI/UXやシ ステムの性能などは実装しないとわかりに
くい
– 「変化への対応」を実現する
– プロトタイピング、スパイクも活用する
• 変更作業の持ち分はSESなら発注側、請負なら合意で
きる方法をとる
– 五月雨(さみ...
マルチリリースのイメージ
• オリジナルスクラム
– 各工程が重層的で、
同じメンバーが作業することで、
暗黙知の共有を図っている
• FDD(Feature Driven Development)
– 大規模開発のためのアジャイル手法
• ハ...
リスクベースとリスク
• リスクとは
リスク = 発生確率 × 影響度
※ある事象生起の確からしさと、それによる負の結果の組合せ(JIS Z 8115)
• 作業順序でリスクが変わる
– 早期に実施すべきタスク
• 他の部分に影響を与えるものは...
リスクベース計画のツボ
• リスクの観点で作業順序を検討する
– 実施時期が早期、 遅らせる、その他のタスクに分類
– スパイクや横展開のひな形などを追加する
– 作業順序の依存関係を明確にする
– リリースやレビューなどの作業のまとまりでも検...
補完型チケット駆動開発
• 当初のスコープからこぼれ落ちた作業をチ ケット化
• リアルタイムに情報共有できる
• チケットは類似のプロジェクトの参考になる
– 苦労した経験は蓄積され、再利用される
チケット
チケット
補完型チケット駆動開発のツボ
• 理想を追い求めない
– まずは障害管理から初めて、ITSに慣れる
– 基本的な環境を構築(メール、バー ジョン管理ツール連携など)
– チケットの種類にタスクを増やす
– カスタムフィールド、カスタムクエリ
•...
サーバントリーダーシップのイメージ
12
• ゴールを見失わないように自律的チームを支える
コマンドコントロールサーバントリーダーシップ
サーバントリーダーシップ
13
W・ハンフリー「TSP ガイドブック:リーダー編」, 2007.
– 「自律的なチーム」を構築
– 「その最大限の能力を最大限発揮できるようメンバー
を動機付け、コーチし、後押しする」
– 「フィードバックとコミ...
まとめ
• ウォータフォールをアダプタブルにする
3+1のポイントを説明した
– マルチリリース ・・・プロセスモデル
– リスクベース ・・・実施方法
– 補完型チケット駆動開発 ・・・ツール支援
– サーバントリーダーシップ ・・・チーム作...
おわり
ウォーターフォール開発における
チケット駆動開発
-ウォータフォール開発をアダプタブルにする-
Upcoming SlideShare
Loading in …5
×

ウォーターフォール開発におけるチケット駆動開発 -ウォータフォール開発をアダプタブルにする-

2,415 views

Published on

ソフトウェア品質シンポジウム(SQiP2015) 併設チュートリアル資料より抜粋

Published in: Software
  • Be the first to comment

ウォーターフォール開発におけるチケット駆動開発 -ウォータフォール開発をアダプタブルにする-

  1. 1. ウォーターフォール開発における チケット駆動開発 -ウォータフォール開発をアダプタブルにする- 株式会社SRA 阪井 誠 <sakai @ sra.co.jp>
  2. 2. 古き良きウォーターフォール型開発 社会の変化によってウォータフォール型開発でも アジャイル開発の要素を意識しないといけなくなった 2 成功パターン 難しくなった理由 納期に向けた最適な開発 プロセス 作らないとわからないことが増えた ので、一度の開発で完成できない 抜けなく網羅的に品質を 高める ビジネスチャンスにあわせて開発ス ピードが重視されるようになった 明確な仕様に基づく 社会の変化が激しく、開発中に仕様 を作りこむ。リリース後の改変も多い リーダが全体を掌握する 技術要素が増え、分散統治に。メン バーの協力、自律的な行動が必要
  3. 3. ウォータフォール開発をベースにした チケット駆動開発のアプローチ しかし、アジャイル開発への移行は容易ではない • 大規模開発や平行開発などでは、一定の計画性が 求められる • 監査の観点 • 人材の有効活用の観点 • 契約の都合、など => チケット駆動開発を利用してウォータフォール開発 をアダプタブルにする方法を説明します
  4. 4. 統率の とれた 組 織 の 特 性 自律的 小 変更量 大 チケット駆動開発による開発法の拡張 アダプタブル ウォーターフォール アジャイル開発 ウォーター フォール型開発 TiDD TiDD TiDD アジャイル チケット駆動開発
  5. 5. ウォータフォールをアダプタブルにする 3+1のポイント 1. マルチリリース – 複数回のリリースで変化への対応を容易にします 2. リスクベース – リスクが小さくなるように開発順序を調整します 3. 補完型チケット駆動開発 – 計画にない作業をチケットで共有・管理します +1)サーバントリーダーシップ – メンバーの能力を最大限に発揮させます
  6. 6. マルチリリース • UI/UXやシ ステムの性能などは実装しないとわかりに くい – 「変化への対応」を実現する – プロトタイピング、スパイクも活用する • 変更作業の持ち分はSESなら発注側、請負なら合意で きる方法をとる – 五月雨(さみだれ)契約 – 変更への対応バッファをとる • リリース分割の方法(リスクベースで決定する) – 全工程(刺身モデル、繰り返し型、XP、スクラム) – 下流(段階リリース、FDD) – 製造(ウォータースクラムフォール) ※ バージョン(マイルストーン)で管理できる
  7. 7. マルチリリースのイメージ • オリジナルスクラム – 各工程が重層的で、 同じメンバーが作業することで、 暗黙知の共有を図っている • FDD(Feature Driven Development) – 大規模開発のためのアジャイル手法 • ハイブリッドアジャイル – ウォータスクラムフォールとも呼ばれる AgileJapan2010 基調講演: 野中郁次郎先生による「実践知のリーダ シップ~スクラムと知の場作り」 全体 モデル 構築 ユーザ 機能リスト 作成 ユーザ 機能単位 計画 ユーザ 機能単位 設計 ユーザ 機能単位 構築 S.R. バルマー他,アジャイル開発手法FDD, ピアソンエデュケーション,p.61, 2003. 英他,ハイブリッドアジャイルの実践, リックテレコム,p.20, 2013. 時間 スコープ
  8. 8. リスクベースとリスク • リスクとは リスク = 発生確率 × 影響度 ※ある事象生起の確からしさと、それによる負の結果の組合せ(JIS Z 8115) • 作業順序でリスクが変わる – 早期に実施すべきタスク • 他の部分に影響を与えるものは先に開発する • 横展開のひな形、スパイク(技術課題の確認)、部分レビュー、 探針、先行リリース対象 – 決定を遅らせるべきタスク • 他の部分に影響を受けるものは詳細に決めてしまわない • 作りこまれる(未決定)の仕様 => 単純な分割でなくリスクベースに計画する
  9. 9. リスクベース計画のツボ • リスクの観点で作業順序を検討する – 実施時期が早期、 遅らせる、その他のタスクに分類 – スパイクや横展開のひな形などを追加する – 作業順序の依存関係を明確にする – リリースやレビューなどの作業のまとまりでも検討 • 後ろから線表を引く – 決定を遅らせたタスクの最終決定時点*がわかる – 前から線を引くと無理につめこんでしまう • 期間に合うように線表を変更する – 依存関係のないタスクは並列作業にする – 作業量をなるべく平準化する – 配員を意識する(教育や引き継ぎ、成長も考慮する) =>リスクを考慮した現実的な線表を引くことができる * M. ポッペンディーク他,リーンソフトウエア開発,日経BP社,2004.
  10. 10. 補完型チケット駆動開発 • 当初のスコープからこぼれ落ちた作業をチ ケット化 • リアルタイムに情報共有できる • チケットは類似のプロジェクトの参考になる – 苦労した経験は蓄積され、再利用される チケット チケット
  11. 11. 補完型チケット駆動開発のツボ • 理想を追い求めない – まずは障害管理から初めて、ITSに慣れる – 基本的な環境を構築(メール、バー ジョン管理ツール連携など) – チケットの種類にタスクを増やす – カスタムフィールド、カスタムクエリ • 従来の線表は管理の視点で用いる – チケットは備忘録として開発者の視点で用いる – 線表 に書かれていない作業を見つけたら、チケットを作成 – 開発者が気づいた時に自由にチケットを発行できるように権限 設定 • 管理にチケットを使えるなら完全型に移行することも可能 – 完全型チケット駆動開発ではすべてのタスクをチケット化 – プロジェクトの情報が一元化されて効率的な管理が可能 – ただし、チケットの数が増えて、棚卸が必要になる – メリットとデメリットを考慮して実施する
  12. 12. サーバントリーダーシップのイメージ 12 • ゴールを見失わないように自律的チームを支える コマンドコントロールサーバントリーダーシップ
  13. 13. サーバントリーダーシップ 13 W・ハンフリー「TSP ガイドブック:リーダー編」, 2007. – 「自律的なチーム」を構築 – 「その最大限の能力を最大限発揮できるようメンバー を動機付け、コーチし、後押しする」 – 「フィードバックとコミュニケーション」 – 「動的な負荷調整」 – 「管理することとリードすることは違います」 – 「人はリードされたいけれども管理されたくはない」 – 「リーダーは部下を動機付け」るなど、 「下からリード」して「ゴールを達成」する デブサミ運営事務局、100 人のプロが選んだソフトウェア開発の名著 君のために選んだ 1 冊, pp.20-21. 「リーダーに求められる大切なこと」 http://www.slideshare.net/MakotoSAKAI/ss-16581244
  14. 14. まとめ • ウォータフォールをアダプタブルにする 3+1のポイントを説明した – マルチリリース ・・・プロセスモデル – リスクベース ・・・実施方法 – 補完型チケット駆動開発 ・・・ツール支援 – サーバントリーダーシップ ・・・チーム作り =>ウォータフォールの良さを生かした チケット駆動開発が可能 (次に事例を示します)
  15. 15. おわり ウォーターフォール開発における チケット駆動開発 -ウォータフォール開発をアダプタブルにする-

×