讨论主题谁应该来测试？关键字敏捷教练、引导、测试、完成书中建议归纳测试并不是某一个人的事情，它是整个团队的责任，共同促成“完成”。心得敏捷教练应该帮助团队成员学会互相配合，共同努力完成“进球”。（想想足球比赛，场上所有运动员相互配合，追着球跑或是加强防守，而不是一个地方一直等待）如果再具体点讲，到底哪些人员可以参与测试，如何测试呢？开发人员、客户、测试人员、外部团队均可，需要他们对“完成”的定义达成共识后一同协作。开发人员：自己通过故事测试之后才提交，减少COPQ(不良质量成本)。鼓励开发人员利用编码优势做测试。客户：要让客户获得最新版本进行尝试测试。他们最清楚软件的预期使用环境，关注用户在用户故事中的目标是否达成。提示：他们也许会对边界情况测试不足。测试人员：可以尝试和开发人员结对做测试。他们更专业（各种专业测试），帮助团队充实故事测试。外部团队：多数是一些特定的测试工作。比如安全测试、易用性测试等。需求负责人或PO:团队尽量与PO沟通，可以做一些Show Case。在条件允许的情况下，开发人员可以在未完全开发完毕的情况下与需求负责人沟通，确认方向是否正确，风险前置。以上，欢迎大家交流，共同探讨和分享。

讨论主题敏捷教练如何引导会议关键字敏捷教练、引导、敏捷会议书中建议归纳为团队引进新实践时，需要展示具体做法，不能任由团队自力更生。心得新形式的敏捷会议对团队来说不容易开成功，第一次的会议要由敏捷教练引导。实时进行点评，重要的是要团队理解你在引导会议时的思考过程。之后的会议慢慢退出引导角色，可以做些帮助团队做准备并在会后给予反馈。首次尝试敏捷会议时，教练主动请缨引导会议，向团队展示具体做法。把流程解释给团队，让团队学习如何自主引导会议。下次时，改为协助会议的引导者，最后退居二线。几点提示帮助更好地开会：选择恰当的时间开会，确保整个团队都能参加。布置好场地，准备好工具。明确会议目的，开场时声明会议目的和议程，还要提醒遵守敏捷会议的基本准则。保持会议顺畅，引导者发挥充分作用。鼓励全体参与，确保所有人都发表自己的观点。总结要点，可以记录在白板，复述理解，确认团队真的理解。结束会议，确保产出都已记录。欢迎大家参与讨论。

讨论主题敏捷教练的职责关键字敏捷教练、职责书中建议归纳敏捷教练的使命是帮助团队驾驭敏捷，开发出色的软件。敏捷教练的目标是培养高产出的敏捷团队，成员有自我判断能力，不依赖教练为他们制定敏捷法则。需要改变团队的工作方式和思维方式。心得敏捷教练在辅导团队的时候不能一层不变，要按情况分类：1，新团队，没有接触过敏捷。敏捷教练应该像运动教练一样，积极示范敏捷实践是如何操作的。2，敏捷经验丰富的团队。敏捷教练应该像生活教练一样，通过倾听和提问来帮助他们提升，而非直接给出解决方案。下面给出具体事项供敏捷教练们参考：留意：留意团队的工作方式，思考他们为什么这样做，有些哪诱因。反馈：反馈，分享你的观察到的情况。帮助他们利用这些反馈改进工作方式，做到团队可以自己发现问题。教育：鼓励学习。演示敏捷方法，可以讲故事，可以开设培训课程。引导：清理障碍。促进有建设性的沟通和协作，可以使团队更容易走向敏捷。支持：团队受阻时教练要在场，鼓励团队继续前进，帮助他们保持动力。以上看上去有好多事情要做，但需要注意不一定要一步到位。教练得一步一步脚印地走下去，而不是发起重大变革，这一点非常重要。成功在于建立正确的态度。欢迎大家一起讨论，你认为敏捷教练的职责是什么？应该怎么样做？

在Jez Humble的《持续交付》一书中，我们能看到反模式和持续交付原则提倡的开发方式的对比，持续交付能给我们带来的好处，包括但不限于如下：更早的交付需求提高版本质量减少由不良好的配置管理引入到生产环境的错误。缓解积压发布带来的压力更加灵活地部署书中很多地方提到了精益敏捷，已经假定你所在的公司开发模式就是敏捷了，然后再实践持续交付。但是在我们走访企业的时候，发现很多企业，依旧使用的是瀑布开发模式，因为敏捷转型是一场变革，有的企业由于高层领导不接受转型，所以一直保留着瀑布开发方式。那么在这种情况下，是否可以进行DevOps落地？是否可以采用持续集成、持续交付呢？这里我说的DevOps指的是狭义的DevOps，即Dev-Ops的部分。因为端到端的DevOps已经包括了敏捷部分。在考虑这个问题的时候，想到了一张图，见下图，也是Jez Humble的图。这里我们可以看到，对于瀑布开发模式职能团队来说，开发和测试团队的交接，开发团队和运维团队的交接，分支模式的使用，严格控制发布窗口，这一系列使得交付频率受限，是高不了的。也就是说，瀑布开发的模式，决定了你无法完全进行DevOps落地。那么再看看有哪些能改善的地方呢？能不能在不受职能团队影响的情况下，落地DevOps的一些好的实践呢？比如持续集成的几个原则，这些是纯开发团队自己能做的，不涉及到多职能团队，所以可以独立进行开展。包括如下构建失败之后不要提交新代码提交前在本地，或持续集成服务器，运行所有测试 提交测试通过后再继续工作 回家之前，构建必须处于成果状态不要将失败的测试注释掉开发人员每天开始时至少拉取一次代码开发人员每天结束时至少提交一次代码通过这些实践，可以提高代码的质量，减少协作间的代码冲突，降低反复工作所消耗的时间。测试方面，开发人员自己要做单元测试，同时可以适当加入接口自动化测试，来保证一定的业务场景是好用的。因为每次提交代码都要运行测试来保证质量，所以测试比如使用自动化来进行，考虑到开发人员在测试方面的投入不会高，所以用接口测试来覆盖场景就可以。每次提交新的代码，自己运行一遍接口自动化测试，可以提高代码的质量，降低代码交付给测试团队后，出现的问题。最重要的是，每开发一段新代码，自己运行一遍以接口自动化测试承担的回归测试工作，大大降低了手工的工作量。版本控制方面，由于环境配置等内容涉及到跨职能团队了，所以这里我们只考虑代码版本库。建立版本库进行管理，并保证提交的代码和对应的需求进行关联，这样当回溯问题的时候，方便追踪。部署流水线方面，由于运维团队控制着生产环境，所以我们只考虑开发人员在开发环境的部署，目的是可以尽早做一些集成测试和验收测试。而部署到开发环境做的频率又是很高的，即使这是瀑布开发模式。所以在这里可以引入部署流水线，并配置上代码检查、基本的测试等内容。综上所述，笔者的意见是，对于不接受转型敏捷开发的团队，可以在持续集成、版本控制、部署流水线方面采用DevOps的一些理论、支撑的工具及最佳实践，来帮助团队提供更高质量的代码。

书籍名称《如何构建敏捷项目管理团队》丽萨·阿金斯著 徐蓓蓓 白云峰 刘江华译讨论主题场景描述：一位经理向敏捷教练说：“我想团队最近有些士气低落。在昨天的站例会上，我注意到他们没有什么活力。我们得做些什么。也许带他们玩一天来帮助他们充电？”作为敏捷教练要不要阻止？注：敏捷经理指的是团队成员的直属经理、团队所在的开发项目或者平台的管理者、其他具有合作关系的团队的经理，或者整个公司范围内的利益相关人。书中建议告诉经理把这个问题交给团队自己解决，而不是由自己插手代劳。敏捷工作方式中，发现问题和解决问题都应顺其自然。旁观者不需要通过额外干预而让一些事情发生。团队可以通过回顾来解决问题，不要让经理从团队之外的角度“修复”问题。个人观点书中建议是完全从敏捷的角度出发，让团队自组织和自管理，重点强调的是把问题留给团队。在敏捷实施过程中，有些团队不具备自组织和自管理的能力，需要逐步培养和形成，因此关于是否要把问题留给团队要分阶段分情况进行。向敏捷转型是有一个过渡的过程，在初期需要敏捷经理的干预，等到团队真正成长起来后逐步放手。

