zoukankan      html  css  js  c++  java
  • 优先级排序与需求拆分粒度

    在开发过程中,难免会有人问,我们的需求改拆分到多细才算合适
    我与火星人陈勇在聊天时,我们有过这样一种共识:按团交付更合理
     
    那么什么叫按团交付呢?
    简单来说,就是每次交付刚好可以且仅可以交付一个完整的客户价值——达成一项客户诉求。(注意区分客户与用户——奶瓶的客户是家长,用户是儿童,客户价值是家长以此来简化喂奶,这种价值以家长购买奶瓶的价格来体现)
     
    怎么才能防止拆的过粗?需要明确定义一项需求的客户是谁、这个功能对客户有什么样的价值,直到每一项仅满足一个完整的客户价值。
    怎么才能防止拆的过细?拆分到技术、部署上可以独立发布版本——确保是个潜在可部署的增量    
     
    好的需求拆分可以带来好的优先级排序,而好的优先级排序可以带来多次潜在交付。
    以画梦娜丽莎为例:
     

    蒙娜丽莎的最终图

     
    拆分方法1:每次只画一个完整且完美的局部
    结果:需要9个步骤完成后,才能交付
    不好的排序
     
    拆分方法2:每次都画整幅图画,并提供整体增量
    结果:每三个步骤就能进行一次交付,并且每次交付都越来越好
    好的排序
     
    所以,更好地拆分方法不是完整功能块的堆积(纵向),而是将所有功能块中与某个客户价值相关的任务放到一起(横向)
    从而能够制定基于交付物增量交付计划
     
  • 相关阅读:
    hdu 3613 Best Reward 扩展kmp
    hdu 4333 Revolving Digits 扩展kmp
    poj 1904 King's Quest 强连通
    hdu 3068 最长回文 manacher
    Codeforces Round #243 (Div. 2) C. Sereja and Swaps
    poj 3680 Intervals 费用流
    两个kmp hdu 2594 & hdu 2087
    hdu 3336 count the string
    Arcgis安装要素
    JS关闭窗口而不提示
  • 原文地址:https://www.cnblogs.com/lchrennew/p/requirement-splitting-and-prioritization.html
Copyright © 2011-2022 走看看