無料ブログはココログ

« [#TiDD] 従来法の限界とアジャイルの利点、そしてチケット駆動開発 | トップページ | [#TiDD] 「チケット駆動開発」を分解する »

[#TiDD] リスクベースでリリースする

リスクベースに考える際のリリース順序を考えます。私はこんな風に考えているというだけで、必ずしもこれだけではないと思います。もっと良い観点があれば、お教えください。

基本的には、問題が発生しても取り返しのつくような構造となるように、つまり後になって問題が発覚してプロジェクトが爆発することがないように考えます。後続の作業があるということは、残業などによって作業する余地(バッファ)があるということになるからです。また、早めにリリースすると、他のテストの実施によって信頼性が向上することも考慮します。具体的には、下記のように分類しています。

リリースの順序
リリースを早める後回しにする
必須機能 低重要度(中止可能な)機能
基盤 周辺
基本機能 拡張機能
外部システムと結合 独立機能
初めて利用する環境関係 実績のある環境関係
更新系 参照系
お金・個人情報 サマリ

もちろん、システムの実装やテストの都合もありますし、メンバーの能力を見定めたり、メンバーの負荷の平準化なども考慮すべきでしょう。

また、ここに挙げた順序を避けるために、外部との独立性を高められるようにアーキテクチャを考えるというのもあるでしょう。プロジェクトの計画は、色々なことを考えて戦略を練る作業なのです。

 

以上、ご参考まで

« [#TiDD] 従来法の限界とアジャイルの利点、そしてチケット駆動開発 | トップページ | [#TiDD] 「チケット駆動開発」を分解する »

チケット駆動開発」カテゴリの記事

コメント

コメントを書く

コメントは記事投稿者が公開するまで表示されません。

(ウェブ上には掲載しません)

トラックバック


この記事へのトラックバック一覧です: [#TiDD] リスクベースでリリースする:

« [#TiDD] 従来法の限界とアジャイルの利点、そしてチケット駆動開発 | トップページ | [#TiDD] 「チケット駆動開発」を分解する »