精华内容
下载资源
问答
  • 传统的瀑布工作模式使用详细的需求说明书来表达需求,需求人员负责做需求调研,根据调研情况编制详细的需求说明书,进行需求评审,评审之后签字确认交给研发团队设计开发。在这样的环境下,需求文档是信息传递的主体...
  • [转帖]敏捷开发,Use Case 还是 User Story2009-9-24敏捷开发,Use Case 还是 User StoryMurali Krishna告诉我们:未能彻底明白用户故事的性质往往都是未能有效地转变到敏捷开发的重大问题。用户故事最重要的特点在...

    [转帖]敏捷开发,Use Case 还是 User Story

     

    敏捷开发,Use Case 还是 User Story
     
    Murali Krishna告诉我们:
    未能彻底明白用户故事的性质往往都是未能有效地转变到敏捷开发的重大问题。用户故事最重要的特点在於每一 个用户故事都是一个可独立分配的需求(特徵)单位。要达到可独立分配,就要从用户如何使用系统来表达用户故事。这样才让你实现到一个能让用户 交流,端到端(用户界面到后端)的功能单位。
     
    Murali想的跟众多敏捷社区的人仕一样——用户故事是最好的选择,并引用Mike Cohn写的一篇文章Advantages of User Stories for Requirements。文中指出:
    1. 每一个用户故事都包括三方面:
    2. 写下故事描述,用作计划和提示
    3. 故事的对话为故事细节
    以测试作为细节的记录,用来判断故事是否完成实现
     
    如此看来使用用户故事比较好。但又是否如此呢? Alistair Cockburn,另一位敏捷社区内的名家,仍然使用用例,并从他过往使用用户故事的经验中指出所遇到的问题:
    1. 用户故事和Backlog上的项目不能提供设计师工作所需要的内容脉络——用户在做什么时候情况下做这事情,这行动的内容前文后理,以及在这一刻的高层目标。
    2. 用户故事和Backlog上的项目不能提供项目团队所需要的“完整性”——我发现开发队伍对项目估算的故事点随著工作开始以后不断增加,犹如无止境的一样。开发人员及项目赞助人也为此感到同样的沮丧。到底项目确确实实有多大呢?
    3. 跟 完整性有关的是,用户故事和Backlog上的项目不能提供一个合适的机制来考虑到未来工作的困难程度(原则上他们可以, 只是实际上他们不行)——我不断收到这样的投诉,「我们问客户 (产品负责人)一条问题,他/她用上两星期时间才回覆我们。我们找错了人吗?」不是,他们没找错人,他们是过程出问题——有些问题需要长时间研究,因为不 同部门和用户组要找出什么是正确,平衡各方需要的答案。分析员看著用例中一系列的伸延的形势可以找出那一个较容易,那一个较困难,再进一步进行相关的研 究。用户故事和 Backlog 项目未能及时达到适合作出来那考虑的粒度——伸延的形势通常要在Sprint中才能观察到,这已经太迟。
     
    Alistair说了「为何不使用用户故事」后,进一步集中讨论「为什么使用用例」。
    1. 目标名称列表将系统对业务和用户的贡献进行了最简短的概括,提供给行政人员。这也提供了一个项目计划框架,可用作建立初始优先次序、估计、团队分配,以及时间的选择。这也是“完整性”的第一部份。
    2. 每个用例的主要成功场景能提供各参与者有关系统基本功能的协议,有时候更为重要的是,它可以告诉人们,哪些事情它不能做。给每一项需求提供脉络,这是其他工具很难办到的。
    3. 每个用例的扩展条件可以给需求分析员提供一个框架,可以找出那些可能会用上 80% 的开发时间成本的烦琐细微之处。它提供一个考虑未来的机制,从而客户、产品负责人、业务分析员可以察觉到一些可能用上时间研究的问题。这些问题应优先处 理,让开发团队开始工作时这些资料也同时准备好。这用例伸延形势分析就是 "完整性" 的第二部份。
    4. 用 例 扩展场景提供一些仔细而然往往也是难处理的细节,像编程员常常问到:「你想我如何处理这情况?」(通常回覆却是:「我不知道, 我未想过会有这情况。」)换言之,这是一个思考、文档纪录的框架,跟“如果……那么……否则”的情况作配对,帮助编程员思考不同的问题。分别在於这是在研 究阶段进行,不是到要开始编程时才进行。
    5. 整套用例系列反映出研究人员有详细思考不同用户需 要,不同用户在 这系统上使用目的,以及一些业务上的差异。这是“完整性”的最后部份。(的确如是,我曾跟客户详细讨论长达 240 个用例,到最后,我去问她:「这是全部了吗?」她确认了。我们架建这系统,付运,收到应得的费用,而十年后这系统仍在使用。)
     
    一如很多人所料,这回事不是黑白分明。我们该如何做好?我们现时在做的到底有用么?只有一个正确方法呢,还是有两个不同的 正确方法呢?或者视乎实际情况而定?会不会是有些情况下用用例较好,而有些情况下用用户故事较好呢?还是其实没太大分别呢——像用例中(或许)包含多个用 户故事而该用例因为一个用户情节内外都貌似用户故事呢)
     
    译者附注:
    用户故事好还是用例好的问题,其实不像作者前面提到用户故事为大多数偏爱使用的工具,像 ICONIX、FDD、OpenUP都很依赖或者支持用例的使用,不过明白两者分别极为重要。知道分别才可以作出合适的决定。 Scott Ambler 曾经在 指出两者的分别:
    工具
    通常应用
    什么时候保存
    用例
    1. 主要使用需求综述
    2. 分析现有系统使用需求
    使用需求综述
    用户故事
    1. 探索用户需求
    2. 与项目参与者对话的提示
    功能实现后扔掉
     
    很明显两者的使用情况和目的都很不同。甚至有需要下,两者可共同使用及存在。这就不存在到底是那个比较好的问题,亦不应该 单靠一些报告说那个比那个好就麻木 跟从。重要的是如何更适合当前的情况,这包括项目上的需要,也包括团队的能力。长远来说,是让团队更敏捷。
     
    在我自己的实践中:
    用户故事是应用在PO和客户沟通和PO、Team在Sprint Planning中使用。用例是Team在明确需求,或者说需求分析阶段和PO确认使用。但用例需要做裁剪
     
    文章摘自:http://www.infoq.com/cn/news/2008/08/use-case-or-user-story
    感谢文章的原创者:作者 Amr Elssamadisy译者 麦天志
     
    Andy Yuan,袁斌,迅思威尔资深敏捷咨询师
    Mobile: 13501397696
    迅思威尔-国内专业敏捷项目管理和敏捷开发过程的培训、实践基地,欢迎 访问http://www.agiledo.cn

    转载于:https://www.cnblogs.com/yecllsl/archive/2010/09/28/1837516.html

    展开全文
  • 市面上关于需求说明方面的书籍有很多。不幸的是,这些绝大多数对于软件开发团队来说都不实用。因为那些依赖于传统的工程实践。他们假设需求是可以事先获得的,并且一旦被写出来,在项目进行过程中就不会再修改。...

    5a0e89302cc745015c0e98a636da77ee343ef60d

    前  言

    市面上关于需求说明方面的书籍有很多。不幸的是,这些书绝大多数对于软件开发团队来说都不实用。因为那些书依赖于传统的工程实践。他们假设需求是可以事先获得的,并且一旦被写出来,在项目进行过程中就不会再修改。而且,他们认为就算发生变更,都是一些细微的变化,因此,可以通过变更管理流程来进行追踪。他们创建了从明确需求阶段开始的系列流程,而这个阶段将在团队开始设计和实现产品之前提供详细的需求说明。
    本书目标

    我认为传统的工程实践对软件开发来说并不适用。提炼软件需求说明的流程的核心问题是不确定性很高,这与传统的工程是不同的。幸运的是,在过去十年,随着敏捷社区的成长,我们已经整合出了更符合软件开发现实问题的知识体系。很多书都提到,敏捷方面的书籍已成为对软件开发感兴趣的所有人必读的书籍。这些书绝大部分都包含了至少一到两章跟需求相关的内容,其中有些甚至整本书都只讨论这个话题。我认为描述的有些内容非常重要,因此我会在本书里引用或参考这些内容。
    我写本书是为了让敏捷知识体系更加饱满。这是可执行需求说明相关的敏捷实践的纲要。可执行需求说明能够让你更加轻松地测试软件行为是否满足需求。在本书中,我自始至终都在解释如何在前提条件尚不明确的时候,以及需求难以把握且需要持续演进的情况下把软件需求说清楚。软件研发实践者们将学会如何一步一步地紧紧围绕愿景,采用浮现式迭代实践,渐进明细地捕捉需求。他们还将学会如何通过编写细小的需求分支而将需求说清楚。
    本书的目标是解释获得可执行需求说明收益所需要的技术机制。它不仅会提供一个迭代式挖掘需求的可靠案例,还将进一步地教你如何将需求说明与正在构建的软件连接起来。整个流程将引导你创建一个可执行的需求说明书。
    即使我们有很好的意图也不能强制要求干系人同意我们的做法意识到这一点很重要。有句非洲谚语简洁明了地阐述了这个问题:“你不能拔苗助长。”当认知尚未完善,需求也在持续变更的时候,我们不能再依赖传统的工程技术。相反,强调经验技术的迭代式需求探索方式显得至关重要。探寻目标不仅是为了正确地解决问题,同时也是要解决正确的问题——这是软件构建过程面临的最大挑战。
    本书的独特之处在于,它将教会你如何通过使用可执行的需求说明把需求和架构连接起来。你将学会通过Scrum框架如何在说明需求的同时,将需求验证过程自动化。读完本书,你可以选择一种工具,开始为将来的敏捷项目创建可执行需求说明。以下我列举了阅读本书的五个好处:
    你将明白,当从传统的方式转型成敏捷实践的时候,业务分析工作将会发生何种变化。
    你将学会如何在Scrum 框架内提炼浮现式需求。
    你将见识如何采用故事板和纸原型法改善跟干系人之间的沟通。
    你将发现如何开展浮现式设计,同时确保任何时候的实施的正确性。
    你将了解采用敏捷实践的软件架构师如何随着当前的软件开发进行浮现式设计。

    谁应该是本书的读者

    本书的读者应该是已经在应用Scrum框架或者正在转型实施敏捷实践的人。他们理解敏捷的本质,但是并不熟悉可执行需求说明。他们希望了解为什么可执行需求说明有用,以及最重要的是如何开始实施这一新的实践。
    随着Scrum框架的大量使用,敏捷团队面临的第二大挑战就是如何将业务分析师和架构师组合成活跃互动的团队成员。任何面临这一挑战的Scrum Master、经理、决策者都应该阅读本书。另外,所有参与敏捷项目的团队成员也将从本书获益。它并没有直接宣称业务分析师和软件架构师将会因找到一本直接说出他们所关注的问题的书而高兴。
    高级或专家级的敏捷实践者将会对本书清晰的可执行需求说明全局感兴趣。他们可以利用本书成功地将团队引领到这条路上。另外,全书使用的术语可以帮助领导者更有效地与同事沟通。

    本书的路线图

    可执行需求说明提炼方法要求人们在思维方式上做出改变。本书的重点也在于此。可执行需求说明提炼方法有助于缩小干系人希望软件能做什么(什么)和该软件的确能做什么(如何)之间的差距。可执行需求说明以一种使开发团队很容易根据可执行需求说明来验证软件的方法澄清需求,而这跟需求变更一样在频繁地发生。
    为了促进这种思维方式的改变,本书提供了一个跨越9章的独特思路。
    第1章:解释了为了有效应对持续变更的需求而采用迭代探索和可执行需求说明的必要性。
    第2章:解释了如何识别那些不可改变的事情:那些团队应该依赖的、核心的、有把握的事情。而这些有把握的事情不是需求本身。它们是能够保证一个方案得以实现的防护栏。它们组成了一个牢固的基石,保证迭代式需求探索方法成为可能。
    第3章:揭示了为了找出不确定性,团队必须通过短周期反馈环挖掘干系人的期望和需求(“愿求”)。
    第4章:介绍了如何采用用户故事表达“愿求”,并学会如何使用产品待办事项列表记录它们。
    第5章:解释了如何通过优化产品待办事项列表来帮助我们做迭代计划,这样可以提高整个反馈环成功的概率。
    第6章:展示了如何通过故事场景编写用户故事行为脚本来确认用户故事。
    第7章:解释了如何将故事场景转换成自动化测试,这样我们就可以很容易地对照逐渐演进的需求说明确认软件行为是否符合预期。
    第8章:介绍了如何通过详细说明非功能性需求保障软件质量。
    第9章:本书最后一章,总结了全书最关键的要素。
    

    目  录

    第1章 解决正确的问题
    1.1 从解决方案中甄别需求
    1.2 识别不确定性的影响
    1.3 处理不确定性
    1.4 小结
    1.5 参考资料

    第2章 依赖坚实的基础
    2.1 界定不可更改的边界
    2.2 组建一个健康的团队
    2.3 要求所有干系人参与
    2.4 明确一个可以共享的愿景
    2.5 识别出一个有意义的共同目标
    2.6 识别出一系列高级别的特征
    2.7 验证“可能存在”的假设
    2.8 小结
    2.9 参考资料

    第3章 使用短周期反馈环探索干系人的“愿求”
    3.1 运用试错法
    3.2 应用短周期反馈环
    3.3 根据预期收益设定反馈目标
    3.4 关注干系人的“愿求”
    3.5 小结
    3.6 参考资料

    第4章 使用用户故事表达“愿求”
    4.1 使用用户故事描述愿求
    4.2 通过研究角色及其利益探索“愿求”
    4.3 建立一种通用语言
    4.4 使用待办事项列表记录“愿求”
    4.5 小结
    4.6 参考资料
    第5章 优化产品待办事项列表提炼用户故事
    5.1 管理产品待办事项列表
    5.2 通过合作优化产品待办事项列表
    5.3 采用圆点投票法对用户故事进行排序
    5.4 采用故事板的方式阐明用户故事的需求
    5.5 通过比较的方式估算用户故事规模
    5.6 按照业务价值拆分用户故事
    5.7 使用协作白板追踪用户故事
    5.8 交付一组功能连贯的用户故事
    5.9 使用用户故事计划工作
    5.10 小结
    5.11 参考资料

    展开全文
  • 本节书摘来自华章出版社《敏捷可执行需求说明 Scrum提炼及实现技术》一 中的第1章,第1.1节,作者:(美)Mario Cardinal,更多章节内容可以访问云栖社区“华章计算机”公众号查看。 第1章 解决正确的问题敏捷是一...

    本节书摘来自华章出版社《敏捷可执行需求说明 Scrum提炼及实现技术》一 书中的第1章,第1.1节,作者:(美)Mario Cardinal,更多章节内容可以访问云栖社区“华章计算机”公众号查看。

    第1章

    解决正确的问题
    敏捷是一组鼓励快速、灵活地响应变更的软件开发框架。它们基于迭代开发实践,需求和解决方案都在跟客户合作过程中逐渐演进并完善。2001年发布的“敏捷软件开发宣言”[1]引入了敏捷这个词。
    Scrum[2]现在已经成为最著名且使用最广泛的敏捷框架。Ken Schwaber和Jeff Sutherland[3]设计的Scrum框架,由角色、事件、工件以及将它们整合在一起的一系列规则组成。Scrum使研发团队通过频繁地检查和调整,并不断优化产出成果,最终构建复杂的产品。这个术语来自橄榄球中的scrum(或者scrummage),即用来重新启动强制暂停后的比赛。在2011年发起的年度“敏捷研发现状”调查中,选择使用Scrum或Scrum的变种形式的人数继续在被使用到的敏捷框架中占据三分之二以上的比例[4]。因为Scrum被如此广泛地采用,所以本书也仅关注这种框架形式。对于采用其他敏捷框架的情况,本书所介绍的经验教训因其通用性也足够使用。
    将“敏捷”与“需求说明书”两个词绑在一起看起来有点怪异。而特别为这个话题撰写一本书看起来更加怪异。对很多人来说,需求说明书只与“传统”的以文档为中心的工程实践相匹配。在敏捷背景下,可运行的软件是度量开发进度的基本标准,人们很容易认为需求说明书将不再有存在的必要。然而,需求说明书仍然是需要的——甚至比以往任何时候都更需要。区别在于产出物有本质上的不同。需求说明不仅简短,而且也需要在计算机上以一种固定的格式发布成可执行的文档。——因此得名为可执行的需求说明书。
    本书的目标旨在解决众多软件开发团队不断遇到的问题:他们无法生产“正确”的软件。这是一个很严重的问题,甚至令你震惊。不管怎样,仍然有大量的软件系统成功地解决了“正确”的问题。其中很多这样的系统都是由实施Scrum框架的团队生产的。我不仅从这些团队那里学习到了关于敏捷的技能,而且也是他们中的一员。如果你也属于这样杰出的团队,你就会意识到本书中介绍的这些纲要性的实践正是你所熟知的。
    不幸的是,仍然存在着大量的过于臃肿和复杂的软件系统。即使研发团队写的代码都是对的,结果往往是他们没有有效地解决实际的问题。客户想要的或需要的功能跟产品实际能够提供的功能有着巨大的差距。一个经常被引用的Standish Group [5]的统计结果显示,在一个典型的系统里,64%的功能很少被用到或几乎从不被使用。图1-1是根据Standish Group的准确数据画的饼图。
    screenshot

    从饼图上来看,非常有意思的是有20%的功能一直或者经常被用到。这个结果更重要的是吻合了80–20原则,同时也符合帕累托原则。帕累托原则说的是在很多事件中,几乎80%的成果(产出物)都来自20%的付出(投入)。比如说,在生意场合,通常几乎80%的销售业绩都来自20%的客户。在软件开发行业,如果你能正确地选择最重要的20%的需求来实现,就能满足80%的业务需求了。随着对可用性和可靠性的期望值不断增长,要构建符合要求的软件是很困难的。因此专注于那20%的功能就显得很重要。这样你就可以拥有必要的资源来实现符合预期的技术解决方案。
    本章将介绍为了解决正确的问题,必须首先学会从解决方案中甄别出需求。紧接着,必须在描述需求时识别出不确定性的影响。这是因为描述我们需要构建的是什么,同时还要拥抱变化是很有挑战的。最后,我们将得出结论,当前从传统工程中继承来的实践根本满足不了这种需要。当需求难以把握,并且持续变动时,你必须以一种非传统的方式来应对不确定性。Scrum框架下的可执行需求说明被证明行之有效。本书的目标就是要分享这一经验。

    展开全文
  • 敏捷开发之 12条敏捷原则 欢迎转载,转载请注明:转载自敏捷个人网站   ...我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意 ...以前我们都用需求规格说明书或者用例来编写详细的需求

    敏捷开发之 12条敏捷原则

    欢迎转载,转载请注明:转载自敏捷个人网站

     

    1。我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意

       规划迭代故事时必须按照优先级安排,为客户先提供最有价值的功能。通过频繁迭代能与客户形成早期的良好合作,及时反馈提高产品质量。敏捷小组关注完成和交付具有用户价值的功能,而不是孤立的任务。以前我们都用需求规格说明书或者用例来编写详细的需求,敏捷使用用户故事来罗列需求。用户故事是一种表示需求的轻量级技术,它没有固定的形式和强制性的语法。但是有一些固定的形式可以用来参考还是比较有益的。敏捷估算中使用了这个模板:“作为【用户的类型】,我希望可以【能力】以便【业务价值】“。使用基于用户故事的需求分析方法时,仍可能需要原型和编写文档,只是工作重点更多的转移到了口头交流。 

     


     

    2。即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
      敏捷过程参与者不怕变化,他们认为改变需求是好事情,因为这些改变意味着我们更了解市场需求。 

     

      

     

    3。经常性的交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间间隔越短越好
      迭代是受实践框限制的,意味着即使放弃一些功能也必须按时结束迭代。只要我们可以保证交付的软件可以很好的工作,那么交付时间越短,我们和客户协作就越紧密,对产品质量就更有益。虽然我们多次迭代,但并不是每次迭代的结果都需要交付给用户,敏捷开发的目标是让他们可以交付。这意味着开发小组在每次迭代中都会增加一些功能,增加的每个功能都是经过编码、测试,达到了可发布的质量标准的。
      另外敏捷开发项目中对开发阶段没有什么重要的分割,没有先期的需求阶段,然后是分析阶段,架构设计阶段,编码测试阶段等,在项目真正开始后,每次迭代中都会同时进行所有的上述阶段工作。

     


     

    4。在整个项目开发期间,业务人员和开发人员必须天天都在一起工作
      软件项目不会依照之前设定的计划原路执行,中间对业务的理解、软件的解决方案肯定会存在偏差,所以客户、需求人员、开发人员以及涉众之间必须进行有意义的、频繁  的交互,这样就可以在早期及时的发现并解决问题。 


     

    5。围绕被激励起来的个来构建项目。给他们提供所需要的环境和支持,并且信任他们能够完成工作。
      业务和技术是引起不确定的二个主要方面,人是第三个方面。而业务和技术又必须由人来执行,所以能够激励人来解决这些问题是解决不确定性的关键。只要个人的目标和团队的目标一致,我们就需要鼓舞起每个人的积极性,以个人为中心构建项目,提供所需的环境、支持与信任。 


     
     

    6。在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈
      在十几或者二十几个人组成的大团队中,文档是一种比较合适的传递知识和交流的途径。而敏捷团队一般不会很多人(大团队实施敏捷时也会分成多个小的敏捷团队),所以大量的文档交流其实并不是很经济的做法。此时面对面的交谈反而更快速有效。 


    7。

    工作的软件是首要进度度量标准。
      一般的工作都比较容易衡量任务进展,比如让你去搬运1吨的石头,我只要去称一下你已经搬运的石头重量就知道你完成多少了。而对于软件来说,在软件没有编码、测试完成之前,我们都不能因为代码编写了多少行,测试用例跑了多少个就去度量这个功能是否完成了。衡量这个功能是否完成的首要标准就是这个功能可以工作了,对用户来说已经可以应用了。

      

    8。敏捷过程提可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
      很多人都认为软件开发中加班是很正常的,不加班反而不正常,我对此有点不理解,这个可能是国情所致吧。敏捷过程希望能够可持续的进行开发,开发速度不会随着迭代的任务不同而不同,不欣赏所谓的拼一拼也能完成的态度,开发工作不应该是突击行为。我们不能指望说突击这个项目后就可以轻松了,因为完成一个项目后会接踵而来下一个项目,而只要还是拼拼的态度,下一个项目依旧会让你的组员再次突击。这时不知道有人会不会说,那我们就一直加班,也是“持续的开发速度”啊,这时可要注意了,持续加班智慧导致人疲劳、厌倦,保持长期恒定的速度也只是一种理想而已。 


    9。不断地关注优秀的技能和好的设计会增强敏捷能力。
      敏捷过程有很多好的技术实践可以加强产品敏捷能力,很多原则、模式和实践也可以增强敏捷开发能力。 《敏捷软件开发-原则、模式与实践》一书中介绍了很多设计,感兴趣的可以去仔细看看。 


     

    10。简单----使未完成的工作最大化的艺术----是根本的。
      我们不可能预期后面需求会如何变化,所以不可能一开始就构建一个完美的架构来适应以后的所有变化。敏捷团队不会去构建明天的软件,而把注意力放在如何通过最简单的方法完成现在需要解决的问题。这时有人会说,我已经预计到了肯定存在哪些需求扩展点,我们在一开始是否需要考虑呢?这时团队需要根据自己的理解去决定是否考虑,如果深信在明天发生了这个问题也可以轻易处理的话,那么就最好先不考虑。 


     

    11。最好的构架、需求和设计出自与自组织的团队

    敏捷中有很多种实践,大家都知道,迭代式开发是主要的实践方法,而自组织团队也是主要的实践之一。在自组织团队中,管理者不再发号施令,而是让团队自身寻找最佳的工作方式来完成工作。要形成一个自组织团队其实比较难。CSDN采访Mishkin Berteig中说到 自组织团队的第一个要素就是必须有一个团队,而不仅仅是一群人。一群人是一帮在一起工作的人,他们彼此之间并没有太多的沟通,他们也并不视彼此为一体。项目一开始,我们就会组建“团队”,但很多时候由构架师、需求人员、开发人员和测试人员组成的是一群人而已。他还认为,团队的形成必须经历几个时期。在经历了初期的磨合后,成员才会开始对团队共同的工作理念与文化形成一个基本的认识和理解。团队内会逐渐形成规矩,而且这些规矩是不言而喻的。比如,每个人都知道上午九点来上班,都会主动询问别人是否需要帮助,也都会去主动和别人探讨问题。如果团队成员之间能够达成这样的默契,那么这个团队将成为一个真正高效的工作团队。在这样的团队中,成员之间相互理解,工作效率非常高。在自组织团队中,团队成员不需要遵从别人的详细指令。他们需要更高层次的指导,这种指导更像是一个目标,一个致力于开发出更好的软件的目标。总之,自组织团队是一个自动自发、有着共同目标和工作文化的团队,这样的团队总是在向它的组织做出承诺。但是,实现这些承诺对于自组织团队来说非常重要。否则,一旦出现问题,团队成员之间就会出现信任危机。
      虽然敏捷开发小组是以小组为整体来工作的,但是还是有必要指明一些承担一定任务的角色。第一个角色是产品所有者(Product Owner)。产品所有者的主要职责包括:确认小组所有成员都在追求一个共同的项目前景,确定功能的优先级以便总是在处理最具有价值的功能,以及作出决定使得对项目的投入可以产生良好的回报。可以对应为以前开发中的“产品经理”。另一角色是开发团队(developer),这里的开发人员包括了架构师、设计师、程序员、需求人员、测试人员、文档编写者等,有时产品所有者也可以被看作是开发人员。还有一个重要角色就是项目经理(project manager)。敏捷开发的项目经理会更多的关注领导而不是管理。在某些项目中,项目经理可能同时也是开发人员,少数时候也会担任产品所有者。

      

    12。每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整
      由于很多不确定性因素会导致计划失效,比如项目成员增减、技术应用效果、用户需求的改变、竞争者对我们的影响等都会让我们作出不同的反应。 敏捷不是基于预定义的工作方式,而是基于经验性的方式,对以上这些变化,小组通过不断的反省调整来保持团队的敏捷性。

     

    展开全文
  • 本节书摘来自华章出版社《敏捷可执行需求说明 Scrum提炼及实现技术》一 中的第1章,第1.3节,作者:(美)Mario Cardinal,更多章节内容可以访问云栖社区“华章计算机”公众号查看。 1.3 处理不确定性 在复合区域...
  • 管理敏捷需求,进行需求协作

    千次阅读 2018-08-19 20:29:50
    传统的瀑布工作模式使用详细的需求说明书来表达需求,需求人员负责做需求调研,根据调研情况编制详细的需求说明书,进行需求评审,评审之后签字确认交给研发团队设计开发。在这样的环境下,需求文档是信息传递的主体...
  • 敏捷 需求管理工具

    2018-08-20 12:38:00
    传统的瀑布工作模式使用详细的需求说明书来表达需求,需求人员负责做需求调研,根据调研情况编制详细的需求说明书,进行需求评审,评审之后签字确认交给研发团队设计开发。在这样的环境下,需求文档是信息传递的主体...
  • 软件需求说明书的书写格式

    千次阅读 2009-08-22 20:27:00
     在互联网公司或者一些敏捷开发的公司里,其实大家都是秉承着重开发,重讨论,而轻文档的态度。这个轻文档并不是指没有文档或者几乎不做文档,而是在严格的文档流程中解脱出来,只把最最实际的部分写出来。这个特征...
  • 在互联网公司或者一些敏捷开发的公司里,其实大家都是秉承着重开发,重讨论,而轻文档的态度。这个轻文档并不是指没有文档或者几乎不做文档,而是在严格的文档流程中解脱出来,只把最最实际的部分写出来。这个特征是...
  • 需求分析(研究做什么),输出《需求规格说明书》和产品界面原型图。 概要设计和详细设计,输出概念模型图(ER图)、物理模型图、类图、时序图等。 编码 / 测试。 上线 / 维护。 瀑布模型最大的缺点是无法...
  • scrum 敏捷开发流程 scrum 标准流程图解析 三种角色 产品所有者团队scrum master ...backlog没有详细完整的需求说明书 sprint开启 PO在每一个sprint开启的时候 会有一个计划会议 会议内容,每一个spri...
  • 传统的瀑布工作模式使用详细的需求说明书来表达需求,需求人员负责做需求调研,根据调研情况编制详细的需求说明书,进行需求评审,评审之后签字确认交给研发团队设计开发。在这样的环境下,需求文档是信息传递的主体...
  • 敏捷开发的文档

    2014-06-25 11:33:00
    需求不写文档只写故事卡片,一般我也会写验收条件,...这个是作为系统说明书开发基本不太看了。重点是用例和算法,业务规则等。在代码之前编写测试:测试本身可以用来阐释真正需要的设计。设计的缺陷常常是通过测...
  • 传统的瀑布工作模式使用详细的需求说明书来表达需求,需求人员负责做需求调研,根据调研情况编制详细的需求说明书,进行需求评审,评审之后签字确认交给研发团队设计开发。在这样的环境下,需求文档是信息传递的主体...
  • 传统的瀑布工作模式使用详细的需求说明书来表达需求,需求人员负责做需求调研,根据调研情况编制详细的需求说明书,进行需求评审,评审之后签字确认交给研发团队设计开发。在这样的环境下,需求文档是信息传递的主体...
  • 转:敏捷开发 2

    2007-07-09 13:59:00
    在我们传统的印象中,需求是厚厚的软件规格说明书,实现则是无穷无尽的bug产生器。需求是在实现 之前写好的,客户签字确认的。实现是程序员拿着需求不断猜测这该怎么做,那该怎么做的重新发现的过程。在需求与实现...
  • 传统软件开发过程 传统软件开发过程中...在需求分析阶段详细分析所有的需求,由产品设计人员和需求分析人员根据市场需求以及客户反馈进行详细的需求分析,写出需求规格说明书需求规格说明书在规定时间冻结,不再允
  • 比如需求分析步骤会产生需求规格说明书。适用于需求比较没明确的项目。 瀑布模型最大的缺点就是对需求的变化无法做出应对 V模型 v模型很注重测试。单元测试主要测试编码,以详细设计为依据,集成测试测试的是详细...
  • 当没有需求规格说明书时,判断标准最终由用户决定。 测试生命周期 需求分析、计划、设计、编码、测试、运行维护 开发模型 瀑布模型 强调开发的阶段性,强调早期计划及需求调查,强调测试。风险在后期测试才能显露,...
  • 在开始编码前,并不应该尝试弄清楚所有的细节,而是只要一旦有足够的可以开始开发需求规格说明书,即可立即着手实现某些功能。毕竟,在整个开发过程中,细节是随时会发生变化的。 用例、页面流程和数据 在写出一...

空空如也

空空如也

1 2 3 4 5 6
收藏数 109
精华内容 43
热门标签
关键字:

敏捷开发需求说明书