[#TiDD] リスクベースでリリースする
リスクベースに考える際のリリース順序を考えます。私はこんな風に考えているというだけで、必ずしもこれだけではないと思います。もっと良い観点があれば、お教えください。
基本的には、問題が発生しても取り返しのつくような構造となるように、つまり後になって問題が発覚してプロジェクトが爆発することがないように考えます。後続の作業があるということは、残業などによって作業する余地(バッファ)があるということになるからです。また、早めにリリースすると、他のテストの実施によって信頼性が向上することも考慮します。具体的には、下記のように分類しています。
リリースを早める | 後回しにする |
---|---|
必須機能 | 低重要度(中止可能な)機能 |
基盤 | 周辺 |
基本機能 | 拡張機能 |
外部システムと結合 | 独立機能 |
初めて利用する環境関係 | 実績のある環境関係 |
更新系 | 参照系 |
お金・個人情報 | サマリ |
もちろん、システムの実装やテストの都合もありますし、メンバーの能力を見定めたり、メンバーの負荷の平準化なども考慮すべきでしょう。
また、ここに挙げた順序を避けるために、外部との独立性を高められるようにアーキテクチャを考えるというのもあるでしょう。プロジェクトの計画は、色々なことを考えて戦略を練る作業なのです。
以上、ご参考まで
« [#TiDD] 従来法の限界とアジャイルの利点、そしてチケット駆動開発 | トップページ | [#TiDD] 「チケット駆動開発」を分解する »
「チケット駆動開発」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- [#TiDD] ポケモンGOにチケット駆動開発のポイントを学ぶ(2018.05.01)
- [#TiDD] プロジェクトを成功させるチケット管理(2017.07.02)
« [#TiDD] 従来法の限界とアジャイルの利点、そしてチケット駆動開発 | トップページ | [#TiDD] 「チケット駆動開発」を分解する »
コメント