讨论主题敏捷团队在迭代结束时，没有可演示的产品，是否每次都需要开评审会议？书籍名称《敏捷教练》-如何打造优秀的敏捷团队关键字敏捷、团队、客户、承诺、转型、教练书中建议归纳鼓励团队坦然面对,想办法按照产品当前的状态进行展示。如果轻易取消会给团队和干系人发出一个信号，即每个迭代结束交付可工作软件这件事并不那么重要。需要通知重要干系人，以免他们觉得是在浪费时间。提醒团队，即使软件尚未完成，他们仍然可以拿到一些有意义的反馈。个人观点书中建议很好，需要提醒一点，特别在和客户初次合作，彼此磨合期信任度不够时，应该加强有效沟通频率，评审会议是比较不错的反馈工作成果的机会，加强客户信任感。即使是成果不多，哪怕一点点，只要让客户知道团队在这个迭代付出了努力，有过程产出即可。相反，如果与客户合作时间已经很久了，彼此有很强的信任感，可以减少相对意义不大的沟通，不要给客户一个错觉，好像做了一点成果就要汇报的感觉，也要考虑客户的工作时间是否饱和，客户的关注点在哪里，做好充足准备，有可演示的产品增量时汇报效果会更好。当然，如果客户对敏捷有热情，愿意参与敏捷活动中的各个环节，那么邀请客户参与无演示成果的评审会议，一同聊聊迭代工作内容也不错，我们也鼓励这样做。欢迎大家留言讨论。

感谢关注华为云 · 云享读书会系列活动~本期活动已结束~查看本期读书会领读视频   请戳：云享读书会《猎豹行动：敏捷转型之旅》查看本期读书笔记   请戳：读书笔记征集【云享读书会-猎豹行动：硝烟中的敏捷转型之旅】获取近期读书会活动安排，请私信小助手咨询哈~开发者，你好哟~华为云 · 云享读书会 2020年首期活动上线！本期为系列活动的第五期，领读书籍为《猎豹行动：硝烟中的敏捷转型之旅》邀请书籍原作者-敏捷圈内大咖——刘华 现身领读，带你了解敏捷转型的高效实施策略！！！如果你已完成结业实践作业，请在此帖回复结果截图~01. 征集时间2020.03.09 - 2020.03.1502. 截图示例回帖时请务必留下你的微信昵称和华为云账号截图示例：03. 注意事项1. 截图提交后，小助手会在3个工作日内按续完成审核，并增加活动积分200分；2. 本次活动共包含1个结业实践任务，通过完成结业实践，可获得的积分上限为200分；3. 请务必按照上述要求提交内容，以免影响积分增加；4. 若积分值相同则以完成学习任务的时间先后排序，其中任务完成时间的判定优先级为：结业实践>读书笔记>自测题；5. 其他积分获取方式请查看活动社群公告；6. 其他未说明事项请参照 云享读书会《猎豹行动：硝烟中的敏捷转型之旅》04. 活动奖励05. 关于云享读书会每期云享读书会活动，会选取一本技术相关的畅销书籍，由原作者提炼书籍精华，在读书会的专属微信社群中，每日输出精华知识的领读视频，帮助大家快速积累专业知识。活动期间会设置每日自测题、结业实践任务、提交读书笔记三种积分获取任务，并根据活动结束后的积分排行发放活动奖励。

感谢关注华为云 · 云享读书会系列活动~本期活动已结束~查看本期读书会领读视频   请戳：云享读书会《猎豹行动：敏捷转型之旅》获取近期读书会活动安排，请私信小助手咨询哈~开发者，你好哟~华为云 · 云享读书会 2020年首期活动上线！本期为系列活动的第五期，领读书籍为《猎豹行动：硝烟中的敏捷转型之旅》邀请书籍原作者-敏捷圈内大咖——刘华 现身领读，带你了解敏捷转型的高效实施策略！！！经过作者的视频领读，如果你有些敏捷相关知识收获，欢迎在此帖留下你的读书笔记~01. 征集时间2020.03.09 - 2020.03.1502. 读书笔记要求1. 每篇读书笔记字数要求≥300字；2. 内容要求与每日领读视频、《猎豹行动：硝烟中的敏捷转型之旅》书籍或是华为云DevCloud产品优化意见相关；3. 内容原创不可抄袭；4. 回帖时请务必留下你的微信昵称和华为云账号。03. 注意事项1. 读书笔记提交后，小助手会在3个工作日内按续完成审核，并增加活动积分100分/篇；2. 本次活动通过提交读书笔记，可获得的积分上限为500分；3. 请务必按照上述要求提交内容，以免影响积分增加；4. 若积分值相同则以完成学习任务的时间先后排序，其中任务完成时间的判定优先级为：结业实践>读书笔记>自测题>其他；5. 其他积分获取方式请查看活动社群公告；6. 其他未说明事项请参照 云享读书会《猎豹行动：硝烟中的敏捷转型之旅》04. 最佳读书笔记奖励领读专家将在活动时间内提交的有效读书笔记中，评选出3篇最佳读书笔记05. 活动排行奖励06. 关于云享读书会每期云享读书会活动，会选取一本技术相关的畅销书籍，由原作者提炼书籍精华，在读书会的专属微信社群中，每日输出精华知识的领读视频，帮助大家快速积累专业知识。活动期间会设置每日自测题、结业实践任务、提交读书笔记三种积分获取任务，并根据活动结束后的积分排行发放活动奖励。附录. 每日自测题答案DAY01自测题1.     以下有哪些是瀑布模型对于业务方的痛点？（多选，正确答案：a、c、e、f）    a)      超支    b)      惧怕需求变更    c)      缺乏透明度，不知道具体进度    d)      过度承诺    e)      逾期交付    f)       贻误战机，丢失市场机会2.     项目开始的时候，有哪些要素是完全确定的？（多选，正确答案：b、d）    a)      范围与具体需求    b)      交付日期    c)      对现有系统的影响    d)      预算3.     敏捷与瀑布最大的不同点是什么？（单选，正确答案：b）    a)      全量开发    b)      增量开发4.     以下有哪些是Product Owner应该做的业务决策？（多选，正确答案：b、d）    a)      解决方案    b)      需求    c)      开发周期    d)      优先级5.     DevOps要打破的最后哪堵“墙”？（单选，正确答案：d）    a)      业务与开发之间    b)      开发与测试之间    c)      测试与运维之间    d)      开发与运维之间 DAY02自测题1.     JIRA和Confluence可以结合使用吗？（是非，正确答案：可以）    a) 可以       b) 不可以2.     下面哪个工具可以实现自动化部署？（单选，正确答案：d）    a)      Github    b)      Jenkins    c)      SonarQube    d)      Ansible3.     Github可以增强代码评审流程吗？（是非，正确答案：可以）    a) 可以       b) 不可以4.     JIRA可以用来做测试管理吗？（是非，正确答案：可以）    a) 可以       b) 不可以5.     JIRA和Confluence的产品设计体现哪些原则？（多选，正确答案：b、e、f）    a)      独占性    b)      去中心化    c)      中心化    d)      保密性    e)      信息共享    f)       灵活 DAY03自测题1.     把需求文档里面的功能点分出来，就是用户故事了吗？（是非，正确答案：不是）    a) 是          b) 不是2.     用户故事可以独立交付上线运行吗？（是非，正确答案：可以）    a) 可以       b) 不可以3.     运用极限编程，需要做长期的计划吗？（是非，正确答案：不用）    a) 用          b) 不用4.     没有限制在制品的可视板是看板吗？（是非，正确答案：不是）    a) 是          b) 不是5.     下面哪些实践是极限编程提出的？（多选，正确答案：a、c）    a)      测试驱动编程    b)      大爆炸式上线    c)      持续集成    d)      回顾会议 DAY04自测题 1.     实例化需求是为了解决什么问题？（多，正确答案：b、c、d）    a)      需求太大太复杂    b)      需求理解不一致    c)      通过具体例子描述验收条件    d)      形成交付闭环2.     微服务架构就是把前端、后端拆成两个独立的应用吗？（是非，正确答案：不是）    a) 是          b) 不是3.     特性团队里每个人都要是通才，需求分析、开发、测试、运维、前端、后端样样精通吗？（是非，正确答案：不是）    a) 是          b) 不是4.     契约测试是通过文档来约定API提供者和消费者之间的接口吗？（是非，正确答案：不是）    a) 是          b) 不是5.     契约测试里的契约是由哪方提出的？（单选，正确答案：b）    a)      API提供者    b)      API消费者 DAY05自测题1.     故事点就是人/日的另一种表达方式吗？（是非，正确答案：不是）    a) 是          b) 不是2.     敏捷计划是在开发开始前就知道多少个迭代可以交付所有的用户故事吗？（是非，正确答案：不是）    a) 是          b) 不是3.     好的累积流图应该是怎样的？（单选，正确答案：c）    a)      待开发的面积最大    b)      待测试的面积最大    c)      已完成的面积最大4.     在服务等级中，加急类别的请求可以违反限制在制品的要求吗？（是非，正确答案：可以）    a) 可以       b) 不可以5.     在估算扑克游戏中，参与的人员是各人按座位的顺序依次亮出自己的牌吗？（是非，正确答案：不是）    a) 是          b) 不是

