模糊的客户需求

• 客户需求不明确
• 做出来的产品功能无法确定是否满足客户需求

解决方式

• 如果客户需求不明确，是一个模糊需求的时候就尽量做出一个产品，看看是否能够满足客户的需求。
• 如果客户的需求能够被确定下来，在及时完成客户交付需求的同时尽量在小单元交付的时候给客户惊喜
• 比如抖音，新闻类的APP里面，大多都是会将用户喜欢经常浏览的内容反复推送
• 比如海底捞，就会在不断满足客户的要求后还能够给客户带来惊喜
• 通过不断提升产品需求，满足客户的需求并且可以带动客户达成目标

敏捷的流程时间

• 瀑布模型，敏捷，DevOps能够多快的完成迭代任务

  
  来源课程.png

各个流程的时间与特点

• 瀑布模式
  1.流程持续时间长，多数按月来计算，从无到有的过程可能要经历几个月的时间
  2.流程每个环节是分开，比如开发结束，测试开始，最后运维
  3.需求确定以后到交付往往错过了最佳的时机，比如好的想法在经历几个月时间后已经变成过时的想法

• 敏捷
  1.开发，测试同时进行，节省一部分的时间，将需求明细以后就并行开发，测试介入
  2.时间周期往往按天来计算，多数的国内项目还是按照迭代的瀑布模型开展
  3.将功能按照瀑布模型开发，然后通过周期短的时间比如2周一个迭代版本来进行交付
  4.暂时无法完全做到每日更新，每日发版的要求

  
  来源网络.png

• DevOps
  1.将所有的工作内容按照小时计算
  2.内容足够小，功能足够小

敏捷流程是否改变了交付速度

• 如果是需求足够明确的前提，瀑布模式最合适
• 传统行业往往还是需求足够明确，而且不会像互联网一样有太多需求要满足用户当下的思想
• 在目标不明确的情况，尽量减少错误，将目标设定足够小，错误发生以后能够及时改正
• 当需求不确定可以很快调整目标，并且能够对无效的需求进行替换

• 开发过程中遇到的所有需求可能会根据实际情况有所取舍

  
  来源网络.png

在快速交付下的悖论

• 当足够快的时候如何保证质量
  1.当足够快的情况下，很多想法或者条件不成熟，导致质量问题

• 做的快，错的远
  1.当想完成一个需求的时候，可能有多个需求想关联。这样做出所有的需求后，发现最初的需求都没有达成
  2.当出错以后的10%甚至更低的需求才是客户需要的，但是做的时间越长，发现错误原来越远

• 测试快还不够
  1.自动化测试在实际项目中的占比，往往产出的脚本无法找到bug
  2.自动化测试过程中难找到bug，并且维护成本高
  3.想节省时间，但是还不如手工测试来的更方便

想实现敏捷，有什么方法

• 快有什么办法

  
  来源课程.png

小目标-寻找MVP

• 将目标确定，并制定最小的目标

• 比如图片显示的需要一辆车的目标，最初的小目标是提供一个代步工具，而且不是造一个车轮

  
  来源网络.png

• 将目标先设定在能够达成，比如一个代步车辆

• 每个人设定的目标大小不同，比如有人需要达成的目标是豪宅，有人目标是公寓等

  
  来源网络.png

小团队 - 独立自治

• 以前都是领导指挥不同角色人员
• 不同角色人员分工工作，完成领导下达的任务安排

• 工作应该不分角色，根据需求来分工协作

  
  来源课程.png

能力 - 责任共担

• 传统工作中都会按照工作觉得来分工
• 在敏捷团队需要根据能力分工，比如测试需要了解业务，需求，测试，开发需要了解前后端开发等
• 每个角色不应该只做一件事，而是将不同的事情都有所涉及，这样才能将工作高效化
• 敏捷团队需要每个人都在不断提高个人能力，更好的完成目标
• 比如测试人员不仅仅了解测试知识，还要掌握一些开发技能

• 举例现在小孩会乐器，舞蹈，书法等等，都是一人多能的表现

  
  来源课程.png

• 如果文章不错，帮忙点赞！