1、敏捷开发全景视图敏捷开发全景视图（流程、方法和最佳实践）（流程、方法和最佳实践）钟玮军钟玮军2016-02-25目 录 Contents敏捷 vs 传统敏捷开发流程框架敏捷方法和最佳实践思考与答疑敏捷 vs 传统IT项目管理方法的发展历史项目管理方法的发展历史196019701980199020002010SDLCWATERFALLRADPMBOKITILPRINCEZachmanDSDMRUPXPPRINCE2CRYSTALSCRUMAGILEMANIFESTOFEATOGAF 8.0LEAN KANBAN软件开发生命周期（软件开发生命周期（SDLC）https:/en.wikipedia.
2、org/wiki/Systems_development_life_cycle传统软件开发模式传统软件开发模式传统瀑布式软件开发方式向迭代式软件开发方式转变（RUP框架）http:/ 交付周期长；害怕需求变更；中间过程不可控；测试周期被一缩再缩；最终结果差强人意 与“唯快不破”的互联网经济格格不入l敏捷软件开发模式敏捷软件开发模式 由传统迭代式软件开发模式发展而来，Time-Boxed 抛开传统软件开发模式的繁文缛节，强调产品价值、团队协作、客户参与、先期验证、简化流程、拥抱变化 总结吸收成功软件项目研发的最佳实践；与现代管理思想相辅相成 前期有学习成本，后期会获益匪浅敏捷软件开发模式敏捷软件
3、开发模式Source:Forrester Research,Inc.趋势：敏捷开发逐渐成为主流趋势：敏捷开发逐渐成为主流模式模式2009 Q32014Growth敏捷开发带来的好处敏捷开发带来的好处TOP 5 reported benefits:Improved quality(56%)More opportunities for mid-course corrections(56%)Overall improved customer and business satisfaction(38%)Better business-IT alignment(37%)Improved time to
4、market(32%)A lot more than velocity质量改善利于中途修正总体改善客户和业务的满意度商业需求与IT实施更加匹配更快投入市场Source:2013 Forrester Research,Inc.敏捷开发宣言敏捷开发宣言lManifesto for Agile Software Development Individuals and interactions over processes and tools 人和交互 重于 过程和工具 Working software over comprehensive documentation 可以工作的软件 重于 面面俱到的
5、文档 Customer collaboration over contract negotiation 客户合作 重于 合同谈判 Responding to change over following a plan 随时应对变化 重于 遵循计划l虽然右边也有其价值，但我们认为左项更加重要虽然右边也有其价值，但我们认为左项更加重要敏捷原则敏捷原则(Agile Principles)1.Satisfy the Customer2.Welcome Change3.Deliver Frequently4.Work as a Team5.Motivate People6.Communicate Face
6、-to-Face7.Measure Working Software8.Maintain Constant Pace9.Excel at Quality10.Keep it Simple11.Evolve Designs12.Reflect Regularly敏捷开发价值观敏捷开发价值观 专注专注：由于我们在一段时间内只专注于少数几件事情，所以我们可以很好地合作并获得优质的产出。我们能够更快地交付有价值的事项。公开公开：在团队合作中，大家都会表达我们做得如何，以及遇到的障碍。我们发现将担忧说出来是一件好事，因为只有这样才能让这些担忧及时得到解决。尊重尊重：因为我们在一起工作，分享和成功失败，这
7、有助于培养并加深互相之间的尊重，并帮助彼此成为值得尊重的人。承诺承诺：由于对自己的命运有更大的掌握，我们会有更坚强的信念获得成功。勇气勇气：因为我们不得单打独斗，我们能够感受到支持，而且掌握更多的资源。这一切赋予我们勇气去迎接更大的挑战。从传统到敏捷：思维的转变从传统到敏捷：思维的转变 形而上者谓之道，形而下者谓之器。形而上者起于学、行于理、止于道，形而下者起于教、行于法、止于术。l从重视从重视“流程流程”到重视到重视“原则原则”道本器末，不忘初心 做正确的事比正确地做事更重要l如何看待流程、方法、最佳实践在敏捷开发中的作用如何看待流程、方法、最佳实践在敏捷开发中的作用 无其器则无其道，器和道
8、一样重要 上善若水，原则的“刚性”和流程的“柔性”从传统到敏捷：认识误区从传统到敏捷：认识误区从传统到敏捷：阻碍和要点从传统到敏捷：阻碍和要点改变我们的商业文化采用敏捷技术实践改变我们的IT文化以一种敏捷的态度使用我们现有的工具采用新的敏捷开发工具采用敏捷管理实践从传统到敏捷：关键因素从传统到敏捷：关键因素改变我们的商业文化采用敏捷管理实践改变我们的IT文化采用敏捷技术实践采用新的敏捷开发工具以一种敏捷的态度使用我们现有的工具敏捷开发流程框架产品研发：一个持续的过程产品研发：一个持续的过程WhatWhat？HowHow？Management is doing things right;lead
9、ership is doing the right things.(Peter Drucker)敏捷开发流程框架：敏捷开发流程框架：Scrum注：Scrum是最为流行的敏捷开发流程框架之一WhatWhat？HowHow？Scrum框架：简介框架：简介 lScrum 是一个用于开发和维持复杂产品的框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的Sprint)。在Scrum中，使用产品产品Backlog来管理产品的需求，产品backlog是一个按照商业价值
10、排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。Scrum起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。l要素：要素：周期：Product Release=Time-Boxed Sprint=Daily Continous Delivery 团队：Product Owner，S
11、crum Master，Dev Team(Cross-Functional)工件：Product Backlog，Sprint Backlog，Product Increment 活动：Sprint Planning Meeting/Review Meeting/Retrospective Meeting，Daily Scrum Meeting，Product Backlog Refinement 度量：Burndown图、Burnup图、VelocityScrum（一）（一）：迭代周期框架：迭代周期框架l迭代迭代周期框架：周期框架：Product Release=Time-Boxed Spr
12、intPortfolio=Product=Release=Sprint=Daily WorkingWhatWhat？HowHow？Scrum（二）：团队（二）：团队Build The Right ThingBuild The Thing RightBuild It FastScrum TeamScrum TeamlAchievement-Achievement-orientedorientedlCustomer-orientedCustomer-orientedlCommittedCommittedlMotivatedMotivatedlSelf-organizedSelf-organized
13、lEmpoweredEmpoweredlSkilledSkilledScrum团队：团队文化团队：团队文化共赢的文化共赢的文化l团队成功团队成功l个人发展个人发展l立足立足现实现实l挑战极限挑战极限Scrum团队：角色分工概览团队：角色分工概览http:/ Owner职责职责l主要负责确定产品的功能和达到要求的标准，指主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权利接定软件的发布日期和交付的内容，同时有权利接受或拒绝开发团队的工作成果受或拒绝开发团队的工作成果lPO在在Scrum中承担中承担了多项职责了多项职责 产品经理：愿景和方向，结果负责 需求分析：业务分
14、析和需求分析 需求管理：维护、终止和变更 项目管理：优先级排序和项目状态跟踪 质量保障：检查产品结果 客户代表：产品体验/接受拒绝lPO对外承担了与产品干系人交流沟通的职责对外承担了与产品干系人交流沟通的职责 老板、客户和用户、营销和销售、Scrum团队：团队：PO的职责关系的职责关系http:/ Owner属于研发角色，但与战略、市场和销售等公司其它角色存在密切合作关系，需要掌握跨界知识和语言表达。图示表现了产品管理四种角色之间的关系和分工定义，但根据项目规模不同，某一成员可能身兼数职。Scrum团队：团队：PO能力要求能力要求l业务分析能力（业务分析能力（Business Analysis
15、）l工程技术能力（工程技术能力（Engineering）l领导和协调能力（领导和协调能力（Leadership&Coordination）http:/ Analysis CapabilitiesHelping organizations develop the capabilities to achieve Enterprise AgilityUnderstand Needs of the Customer Develop Product StrategyManage Product Portfolio Achieve Customer Acceptance Define Business R
16、equirements Product StrategySolution RequirementsDevelop ProductLaunch ProductOperate and Support ProductDefine Product Backlog Establish Product VisionDefine Product RoadmapPlan Launch Engage StakeholdersPlanning Coordinate Launch Establish Development Environment Manage Suppliers Ensure Process Ad
17、herenceIdentify and Remove ImpedimentsEnsure Internal CommunicationMaintain Work EnvironmentDevelop TeamSupport Operations Provide Customer SupportSupport Implementation Coordinate Work Maintain Architecture Understand Requirements Maintain Product Quality Design and Engineer SolutionDeploy Product
18、Integration Testing Learn from Outside SourcesCommit To AgilityManage Risks Provide Job TrainingEveryoneEnvironment Perform Maintenance and Customizations Product Developmenthttp:/ CapabilitiesHelping organizations develop the capabilities to achieve Enterprise AgilityUnderstand Needs of the Custome
19、r Develop Product StrategyManage Product Portfolio Achieve Customer Acceptance Define Business Requirements Product StrategySolution RequirementsDevelop ProductLaunch ProductOperate and Support ProductDefine Product Backlog Establish Product VisionDefine Product RoadmapPlan Launch Engage Stakeholder
20、sPlanning Coordinate Launch Establish Development Environment Manage Suppliers Ensure Process AdherenceIdentify and Remove ImpedimentsEnsure Internal CommunicationMaintain Work EnvironmentDevelop TeamSupport Operations Provide Customer SupportSupport Implementation Coordinate Work Maintain Architect
21、ure Understand Requirements Maintain Product Quality Design and Engineer SolutionDeploy Product Integration Testing Learn from Outside SourcesCommit To AgilityManage Risks Provide Job TrainingEveryoneEnvironment Perform Maintenance and Customizations Product Developmenthttp:/ CapabilitiesHelping org
22、anizations develop the capabilities to achieve Enterprise AgilityUnderstand Needs of the Customer Develop Product StrategyManage Product Portfolio Achieve Customer Acceptance Define Business Requirements Product StrategySolution RequirementsDevelop ProductLaunch ProductOperate and Support ProductDef
23、ine Product Backlog Establish Product VisionDefine Product RoadmapPlan Launch Engage StakeholdersPlanning Coordinate Launch Establish Development Environment Manage Suppliers Ensure Process AdherenceIdentify and Remove ImpedimentsEnsure Internal CommunicationMaintain Work EnvironmentDevelop TeamSupp
24、ort Operations Provide Customer SupportSupport Implementation Coordinate Work Maintain Architecture Understand Requirements Maintain Product Quality Design and Engineer SolutionDeploy Product Integration Testing Learn from Outside SourcesCommit To AgilityManage Risks Provide Job TrainingEveryoneEnvi
25、ronment Perform Maintenance and Customizations Product Developmenthttp:/ Master职责职责https:/www.scrumalliance.org/community/articles/2014/may/what-it-is-that-a-scrum-master-does-all-day-longl主要负责整个主要负责整个Scrum流程在项目中的顺利实施和进行，以流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发以直接驱动
26、开发。Scrum团队：团队：Scrum Master能力要求能力要求l出色的沟通和决策能力出色的沟通和决策能力能及时、清楚、明确地传播信息；知道什么时候做出决定，不必要再做分析；平衡短期和长期目标，快速在团队和Product Owner之间达成一个共同的愿景；l促进团队合作的能力促进团队合作的能力能够促进和培养团队合作的能力，能够诊断、理解和帮助团队的日常变化；持续衡量团队工作状况，并推动必要的行动，以改进团队的工作；l鼓舞和激励能力鼓舞和激励能力促进团队活力，鼓舞、表扬和奖励团队中做得最好的人，宣扬突出的行为、技能和成就；伟大的工作态度，总是寻找方法来改变工作，而不是认同为什么做出改变是不可
27、能的；l抗压能力抗压能力在压力环境下仍能保持镇定，出色工作l解决冲突能力解决冲突能力促进建设性的辩论，使得产生更好的决策和共同愿景建设性地解决分歧和冲突，知道什么时候让其他人也参与进来在所有交往中，体现出情感成熟度（周到、客观、正直、可靠）即使在他/她不同意的时候，也会支持哪些已经做出的决定l敏捷开发实践能力敏捷开发实践能力Backlog跟踪，burndown图，会议组织，计划能力，进度跟踪，风险管理，组织变革、团队成长，敏捷开发实践，持续集成/交付/部署，.参考：https:/www.scrumalliance.org/community/articles/2007/april/the-ri
28、ght-skill-set-the-right-mind-set-the-rightScrum团队：团队：Scrum Master特质特质l专注并细心专注并细心确保团队行为始终与验收标准和项目目标（愿景）保持一致；通过良好的组织方法分配工作任务，减少失误；l团队合作者团队合作者勇于承担任何能够帮助团队的任务，并以身作责（比如，团队决定加班来完成Sprint目标，Scrum Master应该和团队在一起）l善于解决问题的能力善于解决问题的能力是一个能快速获取信息去解决问题的老手；帮助团队识别冲突的优先级，并表达并逐级向上反应不能快速的问题；l值得信赖值得信赖信守承诺，说到做到l亲近亲近平易近人，
29、风度翩翩l高度高度的决心和毅力的决心和毅力这是成功的关键性因素。因为，对于推动队员思维模式的转变是非常困难的，更不用提整个组织的转变了，特别是在看到组织内部有失败案例的时候；你必须有足够的耐心来帮助团队一步一步地转变，因为要想看到积极的趋势是会花很多时间和精力的。在出现“信任危机”的时候（非常可能出现），你必须要有足够的耐心来说服他人、影响他人；l既要理解标准化的既要理解标准化的Scrum模式，又要根据自己组织的固有特点来实际地运用它模式，又要根据自己组织的固有特点来实际地运用它这是成功的决定性因素。因为没有任何两家公司是相同的；这也要求你要比较温和的推进转变。记住：欲速则不达；Scrum M
30、aster需要制定一个比较长远的推进计划，然后步步为营，直到团队自己找到基于Scrum框架和思维模式的最佳工作方法；l准备好挑战他人并接受他人的挑战准备好挑战他人并接受他人的挑战向管理层寻求帮助固然有用，但通常比较困难。因此在适当的时候记得去挑战你的老板。很多成功的变革通常是由下至上发起的，不要一味地依赖老板的指示；若在实施过程中受到外界的挑战和动摇，一定要对自己、对团队、对组织有坚定的信心。如果外界的动摇具有10分的摧毁力，那么你自己的动摇则具有100分；l持续改进自我的愿望持续改进自我的愿望这点不仅适用于团队成员，更是适用于Scrum Master自身。因为通过自我的持续改进，你才能有效的
31、影响团队成员，让大家积极的凝聚在一起，直到找到最高效的工作方法这一终极目标。Scrum团队：团队：Dev Team职责职责l主要负责软件产品在主要负责软件产品在Scrum规定流程下进行开发工作，人数规定流程下进行开发工作，人数控制在控制在510人左右，每个成员可能负责不同的技术方面，但人左右，每个成员可能负责不同的技术方面，但要求每个成员必须要有很强的自我管理能力，同时具有一定要求每个成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。的目标。l主要职责主要职责 定义（分解）工作任务 评
32、估工作量 开发产品 确保质量 完善过程Scrum团队：团队：Dev Team(1)跨跨职能团队职能团队Scrum团队：团队：Dev Team(2)特性团队特性团队Component TeamFeature TeamVS.http:/ Team的组织方式会导致瀑布式的开发流程，以便协调团队间的工作任务。Feature Team组织方式的成功依赖于团队能力，以及团队对于重构、持续集成、自动化测试等敏捷开发工具和实践的使用。Scrum团队：团队：Dev Team成员成员能力拓展能力拓展成就全栈工程成就全栈工程师师瀑布式：瀑布式：团队成员专司一职，难以获得横向拓展团队成员专司一职，难以获得横向拓展SC
33、RUM：人们可能主要技能不尽相同，如人们可能主要技能不尽相同，如有人擅长开发而另外的人擅长测有人擅长开发而另外的人擅长测试，但是，在试，但是，在Scrum团队里，我们团队里，我们鼓励团队成员学习新的领域技能鼓励团队成员学习新的领域技能，尝试在新的领域工作，团队成，尝试在新的领域工作，团队成员跨领域互相帮助完成一项产品员跨领域互相帮助完成一项产品特性。比如，一个特性。比如，一个“架构师架构师”可可能要写自动化测试代码，而一个能要写自动化测试代码，而一个“测试人员测试人员”则可能要分析业务则可能要分析业务。SCRUM（三）：（三）：SCRUM工件工件lSCRUM工件工件 核心工件：Product
34、Backlog，Sprint Backlog，Shippable Product Increment；其它工件：Dependencies/Blocker list；SCRUM工件：工件：Product BackloglProduct Backlog是条目化是条目化/量化的用户需求，它将需求文档中需要量化的用户需求，它将需求文档中需要实际开发的需求（包括功能性和非功能性需求）条目化地表达出来实际开发的需求（包括功能性和非功能性需求）条目化地表达出来。Product Owner维护，用场景描述的用户需求(Story)列表 经过优先级排序和工作量评估的 优先级越高的条目，User Story描述粒度
35、越细 反映了业务的计划SCRUM工件：工件：PB(1)ItemsMy primary rule for including any item in the product backlog is that the work must be something the product owner can understand and can reasonably prioritize against features.So if you do choose to include PBIs of type technical work,you will need to make the value
36、of the item clear to the product owner.http:/ Story描述描述As a,I want a So that I can get.基于目标和场景驱动，体现业务价值SCRUM工件：工件：PB(3)User Story 粒度粒度按照业务优先按照业务优先级次序，将大级次序，将大粒度的用户故粒度的用户故事拆解为小粒事拆解为小粒度的用户故事度的用户故事，并依次经过，并依次经过评估后安排进评估后安排进入入ReleaseRelease计计划和划和SprintSprint计计划划SCRUM工件：工件：PB(4)User Story优先级优先级SCRUM工件：工件：P
37、B(5)User Story评估评估l用户故事用户故事INVEST模式模式 Independent:减少依赖，便于计划 Negotiable:通过协作添加细节 Valuable:对客户有价值 Estimable:太大或太模糊的用户故事，无法评估 Small:可以在由一个团队在一周内完成 Testable:有好的验收原则l评估用户故事的大小评估用户故事的大小 Story Points Anchor Story，相对值评估 斐波那契数列和扑克牌游戏 贴墙技术l衡量团队衡量团队Velocity 用46个Sprint来确定速率SCRUM工件：工件：PB(6)非功能非功能性需求描述性需求描述lNonfu
38、nctional requirements represent important system-level constraints that affect the design and testing of most or all items in the product backlog.Nonfunctional requirements are used to specify various characteristics such as system performance,accuracy,portability,reusability,maintainability,interop
39、erability,capacity,platform fan-out,and so on.l以以User Story方式描述方式描述NFR，有助于理解部分技术决策背后的原因，如：，有助于理解部分技术决策背后的原因，如：As a customer,I want to be able to run your product on all versions of Windows from Windows 95 on.As the CTO,I want the system to use our existing orders database rather than create a new on
40、e,so that we dont have one more database to maintain.As a user,I want the site to be available 99.999 percent of the time I try to access it,so that I dont get frustrated and find another site to use.As someone who speaks a Latin-based language,I might want to run your software someday.As a user,I w
41、ant the driving directions to be the best 90 percent of the time,and reasonable 99 percent of the time.l参考参考http:/ Backlog确保考虑到工作中所有细节：编码、确保考虑到工作中所有细节：编码、测试、代码评审、会议、学习新技术测试、代码评审、会议、学习新技术、编写文档、编写文档Sprint tasks需要评估到小时需要评估到小时如果任务需时超过一天，尝试分割成如果任务需时超过一天，尝试分割成几个小任务几个小任务如果团队认为如果团队认为Sprint Backlog项目过项目过多或过少
42、，和产品负责人一起调整问多或过少，和产品负责人一起调整问题数量题数量团队确认团队确认Sprint目标目标如果工作不清晰，可以先建一个粗粒如果工作不清晰，可以先建一个粗粒度的度的Sprint Backlog，然后再分解，然后再分解所有任务项都分配给团队成员所有任务项都分配给团队成员每日更新剩余工作评估每日更新剩余工作评估团队团队成员对任务的成员对任务的DoD(Definition of“Done”)应该有应该有共同共同的理解的理解只计算全力以赴完成所需要的时间，只计算全力以赴完成所需要的时间，剩下的剩下的交给燃尽交给燃尽(Burndown)图解图解决决 Sprint Backlog是Scrum团
43、队在Sprint Planning会议中确认的待办任务列表，映射到传统项目管理理论中就是WBS，而且是典型的采用面向交付物的任务分解方法得到的WBS。SCRUM工件：工件：Impediments List(1)http:/ Master找出相关的干系人来一起解决 也有一些小而重要的障碍，可能是公司组织所固有的，任何一个团队无法独立解决，需要公司层面企业文化、组织架构的变革来解决，这需要Scrum Master推动管理层完成。SCRUM工件：工件：Impediments List(2)10大典型障碍 会议规则没能被遵循 产品远景和Sprint目标不清晰 没有产品负责人负责回答提问 产品Backl
44、og未能按商业价值区分优先级 并不是所有负责交付产品的人员都是团队里的成员 Scrum Master还要处理其他任务，不能集中精力 团队人数过多（多于7个开发人员）团队没有能坐在一起工作的空间 团队的Sprint Backlog混乱 以障碍Backlog方式管理障碍 把所有已知的障碍加入到障碍Backlog的“新事项”栏中 按优先级顺序排列“新事项”栏中的障碍问题 每当您开始着手解决一个障碍问题时，将它移至“正在处理事项”栏中 尽快解决这个障碍 障碍得到解决时，将它移到“已完成”事项栏中 在Scrum每日例会和Sprint回顾会议中收集新的障碍问题Scrum工件：工件：Definition o
45、f“Done”l对于对于Scrum工件中的条目，工件中的条目，团队一起定义团队一起定义“Done”（“完成完成”）的真实内在含义，）的真实内在含义，以免在评估项目时发生误解以免在评估项目时发生误解和分歧。和分歧。l“Done”的几个例子：的几个例子：Design,coding,unit testing,integrated Static analysis,refactored Acceptance tested,deployablehttps:/www.scrumalliance.org/community/articles/2008/september/definition-of-done-
46、a-referenceScrum（四）：（四）：Scrum活动活动 Scrum活动：活动：Release Planning(1)Who:Scrum Coach,Product Owner,Scrum Team,Scrum Master,Key StakeholdersWhen:before release n+1 begins(.5-2 days)How/Topic(s):lPO presents the vision,strategy and goals.lPO present key dates and milestones.lPO presents draft of the priori
47、tized backlog.lDiscussion to understand user stories.lReview rough estimates+prioritized features.lAgreement on Sprint length(in weeks)and target release dates.lRelease Plan is organized by scope(functionality)or time(release every N sprints).lContinual Planning.The initial release plan is a bluepri
48、nt to get started and will be revised.Selected stories for the releaseProduct VisionHigh level prioritized goals&roadmapKey risks and assumptionsStakeholder consensusPrioritized product backlogGoal:Establish the overall release schedule and determine in what sprint stories will likely be delivered.P
49、roduct Backlog(priority draft)Release PlanRough Estimates产品负责人和团队一起对整个产品产品负责人和团队一起对整个产品Backlog进行评估，提出划分发行版本和进行评估，提出划分发行版本和Sprint计划的主计划的主要依据。要依据。Scrum活动：活动：Release Planning(2)https:/ Planning会议活动日程安排的示例：会议活动日程安排的示例：Scrum活动：活动：Sprint Planning(1)Who:Scrum Coach,Product Owner,Scrum Team,Scrum Master.Whe
50、n:before Sprint n+1 begins(2-3 hrs).How/Topic(s):lPO presents the backlog items in priority order for review.lStories with failed acceptance tests from prior sprints are added*.lDiscuss story creation for defects from prior sprints*.lReview and clarify user stories.lBreakdown larger stories and each
