发帖
雷达卡
敏捷开发中，PO将需求整理成Product Backlog，，在这之前，是否需要需求分析呢？在我看来，是需要的。需求的准确无疑一直都是项目后期开发的根基，即使敏捷，拥抱变化，如果在早期可以将需求更准确的分析出来，更贴近客户，后期我们的成本才会更低。所以需求分析是必要的，这点我毫不怀疑。
需求分析--》需求规格说明书（部分界面设计或原型系统）--》客户评审--》评审签字通过
这一流程在敏捷中没有区别
区别是传统项目管理到此后就进入了设计，而敏捷这里多了一步，要整理成PO的Product Backlog，将需求变成一条条的用户故事。然后排好优先级，根据项目经理事先设定好的项目计划，将几个sprint的工作填满。
到了设计这一阶段了。到底敏捷是否需要如传统项目的界面设计、数据库设计、概要设计--包括架构设计、接口设计等。敏捷中或者说XP中的观念是不需要预先设计的，设计包含在代码中，这里引入了重构等。但是这样带来的后果自我感觉是糟糕透顶。没有统一的设计，没有统一的接口，，每个人根据自己的想法设计自己的模块，然后在争吵中确定大家的接口和边界。有多少个人就有多少个想法。就可能有n的平方种接口。没有统一的设计，当然更没有统一的文档。接手的人无所适从。
所以，思考的结论是，设计还是一样要做，原来怎么做，还是怎么做，一个都不能少。
于是到了编码阶段，这里终于可以开始编码，召开计划会议，各人领自己喜欢的任务，按照设计的思路和方法开始编码。
这里又涉及到一个编码共同享有的问题。敏捷中提倡每个人了解多个模块。我们有两种产品，一种是开发型，一种是维护型。在开发型中，是否真的需要每个人掌握那么多模块的开发呢？开发阶段的产品大多数是进度压迫型的项目，一个人专心一个模块是最快速度的开发方法，，当一个产品开发完成后，维护并不需要同时一批人维护的时候，似乎一个人掌握多个模块的开发完全没有必要。这样看来，计划会议的集体讨论其实也并不是那么重要，，既然抱着相信每个人的职业道德的信念，不如直接按照优先级派发任务好了，，顶多要一个高手去帮忙估算一下时间，掌握一下进度而已。。
看来到此为止只有安排优先级排序这个理念比较有用一点。
在维护型项目中，大的设计已经定下来了，而且人员不会很充裕的情况下，也许敏捷上面的几个实践才能更好的实践吧，，只是优先级排序现在看起来又没那么重要了，，这一维护期内的需要反正都要做完，做完就上线，不需要什么优先级了，都做就是了。
京公网安备 11010802022788号
