2019-05-18 18:58:21 Peter_Changyb 阅读数 609
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13683 人正在学习 去看看 张传波

    敏捷开发中的POProduct Owner,产品或业务负责人,即熟悉该产品所有业务相关的逻辑、流程、设置等方面事宜的人员,一般可由产品经理担任,也可由熟悉业务的开发人员担任。如果敏捷团队是在一起办公的,建议由产品经理担任,本身产品经理已经是所有业务的接口人,熟悉业务是其本职工作;如果产品经理和开发、测试团队是两地办公的,如设立的研发中心、外包服务等形式的,建议在开发团队内指定一个人来担任PO,这样产品经理在第一次PRD全体review之后,只需跟这个PO讲解清楚产品逻辑,后续开发和测试当中遇到的问题,都可以咨询PO来得到解决,PO不确定的可以联系产品经理确认,这样可以减少一部分的沟通成本。

    敏捷开发中的SMScrum Master,字面意思是敏捷专家或者敏捷大师,即熟悉敏捷开发模式及敏捷实施流程的人员,一般可由敏捷团队当中的开发负责人担任,部分能力很强且懂技术的产品经理也可担任这个角色,因涉及到工作量评估和分派等工作,最好都是由技术能力较强的人员担任。

Product OwnerPO

Product Owner角色定义

确定产品的方向和愿景,定义产品发布的内容、优先级及交付时间,为产品ROIprofitability of product)负责。 是维护产品需求清单( product backlog )的人,代表利益相关者的利益。

Product Owner工作职责

负责最大化产品以及开发团队工作的价值。主要职责如下:

1、确定产品的功能;

2、决定发布的日期和发布内容;

3、为产品的ROI负责;

4、根据市场价值确定功能优先级;

5、每个sprint中,根据需要调整功能和优先级(每个sprint开始前调整);

6、接受或拒绝开发团队的工作成果;

7、参与Scrum Planning MeetingsSprint计划会议),Sprint Review MeetingSprint评审会)和 Sprint Retrospective MeetingSprint回顾会)

Product Owner在团队中的作用

junior团队中:主要的需求来源,个人确定需求价值和优先级

intermediate团队中:多角度的收集需求,和团队成员共同确定需求的价值和优先级

Senior团队中:和团队成员共同提出和收集需求,共同对产品负责

这里的团队分级主要是指团队的敏捷成熟度,即产品团队实施敏捷开发模式后,对敏捷开发模式的适应程度、接受程度和学习程度。后面会专门介绍团队的评估标准。

一句话总结PO这个角色就是:告诉产品团队要做什么,做功能的先后顺序是怎样的,需求有变动时该如何处理。

Scrum MasterSM

Scrum Master角色定义

是团队的导师和组织者,与Product Owner紧密合作,及时为团队成员提供帮助。促使team按照scrum方式运行,为Scrum过程负责的人。

Scrum Master并非团队的领导(因为团队是自我组织的),而是一个负责屏蔽外界对开发团队干扰的角色。 Scrum Master是规则的执行者,他是Scrum团队中的服务型领导。

Scrum Master工作职责

确保scrum被理解和正确使用并使得Scrum的收益最大化。主要职责如下:

1、保证团队资源合理利用;

2、保证各个角色及职责良好协作;

3、解决团队开发中的障碍;

4、作为团队和团队外部的接口,协调解决沟通中的问题;

5、保证开发过程按计划进行,组织Scrum Planning MeetingsSprint计划会议), Daily Stand-up Meeting(每日站会), Sprint Review MeetingSprint评审会)和 Sprint Retrospective MeetingSprint回顾会)。

Scrum Master在团队中的作用

junior团队中:主导和控制

intermediate团队中:引导和教导

Senior团队中:辅导和协助

一句话总结SM这个角色就是:教整个团队怎么做,如何估时,跟进每天进度,风险控制,定期总结,计划排定。

2019-11-20 09:34:20 qq_44614026 阅读数 45
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13683 人正在学习 去看看 张传波

本部分将简要介绍敏捷开发中测试人员所需要具备的素质和职责。

敏捷开发团队介绍