本次课堂为大连理工马瑞新老师《系统分析与设计》里面的一节，本课程自2004年开课以来，先后进行了几次大的变革。在2016年申请了教育部产学协同育人项目和华为签署了战略合作协议引入了华为软件开发云，将华为ICT技术与产品知识融入到实际教学中，让企业教师走进课堂。教学中采取基础知识和新应用综合案例，企业实践的结构和由浅入深由深到精的学习方式，把企业中的规范和流程融入到学生的学习中。本课有四部分。第一个部分介绍了传统与敏捷的比较。第二个部分通过通过传统和敏捷的比较，用一个棉花糖挑战来体验一下敏捷的精髓。第三部分是去讲敏捷中的一个重要环节——用户故事。最后通过Devcloud软件开发云课堂实训平台能完成一个当堂的在线实践。

大连交通大学“敏捷桃花岛”项目实训总结背景：大连交通大学是东北地区唯一一所以轨道交通为特色的高等学校，是教育部第二批实施卓越工程师教育培养计划高校、国家软件人才国际培训（大连）基地、国家级人才培养模式创新实验区、全国建设高水平运动队院校和体育文化研究基地、辽宁省车辆工程紧缺本科人才培养基地、辽宁省对日服务外包人才培养基地和大连东北亚国际航运人才培训基地，是国家产学研合作先进单位，是辽宁省产学研合作创新基地。学校以**新时代中国特色社会主义思想为指引，紧紧围绕辽宁老工业基地全面振兴和现代轨道交通装备制造业发展，抓牢“一带一路”“交通强国”“高铁走出去”等国家战略实施的发展机遇，全面深化改革，深入推进“双一流”建设。在成绩获得了充分肯定的同时，大连交通大学也认识到，人才培养、科技创新与社会服务等方面的发展水平与区域经济社会发展的需求仍然有较大差距，一些发展瓶颈问题还有待破解，为了加强学科内涵建设，大力推动特色学科发展，大连交通大学希望根据中华人民共和国教育部‘合理提升学业挑战度、增加课程难度、拓展课程深度，切实提高课程教学质量’的文件精神，结合大连交通大学计算机科学与技术专业本学期的课程安排，校企结合，通过企业对教学课程赋能，提升学生的实践动手能力和项目开发能力。与此同时，华为云DevCloud教育解决方案内容建设团队正好在大连基地，大连交通大学与华为双方一拍即合，通过将华为的企业实践项目引入到教学场景中，充分发挥企业实践优势，让同学们将所学软件工程及编程语言与实际相结合，在学校期间提前了解企业真正的软件开发过程，提升同学们的编码、项目敏捷开发等实践动手能力。 挑战：1、基础设施：学校服务器数量有限，机房网络带宽小，影响上机实践，同时目前还缺少一套可供学生课上课下操作练习的环境。2、教学方案：学校比较缺乏企业实践项目教学案例，教学过程中，大多数时候教的是基础知识，相应的实践项目供学生参考使用，无法让学生了解企业软件开发的整个流程。3、学生方面：学生水平参差不齐，大多数学生还停留在编写代码，熟悉语法的基础上，对软件开发流程、开发模式、团队协同、自动化、流水线、CI、CD以及DevOps等开发模式，接触得非常好，甚至没从来没听过这些名词。 解决方案：    与大连交通大学王老师、田老师等多名老师，多次交流讨论，以客户为中心，解决客户痛点，我们华为云DevCloud教育解决方案EduCloud给出如下方案。1、  使用EduCloud进行教学。理由：EduCloud是华为云DevCloud教育解决方案的一站式教学平台，为老师和学生提供统一的平台。 老师通过EduCloud可以轻松的进行备课、下发作业、统计学生作业完成情况、分析学生对知识的掌握情况等。一方面，EduCloud提供了丰富的内容资源，包括基础编程课如：java、c、c++、Python等，也包括项目开发课程，如：敏捷江湖桃花岛、黑白棋等，还包括前沿技术方面的课程，如AI、自然语言分析等。 另一方面，EduCloud还提供了大量的习题资源，所有习题均可以通过EduCloud在线判题能力，进行自动判题。 这样一来，可以大大的减轻老师备课、出题、判题所消耗的精力，可以更聚焦到教学上面。 学生也可以通过EduCloud平台，在下课之后，在宿舍利用便携完成老师布置的作业。这就解决了机房服务器问题，解决了网络带宽问题，解决了课上课下随时可以进行写作业的问题。2、  使用华为云DevCloud +《敏捷江湖桃花岛》项目进行实训教学。 理由：该课程结合高校实际教学场景，从棉花糖挑战赛这个游戏，引出对现代软件工程的认识，从而引出敏捷及scrum开发的相关概念。 紧接着通过一个典型项目，分4个阶段分别就项目立项、产品规划、技术准备和Sprint开发进行了详细的介绍。结合实践项目，搭配软件开发云，帮助学生了解整个软件开发的开发过程。 从需求管理，项目管理，到代码开发、测试、代码托管、代码质量检查、编译构建、发布、部署、流水线等方面，了解敏捷开发的整体流程，为学生毕业后进入企业工作，提前做技术储备工作。通过《敏捷江湖桃花岛》项目实践教学，可以解决上述挑战中的问题2、3.图一：项目开发全景图  在大连人才培养也"上云" 华为云EduCloud首发上，对于华为云参与产教融合创新、培养高校人才的积极作用，大连交通大学副校长傅利斌表示，作为第一批通过华为云进行授课的学校，大连交通大学在学科建设、教学信息化、软件工程人才培养和学生就业方面取得积极进展——学生学习热情、教师工作干劲、教育教学质量得到提高，真正做到教师在教中教、学生在学中学，理论与实践结合。华为云助力高校培养信息人才的行动为中国经济转型和升级创造了新动力。图二：华为云DevCloud教育解决方案大连首发上线，大连交通大学副校长致辞 在实际教学过程中，华为方多次派出专家，去大连交通大学，与老师和同学一起，针对《敏捷江湖桃花岛》进行剖析和指导，模拟项目开发，团队组建分组等。带领同学们进行需求分析、Story编写、迭代任务制定、回顾会议召开、项目开发、代码提交和管理、代码检查、编译构建、发布、部署、流水线端到端拉通等等。同学们收益匪浅，通过实践活动，同学们了解了企业软件开发的真实流程，了解了很多在课堂上学不到的但进入企业工作却非常重要的知识。根据以学代练，通过《敏捷桃花岛》项目案例作为参考，同学们积极主动的进行实践，开发了几十个项目出来。图三：华为专家在大连交通大学现场授课  图四：大连交通大学基于《敏捷江湖桃花岛》项目进行项目实践开发情况 总结本次通过这门《敏捷江湖桃花岛》项目实践课程，进行校企合作的开展，将符合中华人民共和国教育部的全新的理念融入到教学当中去，通过课堂、课中、课后对学生进行全方位指导教学，整体上老师结合企业实践教学，效果更好，更满意。 学生通过实践项目进行参考练习，学到了课本上学不到的知识，为今后毕业进入企业工作，提前打好了坚实的铺垫。 校方也因引入产教融合，提升了学校的教学质量，真正做到理论与实践结合而满意，政府因引入华为云DevCloud教育解决方案，提高了本地产业人才能力，为本地产业发展融入新鲜血液，促进产业创新而开心。 当然，要让高校的所有软件类学生使用并提升他们的实际动手能力，我们还需要做很大的努力，今后我们将积极在政府的带领下，与高校老师进行深入合作互动，将更多的企业实践项目开放出来给高校进行教学，与学生进行充分的互动交流，提升教育水平，为培养创新型、复合型、应用型人才而努力奋斗。

