|
每天一个版本，混乱。在Android上，你可以自行发布更新，但如果基于iOS的，在Apple的App
Store上发布，别说每天一个版本，就算每周一个版本，Apple的软件审核流程还没走完，就又扔一个新的版本，这就很容易造成下游工作根本没法正常进行。项目管理者联盟
将版本更新速度视为敏捷开发，是完全错误的。敏捷开发在于你能够准确抓住市场，在时间窗口内快速推出产品。由于市场的不确定性和用户喜好/需求的不确定性，用户通常不清楚需要什么，你先给他，他再去判断，这需要在需求-开发-市场验证中进行循环迭代，以用户为最终目标，而不是机械地将敏捷视为快，而判断什么为快，又机械地用版本推出速度来说明，每天推一个版本，只能说明开发流程出了问题，整个学生小作坊。项目管理者联盟
敏捷开发也仍然是和版本更新有一定的关系。但这个版本，不是小修小补的小版本，而是有新功能，新UI，新互动方式，在用户体验上有新的感受。这样的版本，不可能一两天就升级。另外，你推给客户的都应该是个稳定的版本。项目管理者联盟
18. 误区：没有分析和设计
敏捷开发强调简单设计，团队每个成员都从接触客户到分析设计，到编码，全部承担。但是实际上团队成员的素质参差不齐，如果只有简单设计、立即编码，而没有后续的持续重构等实践，将导致设计混乱不一致，尤其是对老系统的功能升级，如果对原有系统的影响分析不够，弱化了分析设计，将导致很多工作在后期频繁变更，使得团队的挫折感增强，产生较多的重复工作和浪费。项目管理者联盟
必要的系统架构和设计从来都是非常重要的。只是这里的分析设计有别于传统的开发模式，应该应用敏捷的思想，简单设计，持续重构，尽快反馈等。项目管理者联盟
19. 误区：敏捷拥抱变化，因此前期需求可以随意简单项目管理者联盟
因为敏捷的导向，可能造成的问题是，前期需求比较随意，对需求质量的控制弱化，需求变更更加频繁，但是这并不意味着对需求可以不做深究，甚至可以随意变更需求。blog.mypm.net
(1)需求质量的审核，仍然需要改进，需求方向性的错误将导致后续一系列的工作浪费，所以团队内部应该设定里程碑和review标准，从而确保基本的需求质量。项目管理者联盟
(2)在Iteration里需求尽量不要变更，明确Iteration的边界。否则频繁的变更导致团队没有成就感，方向和目标不明确。项目管理者联盟
(3)敏捷讲求业务价值导向，有些变更从业务价值上看，可能并非真正需求急切变更。项目管理者联盟
有些变更通过更好的Impact分析和设计应该也可以避免。BA和SA等不同的角色应该一起配合来做出Impact分析，以供决策training.mypm.net
20. 误区：可以孤立地实践少数的敏捷实践项目管理者联盟
一些敏捷实践容易实行，一些比较困难，所以大家习惯性的会割裂敏捷实践的关联，孤立地实践少数易于实现的敏捷实践。敏捷开发之所以可以替代以往传统开发模式，是因为一组(系列)的开发实践来共同代替以往开发模式。孤立的引入少数实践，通常不能给团队成员感觉有大的改进，从而也放弃对敏捷开发的信心。项目管理培训
例如Stand-up
Meeting(站立会议)这是一个比较容易的实践，但是如果没有背后的需求转化为比较容易衡量的Story-base，没有BA、QA等共同参与基于Story-base去沟通，没有OfflineofMeeting更多的面对面沟通交流，没有大家彼此知道对方的工作内容(CodeOwnership)，那么可以设想这种Stand-up
meeting和以往的传统的开发模式，Leader布置任务检查任务进度没有任何区别。club.mypm.net
再如简单设计实践，如果没有背后的结对编程、重构等实践，必然导致比较混乱的代码，很难维护的架构，难于扩展，重复实现类似功能等弊端。项目管理者联盟
再如持续集成(CI)，即使这是公认敏捷软件领域内相对没有争议的一个实践，但是如果没有与TDD结合，没有与持续重构，没有与小的Story，快速频繁Deliver等实践结合在一起，并且坚持保持CI的健康，也会让团队成员觉得CI效果不如宣传，从而对敏捷实践等产生质疑。PgMp.mypm.net
文章来源：懂点项目管理项目管理者联盟
club.mypm.net项目管理者联盟
|