我们的敏捷开发团队由四位开发人员、两位测试人员、一位产品设计,一位项目经理和一位产品经理组成(参见图 2)。每天早上十点,在固定的时间和会议室里面,团队会举行站立会议。这时候,团队成员按照既定的顺序向项目经理汇报各自前一天完成的任务,所遇到的困难和当天要完成的任务。同时,项目经理更新 Sprint Backlog(一张制作精良的 Excel 表格),并及时解决每个人所提出的问题。

在这里插入图片描述

测试人员需要具备的素质

测试是软件开发中不可或缺的一部分。在敏捷软件开发中亦是如此。不同的组织给测试人员以不同的称号:测试开发 (Test Developer)、质量分析员 (Quality Analyst)、软件质量工程师 (Software Quality Engineer) 等。

每个称号隐含有不同的职能。以上的称号分别对应以下的能力要求:

具有质量检测和编写代码的能力–> 测试开发

具有防止缺陷 (Quality Assurance) 和质量控制 (Quality Control) 的能力–> 质量分析员

具有开发和执行测试程序的能力 -> 软件质量工程师

总结而言,有三方面的基本素质要求:代码编写(Coding)、测试 (Testing) 和分析 (Analysis)。

在很多其他的开发流程中,各个测试阶段对测试人员的能力有所不同;有时候侧重分析(比如系统配置测试),有时候侧重代码编写 ( 比如功能测试 )。但是,在敏捷开发流程中,测试人员需要结合这三方面来开展工作,只有这样才能真正反映敏捷测试的本质:简单而高效得应对变化。

测试人员的主要职责

在敏捷软件开发中,测试人员的职责有三个主要方面:

定义质量 (Define Quality)

这应该是软件测试人员的基本职责。敏捷方法鼓励测试人员在 Sprint 计划的时候直接与客户交流,从自己的经验出发,共同为产品功能制定质量要求。

交流缺陷(Communication)

敏捷过程强调团队中的交流。开发人员经常会专注于重要而新奇的功能,测试人员应该抓住细节,寻找设计中的“missing door”;另外,开发人员使用单元测试来保证产品的基本质量,测试人员可以使用验收测试(Acceptance Test)来鉴定客户需求与实际成果之间的不一致性。

及时反馈 (Feedback):

敏捷过程强调简单而高效。测试人员需要及时反馈产品目前的质量问题。
这样一来,团队才可以立刻着手解决。如果传统的流程是一周汇总一次状态的话,敏捷流程要求每天汇总质量问题。在我们的项目中,内部的测试报告会以网页的形式显示在内部站点上。每个团队成员能够随时获取。
另外,我们的测试框架提供自助测试 (Self-assistant Test):通过点击测试用例列表中的某个具体用例,开发人员不需要中断测试人员的工作就可以重现缺陷。

敏捷开发中QA的职责之敏捷中的QA

QA,通常指的是质量保证(Quality Assurance)工程师,但我更喜欢定义敏捷中的QA为质量分析师(Quality Analyst),主要基于以下几个方面的原因:

质量保证更偏向于工业说法,称参与软件测试的人员为质量分析师感觉更恰当;

质量保证师更多的还是把测试当作软件质量的最后把关着、看门人,而敏捷中的QA更多的是建议提供者而非看门人,把QA称为质量分析师更能体现敏捷中团队对质量负责的原则;

质量分析师更重视业务价值,关注业务价值的分析。

QA,质量分析师,显然与测试有关。敏捷中的QA,也就是与敏捷测试有关。敏捷测试就是在敏捷开发模式下对软件进行的测试,要求尽早测试、频繁测试,以及时提供反馈。敏捷测试要求团队对软件产品的质量负责,而不是某个带有QA头衔的特殊人员。 敏捷中的QA可以是参与敏捷测试的所有团队人员,而并不一定是特定的专职的测试人员。

这听起来是不是有点特别?跟传统开发模式下的测试人员是不是有些不一样?别急,我们先来看看敏捷中的QA是如何进行日常工作的。

敏捷QA的日常活动

从迭代到发布,敏捷测试的生命周期各个阶段QA的活动主要有:测试分析,测试自动化策略分析、框架构建等,故事测试,迭代计划会议和客户演示,测试自动化的维护和执行等。如下图示:

在这里插入图片描述