作者：黄隽（Charlie）背景敏捷江湖桃花岛社区下线会议时，敏捷实践者问了很多关于估算的问题。作者在这里把具有共性的问题简单做了梳理。问题主要集中在团队只关心估算结果，也就是数字。再则团队经常在外界压力下过度承诺迭代目标。这两个比较集中的问题描述如下：问题一：团队只关心数字。计划会议大家只关心估算的数字，经常花费大量时间做估算，怎么办？问题二：团队过度承诺。有时候，团队被迫承诺过多的工作，迭代目标完不成，怎么办？团队用于估算时间过多，留给开发的时间会相应减少，大家工作紧张，状态不佳。团队过度承诺直接造成迭代目标不能完成，士气低落。以上弊端直接伤害敏捷团队，是敏捷团队保持稳定健康节奏的阻力。问题分析以上两个问题也是敏捷初始团队经常遇见的问题，现简单分析发生原因如下：问题一：团队只关心数字。团队从瀑布开发方式转为敏捷开发后，学习了敏捷Scrum框架，然后开始使用敏捷开发。他们知道其中有一个事件是迭代计划会议。在会上团队成员经常耗费大量时间做估算。常见对话：“这个估算数字合理吗，我们要不要再好好想想清楚？”因此团队常常陷入无休止的讨论中。团队狭隘的理解为，计划会议中最重要的事情就是估算，而估算最重要的事情就是得到每个用户故事完成所需要花费的精确时间，即数字。也就是说，团队过于追求数字的准确性，忽略了估算的真正核心价值。问题二：团队过度承诺。团队经常在产品上市日期已经确定的情况下过度承诺。因为时间紧迫，领导施压（与资金和绩效挂钩）。比如，领导经常说：“大家加把劲儿，我相信大家的能力，努力一下，这些需求你们是可以做完的，大家的表现会影响绩效评估，年底咱们多发点资金。”所以团队常常了了估算、一言堂（架构师说的算）、猜测工作量，最后造成过度估算，经常完成不了迭代目标。小结“团队只关心数字”和“团队过度承诺”两个问题是敏捷初始团队经常遇见的问题。从以上问题分析中可知，团队成员并没有了解估算的真正核心意义，导致团队狭隘地理解成估算就是要最后的数字，而且在有外部压力的情况下团队也顾不上认真估算，盲目地过度承诺工作内容。其实估算并不只是为了得到估算数字和不靠谱的承诺。我们先一起学习和了解什么是估算的核心内容，这样可以更好地理解估算，然后再针对以上2个问题进行解答。解决措施利用核心概念树立正确认识在这里，我们只考虑不了解核心概念而导致估算活动不理想的情况。还有其它情况可以导致估算活动不理想。比如，不会利用故事点估算、不会估算具体方法等。这两种情况我们在后续的2篇文章中给予解答。通过上一篇《估算第一篇：利用用户故事了解需求》相信了解了如何利用用户故事理解需求。如果对用户故事不太了解的朋友，建议可以花一点时间阅读上篇文章，也会有助于做好估算。现在我们一起了解一下估算的4个核心概念，以便理解估算，树立正确认识，然后才能更好地解答以上2个问题。估算的4个核心概念所对应解决的问题如下表所示：问题估算核心概念问题一：团队只关心数字。利用“区分准确与精确”：估算应该准确，但不必过分精确。利用“估算相对大小”：人们更擅长对大小进行估算，而不是绝对大小。问题二：团队过度承诺。利用“团队一起估算”：在估算活动中，团队成员一起估算，结果更合理。利用“估算不是盲目承诺”：估算不是承诺，重要的是我们不能这样认为。区分准确与精确估算应该准确，但不必过分精确。比如，我们估算某产品是10888人时（是怎么做到这么精确的？）。其实这是很荒唐的，过于精确的估算纯属浪费。我们需要应该投入刚好够用的工作量，得到一个刚好的、大致正确的估值，如做估算时工作量和准确度的对比图所示：做估算时工作量和准确度的对比图在做估算时，有一个收益递减的点，在这个点之外，额外投入任何时间和精力都不会使估算更准确。在这个点之外，就属于浪费时间。团队成员在做一项工作的同时，难免会遇到各种各样的问题，所以为了做到准确估算，在做估算时，任务的拆分一定要适当细，只有细化后，团队成员才清楚每项工作预计会花多少时间。当然细化也是有个度的，如前面提到的做估算时工作量和准确度的对比。当团队成员反馈超过预计工时时，需要了解是不是遇到了什么困难，需不需要帮助解决。超过16小时的任务建议需要再细化。在做估算时，我们经常会填写预计工时和实际工时。预计工时是我们估算的结果，实际工时是对估算结果的检验。我们允许预计工时的不准确，但是一定要填写准确的实际工时，这样才有助于我们在估算不准的问题上有充分的证据做分析，然后改进，进行良性循环。随着团队成熟度的提高和对业务的越来越了解，估算准确度经过几个Sprint会有所提高。估算相对大小建议使用相对大小而不是绝对大小来估算PBI。比较所有条目，然后确定某个条目和其它条目的相对大小。如下图所示，讨论一个杯子相对于另一个有多大比较容易，但对于杯子中可以盛多少绝对数量的液体，我们可能没有概念。相对大小对比图人们更擅长对大小进行估算，而不是绝对大小。让团队成员做估算，建议用大家都擅长的技术。当然，有些较成熟的团队，也可以借鉴历史数据和经验，直接应用工时或理想人天估算也并非不可。更多关于相对大小的内容介绍，可以阅读下一篇《如何估算第三篇：估算故事点》，其中会介绍一个具体实践，即故事点估算。团队一起估算而不是个别人估算在估算活动中，团队成员一起估算，而不是仅仅由项目经理、架构师、主要程序员估算。简单说，是负责完成工作的所有人，也就是指实际动手设计、构建并测试PBI的开发团队来估算。产品负责人和Scrum Master这两个角色都在场，但并不实际参与估算。产品负责人负责阐述PBI，并回答团队要求澄清的有关需求的问题。Scrum Master负责帮助指导和引导估算活动。最终的目的是开发团队能够一起确定每个PBI的大小，当然包括开发和测试的所有工作量。团队成员一起估算也是为了确保工作没有遗漏，不管怎么拆分任务，甚至是不拆分任务以story为最小颗粒度，那就按照story可以上线为标准来估算。如果团队非常关注每个人手头上的task，比如测试和开发人员手头上的task，那就没有统一标准，根据具体task内容估算。 记录工作项工时，可以参考华为云DevCloud，工作项工时显示如下图所示。需要客观估算而不是盲目承诺估算不是承诺，重要的是我们不能这样认为。举一个例子，如果在估算的时候告诉团队成员他们的估算正确性直接影响着他们的奖金和绩效，那么每个人都会给出一个比开始大得多的估值。估算应该是较为实际的估值，应该靠谱，我们不想因为外因而人工放大估算值，变成团队成员往上加和管理层往下减的抛球游戏。所以，团队成员在没有外因干扰情况下，大胆、放心的估算工作量，也就是估算预计工时。预计工时不仅仅是用于安排任务和估算本Sprint PBI在哪个时间点完成的,它还可以用于持续改进。预计工时就是估算需要多少时间可以完成，在Sprint进行中，会让团队成员根据实际情况去更新实际工时。例如，昨天更新4小时，今天又更新4小时，那就把实际工时更新为8小时。当Sprint结束后复盘时，我们会整体看这些预计工时和实际工时的数据，主要是为了提升团队/个人估算水平。如果估算和实际有明显差距，是需要深入分析的。本身也是期望通过估算促进做简单设计。应用正确认知处理问题，做好估算以上是估算的核心内容。现在我们回头看看之前的两个问题。问题一：团队只关心数字。面对这个问题，作者主张团队成员不要只是关心数字，还要关心投入产出比（ROI），避免浪费。另外还可以考虑采用更快、更易于理解的方式来进行估算。从估算的核心概念“准确与精确”中了解到，在做估算时，有一个收益递减的点，在这个点之外，额外投入任何时间和精力都不会使估算更准确。在这个点之外，就属于浪费时间。另外从估算的另一个核心概念“估算相对大小”中了解到，人们更擅长对大小进行估算，而不是绝对大小。让团队成员做估算，建议用大家都擅长的技术。因此，我们在做估算时：首先，要把握一个估算的适度准确原则，不要过度浪费。其次，为了降低难度，团队更好的达成一致意见，可以采用相对大小方式进行估算。问题二：团队过度承诺。面对这个问题，作者主张估算由真正完成工作的成员在安全的环境下大胆、放心地估算，避免过度承诺。从估算的核心概念“团队估算”中了解到，估算活动是负责完成工作的所有人，也就是指实际动手设计、构建并测试PBI的开发团队来完成。也就是说，真正完成工作的人才会对工作需求内容更用心，也更了解团队的速率，他们的承诺更客观。估算另一个核心概念“估算不是承诺”中提到，估算应该是较为实际的估值，应该靠谱，我们不想因为外因而人工放大估算值，变成团队成员往上加和管理层往下减的抛球游戏。团队成员在没有外因干扰情况下（不建议奖金、绩效明显挂钩），大胆、放心的估算工作量。如果能做到以上相信至少在估算的结果上更为客观和靠谱。有些朋友可能会问，如果得到的估算结果是靠谱的，完成需求就是那么多工作量，产品上市日期也已经确认，那么怎么办？如果真的是因为产品上市日期已定，有上线压力，团队一定要承诺过多的工作内容，那么就确保团队把故事拆分得更细，即使他们交付不出设想中的高档理想的全功能版，至少也能每个典型的功能领域多少交付一些内容。说到这里，还是不建议这样做，尽量采用高价值的事情优先做原则，与客户协商，产品经理对需求排好优先级，优先实现高优先级的PBI。了解更多以上是针对不了解估算核心概念而导致估算活动不理想的解决措施。朋友们看到这里，相信对估算的核心有了基本了解。也许对什么是故事点估算以及具体估算方法感兴趣，欢迎阅读接下来的关于估算的另外两篇文章，即《如何估算第三篇：利用故事点做估算》和《如何估算第四篇：利用2种常见方法做估算》。参考附录Kenneth S. Rubin. Scrum精髓[M].北京：清华大学出版社。Mark C. Layton. 敏捷项目管理[M].北京：人民邮电出版社。Rachel Davies. Liz Sedley.敏捷教练[M].北京：清华大学出版社。附件：如何估算第二篇：利用核心概念解决估算常见问题V1.2.pdf[hide]链接: https://pan.baidu.com/s/1qQHK_WxG_9YQOKIm8MO8aQ提取码: g6vn[/hide]

