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