QA通常不是仅仅工作在某个迭代,而是并行的同时工作在多个迭代:要对当前迭代的故事进行验收测试、探索性测试,和开发人员结对实现测试自动化;还要和业务人员结对分析下一个迭代的故事,编写验收标准和测试用例。

在这里插入图片描述

在单个迭代内部,伴随着故事生命周期,QA的活动有哪些呢?用户故事生命周期包括以下几个阶段:故事分析、故事计划、故事开发、故事验收、故事测试/探索性测试、系统测试和客户演示。QA参与故事的整个生命周期,在每个阶段都会发挥作用。

在这里插入图片描述

  • 故事分析阶段:需求澄清,业务场景和验收测试的确认

  • 故事计划阶段:拆分测试任务,在每个故事开发估算基础上考虑测试的时间和估算

  • 故事开发阶段:和开发人员结对实现自动化测试,和团队沟通发现的问题和缺陷

  • 故事验收阶段:开发人员开发完故事后,QA和业务分析人员要在开发机器上进行验收,以提供快速的反馈;同时还要对测试覆盖率(单元测试、组件集成测试、功能测试)进行确认和提出反馈

  • 故事测试/探索性测试阶段:执行自动化验收测试,执行探索性测试,强调会阻碍故事发布的因素,和团队就测试覆盖率进行沟通,为发现的缺陷添加自动化测试

  • 系统测试和客户演示阶段:执行端到端的系统测试,执行业务或集成的用户测试场景,和团队及客户就功能特性的质量和稳定性进行沟通,参与给客户演示功能和特性

正如前面提到的,在每个阶段,QA除了要独立进行测试,通常还需要跟不同的角色结对,包括业务分析人员、开发人员、以及客户。

在这里插入图片描述

  • QA与业务分析人员结对:通常在业务分析师分析用户故事的时候,QA要与业务分析人员结对编写验收标准。通过与业务分析人员结对,QA能够更好的理解领域知识,从而有利于定义合适的测试用例;QA从测试角度添加的验收测试用例可以帮助整个团队对产品功能性有更好的理解。

  • QA与开发人员结对:QA和开发人员分别能给团队带来不同的技能集,认识到这一点很重要。
    作为一个团队,最好通过平衡不同的技能集来获得共同的目标。这对于传统的瀑布式团队来说是一个很重要的心态改变。
    通常在实现测试自动化的时候,QA与开发人员结对是比较理想的方式。这样结对实现的自动化测试质量相对较高,有测试意识较强的QA参与能够保证自动化测试测得是真正需要测试的部分,而开发人员的编码能力有利于写出简洁可维护的自动化测试代码。
    另一方面,QA通过与开发人员结对,编码能力也会相应有所提高,而开发人员通过与QA结对,测试意识也会增强,更有利于编写质量较高的产品代码,更有利于形成全功能团队。

  • QA与客户结对:客户是业务领域专家,通过与客户结对,QA能够更好的从终端用户的角度理解系统,从而定义或者增加更多的端到端的测试用例;
    一旦QA理解了领域知识和终端用户的观点,其业务价值分析能力会有所提高,在团队需要的时候可以承担业务分析角色;在用户验收测试(UAT)阶段,QA通过与客户结对,帮助客户熟悉使用系统,在必要时可以帮助客户解决一些系统问题。

敏捷QA的这些日常活动,的确反映出敏捷QA的日常工作内容和方式都跟传统开发模式下的测试人员有很多不同。下面为大家来详细介绍一下两者的不同,以及敏捷测试对QA的要求有哪些。

敏捷QA与传统测试人员有何不同

我们分别从团队构成、测试阶段、工作方式、关注点、业务知识来源以及发布计划制定几个方面,来看看敏捷QA与传统测试人员有哪些不同:

传统测试人员 敏捷QA
单独的测试团队 多角色开发团队的一员
在开发流程后期才开始测试 测试贯穿于整个开发流中
通常是独立工作 QA和不同角色进行结对
被当作最后也是唯一的质量保证 关注并强调风险
缺乏与业务人员的直接沟通 和业务人员直接沟通
没有机会参与发布计划制定 参与发布计划的制定