我们常见到Epic、Feature、Story和Task这些和敏捷相关的概念，它们之间的关系是什么？我们如何灵活使用这些概念，从而让敏捷的需求管理更为高效？本文为你解答，建议收藏。什么是Epic、Feature、Story和TaskEpic、Feature、Story和Task用来划分需求颗粒度的标签，可以看作需求占位符，分别代表需求颗粒度从大到小。每个层级的需求本身又承载着一些意义，在进行需求划分的时候可以进行参考。Epic：史诗，是项目的愿景目标。通过Epic的落地达成，使公司可以获得相应的市场地位和回报，具有战略价值。通常需要数月完成。Feature：可以带来价值的产品功能和特性。相比Epic，Feature更具体，更形象，客户可以感知，具有业务价值。通常需要数周，多个Sprint才能够完成。Story：通常所说的用户故事，是User Story的简称。是从用户角度对产品功能的详细描述，承接Feature，并放入产品Backlog中，持续规划，滚动调整，始终让高优先级Story交付给客户，具有用户价值。Story要符合INVEST原则（Idependent, Negotiable,Valuable,Estimable,Small,Testable），通常需要数天，并在一个Sprint中完成。Task：是团队成员要完成的具体任务。在Sprint计划会议上，将Story分配给成员，然后由成员分解为Task，并预估工时，通常在一天内完成。  将上面的描述简单整理，如下表所示。它们之间关系是什么Epic-Feature-Story-Task是一种将需求进行结构化管理的方法，在使用时是从上到下逐层分解，形成自下而上的依赖。如下图所示。在实际的开发过程中，需求会发生变化，我们要不断的调整，在调整中避免偏离目标方向，每次新建需求的时候都要记得向上对齐到Epic，保证所添加的Story和Task和它们上层是有关联的，这样就可以在一定程度上保证团队在朝着目标前进。更多关于需求结构化管理的内容，请阅读【参考附录】【DevCloud· 敏捷智库】如何进行需求结构化管理？。我们如何灵活使用这些概念，让需求管理更为高效为了帮助大家加深对 Epic、Feature、Story和Task的理解，我们对一个案例进行需求拆分，过程中会结合项目管理平台进行展示，以华为云DevCoud为例。案例：某大型商超受互联网的冲击，营业额大幅下滑。为了减少门店消费者流失，保有市场地位和份额，决定用6个月的时间建立自己的网上商城。第一步： Epic确定和创建根据前面的介绍，在进行需求确认的时候先看颗粒度，然后再考虑其承载意义。※思考：一个产品是一个Epic吗？产品的每个业务模块是Epic还是Feature？产品通常具有战略意义，从这个角度看，产品适合作为一个Epic。但是不是所有的产品都适合，还要看产品是什么，它的颗粒度有多大。在本文的实例中，网上商城周期是6个月，目的是保有市场份额，从颗粒度和战略意义上，网上商城适合作为一个Epic。每个业务模块具体是Epic还是Feature要分情况。比如：构建智慧城市是一个愿景目标，下面包括智慧交通，智慧政务，智慧社区等，这些每个业务模块都很大，用Epic进行需求占位合适一些。我们在DevCoud创建一个Scrum项目，命名为某大型商超网上商城，进入到【需求规划】的界面，在【Epic】下面新建，如下图所示。新建之后，点击进入到详细编辑界面。将描述信息填写完整，可以使用DevCloud提供的模板，如下：作为 <用户角色> ，对于这个Epic来说，用户角色是整个公司。我想要 <结果>，想要的结果就是建造网上商城。以便于 <目的> ，目的是想要减少消费者流失，保有市场地位和份额。同时在基本信息中设定这个Epic的起止时间，优先级，重要程度，预计工时等信息。这些信息对于团队理解产品、理解项目起到至关重要的作用，所以要填写详细。编辑界面如下图所示。第二步：将Epic分解为Feature客户要求在6个月内交付5个功能模块：促销管理、会员管理、订单管理、配送管理和客户端。团队的一个Sprint是2个星期，每个模块大概需要2-3个Sprint完成，从颗粒度和承载的意义，这5个模块适合作为Feature。创建如下。创建之后，如需要填写详细信息，可以在详细页面进行编辑。界面信息项和前面Epic的相同，此处不再赘述。第三步：Feature分解为Story敏捷开发是渐进明细的，不要求所有需求在相同时间做到同样详细，只要求当前Sprint和未来的一个或两个Sprint的Story是详细的。将来Sprint的Story可以是一个大概的情况。进入到当前Sprint的Story要符合INVEST原则。开发团队要在Sprint结束时完成交付。客户优先级中，会员管理Feature优先级高，会员管理这个Feature就要在需求梳理会议上详细分解为Story放入到产品Backlog中。经过分解后，需要包含和管理员相关的以下功能: 积分管理、会员级别管理、用户分析、用户管理。这些具体的功能就可以作为Story。需要注意的是，我们分解出的Story要尽量在一个迭代内完成交付，如果无法完成就尝试继续分解。因为只有交付的Story才是有价值的，无法交付的Story对于当前Sprint来说就是浪费。分解后的Story如下图所示。第四步：将Story划分为Task在Sprint计划会议上，团队和PO要共同从产品Backlog中按照优先级顺序选择本次Sprint需要完成的Story，进入到冲刺Backlog中。团队成员认领后，将Story分解为Task，并进行估算。※思考：Story和Task如何区分？Story聚焦价值，需要在Sprint中完成，要用数天的时间，要符合INVEST原则。Story的描述是一个名词，如积分管理这个Story的完整描述是：作为管理员，我能够进行会员的积分管理，以此来划分消费等级提供不同增值服务。Task聚焦实现价值，通过过程性的任务来实现Story的功能。通常是1-8个小时。Task的描述是一个动作。如积分管理这个Story，功能的实现需要通过业务逻辑开发，积分规则设计和积分数据库设计这几个过程来完成。这些就是Task。如下所示。这样，从Epic开始，到Task结束，我们完成了网上商城的需求拆分。总结：使用Epic、Feature、Story、Task管理需求时，需要注意以下几个方面。1.敏捷开发中需求是逐步细化的，遵循自上而下的方式去分解需求。2.Epic和Feature都是颗粒度比较大的需求，是用户对于产品的期望和功能特性的描述。3.分解为Story的时候，目前正在进行的Sprint需要分的更小更细，将来的Sprint需求（可能是3个及以上）就不需要那样细分。当进行到某个Sprint时，再进行分解，细分成一组更小、更细的条目。4.只有当前Sprint的Story进行Task分解。5.所有这些粗略和详细的Story都放在产品Backlog中，整个列表要遵循DEEP( Detailed appropriately, Emergent , Estimated , Prioritized )原则，定期梳理和排序优化，保证高优先级的需求优先实现和交付。6.在整个过程中需要和客户一直保持沟通合作，这样才能保证我们实现的功能是客户真正想要的。写在最后本文通过一个用户场景来帮助大家理解Epic、Feature、Story、Task的含义以及如何使用。因为没有相同的项目，所以在开发过程中还要结合产品和业务本身的特点，进行具体问题具体分析。为了更好的分析问题，我们需要扎实的掌握Epic、Feature、Story、Task的含义并理解他们之间的关系。相信随着大家深度使用，一定能运用的得心应手。敏捷路上，你我同行！参考附录1、Kenneth S. Rubin. Scrum精髓[M].北京：清华大学出版社。2、Mike Cohn.用户故事与敏捷方法[M].北京：清华大学出版社。3、【DevCloud· 敏捷智库】如何进行需求结构化管理？4、文章博客地址：https://bbs.huaweicloud.com/blogs/142259附件：【DevCloud•敏捷智库】读懂敏捷需求管理的4个关键词.pdf [hide]链接: https://pan.baidu.com/s/1O6viir4TtSoC2jWmRDfe_w提取码: diq8[/hide]

