敏捷开发猪图_敏捷开发 猪和鸡 - CSDN
  • 关于鸡与的故事有很多种版本,被用在各种不同的场合,管理的、营销的、敏捷开发的,大体相同,但稍有差异。 故事一:有一只鸡和一头合伙开饭店,双方各占50%股份。鸡对猪说:“我每天下一个蛋用来炒菜,你...

    猪和鸡的故事

    关于鸡与猪的故事有很多种版本,被用在各种不同的场合,管理的、营销的、敏捷开发的,大体相同,但稍有差异。

    故事一:有一只鸡和一头猪合伙开饭店,双方各占50%股份。鸡对猪说:“我每天下一个蛋用来炒菜,你每天割一块肉下来炒菜”,猪认为合理:“同意”。饭店后来开大了,这个饭店的股权最后会归谁所有呢?毫无疑问会归鸡,因为猪最后一定会被割死!

    故事二:一天,一头猪和一只鸡在路上散步。鸡对猪说:“嗨,我们合伙开一家餐馆怎么样?”猪回头看了一下鸡说:“好主意,那你准备给餐馆起什么名字呢?”鸡想了想说:“叫‘火腿和鸡蛋’怎么样?”“那可不行”,猪说:“我把自己全搭进去了,而你只是参与而已。”

    前面一个故事往往被用作在管理和营销上来说明一些道理,而后面这则故事应用在敏捷开发,用来说明不同角色的职责。在Scrum过程中,“猪”是在Scrum过程中全身投入项目的各种角色,他们在项目中承担实际工作。他们有些像上边那个笑话里的猪,要把自己身上的肉贡献出来。“鸡”并不是实际Scrum过程的一部分,但是必须考虑他们。

    采取Scrum模式最大的优势在于以口头的面对面沟通取代文档沟通,来保持沟通的高效与快捷,但如果参加迭代会议的人员过多时,会使沟通效率打折扣,这个时候就要求参与Scrum会议的人员明白各自的职责,关注各自的焦点,以避免限于冗长的会议泥潭中。Scrum本身非常关注这点,也就有了上面的鸡与猪的故事。从这个故事引申出来这样的结论:猪类才是团队的核心,拥有较大的话语权;而鸡类仅仅为部分参与者或者关联者,拥有较少的话语权,并明确规定在类似于站立会议中鸡类人员不得讲话、评论等。

    在Scrum团队中,一般ScrumOwner(产品经理)、ScrumMaster(项目经理)、Developer、需求分析师为猪类角色,而测试工程师、UI工程师、QA、客户等为鸡类角色。Scrum教练参与会议以控制迭代及其过程。但实际项目中往往是猪类角色没有发言,鸡类角色喋喋不休。

    展开全文
  • Scrum之三个

    2014-07-31 22:43:29
    从前和鸡一起去创业,他们两个打算开餐馆,专门出售火腿煎蛋。这时候想了一下,我用的是自己身上的肉,鸡只是用了它生下的鸡蛋。万一创业失败了,我自己命都没了,而鸡还是继续可以产蛋,没有任何影响。 1. ...

        从前猪和鸡一起去创业,他们两个打算开餐馆,专门出售火腿煎蛋。这时候猪想了一下,我用的是自己身上的肉,鸡只是用了它生下的鸡蛋。万一创业失败了,我自己命都没了,而鸡还是继续可以产蛋,没有任何影响。


    1. Scrum两类关系人


        在Scrum方法中将项目的利益相关者分成两大类:chickens和pigs,chickens为项目的相关干系人,部分投入项目,例如高层领导、最终用户等等,pigs则为项目的实际参与人员。在公司中我们都是Pigs,Pigs是全身心投入项目,直接决定项目的成败。Pigs在scrum中细分为三个角色:Scrum master、Product owner、Team,这三个角色构成一个平衡的铁三角推动整个项目的进展。


    2. 三个角色(猪)


    2.1 Scrum master

        类似于传统项目管理中的PM,但又不完全是,在项目组承担了如下的细分角色:

    (1)会议主持人:负责主持四个主要的会议:策划会议(迭代会)、站立会议、迭代评审会议、迭代回顾会议。

    (2)牧羊犬:负责屏蔽项目组外部的干扰。

    (3)活雷锋:给product owner、team提供帮助,帮助product owner确定需求、排定优先级,帮助team做估算、分解任务、完成任务。

    (4)外交官: 当项目组外部有人不理解项目组的工作时,他负责去解释说明,负责对外发布项目组的信息。

    (5)教练:指导项目组的成员按照Scrum的原则、方法做事情,当出现偏差时,他去纠正,如果有项目组的成员不熟悉Scrum的方法,他要去提供相关的培训。

    (6)清道夫:负责排除在项目进展中遇到的各种障碍,如果他没有能力或资源他可以协调项目组的其他成员一起来排除障碍。


        Scrum master并非固定的由一个人承担,可以在一个团队中,有能力的、熟悉Scrum的成员都可以担当Scrum master。


    2.2 Product owner

        是产品的负责人,或者讲是需求的负责人, 他在项目组承担了如下细分角色:

    (1)领域专家:是需求方面的专家,熟悉需求。他知道客户、最终用户、以及其他利益相关者对项目的真正需求是是什么。他负责编写用户需求、维护用户需求。

    (2)需求决策人:哪个需求重要,哪个需求不重要,需求的优先级如何排列,在某次发布中要发布哪些需求是他来拍板的。他负责来平衡需求、进度与资源的关系。

    (3)需求讲师:负责在项目进展过程中给项目组的其他成员讲解需求的含义,对需求进行答疑。

    (4)验收人:负责编写需求的验收标准,当项目组成员完成某个需求后,是product owner进行验收,他认可后才能认为某个需求完成了。

        Product owner可以来自于用户、客户、产品策划部门或者是开发部门的需求分析人员。Product owner是一个角色,并非指是一个人,可以是多个人,但是如果是多个人,这多个人要协调一致,对需求的理解与解释是一致的。在移动支付项目组中,有专职的产品经理,负责规划整个项目的需求,当然也有需要和业务方、渠道方合作的需求,这个也是产品经理和项目leader一起负责需求的沟通和获取 。

        

    2.3 Team

        是技术的责任人,是一群人,他们负责实现这个系统。在一个Scrum团队中,一般整个团队(包含product owner,scrum master)最好不超过10人,team应该是一专多能的全才型选手,而不是那种专业化分工的团队,这样才能保证团队的效率比较高,也易于沟通。团队的成员一般都应该是专职的人员,最好不要兼职同时做多个项目。team承担了如下的细分角色:    

    (1)设计人员:对系统进行简单设计。

    (2)实现人员: 负责实现整个系统,并对系统执行单元测试,构建整个系统。在计平包括了开发测试和运维的同学。

        

            

        一句话总结,Product owner定义了这个项目做什么,Scrum master从过程上保证了如何实现这个项目,Team从技术上保证了如何实现这个项目。




    推荐文章:

    《用户说卡,怎么办》

    http://blog.csdn.net/minidrupal/article/details/24544573

    《Scrum -- 晨会那些事》

    http://blog.csdn.net/minidrupal/article/details/25547577

    《产品经理的日常工作》

    http://blog.csdn.net/minidrupal/article/details/26092691

    《快速验证产品价值 -- MVP(最小可行产品)》

    http://blog.csdn.net/minidrupal/article/details/26986885

    《如何进行产品定位(上)》

    http://blog.csdn.net/minidrupal/article/details/29386543

    《用户研究那些事》

    http://blog.csdn.net/minidrupal/article/details/35841945

    《合理构建产品形态(一)——谁是目标用户》

    http://blog.csdn.net/minidrupal/article/details/37767955


     

    Author: Andy
    Introduction: Web工程师、项目经理、产品经理
    Sign: 做人如果没有梦想,跟咸鱼有什么区别 



    展开全文
  • 一天,一头和一只鸡在路上散步 鸡看了一下说:“嗨,我们合伙开一家餐馆怎么样? 回头看了一下鸡说:“好主意,那你准备给餐馆卖什么呢?” 鸡想了想说:“餐馆卖火腿和鸡蛋怎么样?” 说:“不开了,我全身...
    让我们来看这么一个故事:
    一天,一头猪和一只鸡在路上散步
    鸡看了一下猪说:“嗨,我们合伙开一家餐馆怎么样?
    猪回头看了一下鸡说:“好主意,那你准备给餐馆卖什么呢?”
    鸡想了想说:“餐馆卖火腿和鸡蛋怎么样?”
    猪说:“不开了,我全身投入(火腿是一次性资源),而你(鸡蛋是可再生的)只是参与而已!”
    

    在这里插入图片描述

    这个故事是Implementing Scrum网站为了解释,什么是Scrum而推出的系列故事中最具代表性的一个,它展示了在Scrum中的两组角色:猪和鸡。

    在故事展开之前,我们先来了解一下什么是Scrum。

    Scrum是迭代式增量软件开发过程,通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务,产品负责人代表利益所有者,开发团队包括了所有开发人员。虽然Scrum是为管理软件开发项目而开发的,它同样可以用于运行软件维护团队,或者作为计划管理方法。

    好了,回到本文开头的故事。

    猪被认为是Scrum团队中的核心成员,在一个团队中产品的负责人和Scrum主管和开发团队就是"猪"角色。

    鸡不是Scrum的一部分,但必须要考虑他们,用户、客户或提供商、经理等扮演着“鸡”角色。需要说明的是在Scrum团队中不会有一个人同时成为“猪”角色和“鸡”角色。

    我们看看团队中的“猪”都有哪类角色:

    产品负责人(Product Owner)

    即负责维护产品订单的人,代表利益相关者的利益。

    我们可以把这一角色理解为没有项目管理权限的产品经理,他只对产品负责,决定做出来的产品是什么,包含哪些功能要点。传统的软件开发流程中,产品经理是要肩负起一定的项目管理的职责的,产品经理可能同时就是项目经理,甚至在一些企业中CEO就是最大的产品经理。但是在Scrum框架中,产品经理没有项目经理的权限,无权干涉项目开发的进度,项目的成功与失败也不需要产品经理独自承担责任。产品负责人最大的职责就是做好开发团队与客户之间沟通的桥梁,维护好“产品订单”,排列出开发的优先级。简单来说,有没有按时做完项目不是产品负责人的责任,但做出来的东西是不是客户想要的就是产品负责人的事情了。所以产品负责人必须是Scrum团队的一员,和其他成员一起时刻盯着团队开发的是否是“产品订单”中列举的东西。

    Scrum主管(Scrum Master)

    即为Scrum过程负责的人,确保scrum的正确使用并使得Scrum的收益最大化。Scrum Master需要知道团队其他成员如何完成开发工作。这一角色通常要团队中最资深的那个开发人员来担当比较合适,不仅仅是他的技能可以指导其他成员,更因为他有资历去排除哪些影响Scrum实施的外界干扰。 Scrum Master虽然同样无项目经理的权限,但需要他在关键的时刻站出来,帮团队推掉来自外界甚至是高层临时下达的产品开发需求。

    开发团队

    由负责自我管理开发产品的人组成的跨职能团队。Scrum教程里倡导的Scrum团队的理想人数是7人,那么即意味着除了1个Product Owner和1个Scrum Master外,开发团队应有5人。开发团队必须是跨职能的,如果大家的技能相同,很容易出现彼此推诿的现象。 每个人都应该明确,自己的工作只有自己才能最好的完成,这样才能组合在一起形成一个团队。另外,开发团队人数不能过多。

    Scrum倡导的是自我管理的团队,这其实是违背传统的管理模式的。团队人数少的时候,即使团队中个别人缺乏自我管理的意识,那周围同伴也很容易帮助其提高和改善自我管理的能力。但团队人数一旦很多,出现一群无自我管理意识的人群的时候,那影响的作用力就是相反的,这一小群人会影响周围更多的人,此时Scrum团队又无一个专职的管理者,便会出现“无政府主义”的现象,造成一盘散沙的恶果。
    在这里插入图片描述

    属于“鸡”的又有哪类角色呢?

    用户

    在Scrum流程中,虽然不能完全听取用户的意见,但还是得时刻关注用户的感受和反馈。 因为Scrum是一种迭代式增量软件开发的过程,如果每个小模块都能得到用户良好的反馈的话,那无疑最后完工的整个系统出差错的概率会小很多。毕竟用户不是专业软件开发人员,整个系统对其来说过于庞大和复杂,一个个小模块是其能最好理解的单元个体。处理好用户与开发者关系的重要人物就是前面所讲的Product Owner,他必须及时的收集用户的反馈,以此完善每次冲刺的订单,但同时又不能让用户的反馈去影响开发的步骤。

    利益所有者(客户,提供商)

    在Scrum体系中,一旦开发团队与客户确认好开发需求后,客户应该无权在中间干涉团队是怎么完成的。客户需要了解,随意的更改需求、干涉开发的流程是很危险的,极有可能出现鸡飞蛋打的双输场面。在前期项目立项的时候要尽可能多的和客户接触,完整的记录客户所有的需求。但在开发过程中,特别是每天的站立会中,建议不要让客户,特别是根本不知道什么是Scrum的客户来旁听站立会。

    经理

    可以把他理解为项目经理或部门经理,甚至是管理产品开发的副总或直接就是老板!这群人就是故事中的鸡爷爷,他们财大气粗,有权有势,为了能开发出新的有竞争力的产品,为小猪们提供了资金和场所,所以他们对产品的意见也是至关重要的。

    Scrum实施中一个令工程师们兴奋的就是项目经理将不再管理我们的开发过程,我们自己管理自己。但实际操作起来,这确实是最难的一个环节。

    一旦项目经理在Scrum“每日立会”中下达指示,而Scrum Master又没挡住的话,那这个团队的Scrum实施就失败了,团队成员会觉得自己失去了领导的信任,被授予的自我管理的权限又被无情的收回了。

    大家又会重新回到原先的模式,每一步听从项目经理的指示,按指示办反正不会有错,失败了是项目经理指示错误的责任,成功了也能跟着项目经理分碗汤喝。

    Scrum能否成功实施,很关键的是能否得到高层的认同和理解。一个团队要实施Scrum,首要需要接受培训的就是公司高层领导们,高层领导们要权衡实施Scrum的利弊,如果Scrum能带来高效、优质的开发成果,那就应该忘记Scrum实施过程中给所带来的心灵上的折磨。我们可以合理的定好Scrum团队中每个人的KPI,让每个成员真正意识到项目成功是自己的事,而不是项目经理、高层们的事。

    Scrum能否成功实施关键在于“猪”与“鸡”两种角色之间心理上的平衡与和谐!“鸡爷爷”切不可把“小猪”们看成是一群猪八戒,空有一身本领,但好吃懒做。“小猪”们也不可把“鸡爷爷”想象成周扒皮,只会半夜鸡叫,影响正常的开发进度。猪和鸡双方相互理解,达到项目开展过程中的平衡点,才能让整个项目顺利的完成。

    展开全文
  • 本文将为您分享敏捷测试概念及Choerodon在敏捷开发过程中的测试实践。 什么是敏捷测试 在敏捷开发流程中,测试不再是瀑布式开发流程的其中一个环节,而是全程参与整个开发流程。开发中可以通过多种方式来保证产品的...

    Choerodon的测试管理主要为用户提供敏捷化的持续测试工具,包括测试用例管理、测试计划、测试分析等,可以有效地提高软件测试的效率和质量,提高测试的灵活性和可视化水平,最终减少测试时间,让用户将主要精力放到软件功能构建上。本文将为您分享敏捷测试概念及Choerodon在敏捷开发过程中的测试实践。

    什么是敏捷测试

    在敏捷开发流程中,测试不再是瀑布式开发流程的其中一个环节,而是全程参与整个开发流程。开发中可以通过多种方式来保证产品的质量,无论是原则中的“频繁交付”,还是对“可工作的软件”的度量,或是敏捷开发实践中的“测试驱动开发”、“行为驱动开发”,都离不开测试的支持。 当然,敏捷测试对测试人员也提出了更高的要求,对测试人员来说是新的挑战。

    敏捷测试人员的定义

    专业的测试人员,必须有适应变化的能力,理解利用测试记录需求和驱动开发的思想,才能与技术人员和业务人员展开良好的协作。敏捷测试人员往往具有优秀的技术能力,知道如何与他人合作以实现自动化测试,同时也擅长探索性测试,他们了解客户在做什么,以此更好地理解客户的软件需求。

    测试人员在敏捷过程的价值体现

    1. 需求讨论:测试人员可以站在客户角度上来阐述自己的观点,和产品人员、开发人员等进行充分的交流和讨论,使自己在用户体验、业务逻辑等等方面的经验充分体现出来。
    2. 开发过程:测试人员不仅扮演“用户代表”角色,而且可以及时提供更全面的质量反馈,包括代码质量、接口一致性等。测试人员不写代码,可以参与代码复审(code review),将质量问题及时提交给项目组,保证在产品构造的整个过程中质量受到足够的关注,提高质量改进的持续性和可视性。
    3. 单元测试:单元测试由开发人员做,测试人员可以推进开发人员进行单元测试,检查单元测试状态。例如确保单元测试达到75%以上覆盖率,以及帮助开发人员开发出具有良好可测试性的代码。
    4. 集成测试、端到端(end-to-end)测试、性能测试:因为在敏捷方法中,往往将一个大的系统开发分解成多个小的子系统(模块/组件),集成测试和端到端(end-to-end)测试显得更重要。其有效保证整个功能流程的完整、畅通,以及所开发的产品与其任何子系统协调良好。
    5. 回归测试:持续回归测试,保证产品的稳定性。可以采用自动化回归测试。
    6. 对缺陷进行分析:总结出一些规律,帮助开发人员建立良好的习惯,改进代码的质量。例如标记出反复出现的bug,以便于开发总结原因。
    7. 缺陷优先级:与开发沟通上有直接交流、灵活应对变化,质量控制,什么bug是重要的,什么是可以后期去做,分清bug优先级。

    Choerodon在敏捷迭代中的测试流程

    1. 需求分析:依据需求文档提取测试点

    通过分析需求描述中的输入、输出、处理、限制、约束等,给出对应的验证内容,并分析各个功能模块之间的业务顺序,和各个功能之间的传递信息和数据,对存在功能交互的功能项,给出对应的验证内容(功能交互测试)。同时需要考虑到需求的完整性,要充分覆盖软件需求的各种特征,包含隐形需求的验证,比如界面的验证,账号唯一性验证(界面、易用性、兼容性、安全性、性能压力)。

    2. 编写测试计划和测试用例

    为项目需求而编制的一组测试步骤,测试数据以及预期结果,以便测试某个程序是否满足客户需求,测试用例需关联到对应的issue或者story,测试计划的内容包含迭代内的全部开发任务。

    3. 用例评审:确认用例是否覆盖到各个场景,以及用例是否符合需求

    用例评审主要是产品、开发和测试人员,针对测试用例能否用于项目的测试而做的工作。主要是为了减少测试人员执行阶段做无效工作(提交无效问题等),以避免三方需求理解不一致。评审按用例的优先级,功能的复杂程度进行;先对优先级高,功能复杂,疑问多的用例进行评审,再评审功能简单,优先级低的功能点。评审过程中尽量做到思路清晰,用最简洁的语言阐述每一个功能点。对于评审过程中,超过5分钟无法确定结果的问题,可以记录下来,作为会后讨论跟进的重点。

    4. 测试执行

    测试执行是执行所有或部分选定的测试用例,并对结果进行分析的过程。测试执行活动是整个测试过程的核心环节,所有测试分析、测试设计、测试计划的结果将在测试执行中得到最终的检验。

    5. 转化测试后的bug

    将执行完的有bug的测试用例关联敏捷协作中的缺陷。在敏捷协作中一个缺陷可以快速定位到测试用例,帮助开发者快速获取测试结果,实现测试闭环。

    6. 回归bug测试

    通过敏捷中的迭代规划,制定团队的回归方案,积极跟开发人员沟通问题原因、修复的方案和影响。整体的回归bug测试进度计划中需要包含所有回归测试和自动化回归测试时间,同时预估好每天的工作量,与实际完成的工作量进行对比,尽早知道测试进度是正常还是延期,提早控制好风险,从而达到团队能更好地交付价值的目的。

    总结

    以上我们回顾了Choerodon猪齿鱼敏捷测试在整个项目开发中的基本流程,详细介绍了各阶段存在的主要测试活动。总的来说,敏捷测试的最终目的是持续交付,快速交付可靠的产品。敏捷过程的测试,除了对测试能力的要求之外,还要求测试人员在团队的协作能力更高。此外,随着迭代的不断增加,对自动化测试的能力也有较高要求。

    希望本文有助于正在使用敏捷模式或者打算使用敏捷模式的团队更好得理解敏捷测试。

    关于猪齿鱼

    Choerodon 猪齿鱼作为开源多云应用敏捷全链路技术平台,是基于开源技术Kubernetes,Istio,knative,Gitlab,Spring Cloud来实现本地和云端环境的集成,实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理,从而更快、更频繁地交付更稳定的软件。

    更加详细的内容,请参阅Release Notes和官网。 大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性,以及参与社区贡献:

    欢迎加入Choerodon猪齿鱼社区,共同为企业数字化服务打造一个开放的生态平台。

    本篇文章出自Choerodon猪齿鱼社区柴晓燕。

    展开全文
  • 敏捷项目中,架构师可以扮演重要的角色吗?还是说,因为他们倾向于“预先做大量设计(big design up front)”而只能成为辅助角色?最近,微软的企业架构师Nick Malik在一篇博文中对该话题进行了探讨,他的结论是...

    在敏捷项目中,架构师可以扮演重要的角色吗?还是说,因为他们倾向于“预先做大量设计(big design up front)”而只能成为辅助角色?最近,微软的企业架构师Nick Malik在一篇博文中对该话题进行了探讨,他的结论是,架构师完全可以在使用Scrum的软件项目中扮演关键角色。

    \

    Malik的博文源于一个项目。在这个项目中,他试图把架构实践活动作用于Scrum过程。在文章的开头,他就立即断言,软件架构与敏捷开发过程并冲突。不过,他也承认,在一个交付周期较短的Scrum项目中,花费数月时间编写文档和图解系统的传统架构实践活动“相当傻”。但是,必须承认,任何软件项目——包括通过Scrum开发过程交付的项目——都有一个基本的软件架构。

    \
    \

    软件架构的价值在于,它对系统自身核心基础设施做一系列关键决策:哪里需要泛化?要使用分层模式吗?如果使用,每一层的职责是什么?每一层包含哪些模块以及为什么要创建这些模块?如何在层和组件之间划分系统的职责?如何将模块进行大规模部署?信息如何在模块之间以及系统与外围系统之间流转?

    \

    这些问题的答案可以说明一个系统的架构是什么样子。

    \
    \

    据Malik说,做每一项选择都要仔细平衡系统的一连串质量需求。软件架构师在软件架构职责的三个不同层次上工作时均需要考虑这些需求。

    \

    86a661862cae25aafed52d5df7facd0d.png

    \

    原始地址

    \

    最上面一层称作“校准过程(Aligning Processes)”,每季度或者每半年发生一次,解决整个组织的信息和商业策略相关的架构问题。这一层的输出是组织的未来软件模型。第二层包括“平衡过程(Balancing Processes)”,它与给定的软件项目相关联,可能发生在前面几次Scrum冲刺的推进过程中。Malik解释说,在这一层会对系统的逻辑架构进行精心设计。

    \

    这些过程考虑单一系统的需求,但仅仅决定几个方面的问题,包括为什么软件要分成模块、层和组件,如何进行职责划分,以及最终系统使用特定技术部署到特定的环境以后是什么样子。

    \

    最后,该模型的最底层是“实现过程(Realization Processes)”。据Malik说,这一层是“架构变成软件的地方”,架构师做出具体的设计决 ,软件开发人员按照决定构建系统。Malik承认,开发人员可能不接受架构师选择的设计模式,即便如此,“开发团队还是极有可能按照架构师的描述实现软件架构,但是可以改进它”。

    \

    那么,在实践中,对于一个给定的Scrum软件开发过程,如何开展这项工作呢?Malik直接在“冲刺规划(Sprint Planning)”会议之前增加了一个阶段。原先,可以从优先“产品待办事项列表(Product Backlog)” 阶段直接进入到冲刺规划会议及后续软件冲刺阶段。现在,项目团队插入了“冲刺前Story审查(Pre-Sprint Story Review)”阶段,用于对Story进行改进及架构评估。

    \

    533cc1f0f759cb9d516744c22c511b75.png

    \

    原始地址

    \

    Malik建议在冲刺规划会议前一周执行这个专注于架构的新步骤。

    \

    在冲刺规划会议前的一周里,那些与产品经理一起工作的人可以改进Story、增加约束、完善描述和验收标准。这时,架构师开始发挥作用。他完成了上述模型中的“平衡”任务,将有(或可以创建)一份描述软件系统架构的概要文档,并且能够把文档与受该设计影响的具体Story“链接”起来。

    \

    Malik的结论是,在敏捷项目中,一名架构师是“鸡”还是“猪”取决于他在哪一层。在精心设计第一层和第二层的时候,架构师是团队的一名普通参与成员,即扮演“鸡”的角色;当在第三层工作的时候,架构师是一名投入大量时间与精力的参与者,即扮演“猪”的角色。这项由Malik推动的活动继续对架构师在敏捷实践中所扮演的角色进行研究。在今年早些时候的一篇博文中,Malik提出,架构师天生敏捷,他们注重通过增量过程完成高价值的活动,这一点与敏捷精神一致。由于企业试图提高软件开发的效率,同时又希望能够避免增加架构方面的负担,所以敏捷与架构的交点仍然是一个热门领域。

    \

    查看英文原文:Architects: Chickens or Pigs in an Agile Development Process?

    \

    感谢马国耀对本文的审校。

    \

    给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

    \
    展开全文
  • Scrum是一种敏捷开发的模式,借助Scrum,团队可以实现产品的迅速迭代,十分适用于需求变化快的行业。因此,Scrum这种模式在互联网时代被广泛地使用,受到越来越多人的追崇。本文中,Momenta无人驾驶软件架构师梁潇...
  • 敏捷开发知识体系整体框架敏捷开发工程实践项目管理 迭代开发 风险价值生命周期 多级项目规划 完整团队 每日站立会议 任务板 燃尽 需求管理 需求订单 业务流程草图 用例驱动开发 用户故事 架构 演进的架构 演进的...
  • 什么是敏捷开发1.1 敏捷开发的定义1.2 敏捷开发的原则1.3 敏捷开发的特点1.4 传统的开发模式和敏捷开发模式的对比1.5 敏捷开发的分类1.5 Scrum 一. 什么是敏捷开发 1.1 敏捷开发的定义 2001年,由Martin Fowler,...
  • 敏捷开发方法综述

    2019-07-05 10:24:04
    敏捷开发的出现是由于在2000年左右,许多团队采用庞大,重型的过程方法的趋势在逐渐增长,一批自称敏捷联盟的业界专家概括出了可以让软件团队具有快速工作,响应变化能力的价值观和原则。影响至今的就是他们的敏捷...
  • 越来越多的人将「敏捷开发」搬上台面大谈特谈,或是为了抢占市场先机、或是为了不断修正需求方向、或是表现出相当的创业精神进而“骗取”资本热钱。 有太多太多的原因让人们追捧「敏捷开发」,这些追捧既有目的性...
  •  越来越多的人将「敏捷开发」搬上台面大谈特谈,或是为了抢占市场先机、或是为了不断修正需求方向、或是表现出相当的创业精神进而“骗取”资本热钱。  有太多太多的原因让人们追捧「敏捷开发」,这些追捧既有目的...
  • 敏捷开发知识体系

    2017-03-28 08:27:22
    敏捷开发知识体系整体框架 敏捷开发工程实践 项目管理 迭代开发风险价值生命周期多级项目规划完整团队每日站立会议任务板燃尽 需求管理 需求订单业务流程草图用例驱动开发用户故事 架构 演进...
  • 这是敏捷开发一千零一问系列的第三十一篇。(在这里提问,之一,之二,之三,问题总目录)这是在QQ群中偶然有人提到的一个问题,估计很多人都想知道。特别是有一次培训到半小时左右的,也就是刚听了敏捷概论的时候,...
  • 简要介绍《轻松Scrum之旅–敏捷开发故事》以小说的方式向我们介绍了主人公在经历了如噩梦般的传统的瀑布开发模型后,成功向敏捷开发转型的故事。 作者通过4个迭代开发过程,展现了主人公是如何从一个敏捷开发的新手...
  • 敏捷开发知识体系整体框架 敏捷开发工程实践 项目管理 迭代开发 风险价值生命周期 多级项目规划 完整团队 每日站立会议 任务板 燃尽 需求管理 需求订单...
  • 一个是敏捷开发的宣言 另一篇是稍微具体的方法
  • 敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可...
  • 《C#敏捷开发实践》是一本相当不错的良心之作。本书分为两个部分: 第一部分:讲了敏捷开发的一些原则,书中列举了一些很不错的实现例子。本书主要使用的是Scrum的敏捷开发流程 第二部分:通过一个具体开发过程中...
  • 最近在参与一个采用敏捷开发的项目,近几天又看了一本关于Scrum的书。在此跟大家分享一下。 敏捷开发不同于以往的瀑布模型开发。 瀑布模型中有严格的文档要求(需求、概要、详细等)、对员工的工作量也有明确的定义...
1 2 3 4 5 ... 20
收藏数 1,743
精华内容 697
热门标签
关键字:

敏捷开发猪图