从上表的对比可以看到,敏捷QA是特殊的,主要体现在:

  • 敏捷QA是提出建议者而非看门人,需要在参与的每个阶段提出自己的建议,而不是等到开发流程最后来对系统进行验证;不仅要验证开发设计是否满足需求,还要发现需求是否能真正体现业务价值,分析是否有不恰当或缺失的需求。
    比如说,敏捷QA在跟业务人员结对编写验收标准的时候发现故事分析过程中漏掉的需求,在跟开发人员结对过程中跟开发人员讨论某个测试放在哪层实现比较合理等。

  • 发现风险,并将风险与团队及客户沟通。QA参与整个开发流程,对系统整体的认识和把握可以说是团队里边最全面的,因此也更容易看到系统存在的风险。

  • 及时向团队提供关于产品质量的反馈,便于调整。在每个迭代结束时候,QA需要分析统计该迭代的缺陷,并结合自己通过测试对系统质量的了解,及时跟团队反馈,讨论分析质量下降的原因以尽快作出改进,或总结质量上升的经验,鼓励团队再接再厉。

  • 在制定产品和版本的发布计划的时候,QA可以根据自己对产品质量的了解,从测试人员独有的视角提出一些关键的建议。

  • QA通过参与开发流程的每个阶段,能够协助团队从内部提升质量,让质量融入到产品开发中来。比如:在故事验收阶段对测试覆盖率的确认。

这些特殊性对敏捷QA也提出了更高的要求,需要做到:

  • 具有丰富的产品知识和对用户业务目标的准确了解

  • 对不同系统和数据库所用到的技术知识的了解

  • 和不同角色以及客户进行有效沟通

  • 主动验证质量目标并及时说出自己的想法

  • 编写测试计划,列出需要执行的活动并进行估算

  • 自动化测试的能力和对测试工具的基本了解

  • 在团队内部进行知识分享,协助整个团队参与到测试活动中来

  • 持续提供并获取反馈

大家熟悉的测试工作(也是传统的瀑布式),是接到项目后参与需求评审,然后根据需求文档写写用例和准备脚本,等开发提测之后正式开始测试、提bug、回归,测试通过后就结束了,项目交给运维上线,之后投入下一个项目继续重复这样的流程。

这样的流程看似没什么问题,但缺点是:

  • 测试过程是在一定时间间隔内发生的,测试人员必须等待产品完全构建才能找到错误和故障。不可否认,花费的时间超过了可以商定的时间;
  • 测试同学非常被动:当需求质量、开发质量差的时候,你只能被动接受,结果就是你会进行漫长痛苦的测试过程以及因为质量差导致上线延期;
  • Bug的成本在后期是非常高的,需要花费很多精力和时间去修复。甚至严重的情况是产品都不能按时发布,导致很大的损失。
  • 很有可能一个线上问题裸奔了几个月,最后是业务方先发现才排查到是Bug导致,由于影响时间过长给公司造成的损失巨大,还被质疑为什么这么明显简单的问题上线之后没人发现。
2019-08-24 23:07:05 seagal890 阅读数 70
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13683 人正在学习 去看看 张传波

[敏捷开发实践] Product Owner的职责

在敏捷软件开发方法中,团队成员被分配不同的角色。敏捷开发Scrum框架具有以下角色:产品所有者(Product Owner)、Scrum Master、Scrum Team。当然还有项目干系人(Stakeholders)。Scrum框架的所有这些角色都有其重要性,在本文中,我们将详细讨论产品所有者(Product Owner)的角色和职责。

Product Owner首先是项目团队中对产品有非常清晰的愿景,并且有能力将自己的产品愿景转化为精确的Product Backlog的人。

这些Product Backlog可以被进一步分解为User Story并按照优先级分配到团队的Sprint迭代中。团队估算在预定的期限内完成Sprint中的Product Backlog/User Story的工作量。Scrum框架中的Sprint迭代时间从1周到4周不等,这取决于每个Sprint内需要完成并交付的Product Backlog/User Story的数量。

Product Owner是在编写了User Story(其中描述了产品和客户需求)之后启动Scrum框架过程的人。这些User Story对产品的功能和Vision有清晰的描述,开发者和测试者可以很容易地理解这些信息,并利用这些信息提供工作量的估算。