作者：黄隽（Charlie）背景很多团队在应用敏捷开发时，对估算经常感到困惑。这里所说的估算是指产品列表条目（PBI, Product Backlog Item）的估算 。比如，估算以什么标准进行？开发、测试的工作量都要估算进去吗？又比如，估算出了预计工时，但是实际工作中这个预计工时经常不准，为什么还要估算这个预计工时呢？还有，做估算管理时，实际工时也会经常被使用，但很多团队成员不按实际情况做实际工时的更新，它的意义何在？问题分析为什么做估算呢？在规划和管理产品开发过程中，我们需要回答一些重要的问题，例如：“将要完成多少个特性？”“我们什么时候做完？”在使用敏捷时，为了能回答这些问题，我们需要估算产品的工作量大小并测算工作速率。有了这些信息，用特性集的估值除以团队速率，我们就能推算出产品开发的持续周期了。从小目标来讲，做好了估算也可以很好的理解需求，帮助团队成员认领任务。换句话说，团队成员通过估算过程（持续沟通、确认）达成对需求的理解一致，明确完成定义是最重要的。团队之所以做不好估算，首先是因为没有足够细化需求，更不了解敏捷估算的几个重要核心概念 ，即：“团队估算”、“估算不是承诺”、“要准确，而不是精确”和“使用相对值，而不是绝对值”。其次是不了解估算的正确方法 。这篇文章主要解决因为不能很好地理解需求而估算做不好的问题，在这里可以了解下如何利用用户故事了解需求。解决措施估算有这么些重要的意义，以下关于估算的内容是针对认可估算有意义，但是做不好的情况下给予的估算解决方案。如何更清楚的了解和细化需求是第一步，细化需求和估算是一对儿不能拆分的“鸳鸯”。然后再学习准确的估算，解决估算的各种困惑。要想准确的估算，先要了解和细化需求，同时了解需求很好的一种描述方法，即User Story。然后了解故事点以及什么是估算及估算的核心概念。基于以上了解后再研究估算方法的实践，最后选择适合的估算方法完成估算活动。可以参考如下示意图便于理解。本篇主要介绍如何了解和细化需求，后面几篇会分别介绍估算核心概念、故事点、估算实践方法和完成估算等内容,即：《如何估算第一篇：利用用户故事了解需求》、《如何估算第二篇：估算的核心》、《如何估算第三篇：估算故事点》和《如何估算第四篇：常见估算方法》。如何了解和细化需求，要先从用户故事开始聊起。什么是用户故事？用户故事是可用于陈述业务价值的一种简便格式，适合各种PBI,特别是特性。用户故事的制作方式旨在帮助业务人员和技术人员双方都能更好的理解需求。一个编写良好的用户故事是敏捷开发的基础。编写用户故事的过程就是了解需求，一点点细化需求的过程。需求了解清楚了，一定程度上讲估算的工作就已经完成了一大半，在不了解需求的情况下，估算也是没有意义的。需求的了解是渐近明细的，很多情况下用户的角度看是一种情况，开发人员角度看是另一种情况，这种误解在需求了解阶段经常出现，如下图。理解需求误区图我们一起看看，为什么说用户故事写好了就了解需求了呢？一个良好的用户故事应该是相对独立的、详情应该是便于开发者和用户沟通的、应该对用户是有价值的、应该对于开发者来说尽可能的清晰以便进行估算的、应该短小的、通过预定义测试用例的使用确保它是可以测试的。以上的特点具备了，相信写出来的用户故事是在了解了用户最初的需求基础之上。其实，这些特点有一个名称“INVEST原则”，是极限编程（英语简写XP,是敏捷开发方法之一）中对用户故事拆分的指导原则。INVEST原则用于评估用户故事，也就是说，好的用户故事应该具备INVEST特性：即独立的（Independent）、可协商的（Negotiable）、有价值的（Valuable）、可估算的（Estimatable）、大小适合的（Small）和可测试的（Testable）。用户故事究竟是什么呢,如何才能写好用户故事？极限编程（XP）的创始人之一Ron Jeffries给出一个简单有效的方法来帮助我们理解用户故事。他将它描述为3C：卡片、会话和确认。了解了3C也就大概清楚了怎么样才能写好一个用户故事，以及为工作量估算做好基础准备工作。 卡片卡片非常简单，最初可以写在便利贴上，有一个通用的格式，如下面用户故事模板图，即写明用户种类（即用户角色）、这类用户想要达成什么（目标）以及用户为什么想达成目标（收益）。用户故事标题的命名也是有讲究的，在辅导团队过程中发现有些团队的用户故事名称不统一，容易对团队造成困扰。例如，有的名称太长，甚至是长长的一段话；有的太短，不能清晰的识别用户核心内容是什么；有的没有价值，就是普通的任务（Task）。建议采用统一的动宾短语写出较好的用户故事标题：用户角度描述从用户角度看到的功能。例如，查看详细信息、新增查询、删除货品等。系统角度描述从待开发的系统的角度要实现的功能。例如，推送合同信息、发送用户订阅信息等。当然，你也许会有个疑问。这些标题都没有主语，好像也不太能快速识别用户故事的核心内容。Of course，如果你想更清楚表达，也是可以加上主语的。比如，新注册用户查看详细信息、库存管理员查询商品号、HR系统群发助手发送订阅信息等。不过，更想说的是，更详细的信息建议在卡片内容中说明，因为里面写明了用户种类（即用户角色）、这类用户想要达成什么（目标）以及用户为什么想达成目标（收益）。用户故事标题还是以简单、明了为主。用户故事卡片模板图 对话在对话中讨论需求细节。开发团队、产品负责人（PO, Product Owner）利益干系人在对话中发现并探讨需求的细节。用户故事仅仅是进行此对话的承诺。用户故事的一大好处就是它能把关注点从写作转移到会话。对话开启了一个更丰富的信息交换与协作形式，从而确保正确描述需求并使每个人都能理解需求。对话不仅仅是靠口头交流，还可以而且经常借助于文档，也可得出可以记下来的一张用户界面草图或业务规则的一份详细阐述。 确认用户故事还要包含确认信息，也就是我们常说的接收标准（AC, Acceptance Criteria）。有了接收标准，开发团队才更清楚要构建和测试什么，产品负责人也可以确认用户故事的实现是否符合预期。这些定义的接收标准也可以看作是高一级的接收测试。当然，开发故事的时候不会只有这几个测试，这些与故事挂钩的接收测试之所以存在，是因为从产品负责人的角度看，它们是捕获及沟通信息、确定故事是否已经正确实现的重要方式之一。我们了解了用户故事和它的3C原则，现在来看看怎么写一个好的用户故事，来更好地分析和理解需求。我们知道了用户故事的模板内容，看着非常简单，然而越简单的东西，反而越容易让人放松警惕，然后照着模板内容写出来的并不是一个很好的能够理解需求的故事。举例，一个餐饮点评网站的用户故事可能会这样写：作为一个用户，我希望看到某个地址附近的餐馆的公正的评论，这样可以决定去哪里吃饭。其实，这就是一个典型的质量不高的用户故事。写出高质量的用户故事的关键在于是否能够准确地描述用户希望获取的价值。这个观点只对了一部分，就像上面的故事一样。大家可能会问，既然用户希望获取的价值都描述清楚了，为什么客户还不接受呢？主要原因是你高估了自己的理解能力和表达能力，同时也高估了客户的理解能力和表达能力。如上面提到过的理解需求误区图，客户的角度看需求是“6”，需求调研人员角度理解的是“9”，这也是常见的需求理解问题。再来看另外一个例子：作为一个在国贸工作，午休时间短，又追求健康饮食的公司白领，我希望看到某个地址附近的餐馆的客观的评论，这样可以决定去哪里吃饭。可见，第二个故事中，感觉好多了。仔细看看差在哪里呢？熟悉需求调研的伙伴儿们都知道，需求调研是从了解客户是谁开始的，需要弄清楚产品需要获得什么样的客户的认可和接受，利用“对话”原则，充分沟通。这个故事描述了用户的特征，站在用户角度思考，更能够提升最终交付物为客户接受的可能性。同时，还要定义清楚什么是“接收标准”，与客户确认清楚具体的条件。这个故事的接收标准可以参考接收标准参考内容图：接收标准参考内容图现在可以了解怎么写好用户故事，以及如何更好地理解客户需求了。对需求有了更好的理解，接下来需要再了解一下估算的核心，《估算第二篇：估算的核心》以便更好地完成估算。参考附录1. Kenneth S. Rubin. Scrum精髓[M].北京：清华大学出版社。2. Mark C. Layton. 敏捷项目管理[M].北京：人民邮电出版社。----------------------------------------------作者随笔作为敏捷推广者和马拉松爱好者，聊聊敏捷与马拉松。一个胖子想变成瘦子，方法很多，比如无氧器械、疯狂单车、要命波比跳，当然还有马拉松。近年来马拉松被炒得火热，引得大家蜂拥而至。马拉松看似简单，实际上一个优秀的跑者是需要长年的基础训练和日积月累的跑量。有些人参加拉松是为了赶时髦，全凭三分热度，急于求成。往往前者已达终点，后者却在半路怀疑人生，早早弃赛。敏捷转型就像马拉松一样：理论实践vs基础训练，稳定速率vs平稳配速，定期回顾vs适时补给，持续改善vs健康奔跑，团队稳定vs跑得长久，个人有所长，团队全功能vs个人跑得快，群体跑得远。如果没有夜以继日的“内功”修炼，想要一朝练成“碧海潮生曲”，无疑是天方夜谭，必以失败告终。—敏捷江湖桃花岛 黄药师附件：如何估算第一篇：利用用户故事了解需求V1.0.pdf[hide]链接: https://pan.baidu.com/s/1yTVQoyD3gblF5Z6e1Ht7cA提取码: dzjv[/hide]

