敏捷开发讲究的是团队的自我改进,讲究的是通过自我管理达到团队整体效能的提升,因此对于敏捷开发的绩效考核一定不要考核到个人头上,那将严重破坏敏捷团队的自管理,破坏团队内部的协作精神。
绩效考核和敏捷开发在理念上是存在一定冲突的,绩效考核更注重通过外部压力促进绩效的提升,而敏捷开发更注重通过内部的自我改进动力促进绩效提升,所以对敏捷团队做绩效考核一定要慎之又慎,否则极易破坏敏捷团队的自我改进动力,将其从与客户共赢为中心的导向变成以绩效指标为中心,那就不再是敏捷了。
如果要做绩效考核的话,对于敏捷开发团队的考核只能做到团队整体级别。在选取指标时要与敏捷的精神想匹配,可以从与客户的合作关系、团队内部的协作、响应变更的速度、可使用的工作组件的发布速度等角度去设计指标。
至于开发工作的量化,可以考虑将功能点估算作为软件规模的度量方法,相对比较客观一些,但这个指标不能反映开发过程中变更带来的额外工作量。所有指标都有局限性,关键看公司想获得什么商业目标。
敏捷开发绩效管理之九:阿米巴经营之软件团队经营什么(上)
这是敏捷开发绩效管理的第九篇。(栏目总目录)若正在为长期没有得到职务提升而感到困惑,下面的内容可能会有所帮助。因为越向上的职位越不像一个打工者,而是像一个企业的经营者。何为经营对一个开发团队而言,大致需要“经营”以下四种主要内容:产品,团队,技术,过程。当然仔细分析,可能还有更多相对次要的内容。对于一般开发人员而言,不太好理解“经营”的含义,然而经营意识的缺乏,正好是研发管理中最大的问题之一。曾经有一个与员工一起培训的部门经理,在第一天培训(讲用户故事,需求管理,用户建模,版本规划等)最后拍案而起说:“研发团队不关心市场经营,这个就是我们现在最缺少的!”。具体缺少什么呢?我们来看看一个开发团队的两种职责描述,就能发现问题。这是一种很正常的描述:1. 产品:收集、描述和分析产品需求。2. 团队:计划并分配人员完成任务。3. 技术:保证产品的技术先进性与质量。4. 过程:建立和维护项目管理制度。……这些都是中规中矩的管理概念,甚至可以说,如果能按上述条目完成管理,已经属于比较好的了。但在阿米巴式经营,或者说百度提到的“狼性”文化中,这些还不够。因此整体上可以看出,做这四件事情的人,显然是“被雇来”按照“既定制度”管理产品、团队、技术和过程的。当然这里边有一个先有鸡还是先有蛋的过程:“如果我们本来就被雇来奉命行事的,又怎么可能不奉命行事呢?”这正是阿米巴经营要解决的问题。其实很多时候领导都希望放权,但当看到所有人对“做什么”都不关心,而只是盯着“怎么做”,领导就退缩了。经营什么经营产品经营产品就是要真正把产品当作自己要做的东西,而不是别人雇自己来做的东西。要经营的内容,大致包括:1. 基于产品的商业计划(时间上的,偏重营收分析)2. 客户群定义(空间上的)3. 产品版本规划(基于时间及客户群的综合分析)……实际开发中比较容易忽略的是1和2,典型的情况包括:1. 开发人员只盯着发版计划,却不关心发版的产品的销售情况和客户反馈2. 开发人员不断开发功能,却不知道产品可能卖给谁,甚至连用户是谁都有点模糊(在我培训课程中有一个沙盘演练环节,此情况屡屡出现!)……如果陷入了这两种情况,就要思考是否忘记了主动经营产品。还有一些比较复杂的以后或许有机会会讲到(确切说,现在还没有足够的能力写出来),比如:产品线规划,即不同产品的搭配,以在原客户群中产生附加值或占领更大的市场。经营团队精英团队就是要把自己的部门、小组当作自己的小公司一样经营。包括:1. 思考合理的人数和知识体系2. 思考下属员工的职业生涯规划3. 理解和优化团队的投入产出比……“投入产出比”是一个很重要的属性,就是要理解自己团队在公司中的位置,并利用营收数据来指导团队的发展。举个例子:曾经有一次我们的团队营业额达到了上一年的3倍多一点,而大家的收入也平均增长了30%左右(这个是估计的),但大家仍然觉得心里不平衡:因为3倍和30%还是有很大差别的。但随后的营收分析揭示了一点:其实即使我们在营业额暴增之后,每年仍然净亏损150万元左右。有了这个数据,团队就冷静多了,也有了新的目标。这不是说要用这种方法“防止给下属加薪”,而是说无源之水是不长久的,要令团队知道、思考和改善自己所处的经营状态。对开发团队而言,可能没有直接可以考量的营收指标,但是另外一些指标一般也是一笔糊涂账:团队的生产率?质量?成长性?……别说具体的数值,可能连合理的定义方法团队都较少去思考。这些都是缺少经营感的表现。当然要做到精英团队很难!但这正是需要做的原因之一,因为一旦做成,别人很难复制。(待续……)本人正在参加CSDN博客之星评选
敏捷开发到底是什么意思
过去的软件如word之类的迭代都以年为周期的,自然无法应对快速变化的市场需求。因此,需要更加敏捷的方式,应对快速发展的互联网世界的发展。
敏捷开发最重要的特点是:以用户需求为中心,快速灵活,团队合作度高。
敏捷开发有很多方法,例如XP、精益开发。其中以scrum最为普遍。Scrum本义为带球过人,双方队员比赛前要摆开阵势,计划好进攻路线,而在软件开发中,团队领导人要做好迭代计划,排列优先级,规定必须完成的任务。
scrum3.0中有6个角色,3个工具,4个会议。
scrum3.0中的6个角色
利益相关者(Stakeholders):
运营、市场、销售等,他们负责向产品经理提出产品需求。
业务所有者(Business Owner):
通常是产品经理,他负责对利益相关者提出的需求进行拆解以及进行优先级排序,并负责后期的产品评审,同时负责预测一个sprint周期的时间。
团队队长(Team Captain):
通常是我们的开发经理,负责安排一个sprint内的工作安排,通过合理安排让scrum团队的效率以及价值最大化。
行业专家(Subject Matter Experts):
行业专家拥有Scrum团队需要的,但团队中没有的知识和专业技能。
协调人/教练(Facilitator/Coach):
scrum制度的落实者,让scrum在团队中流畅的运作,消除他们的障碍,提高Scrum和敏捷的使用。
变更代理(Change Agent):
Scrum的咨询顾问,将Scrum引入团队中,并帮助教练理解如何最好地支持和与Scrum团队合作。
3个工具:交付清单、工作清单、正在进行的工作。
4个会议:计划会议、产品评审、进度回顾、团队回顾。
因此,scrum3.0既有计划会议、产品评审、进度和产品回顾会议,也有迭代期内的灵活应变过程,是一种轻重结合的比较好的敏捷方法。
随着各种敏捷团队在国内成熟,很多应用于敏捷的工具也层出不穷。
在工具集中挑选适合的工具使用,可以提高工作效率。以日事清团队为例:
在日事清软件中,利益相关者如销售、市场、运营等,在与用户平日的接触中积累的功能、缺陷、创意上的建议,并收集于计划看板的【BUG看板】、【建议看板】。
接下来,业务所有者(BO)需要维护精细的需求池,这个职责通常由产品经理担任,他需要非常明白产品的定位和发展,将需求池中的任务按照优先级排序,并拆解为一个个小的用户故事。然后设置具体的实施时间和项目名称,将可交付成果和待办清单,记录于road map中。
之后,我们的scrum团队会创建一个计划为【产品开发】,产品经理(业务所有者)以及开发经理(团队负责人)会从【roadmap】中提取功能形成work backlog,复制到【产品开发】的【规划池】中,work backlog中还包含一些开发团队必须做的工作,会直接记录在【规划池】中。
正式开始开启sprint (sprint:整个开发过程中若干个短的迭代周期组成)的第一件事,就是召开sprint计划会议。sprint会议上会确定本次sprint周期的目标是什么,我们需要完成哪些功能。在会议中,开发经理(团队负责人)需要将【规划池】中的功能拖动到【开发中】,从【开发中】到【测试中】就是日事清所实践的正在进行的工作(WIP)。
会议上会评估每个功能所需的工时以及功能的负责人,我们为确定好的功能添加时间以及任务成员。通常计划会议会开比较长的时间,它是之后迭代开始运作最关键的会议。
为使得这个会议得到很好地传达,可以通过日事清的日程应用创建好会议任务,并下发给团队成员。
sprint计划会议的开启,意味着第一个sprint开始了:从开发到测试,形成的工作成果都发布到beta版本中。执行sprint的过程中也有很多问题被发现,需要解决,应此需每日召开约15分钟的站立会。
在每日站立会上,每个团队成员需要回答三个问题:
● 昨天做了什么工作?
● 今天要做什么?
● 完成目标是否存在什么问题?
当测试人员完成了本个周期内的所有功能的测试工作时,预示着本个sprint结束。
在迭代结束前,产品负责人需要进行产品评审,产品会对测试中的功能进行验收。将达到了产品目标的成果拖动到【待发布】中。
最后整个团队还需要进行一次回顾总结会议,回顾这次迭代有哪些做的好,哪些做的不好,有什么计划。团队成员需轮流发言,完成自评和他评,分析和总结上一个迭代中遇到的问题,并列出下次的可执行任务,便于改进整个团队的效能。
至此,一个sprint周期完成,以此开始下一个sprint,不断循环往复。
想找一个敏捷过程框架设计
建立敏捷统一过程框架【内容提要】我建议,软件企业可根据自身的实际情况,以统一过程(如 RUP)为基础建立起符合ISO 9001、SW-CMM 和CMMI SE/SW等基准的组织软件过程体系,同时包含敏捷过程(如XP、Scrum)和重型过程(如TSP)等内容。我把这种混合/集成过程体系叫做“敏捷统一过程框架”(Agile Unified Process Framework,AUPF)。
一、过程成熟度与多样性
近年来软件过程改进在国内日益得到重视,一度出现了许多组织纷纷开展 SW-CMM 商业评估的热潮。迄今全国已有近两百家软件企业通过了 SW-CMM、CMMI 各级评估(1 2 3)。这一方面说明原本作为美国军方标准(如今已成为全球通行的国际标准)的 SW-CMM、CMMI 并非高不可攀,另一方面也说明加强软件开发规范化管理、提高过程成熟度已经得到了业界的广泛认同。
婴儿洗澡椅热季促销行政侵夺科学的灾难美女博客决赛进行北京手机资费下调
与此同时,国际软件界的“敏捷热”、“统一热”也在持续升温。上世纪 90年代以DSDM、Scrum、FDD、Crystal、ASD、XP为代表的轻型软件开发方法逐渐兴起,其中又以XP对传统的“反叛”最为显著,它凭借与传统思维相悖的“极端”做法既获得了许多软件客户、管理者和开发人员的积极拥护,也遭到了传统过程维护者的激烈反驳。2001年2月敏捷联盟成立以及《敏捷软件开发宣言》的发表,标志着这场“敏捷运动”达到了一个高峰。而作为吸收了电信、国防等关键行业以及IBM、HP、Microsoft等多家国际著名软件企业过程经验的商用过程产品,统一过程RUP也在全球取得了广泛的成功。某著名咨询机构 2002 年对全球200位软件相关行业IS/IT经理进行的调查表明:RUP使用率达到了51%,远高于SW-CMM(27%)和ISO 9000(26%);而且到2003年, 大约50%的被调查者预计其50%以上的项目会使用敏捷方法,14%的被调查者认为其所有的项目会使用敏捷方法 [2] 。
承认软件过程的多样性与追求其成熟度一样重要。“ One size does not fit all ”,事实证明不存在一成不变地适合于所有项目的过程模板。由于软件过程的周境不同(如业务、资源、团队、文化),层次不同(如组织过程、项目过程、团队过程、个体过程),开发类型不同(如新产品、重用、服务、产品线),一时间出现这么多过程方法论并不足怪。
二、过程方法论对比分析
那么,敏捷、统一过程有哪些特点,与传统过程有什么不同呢?下面我们以 SW-CMM 为参照,挑选 3 个最典型的过程方法论( XP 、 RUP 和 TSP )作对比分析。
SW-CMM是一套用来评估软件组织过程成熟度的基准,阐明组织为了系统地实施软件过程改进、提高过程成熟度应该做些什么,但没有规定如何去做。它的目标通常适用于所有的软件组织或项目,用来实现目标的大部分关键做法也适合中小企业项目,而许多关键做法中的子做法主要目的是举例说明如何在大型政府、国防合同项目中实现总目标,对中小企业项目仅有参考价值。除了对过程的集成性关注不够,SW-CMM的主要缺点还在于缺少了现代软件过程的一些重要元素,其KPA主要集中在传统过程的静态文档上(如设计、需求文档,合同、计划和报告等),只有很少数的KPA强调了演进式工件(如需求、设计模型,源代码等)、开发环境的自动化水平以及基于架构的过程。 [6]
为了尽早通过评估,人们往往采用或模仿同样是由SEI开发的PSP/TSP过程。建立在PSP之上的TSP可能是迄今为止最为严格的重型过程。为了提高过程的成熟度和可预测性,TSP强调对过程进行全面精确的度量,这依赖于制作大量复杂繁琐的数据表格和文档以及固定程式化流程配合,因而培训、实施的成本很高。
RUP是一个以用例驱动、构件式架构、迭代递增式开发为基本特征,可广泛地应用于各种类型和规模项目的软件过程框架,它的基本特征与需求管理、配置变更管理、OOAD*UML可视化建模、持续检验质量等做法一起集中体现了现代软件开发的最佳实践。RUP定义了起始、细化、构造、移交4个阶段和业务建模、需求、分析设计、实现、测试、部署、配置变更管理、项目管理、环境等9个工种。阶段对应着主里程碑的划分,不同工种的工作流活动在生命周期的迭代中并发进行,具体执行强度可以按需调节,角色、活动和工件也是灵活可配置的。由于RUP提供了极其丰富的内容,所以常被误解为一个重型过程。通过定制RUP通用框架,针对具体项目去掉不必要的元素并吸收其他敏捷方法,完全可以定制出敏捷轻型的RUP过程(如RUP的XP插件)。
极限编程 XP具有强沟通、简化设计、迅速反馈等特点,一般只适合于规模小、进度紧、需求不稳定、开发小项目的小团队。在其12种做法中,测试为先、持续集成、简化设计、代码规范、现场客户、每周40小时工作制、小型发布等早已有之,并不是新的发明,但XP通过巧妙整合把它们发挥到了极致。而代码集体拥有、结对编程、重构、系统隐喻、计划游戏等做法并不是在任何情况下都适用的,使用不当往往会起到相反效果。SW-CMM与XP是互补的,Barry Boehm、Watts Humphrey等权威更认为XP与SW-CMM是哲理相容的 [5] 。主要区别在于,后者更关注过程实施在组织管理上的问题,而XP侧重于具体的过程执行和开发技术,不含有被SW-CMM认为是使良好的工程和管理实践制度化的关键基础设施。
许多团队在一定条件下实践 XP可能会收到意想不到的好效果,但纯而又纯的XP的适用面可能也很小。克莱斯勒公司的C3薪资系统项目恐怕是引用次数最多的XP成功案例,但实际上该项目后期还是由于开发团队与管理者之间的沟通出现问题而遇到了麻烦。一个经典的XP项目偏偏在其核心的沟通要素上出现问题,的确值得人们深思。 [7]
XP以代码为中心,编码和设计活动融为一体,弱化了架构,这是它与以架构为中心的RUP的最大不同,而且它没有业务建模、部署、过程管理等概念。两者也有不少共同点:它们都采用OO技术(取代传统结构化方法)、演进式迭代周期(取代传统瀑布模型),强调风险驱动,以保障可用产品的持续性交付为前提,尽量减少不必要的过程工件,使度量、文档最小化以获得弹性和应变能力。由于RUP、XP结合了具体的开发方法,因此比TSP具有更好的可操作性。
敏捷、统一过程满足了 SW-CMM绝大部分目标及2、3级KPA的要求,对4、5级KPA基本没有涉及。然而,服从类似SW-CMM这样高质量的过程框架,并不一定会开发出高质量的产品,生产出高质量产品的真正高质量的过程却理应被评估为成熟的过程 [6] 。事实上,国际上不少采用RUP的组织已经达到或超过了SW-CMM 3级的水准。通过SW-CMM评估要求组织在过程制度化建设上付出大量复杂、高成本的努力,但过程改进的有效性与复杂性、高成本之间没有必然联系。过程选择的多样性和SW-CMM目标的通用性决定了过程改进途径的多样化。
内容太多,只好再到网上查找:
来源网站:“ERP总设计师论坛”(摆渡搜索)[面向敏捷Agile栏目]
涉及:ERP解决方案||需求分析||业务建模||系统分析||信息监理;
什么是敏捷工艺?
敏捷工艺(Agile process)来源于敏捷开发。敏捷开发是一种应对快速变化的需求的一种软件开发能力。相对于“非敏捷”更强调沟通,变化,产品效益。也更注重做为软件开发中人的作用。
敏捷开发的四条宣言:
个体和协作 胜于 过程
可工作的软件 胜于 完整的文档
客户协作 胜于 合同
响应变化 胜于 遵循计划
linux后台开发必看书籍
程序设计类
《C++ PRIMER》
系统编程类
《UNIX环境高级编程》
W.Richard Stevens:非常经典的书。虽然初学者就可以看,但是事实上它是《
Unix Network Programing》的一本辅助资料。国内的翻译的《UNIX环境高级编程》的水平不怎么样,现在有影印版,直接读英文比读中文来得容易。
《Unix网络编程卷二》
Unix网络编程卷第二卷没有涉及网络的东西,主要讲进程间通讯和Posix线程。
网络编程类
《Unix网络编程》第一卷讲BSD Socket网络编程接口和另外一种网络编程接口的,不过现在一般都用BSD Socket,所以这本书只要看大约一半多就可以了。
《TCP/IP详解》一共三卷,卷一讲协议,卷二讲实现,卷三讲编程应用,也很经典的。
《用TCP/IP进行网际互连》一共三卷,内容讲解十分精彩。卷一讲原理,卷二讲实现,卷三讲高级协议。感觉上这一套要比Stevens的那一套要好,就连Stevens也不得不承认第一卷非常经典。事实上,第一卷即使没有一点网络的知识,看完以后也会对网络的来龙去脉了如指掌。第一卷中还有很多习题也设计得经典和实用,因为作者本身就是一位教师,并且卷一是国外研究生的教材。习题并没有答案,留给读者思考,因为问题得答案可以为一个中级的Hacker,这些问题的答案可以象Douglus索取,不过只有他只给教师卷二我没有怎么看,卷三可以作为参考手册,其中地例子也很经典。
Linux系统管理类
《linux系统管理手册》
《LINUX与UNIX SHELL编程指南》
《Advanced Bash Scripting Guide》
系统内核类
《Linux内核代码情景分析》
《深入Linux内核源码》
面向对象设计类
《设计模式》
《敏捷软件开发:原则、模式与实践》
《敏捷项目管理》
内功修炼类
《操作系统:设计与实现(第二版)》
《操作系统概念》
《数据结构与算法-面向对象的C++设计模式》
《编译原理》国防陈火旺
《离散数学及其应用》
《计算机组织与体系结构与性能分析》
《深入理解计算机系统》【美】Randal E. Bryant David O'Hallaron著
敏捷开发模式与CMMI如何结合?比如使用敏捷开发模式,QA、PM等角色有所变化吗?
QA/PM的角色会有显著的变化
首先敏捷开发都强调自组织的团队,也就是说团队是自我管理的,而不是受制于外部压力的,团队内部是相互平等的,而不是有人主导其他人配合的。在这样的团队文化中,QA、PM的角色就和传统的角色差异很大了。
以比较流行的Scrum方法为例,这个方法中就不再有PM这个角色,和PM勉强有点像的是ScrumMaster这个角色,ScrumMaster负责在团队内倡导Scrum实践的应用,并守护团队不受外部不利因素的影响,但他并不是PM,并不负责计划的制定、任务的分配和跟踪,这些传统的管理工作是由团队成员自己决定、自己负责的
同样,QA这个角色传统上是用于从团队外部去检查团队工作流程并报告给管理层,但由于敏捷方法倡导团队自我管理、自我改进,团队的管理制度都是由团队成员自己制定的,QA就很难再按照统一的过程要求去约束团队,这时QA要么彻底从监督者转换为服务者,要么就只能从一个相对较高的层级去检查项目的过程,而不能再从细节上去约束团队行为
转载请注明出处51数据库 » 敏捷软件开发管理手册 敏捷软件开发团队如何做绩效考核