这里先留下一个问题:

  • 谁来将产品需求编写成为Product Backlog? 
  • 谁来编写User Story?
  • User Story 和 Product Backlog有什么异同?

Product Owner 的职责(Responsibility)

包括但是不限于以下职责

  • 为最终发布的产品质量负责
  • 为Scrum团队的成长提供有效的意见
  • 为实现Product Vision负责
  • 确保产品功能如期发布(Release)
  • 能够总结产品开发和发布过程中,和产品发布之后关于功能和质量的经验教训
  • 是产品干系人和Scrum Master、Scrum Team之间沟通的桥梁
  • 100%理解敏捷开发和Scrum过程框架
  • 尊重并推崇敏捷开发文化和Scrum框架(规则)

Product Owner的行动指南(Concrete Guidelines)

包括但是不限于以下行动

  • 创建和维护 Product Backlog
  • 为Product Backlog进行优先级排序(Prioritize Product Backlog)
  • 为每一个Sprint迭代分配Product Backlog
  • 协助Scrum Master组织项目会议
  • 参加Scrum Planning Meeting
  • 与Scrum Master和Scrum Team沟通用户需求,并澄清需求,反馈团队意见
  • 维护Scrum Master和Scrum Team 与 Stakeholders之间的关系(尤其是信任关系)


在讨论了Product Owner的上述角色和职责之后,很明显,Product Owner在Scrum框架中扮演着非常重要的角色,因为他在工作实际中充当产品/业务需求以及这些产品/需求的技术实现为最终产品之间的接口。

 

2019-08-25 00:06:24 seagal890 阅读数 135
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13683 人正在学习 去看看 张传波

[敏捷开发实践] Scrum Master的职责

Scrum Master 是仆人式领导者,能够为Scrum团队提供支持,让团队功能完善并高效运作。

  • 作为Scrum框架规则的维护者,帮助项目团队和组织遵守Scrum价值观和实践;
  • 以被动和主动的方式帮助团队扫清项目障碍,并保护Scrum团队免受外部干扰而专注于Sprint迭代开发工作;
  • 促进Product Owner以及其他项目干系人(Stakeholders)和Scrum团队紧密协作;
  • 促进Scrum团队内部建立共识;
  • 保护Scrum团队免受组织层面的干扰;确保Scrum团队中的每位成员都能够在正确的时间专注于正确的工作优先级;
  • Scrum Master 是Scrum过程开发模型方面的专家,能够指导他人工作;
  • Scrum Master需要具有良好的沟通能力,并并拥有足够的组织影响力

有效的Scrum Master的特质

职责 优秀的Scrum Master的特质
维护Scrum框架规则 是Scrum流程的专家,对敏捷实践具有优秀的经验和成功案例
为Scrum团队扫清障碍,防范干扰

拥有组织影响力,可以迅速解决问题

善于表达、讲究策略、具有专业的业务能力

是优秀的沟通者和聆听者

坚定秉持Scrum Team的需求,只专注于项目和当前Sprint的工作

促进外部项目干系人(Stakeholders)和Scrum团队的密切协作

能从全局角度审视项目的需求

能避免工作中拉帮结派,帮助打破团队和成员孤立

引导建立共识 了解如何帮助团队达成一致的意见的方法
仆人式的领导者(Leader)

不需要或者不想要成为组织的领导者,或者更高级的Manager

确保开发团队的所有成员都获得必要的信息以完成工作、使用工具和追踪进度

真正渴望帮助Scrum Team成功的人

 

2014-10-18 09:00:00 cpongo4 阅读数 9
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13683 人正在学习 去看看 张传波

敏捷软件开发,有时被认为是一种没有章法的工作方式。一些机构以此作为不采纳敏捷的理由;而在另一些人看来,敏捷其实是一种比瀑布式开发更有章可循的软件开发方法。下面,我们就来考察章法在敏捷开发中的职责,以及为什么章法对敏捷的成功实施如此重要。

\\

Norberto Gaona在Nearshore Americas上发表了一篇题为《不可低估章法的重要性:敏捷开发的关键》的文章。他就敏捷软件开发中章法的重要性采访了一些人。他总结道:

\\
\