背景在华为云专家团队拜访某企业时，遇到了这样的一个问题，随着业务的扩张，新员工不断加入，其开发组长要对每一位新人交代相关的知识点、工作方式以及团队信息等，工作量在短期内激增……在一个项目中,随着时间推移、业务的扩张，项目中的核心成员，如项目经理、开发组长等往往都会面临如下几种情况和挑战：新员工加入，需要诸多方面的培养（培训），以便能快速进入工作状态。 老员工的离职，导致项目中缺少能了解和掌握关键技术和业务的人员。员工在工作了一段时间后，对自己的规划有了新的想法，从而想要转换工作方向。那么，项目负责人应该如何应对这些事件呢？问题分析一个项目在从小到大的过程中，项目团队也势必扩张，面临新员工的加入。新员工对刚接触的项目不够熟悉，所以针对新员工的培养（培训）是非常有必要投入人员配置的。项目发展过渡到平稳期的时候，可能会因为公司体质、薪资待遇、员工身心疲惫等原因，出现老员工的离职等情况，如果离职的老员工是核心骨干，就可能导致某些如业务无人知晓、关键技术断层等风险，当然在此期间，也包括老员工随着项目的延续，慢慢产生了对原来工作厌倦，或者因认知的提升以想要寻求一些新的工作内容，进而做了转型的打算。所以上述问题，如果没有得到较好的解决，将会影响到项目的进度和造成不必要的开销，甚至对于团队内部成长、自组织能力的发展建设也是不利的。所以问题的关键，仍旧是新人的培养。解决措施一般来说，在针对新员工加入所带来的内耗、关键核心人员的离职风险、个人发展转型等情况的应对，可以从团队信息、工作方式以及知识管理三方面来通过建立信息管理库进行解决。DevCloud是集华为研发实践、前沿研发理念、先进研发工具为一体的研发云平台（更多了解请见附件或官网），也是笔者目前在使用的。以DevCloud为例，在DevCloud中提供了Wiki服务。Wiki本身是一种以知识库文档为中心，共同创作为手段，依靠众人不断地更新修改为实现的多人协作的工具。我们可以通过Wiki来管理和搭建项目或团队内的信息管理库，以达到有知识点可留存，有基本信息可查的目的，参考如下：团队信息用来记录项目团队的职能划分，职责担当等。当新人入职时，可以通过在Wiki中的团队信息，了解团队的组织分工等。这样一方面可以让新员工对团队人员分工有所了解方便日后的交流，另一方面也能让具备较高能力的新员工根据团队组织分工现状提出改善意见等。工作方式团队需要制定团队内的工作方式，如对开发流程、代码的管理、需求的变更等，团队统一按照要求进行工作。当有新员工加入，可以通过Wiki中的工作方式，了解相关流程等进而快速开展工作，同时也减轻了老员工在工作方式上对新员工的培训所带来的消耗。知识管理知识管理对于项目和团队是最重要的，大部分的产品都需要技术相关的输出整理，无论是基于现有项目进行维护，还是重构，开发新的应用，做知识整理都是不可或缺的。这种必要性在于，当新员工加入后，可以通过知识管理的学习了解项目所用技术框架，进而快速上手工作；当老员工离职，团队因有了Wiki对技术、框架、业务等知识的相关管理，可以较好的应对离职所带来没有backup、没有其他人懂某项技术、没有其他人知道某段业务逻辑等带来的影响；当员工内部转岗或转变业务技术方向时，可以帮助其相关知识，有助于更好的帮助提升跨专业技能。更多关于Wiki的相关内容请参见，参考附录。参考附录Wiki网站:维基百科DevCloud使用指南：DevCloud Wiki使用指南关联文章项目团队人员变动频繁，如何对新人进行有效培养和管理？

