はじめに
UPってコンセプトを聞いているうちはうまくいく気になるけど、
実際にやってみようとするといろいろ壁があるよね、
と思っている (+ 少々だけど体験したことがある) ので
そういったところを言語化しておこうかなと思い筆をとりました。
成長し続ける記事ということで、定期的に追記していこうと思っています。
私の経験
- 2008年 EssUP + AOSP 研修 (フルタイム一か月 by Iver Jacobson Consulting)
- 2011年 オフショア向けカスタマイズ研修 (by Iver Jacobson Consulting)
- 2011年 オフショア開発にUPエッセンスを採用
- 2013年 テレビ向けスマホ連携アプリケーション開発にUPエッセンスを採用 (唯一の成功事例)
- 2014年 テレビ向けメディア機能開発にUPエッセンスを採用
参考にした資料
(これも増えたら都度追記しています)
- らくらく Unified Process - ライフサイクルモデル編 -
- Unified ProcessとScrumを比較してみる
- 【改訂版】初歩のUML：第10回 開発プロセスの上手な組み合わせ
- Good/Bad と 事実/気持ち から始める「ふりかえり」の手引き
- 豆蔵さんの資料 (非公開)
疑問
[未解決] 本質、UPが目指すもの
UPに限らず反復手法が目指すものは
「初めから全部を完璧に知ることはできない」
「作ってみて初めて分かることがある」
というところかなと思っています。
よく引き合いに出されるウォーターフォールは、
要件 --> 設計 --> 実装 --> テスト(デバグ)
が一直線で、前段の作業の完全性が期待さるけど、
「実際そんなの無理だよね、だから手戻りするし遅れるよね」
なので、
「もっと現実的でコントロール可能なプロセスを」
というあたりが、反復手法が発明？されたきっかけと認識しています。
なので
- やってみてわかる
- 都度修正できる
あたりが本質かなと思います。
UPでも同じかな？
でも、
「推敲フェーズでリスクに対する対応は決まっているので、作成フェーズではただ作るだけ」
という表現を見ると、ん？ウォーターフォール？と思ってしまいます。
[未解決] 全部って無理
推敲フェーズのゴール設定が重すぎるように感じます
「推敲フェーズですべてのリスクに対する対応を決めておく」
「作成フェーズでは推敲フェーズで決めたことに従ってただ作るだけ」
どうしても空虚な理想論に聞こえます
「すべてのリスク」が洗い出せたことをどうやって判定しましょうか？
[未解決] 推敲フェーズのビルド (=成果物)
フェーズ毎に達成しなければならないことを 「マイルストーン」 といいます。
また、イテレーション毎に 「ビルド」 ＝動くソフトウェアをリリースすることが原則です。
ビルドは方向付けフェーズでは不要ですが、 推敲フェーズ以降は必要 です。
推敲フェーズのマイルストーンは「重大なリスクに対応する」こと。
リスクはいろいろありますが、特に
- 技術リスク
- 要求リスク
- プロセスのリスク
に対応するそうです。
で、技術リスクへの対処が「ソフトウェアアーキテクチャのベースラインの確立」です。
ですが、「ソフトウェアアーキテクチャのベースラインの確立」に対応するビルドって何？
アーキテクチャ・ドキュメントを書いても「動くソフトウェア」ではないですし、
いつもここで悩みます。
[未解決] イテレーティブの皮をかぶったウォーターフォールでは？
「やってみないとわからないから、やってみてリスクを顕在化する」という基本方針に対し
「推敲フェーズでリスクは洗い出し切れている(対応は確定している)」という考えが矛盾しています。
実際には開発の後半に
「機能規模の割に開発規模が大きいアイテム」
すなわち「アーキテクチャへの影響の見逃し案件」(局所化の失敗)
が出てくることは(避けたいけれど)皆無にはできず、
その反省からイテレーティブな開発手法が発明されたわけです。
個々の機能実現なしに推敲フェーズのみでアーキテクチャ確立を目指すプロセスは
ウォーターフォールのそれと同じと言えます。
[未解決] イテレーション計画
各イテレーションの冒頭でイテレーション計画を行い以下の要素を決定していきます。
- 目標 (スコープ)
- 期間、作業順番 (スケジュール)
- 要員
- リスク対応
- 予算
２つわからない。
作業内容 (バックログ)
作業順番というからには、作業内容があるはず。スクラムだとバックログにあたるものですかね？
スクラムだとバックログについてはあるべき姿が色々語られていて
たとえば、INVESTになってないとダメだよ、とかがあります。
また、プロダクトバックログをスプリントバックログに積むのも誰が権限を持つのか明確です。
だから、スプリントの計画が妥当に立てられる。
(逆に言うとスプリントの妥当性を保証する責務が明確)
ところが、UPではバックログにあたる作業内容について
- 何を書くのか
- 誰が作るか
- どのような粒度で作るか
- どのような性質を持つべきか
あまり語られていません。
ユースケース駆動開発手法の一部を取り入れてユースケースベースで語るべきなのかな？
2/5 追記
スクラムのバックログにあたるものが、UPではユースケースだそうです。
そして、ユースケースを立てるときにもINVESTにするのが基本だそうです。
4/15 追記
バックログは「課題」で立てる、という話も出ました。
なるほどと思うと同時に、要件の課題化には分析工数が必要になるけど、それはいつだれがやるの？とも思う
リスク対応
これ、何するの？
何ができていればGOなの？
自分自身真面目にやったことがないです...
[未解決] タスク(PBI相当)のサイズ見積もり
スクラムだとPBI(Product Backlog Item)のサイズ見積もりとして
プランニングポーカーなどの手法が示されています。
これは、プランニングポーカーが良いと言っているわけではなくて、
サイズ見積もり(INVESTのS)がいかに重要かを示しているものです。
UPもイテレーティブな手法かつタイムボックスの延期を許さないプロセスなので
サイズ見積もりは非常に重要です。
しかし、その重要性があまり強調されていない＆具体的な手法なども示されていません。
現場からみるとここはプロセスとしての欠陥に見えます
役割と責務 (Role and Responsibility)
スクラムだと、POとかSMとか役割とその責務が明確に定義されます。
UPはそういう定義がないように見えます。
あるのかな？あったら教えて。
3/23 追記
スプリント・バックログに積む案件を決めるのがだれなのか不明確なまま進行すると、
開発リソース(ex: 海外協力会社のリソース)が競合する際に開発チーム間でトラブルが発生します。
チームT「わがチームでは開発要素Aが最優先」
チームM「わがチームでは開発要素Nが最優先」
海外協力会社「いっぺんにできないので、開発要素Aからやります」
さて、これでよいのか？
スクラムではPOの責任によって優先度の決定がなされますが、
UPではここが明確ではないため「最適な」優先度決定が行えません
4/9 追記
UPでもPOという名前を用いていないだけで、
POのroleを持った人を設定することが必要だそうです。
(ではUPでは何という名前なのだろう...)
議論のための会議体を設定してもいいけれども、
最終意思決定は個人にアサインしないとうまくいかないそうです。
[未解決] イテレーションが終わった時になにをする？
各イテレーションは1～3ヵ月のタイムボックスで進行します。
タイムボックスの延期は認められません。
イテレーション冒頭のスケジュールで計画した作業順番に従い粛々とすすめ、
決められた時期が来れば延長戦なしでそこで終わりです。
タイムボックスに収まるように作業(バックログ)を積む、という大原則がありますが
それでも毎回100%守れるわけはないので、どうしても作業残りが出ることがあります。
そのようなシチュエーションに遭遇したとき何をすべきか、UPでは語られていません。
というか、イテレーション終了時に行うべきアクティビティについてほとんど定義がないです。
うまく回っているうちはいいけど、一度崩れだすと負債が拡大生産されて、
なし崩し的にタイムボックスが守られなくなり、そしてUPは崩壊します(経験済み)
UPは本当に困ったときには助けてくれない、と感じています。
自分の勉強不足かな。
[未解決] バックログ管理
プロダクト全体のバックログをどのように管理するか語られていません。
各フェーズのMain Tasksとして、
- Business modeling (Business Usecased) xx%
- System Usecases xx%
という表記がありますが、これだけ管理するの？まさかね...
各フェーズの Main Deliverables がそれを示すのかな？
でも、これってスクラムだとインクリメントだよね...(成果物でありバックログではない)
[未解決] 縦軸何？
Unified Processで画像検索すると必ず出てくるこの図
縦軸何？
2/5 追記
残業時間説(笑)
[未解決] 高リスクで多くのチームにまたがり開発規模も大きな必須基本機能
序盤に開発するのは100%合意ですが、
多くのチームで高リスクの開発を行わなくてはならず、
さらに一チームでもタイムボックス内に間に合わなければビルドができないです。
どうやってリスク分散するのかな？
UPをみても指針がない気がします。
また、基本機能が故にFailした際には
「次のイテレーションで計画していた多くの機能も開発できない」
という連鎖倒産が発生します。
そもそもそういう粒度で要件をつむのが間違いですかね？
だとしたら...
「要件をイテレーションに積むまえに満たすべき性質についての指針」がほしいと思います。
切に思います。
[未解決] 「あとちょっとでリリースできます」
イテレーションの終わりの日に担当者が
「すみません、その機能は作り終わったんですが、バグっているのでリリースできません」
「あと一日もらえれば修正してリリースできます」
と言ってきました
さあ、どうする？
- A = 一日待つ (タイムボックスを伸ばす)
- B = 次のイテレーションまで待つ
[未解決] 仕事をかけ持ちするチーム
これはUPに限ったことではないですが...
開発チームがUPによる開発のほかにプロジェクトを掛け持ちしていて、
そちらのほうから飛び込みの仕事があったりすると
UPでコミットした仕事が平気で延期されたりします。
プロセスというよりはマネージメントの問題だと思いますが
現実的にはそういう開発チームは多いし
UP(イテレーティブ開発)のケイデンスを乱す大きな要因です。
用語集 (おもに自分のための)
UP
INVEST
- I : Independent 独立性
- N : Negotiable 交渉可能
- V : Valuable 価値のある
- E : Estimable 見積もり可能
- S : Sized Right 適切なサイズ
- T : Testable 検証可能
INVESTはXP由来の様子。
今日UPのUseCase由来みたいな話を聞いたけど違うんじゃないかなぁ...
SCRUMのR&R
スクラムにおける3つのロールを映像制作にたとえてみる
に張り付いているスライドがなかなかよくできています。
こっちじゃないよ