《用户故事与敏捷方法》读后感

Posted 2023-04-30 guoziheng

什么是敏捷敏捷：一种面临迅速变化的需求快速开发的能力

敏捷的优势

降低项目风险缩短反馈周期减少误解(沟通)降低修正错误的代价确保正确的方向可用的软件用户验证适应变化敏捷的4个核心思想

人和相互交流胜于流程和工具（面对面沟通）可以运行的产品胜于编制综合性文档（精力放在可执行程序上）和客户合作胜于合同谈判（合作与团队激励）适应变化胜于按部就班（适应能力）敏捷的3个角色

产品负责人（Product Owner，简称：PO）Scrum Master/技术leader（简称：SM）Scrum团队（包含前后端开发，测试，设计，运维等，前2类必须为全职）敏捷的3个工件

产品Backlog（Product Backlog）SprintBacklog产品增量（Increment）敏捷的4个会议

Sprint计划会议（Sprint Planning Meeting）每日站会（Daily Scrum Meeting）Sprint评审会议（Sprint Review Meeting）Sprint回顾会议（Sprint Retrospective Meeting）敏捷的5个价值

承诺 – 愿意对目标做出承诺专注– 把你的心思和能力都用到你承诺的工作上去开放– Scrum 把项目中的一切开放给每个人看尊重– 每个人都有他独特的背景和经验勇气– 有勇气做出承诺，履行承诺，接受别人的尊重

读《用户故事与敏捷方法》有感

读《用户故事与敏捷方法》有感(五)

　　今天，读到了次本书的第三部分——经常讨论的话题，用户故事不是什么，用户故事的优势与不良征兆。

　　第一，用户故事不是软件需求规格的指南，这种需求规格指南强调的是“系统应该……”，而且对于需求规格指南而言，在写下需求之前，每个需求的成本是不可见的。典型的情况是，一个或几个分析师花两三个月时间(通常更长时间)编写出冗长的需求文档。随后把文档交付给程序员。这时程序员告诉分析师(消息会被转告给用户)，完成项目要24个月，而不是分析师所希望的6个月。在这种情况下，分析师在编写团队没有时间开发的四分之三部分的文档上浪费了很多时间，而且在开发人员、分析师和客户之间反复讨论需要在有限的时间内先开发哪些功能上会浪费更多的时间。每个故事开始都会有一个估算。客户知道团队的速率，也知道每个故事的故事点数。编写完足够填满所有迭代的故事后，她知道自己的任务已经完成了。

　　想对于传统的需求规格指南，用户故事还是有很多优势的，第一，促进口头沟通，大家共同讨论得出最完美的解决方案，众人拾柴火焰高嘛；第二，用户故事没有繁杂的领域术语，这些东西会让开发人员无所适从，所以用户故事比用例和场景更加容易理解；第三，用户故事的大小适合做计划，用户故事时可以根据实际情况和需求进行划分的，所以故事大小可以掌控，也可以很方便地用户做发布规划以及进行编程和测试；第四，用户故事适合于迭代开发，在开始编码之前，我并不需要写出所有的用户故事。我可以写出部分故事就进行编码与测试，然后按照需要的节奏重复这个过程。写故事时，我可以按照合适的粒度去写。正是由于我们很容易对故事本身也进行迭代，所以用户故事很适合迭代开发；第五，用户故事鼓励延迟细节，可以迅速让所有人对要开发的系统有一个整体的概念；第六，用户故事支持随机应变的开发并鼓励参与性设计，用户故事引人入胜，能激发用户的积极性，让开发人员和用户间的关系变得亲密主动，这个良性循环啊使所有开发中设计的人和软件使用者都受益良多。

　　虽然用户故事相对于传统文档而言优势很多，但是我们也应该正确看待它的不足。首先，故事互相依赖，用户故事之间一旦由于设计偏差导致关联度高的话，很可能不利于迭代往往适得其反；二，由于开发人员在迭代中实现了计划外的功能，使得实际功能超出实际需要；三，细节太多，不应该花太多时间去写故事而是讨论故事；四，过早考虑用户界面细节，我们应该尽量避免写关于页面的故事；故事划分频繁而且客户很难为故事安排优先级或者客户不愿意写故事也不愿意为故事安排优先级。

　　用户故事是辅助工具，我们更需要的是敏捷方法，靠思考讨论把团队不断引导到正确简洁的方向上去。