“敏捷江湖桃花岛”侠客行项目基于华为云DevCloud服务课程介绍课程概述：敏捷江湖桃花岛是侠客行项目，通过深入浅出的讲解，从棉花糖挑战认识现代软件工程的敏捷开发，帮助企业快速进行敏捷转型。本课程结合高校实际教学场景，从棉花糖挑战赛这个游戏，引出对现代软件工程的认识，从而引出敏捷及scrum开发的相关概念。 紧接着通过一个典型项目，分4个阶段分别就项目立项、产品规划、技术准备和Sprint开发进行了详细的介绍。结合实践项目，搭配软件开发云，帮助学生了解整个软件开发的开发过程。 从需求管理，项目管理，到代码开发、测试、代码托管、代码质量检查、编译构建、发布、部署、流水线等方面，了解敏捷开发的整体流程，为学生毕业后进入企业工作，提前做技术储备工作。材料数作业数实训项目迭代数需求任务数代码量7420430040k 作者介绍华为云教育，本课程由华为云教育内容开发团队开发完成，团队主要负责教育解决方案内容开发和建设。包括但不限于课件、视频、习题、代码、案例项目、实训课等。  课程定位：本课程知识点涵盖敏捷Scrum、前端、后端、Cloud四大开发方向，项目跨度涵盖整个大学所学知识的连接，适合于高年级的学生来学习实践。在学完本次课程之后，会对本课程中之前所学相关的Java、Javascript、Scala等语法知识更能融会贯通，由于本次实践为学生自行立项组队，其中多角色划分会让学生对企业中岗位职责有初步的认识，为将来求职面试及发展规划打好坚实基础。岗位及从业方向：岗位：项目经理、产品经理、Scrum Master、UI、前端开发工程师，后端开发工程师，架构开发工程师、测试工程师等岗位。从业方向：项目管理、UI设计、产品研发、软件开发、测试、运维等。 前/后导课程：本课程是一门实践课程，既要掌握概念，又要团队配合，还要上机编程运行。其前导课会覆盖之前所学全部知识内容，是所学知识的一次串联与总结，其中有《C语言实践教学精品课》、《Web实践教学精品课》、《数据结构（C语言）实践教学精品课》《JAVA-实践教学精品课》《系统分析与设计》等本课程的主要任务是：1．通过学习本课程，学生可以掌握基本的项目级软件开发的全过程。2．了解敏捷Scrum开发方法，在其中体会到团队协作的工作方式。3．具备初步的高级语言程序设计能力及项目开发的能力。4. 项目完成后，基本达到入职企业所需具备的软件开发职业素质。5．培养学生严肃，认真一丝不苟的工作作风。培养学生积极思考，通过团队中不同角色的深入，锻炼思维能力，培养创新能力。 本课程知识教学目标：        1． 了解程敏捷及Scrum的基本知识。2． 了解如何组建团队立项并展示。3． 了解产品规划及原型设计并展示。4． 掌握前端开发流程。5． 掌握后端开发流程。6． 掌握云上工具的使用。7． 掌握Scrum五大事件并按照流程展示。。8． 了解可视化管理。 教学大纲：从棉花糖挑战认识现代软件工程1)     通过游戏初探敏捷2)     敏捷的历史背景3)     敏捷思维4)     Scrum概述通过本章节的学习，学生可以：1)     了解敏捷的背景2)     掌握敏捷宣言及原则3)     理解什么Scrum框架 项目实战第一阶段：项目立项1)     如何立项2)     如何组建团队3)     团队立项展示通过本章节的学习，学生可以：1)     在Devcloud上创建项目并添加成员分工2)     团队讨论进行立项书的书写3)     团队进行立项书的展示，增强实践代入感 项目实战第二阶段：产品规划 1)     收集需求，进行需求管理2)     书写用户故事，生成产品待办列表3)     了解用户故事地图4)     了解MVP，进行产品版本规划5)     了解原型设计，并展示通过本章节的学习，学生可以：1)     在Devcloud上进行需求管理生成产品待办列表2)     掌握书写评估用户故事的方法3)     在了解MVP的基础上，团队进行自己产品的版本规划4)     团队自主进行低保真原型设计并进行串讲 项目实战第三阶段：技术准备1)     前端准备2)     后端准备3)     高保真原型设计串讲4)     技术准备示例代码展示通过本章节的学习，学生可以：1)     掌握Devcloud的操作使用2)     了解前端的开发流程，前端环境的搭建，及前端技术选型3)     了解后端的开发流程，后端环境的搭建，及后端技术选型4)     掌握前后端示例代码的编写5)     了解高保真原型设计并串讲 项目实战第四阶段：Sprint开发1)     理解Sprint迭代概念2)     进行迭代计划会议，并生成迭代待办列表3)     进行每日站会并记录4)     团队自主完成迭代的开发5)     进行迭代评审会议并展示6)     进行迭代回顾会议并记录7)     了解功能测试及BUG管理8)     了解可视化管理通过本部分的学习，使学生：1)     在Devcloud上进行迭代的开发，编译构建，部署发布2)     熟练掌握计划会议中优先级，增量的概念3)     团队内部每日站会中体会到各自工作4)     对本次迭代的输出产物进行展示评审5)     在回顾会议中体会到团队的问题暴露并改正 课时建议：序号课 程 内 容学  时  数合计理论教学实践教学实训教学教学实习1从棉花糖挑战认识现代软件工程3212项目实战第一阶段：项目立项41033项目实战第二阶段：产品规划52034项目实战第三阶段：技术准备40045项目实战第四阶段：Sprint开发102086项目实战学生自主阶段1000100总计367029 教学过程与方法目标：建议在进行该课程的教学过程中，充分利用Devcloud平台对敏捷团队以及项目的管理功能，在课堂上尽量让学生自己来研究，团队一起商量来展示，把课堂留给学生而不是老师单方面的灌输知识，实现“翻转课堂“在每个阶段之后，都设有不同的团队展示环节，可以将整个课堂交给学生，每个团队控制在在10~15分钟内，老师可以在这个过程中观看每组的情况，针对团队进展情况并进行当场评价，针对学生理解错误的知识点可以再次解答。 通过在Devcloud中，老师可以监控每个团队的项目进展状况，及时了解学生对该章节知识点的掌握情况，以便阶段性的基于落后的团队予以督促指导。在进行到第四阶段后，可以结合学生完成情况，增加相同的迭代阶段，引导学生自主来进行迭代相关的工作，以便帮助学生顺利完成整个项目实践任务。 考核要求：序号条目分值考核要求1Story录入10是否有Story在这个迭代；Story填写开始时间和结束时间(注意不要所有Story结束时间填写为迭代结束时间)；Story预计工时是否录入；Story描述是否完整；Story对应的原型设计；Story分配、分解；关联Story的测试用例；Story关联代码fix id；Story开发过程中，刷新完成度；Story的状态要有变化。新建->进行中->已解决->测试中->已关闭。2原型设计5新增需求都要补充原型设计。归档到文档管理服务。3DBA5补充数据库表结构。每轮迭代数据库变更需要记录，变更过程归档到wiki。最终表结构说明归档到文档管理服务。4每日站会5wiki里记录每日站会情况，每次迭代至少五次5燃尽图2燃尽图一定是符合规律的下行曲线。6Story/Task完成情况3本轮迭代要对所有的Story、Task进行关闭。如果有超期的，备注里说明超期原因，和PO协商放到下轮迭代。如果所有Story都未完成，需要申请迭代延期。7需求覆盖率5需求覆盖率100%。8测试用例完整5确保测试用例覆盖功能、性能、安全、可靠性等领域。9缺陷管理5要有问题单、并且对问题单进行闭环。缺陷越多，证明测试执行的越好。10用例完成率5用例经过新建、设计中、测试中、已完成 四个状态，迭代最终要确保所有用例状态是已完成。11代码质量检查（加分项5分）使用代码检查服务，对devlop分支进行代码检查。自学。12代码分支创建是否合理5人人有自己的分支，每个人代码写完、自验证通过，提交到develop分支，develop分支作为统计每个人贡献度的分支。Develop分支验收通过后，可以由一个人（PL或SE）统一提交到master分支。13打标签5每轮迭代验收通过，正式发布前，需要对Master分支打版本标签。14代码贡献度5要求人人都必须有代码贡献（devlop代码统计提交代码量），并检查是否提交合理，严禁无效代码提交。15代码关联需求、问题5代码提交时，必须关联一个需求、或缺陷（fix id的方式commit）。针对无关联的提交，commit里面必须说明原因。16构建出包2创建一个构建任务，完成出包。17发布归档1在构建任务里配置归档路径，归档到发布仓库服务。18部署2创建一个部署任务，能贵将包部署到目标服务器。19流水线执行5将代码检查（如果有）、出包、部署过程自动化，通过流水线服务串联。20迭代验收10客户+全员进行本轮迭代效果演示，获得客户反馈，整理归档到文档管理服务。21迭代回顾10识别迭代过程中出现的问题，不达标项目进行全员回顾，整理归档到文档管理服务。 参考文献：《Scrum官方指南》 由Ken Schwaber和Jeff Sutherland开发并维护