大家一致赞成的是,必须了解敏捷宣言,并透彻理解敏捷开发的12条原则。软件开发专业人士们都同意这一点,即无论采用什么框架(SCRUM、看板、精益、XP或敏捷建模等等),都存在着误读或偏离这些原则的风险;从而造成了没有章法的局面。

\
\\

Norberto解释道,对敏捷软件开发来说,在敏捷宣言中的各条之间找到一个恰当的平衡是很重要的,这就需要一定章法:

\\
\

根据敏捷宣言,个体及他们之间的互动高于所采用的工具和流程。Juan Diego Vasco解释说,“尽管这并不是说流程和工具没有用”。“敏捷开发方法其实是需要文档的,只是不过度文档化”,他说。“如果你认为敏捷意味着无章可循,那就大错特错了。事实上,由于敏捷采用自管理团队,它对章法的要求是高于平均水平的。”

\
\\

正如Scott Shipp在《敏捷不是边写边改》一文中提到的,敏捷不能成为你采取无章法的边写边改(code-and-fix)的做法的借口。他解释了为什么敏捷是一种更强、更有章法的软件开发方法:

\\
\

许多传统开发方法给人以一种虚假的有章法的感觉。敏捷强调个体与协作,可工作的软件、客户协作和响应变化。有些人认为,敏捷不重视遵守计划或采用流程与工具等方面。而实际上,敏捷是重视的,只不过更重视其他方面。换句话说,敏捷不是提倡无章法的工作方式,而是强调章法。

\
\\

Eric Bristow发表在CIO杂志上的《关于敏捷的九大误解》解释了为什么关于“敏捷流程相对瀑布式开发缺少章法与结构“的神话是错误的:

\\
\

成熟的敏捷开发框架规定了一个有章可循的、可重复的软件开发方法。成功的敏捷方法比传统的瀑布开发模型更讲究流程驱动与协作性。从范围管理(通过排列用户故事优先级)到项目管理(通过定义好的职责与时间),敏捷需要更多章法,因为从规划到启动,项目范围是被积极管理的,同时有涉众定期检查项目进展,并在每一阶段提供反馈。敏捷流程的弹性是有内在保障的(例如禁止在sprint期间新增需求或用户故事),从而可以防止无休止的发布周期。

\
\\

Felipe Brito在IT Business Edge上的一个演讲稿里提出了在企业里推行敏捷的五种方法。他说,组织学习和章法对于企业推行敏捷是必要的。

\\
\

自组织团队的概念告诉我们,敏捷解决过去规定性软件开发方法的不足,正是依靠更多(而不是更少)的章法。而且,随着敏捷在企业中的推广,章法也肯定会得到扩展。给团队一些自由度,但务必让团队受到训练和利用经过考验的方法与工具。在团队级自主和组织级一致之间找到精密平衡,是致胜的关键。同时,你必须建立起实践社区,为分布式团队设立协作工具,并坚持寻求和提供反馈。

\
\\

Jurgen Appelo在他的博客文章《敏捷和章法真能相容吗?》里解释了为什么有章可循的工作方式与敏捷不矛盾。他举了几个例子来说明他是如何用检查列表(checklists)和打标签(tagging)的方式来处理写书时用到的信息的:

\\
\

上周,我请一个人检查自己的故事,因为我的新书里包含了他的故事。他答道:“哇,这是我两年前发给你的故事,你居然现在还记得!”好吧,老实说,并不是我的记性好,而是我老老实实地按章做事。我把人们发给我的故事和记录保存在Gmail和Evernote里,并给它们打上标签。另外,我为书里的每一章都设了一个检查列表项,提醒我必须在将各章书稿发给文字编辑之前“把故事加到Gmail和Evernote里去”。我的另一个检查列表项,告诉我在书稿从文字编辑处返回后,先做“把修改过的故事发给故事原作者确认”这件事,然后再发给校对者。(…) 认真地说,如果没有检查列表,我将无法按敏捷的方式拿出一本高质量的书。

\
\\

在你经历的敏捷软件开发过程中,章法的重要性如何?

\\

查看英文原文:The Importance of Discipline in Agile

SCRUM敏捷开发流程

阅读数 1037

敏捷开发原理

阅读数 16

没有更多推荐了,返回首页