2014-03-16 21:58:59 u012812536 阅读数 1088
  • 项目管理从入门到精通:实践经验分享,实用套路讲解,...

    课程简介: 本系列课程主要讲三个内容: 1)讲解项目规律,解决项目延期和加班严重问题。 2)讲解事物或问题的背后逻辑,打造项目经理的方法论; 3)主动提升项目组成员能力,打造高效的学习型团队。 课程分为三个部分: 第一部分:项目管理的道法术,讲项目规律,讲如何打造高效的学习团队。 第二部分:混合式开发讲解,讲项目管理的方法论。 第三部分:通过对一个完整项目进行全流程的剖析,复习每个阶段的主要工作内容,学习课程上讲的技巧如何在实际项目中落地。 第一部分: 项目管理之道,我讲的是控盘式项目管理,掌握项目规律,根据产品定义、成员及能力和时间,灵活打造适合当下项目的管理方法。 针对项目管理之道,我提出了“灵活变通的流程管理”和“学习型团队建设”两个项目管理之法。 灵活变通的流程管理,我通过时代背景,对敏捷开发宣言和原则进行分析,讲解项目有时能做成,有时做不成,它们的原因所在。结合迭代开发和瀑布型开发的优点,我提出了混合式开发。 学习型团队建设,我讲了团伙与团队,让你对自己的团队做定位;分享了小企业的人才结构,让你知道员工修养低、能力差的前因后果;讲解用人之道和团队建设原理,让你知道怎么用人;通过案例来讲解如何运用生命力四要素,打造学习型团队。 第二部分,混合式开发流程节点讲解。 每个阶段,我从做什么、怎么做、谁来做、做的结果,几个部分详细讲解项目每个阶段要怎么来做。 除这四个部分,我还会讲解在每个阶段遇到的问题,如何提升效率的技巧,原则性的内容等。理解上的错误,方法上的错误,我会重点讲解。某些节点中,有需要讲项目成员的行为模式和思维模式,会拿出来做讲解。 第三部分,完整项目全流程剖析 我把做这个系列课程做为一个项目,从概念阶段开始到项目上线、总结复盘,我是如何做的,中间遇到问题是如何解决的,应用到哪些技巧等,进行完整的分享。

    141 人正在学习 去看看 陈华祥

2001211日,在美国犹他州雪鸟(Utah Snowbird)滑雪圣地的一间小屋中,由著名专家Kent Beck等领头的17位软件专家成立了敏捷联盟”(Agile Alliance)。与会专家经过为期两天的讨论之后共同发布了敏捷软件开发宣言”(Agile Manifesto),简称为“敏捷宣言”。

该宣言定义了敏捷开发的四项价值观,全文如下:


从亲自和协助他人进行软件开发的实践中,我们发现了更好的软件开发方法[即敏捷方法]。基于已有努力,我们已经为这个方法树立了如下四项价值观:

(1) 个体和交互 胜过 流程和工具;

(2) 可工作的软件 胜过 面面俱到的文档;

(3) 客户协作 胜过 合同谈判;

(4) 响应变更 胜过 遵循计划。

虽然上述右边项也具有实践价值,但我们认为左边项具有更大的价值。


上述四项价值观代表了敏捷方法的核心特征,以此为指导定义的所有软件方法都可归入敏捷方法大群体。


无独有偶,另一群业界专家从保住工程师饭碗”并减轻工作压力的角度出发,提出了与上述敏捷宣言对立的所谓“现实软件开发宣言”。该宣言由瀑布联盟(Waterfall Alliance)提出,故又称为瀑布宣言”,全文如下:


基于近些年来参与和观察软件开发实践之所得,我们总结了一个令人沮丧的结论,那就是:这个星球上的软件开发将永远没有所谓更好的方法和途径。虽然敏捷宣言看上去能取悦于经验尚浅的工程师,但是那些在业界滚过千百回的资深工程师都不会为之心动。因为他们知道,敏捷方法只是一项技术而已,它没有考虑和照顾到现实实践中的方方面面。

现实实践教会了我们如下四项价值观:

(1)流程和工具 胜过 个体和交互;

(2)面面俱到的文档 胜过 可工作的软件;

(3)合同谈判 胜过 客户协作;

(4)遵循计划 胜过 响应变更;

 你也许非常幸运,能工作于一个践行敏捷宣言的团队中。但是,只要你能践行上述四项价值观,就能确保在任何情境中都能“保住饭碗”,永无“被开除”之虑。


如瀑布联盟所言,发布上述宣言不是为了抵制敏捷方法,也不是为了鼓吹瀑布模型(由软件工程学先驱Winston Royce1970年提出),而是为了鼓励工程师与客户和用户之间彼此尊重。由此出发,瀑布联盟还定义了一些旨在保护工程师“饭碗”的法则,列举其中之典型如下:


ü  不要主动寻求可能会受到责备的行为。 

ü  需求变更就是受罪,要让客户一提到变更就感受到痛苦。 

ü  不要频繁交付可工作的软件,因为这样会令客户做出改变。 

ü  业务人员和开发人员只应保持最少的必要交流,因为双方通常都很忙且彼此语言不通”。 

ü  遵守完备的过程计划,因为个体比过程更不可靠。 

ü  以经督导委员会审核并同意的正式文档作为信息传递的主要信息。所有其他文档都会造成潜在的责任包袱。 


    显然,上述法则也有悖于敏捷开发的常规实践,甚至有悖于当前软件工程的普通实践。但是,从保证软件工程师自身权益的角度来看,上述法则又确有一定的道理,如能得到业界管理者的充分认可、尊重和践行,则能有效改善工程师的工作环境和待遇(进而提升工程师的工作质量和效率)。
2018-05-18 18:10:19 Tracy19890201 阅读数 247
  • 项目管理从入门到精通:实践经验分享,实用套路讲解,...

    课程简介: 本系列课程主要讲三个内容: 1)讲解项目规律,解决项目延期和加班严重问题。 2)讲解事物或问题的背后逻辑,打造项目经理的方法论; 3)主动提升项目组成员能力,打造高效的学习型团队。 课程分为三个部分: 第一部分:项目管理的道法术,讲项目规律,讲如何打造高效的学习团队。 第二部分:混合式开发讲解,讲项目管理的方法论。 第三部分:通过对一个完整项目进行全流程的剖析,复习每个阶段的主要工作内容,学习课程上讲的技巧如何在实际项目中落地。 第一部分: 项目管理之道,我讲的是控盘式项目管理,掌握项目规律,根据产品定义、成员及能力和时间,灵活打造适合当下项目的管理方法。 针对项目管理之道,我提出了“灵活变通的流程管理”和“学习型团队建设”两个项目管理之法。 灵活变通的流程管理,我通过时代背景,对敏捷开发宣言和原则进行分析,讲解项目有时能做成,有时做不成,它们的原因所在。结合迭代开发和瀑布型开发的优点,我提出了混合式开发。 学习型团队建设,我讲了团伙与团队,让你对自己的团队做定位;分享了小企业的人才结构,让你知道员工修养低、能力差的前因后果;讲解用人之道和团队建设原理,让你知道怎么用人;通过案例来讲解如何运用生命力四要素,打造学习型团队。 第二部分,混合式开发流程节点讲解。 每个阶段,我从做什么、怎么做、谁来做、做的结果,几个部分详细讲解项目每个阶段要怎么来做。 除这四个部分,我还会讲解在每个阶段遇到的问题,如何提升效率的技巧,原则性的内容等。理解上的错误,方法上的错误,我会重点讲解。某些节点中,有需要讲项目成员的行为模式和思维模式,会拿出来做讲解。 第三部分,完整项目全流程剖析 我把做这个系列课程做为一个项目,从概念阶段开始到项目上线、总结复盘,我是如何做的,中间遇到问题是如何解决的,应用到哪些技巧等,进行完整的分享。

    141 人正在学习 去看看 陈华祥

       2001年2月11日至13日,在美国犹他州瓦萨奇山雪鸟滑雪胜地,17个人聚到一起,交谈、滑雪、休闲,当然还有聚餐。他们试图找到共识,最终的成果就是《敏捷软件开发宣言》(Manifesto for Agile SoftwareDevelopment)。参会者们包括来自于极限编程、Scrum、DSDM、自适应软件开发、水晶系列、特征驱动开发、实效编程的代表们,还包括了希望找到文档驱动、重型软件开发过程的替代品的一些推动者。


2012-06-30 23:53:12 iteye_20353 阅读数 39
  • 项目管理从入门到精通:实践经验分享,实用套路讲解,...

    课程简介: 本系列课程主要讲三个内容: 1)讲解项目规律,解决项目延期和加班严重问题。 2)讲解事物或问题的背后逻辑,打造项目经理的方法论; 3)主动提升项目组成员能力,打造高效的学习型团队。 课程分为三个部分: 第一部分:项目管理的道法术,讲项目规律,讲如何打造高效的学习团队。 第二部分:混合式开发讲解,讲项目管理的方法论。 第三部分:通过对一个完整项目进行全流程的剖析,复习每个阶段的主要工作内容,学习课程上讲的技巧如何在实际项目中落地。 第一部分: 项目管理之道,我讲的是控盘式项目管理,掌握项目规律,根据产品定义、成员及能力和时间,灵活打造适合当下项目的管理方法。 针对项目管理之道,我提出了“灵活变通的流程管理”和“学习型团队建设”两个项目管理之法。 灵活变通的流程管理,我通过时代背景,对敏捷开发宣言和原则进行分析,讲解项目有时能做成,有时做不成,它们的原因所在。结合迭代开发和瀑布型开发的优点,我提出了混合式开发。 学习型团队建设,我讲了团伙与团队,让你对自己的团队做定位;分享了小企业的人才结构,让你知道员工修养低、能力差的前因后果;讲解用人之道和团队建设原理,让你知道怎么用人;通过案例来讲解如何运用生命力四要素,打造学习型团队。 第二部分,混合式开发流程节点讲解。 每个阶段,我从做什么、怎么做、谁来做、做的结果,几个部分详细讲解项目每个阶段要怎么来做。 除这四个部分,我还会讲解在每个阶段遇到的问题,如何提升效率的技巧,原则性的内容等。理解上的错误,方法上的错误,我会重点讲解。某些节点中,有需要讲项目成员的行为模式和思维模式,会拿出来做讲解。 第三部分,完整项目全流程剖析 我把做这个系列课程做为一个项目,从概念阶段开始到项目上线、总结复盘,我是如何做的,中间遇到问题是如何解决的,应用到哪些技巧等,进行完整的分享。

    141 人正在学习 去看看 陈华祥

以人为核心的敏捷开发模式,强调团队成员之间以及开发团队与客户之间的充分沟通,微软正在身体力行地实践这种新的开发模式。

 

微软大中华区开发工具及平台事业部总经理谢恩伟主导了敏捷开发模式的导入

自2001年17位软件开发领域的领军人物 聚集在美国犹他州的滑雪胜地雪鸟雪场共同发布《敏捷宣言》开始,敏捷开发作为一种全新的软件开发管理模式和价值观开始在众多软件开发人员和团队中推广。经过8年多的发展,敏捷开发已深入人心,但许多业内人士指出,过去几年,IT业对于敏捷的讨论大多停留在什么是敏捷开发、敏捷开发的价值何在等理论或流派的讨论上, 敏捷开发在普及应用、知识产权建设、商业模式开发等方面还存在问题 - 尤其是如何将敏捷的精神与原则,融合到开发团队每日例行活动与工具使用中。

随着敏捷概念日益深入人心,如今,软件开发人员和开发部门的高管更关注如何将敏捷的概念应用到具体的开发实践中。微软中国研发集团的服务器与开发工具事业部正在身体力行地实践敏捷开发方式,并通过将敏捷方式融入自己研发的Microsoft Visual Studio Team System( 以下简称VSTS) 开发工具,使得采用这种开发工具的客户也可以利用VSTS来实施敏捷开发模式。微软大中华区开发工具及平台事业部总经理谢恩伟认为,这将把微软现有的开发资源带到一个新的局面,使对人才资源的控制得到加强,并使资源应用有所提高。

对客户需求快速反应

IDC的一份市场研究报告显示,软件行业只有30%的开发项目是在规定的时间段内和预算范围之内完成的。传统的瀑布式开发模式已存在了很长一段时间,在这种模式下,整个软件开发过程被严格地分成需要分析、架构设计、软件开发、测试等几个阶段,整个过程不可回溯。而通常一个软件开发的过程会花费几年时间,当软件最后开发完成后,开发人员往往面临的一个困境是,客户的需求已经发生了变化,或是最终的产品由于开发过程中存在的种种问题而导致最终偏离了客户需求。

为了跟上快速变化的市场需求,微软对软件开发过程进行了一些改革,实施敏捷开发的模式,以致力于解决传统瀑布式开发存在的这些问题。谢恩伟主导了敏捷开发模式的导入,作为在微软工作了十五年的高级管理者,谢恩伟深受微软创新文化的影响,在敏捷开发理念刚被提出的时候,他就支持属下的开发团队尝试敏捷开发方式的创新,"这种模式能提高资源的应用。它能帮助我们控制交货时间,使交货的精确度非常高,另外,我们可以提供试验版的产品放在网站上供用户下载试用,这也有利于改进用户体验。"谢恩伟说。

在敏捷开发模式下,整个软件开发周期与传统模式下并无两样,但整个开发过程被分成很多个小的迭代周期,一个迭代周期通常为两周到四周时间,软件开发的需求收集和分析、设计、编码和测试等几个流程被浓缩至每个小的迭代周期中。在每个迭代中,团队成员透过一套共同作业模式的规范,将每个迭代需要的分析、设计、整合、测试,形成一套作业惯例。而每个迭代周期之后,开发人员就能拿出一个可以演示的产品给客户。这个过程通过迭代周期的设置不断循环,使客户可以不断了解产品开发的进展。通过这种沟通方式,开发人员可以不断地和客户验证所发布的产品是否符合客户的真正需求,并且对客户的需求变化迅速做出反应。

敏捷开发模式保证了产品开发能迅速反应客户需求,而不是让客户在几年的开发周期之后才能看到最终的产品。符合微软"为客户而创新"的文化理念

微软中国研发集团服务器与开发工具事业部的部门经理Ramesh Rajagopal是敏捷开发模式的实践者,他的团队利用敏捷开发模式开发VSTS开发工具,同时他们自己也利用VSTS实施敏捷开发模式。"我们首先用自己的产品来进行开发,把一些潜在的问题都暴露出来,修复之后再交付给客户使用。"Ramesh说。

 

微软中国研发集团服务器与开发工具事业部的部门经理Ramesh Rajagopal是敏捷开发模式的实践者

微软Visual Studio产品系列开发团队由几千名开发人员组成,在全球的不同地域和不同时区间进行协作。他们在开发过程中也创建了很多工具来使整个开发流程更简单高效。把这些好的工具,与全球客户共同分享是微软开发VSTS系列产品的初衷。"我们利用自己开发的VSTS工具来与客户共同分享微软的开发经验。"Ramesh说。

敏捷开发模式保证了产品开发能迅速反应客户需求,而不是让客户在几年的开发周期之后才能看到最终的产品。谢恩伟认为这种开发方式正符合微软"为客户而创新"的文化理念,这也是整个开发工作的方向。微软刚在今年5 月发布了一个Visual Studio 2010 BETA1试用版,一些客户试用了这个版本后提出,应在产品中加入更多的颜色,使客户能够有更丰富的颜色来定义图形。这些新的需求被写入Visual Studio 2010 BETA2的待办事项中,并在接下来的几个迭代周期中加以改进。"我们在10月发布的版本中就具有这些新功能,这要是放在以前瀑布式开发模式下,这种客户临时提出的新需求肯定就没有机会满足。"Ramesh解释。

敏捷开发模式还使得微软可以获得对产品缺陷更强的管理能力。在瀑布式开发模式下,产品先设计再开发,这要经历一个很长的不可回溯的过程,等到最后的测试阶段,开发人员往往发现产品的缺陷数可能呈现一种难以控制的增长势头,这些缺陷大多是由以前开发过程中一些没有想到的问题引发的。而在敏捷开发模式下,每个迭代周期之后都有测试,开发团队会借此对产品质量有新的考虑,这使他们可以把产品缺陷数置于一个可控的情况下。微软刚做完的Visual Studio 2010 BATA2版本在进行内部测试时,其产品缺陷数为零,这在传统开发模式下是很难实现的。

根据Ramesh的经验,无论整个产品的总体开发周期多长,都应在开发中遵循敏捷开发的短迭代周期原则。

在开发过程伊始,开发团队通常会通过收集和分析客户需求,形成一个产品待办事项列表,这些待办事项将在整个开发周期中全部完成。但通过迭代周期的设置,在一个迭代周期的开始,项目经理会挑出待办事项列表上最重要的两到三项,根据总体待办事项的概念,把之转化成更具体的用户规范,这被微软称为用户故事(User Story)。用户故事详细地描述了用户的具体需求,开发团队与用户之间有怎样的响应和沟通。然后再由开发人员进行实施,以及由测试人员完成功能测试,标注该待办事项已经完成。"通过这种方式,我们能够非常明确我们所做的每一个开发都是朝着提升用户价值的方向来努力的,通过这个短的迭代周期的设置,我们可以不断调整我们的方向。"Ramesh说。

迭代周期的长度可能会根据不同的产品来做调整。"比如我们自己的VSTS产品,产品开发周期通常为2年,迭代周期也会长一些,而一些发布到互联网上的产品,3到6个月就是一个发布周期,那么迭代周期也会相应的缩短。"Ramesh介绍,一些为客户定制的产品,会根据客户需要提前试用的要求,为客户量身订做一个迭代周期。

保持沟通

"敏捷开发模式能让我们最终以比较低的成本发布更好的软件产品,更贴近客户需求。"谢恩伟说。敏捷开发方式带来的对客户需求-哪怕是小开发需求-的迅速反应,帮助微软准确地把握客户需求,通过这些一点一点小改变的积累,微软产品的可用性得以提高。

在每个迭代周期之后,开发团队会与客户一起召开评估会来评估这个迭代周期的成果。这个评估会能给开发团队带来很多反馈,包括客户对已开发产品的意见,以及对未来需求的期望,开发团队据此调整后面几个迭代周期内的需求优先级。"通过这种方式,我们能够保证两件事情,第一,我们所开发的功能确实是客户想要的,第二,我们永远都在做客户需求优先级最高的事情。这在传统的瀑布式开发模式下是没有办法实现的。"

曾有一家荷兰的IT 咨询公司在试用了VSTS工具后,要求微软服务器与开发工具事业部的开发团队按照自己的管理流程来加强附加功能来管理他们的流程模板,这些附加功能在原本的计划中优先级并不高,根据客户的这个需求,开发团队马上升高了这一功能的优先级。

因为应用了敏捷开发方式,微软得以提前为客户展示一些新功能并让他们进行深度试用,这样微软就得以与客户之前进行经常性的深度沟通,不断使客户需求在产品中得以体现。"以前在软件开发过程中我们很难去与客户进行深度沟通,比如我才进展到设计阶段,我不能跟客户说你来帮我看一下这个文档,这太没意思了。而现在每个迭代周期之后,我们都有软件产品或是新功能让客户试用,这样客户比较有兴趣,我们也能够收集到我们需要的反馈意见。"对于更上级的老板或外包方的CIO 来说,他通过敏捷开发模式以及微软的VSTS工具提供的剩余时间表图,可以知道每天的开发进展情况以及剩余的时间和任务还有多少,以此获得对整个开发流程的及时掌控。

敏捷开发的核心管理理念是强调沟通交流和协作,这是敏捷开发中非常重要的环节,每个迭代周期的设置都非常短,所以团队成员对开发工作的全身心投入以及保持畅通的沟通渠道非常重要。微软为了保证沟通畅通有效,将一个开发小组的所有成员都集中在同一个房间里工作,这样保证一旦出现什么问题,团队成员之间能通过面对面的沟通迅速解决问题。另外,当整个团队中某一个人的任务落后时,其他团队成员也会一起协助他,这也保证了整个开发团队以最高效的形式来运行。

在敏捷开发模式下,微软弱化了传统意义上的项目经理角色,他的职责分别由产品负责人和整个团队来一起担当。产品负责人决定所有用户需求的优先级,根据各个迭代周期之后的用户反馈,制作产品待立项列表。而项目经理原有的考评职责则由整个开发团队一起来担当,大家一起来评估一个功能需要多长时间来开发,并且相互监督在规定的时间内顺利完成任务,这使得整个团队的考评不会有失偏颇。

在那些对敏捷开发方式有兴趣的人来说,他们通过研究微软的敏捷开发模式发现,这种模式对于管理者来说,还是一种有利于降低开发成本的选择。成本的节省主要来自因沟通顺畅而避免的开发错误,以及在团队协作的良好氛围下带来的新进人才迅速成长以及减少成熟人才的流失。"团队协作度比较好,学习的进度也比较快,我们发现,一个新手通常经过两个迭代周期下来,就可以迅速成长为一个熟手,这也为我们节省了成本。"Ramesh解释。

"我们应该重新回到敏捷开发这个大概念上来,想想什么才是敏捷,然后在实施过程当中,记住我们的原则。"谢恩伟说。在他看来,敏捷开发的核心内容是,个人的交流胜过于流程和工具,整个软件开发的核心是人,通过人去制定开发流程,根据流程去采用工具,整个过程的原则不是要有更多的流程,而是要通过工具使大家的敏捷开发更简单,更切合自身的需求。"这不仅仅是个技术议题,"谢恩伟为微软的敏捷开发经验做了一个总结:"所有的高阶技术管理者都应该开始关注敏捷开发方法所带来的管理效益。"

2018-12-26 12:20:23 ysjian_pingcx 阅读数 99
  • 项目管理从入门到精通:实践经验分享,实用套路讲解,...

    课程简介: 本系列课程主要讲三个内容: 1)讲解项目规律,解决项目延期和加班严重问题。 2)讲解事物或问题的背后逻辑,打造项目经理的方法论; 3)主动提升项目组成员能力,打造高效的学习型团队。 课程分为三个部分: 第一部分:项目管理的道法术,讲项目规律,讲如何打造高效的学习团队。 第二部分:混合式开发讲解,讲项目管理的方法论。 第三部分:通过对一个完整项目进行全流程的剖析,复习每个阶段的主要工作内容,学习课程上讲的技巧如何在实际项目中落地。 第一部分: 项目管理之道,我讲的是控盘式项目管理,掌握项目规律,根据产品定义、成员及能力和时间,灵活打造适合当下项目的管理方法。 针对项目管理之道,我提出了“灵活变通的流程管理”和“学习型团队建设”两个项目管理之法。 灵活变通的流程管理,我通过时代背景,对敏捷开发宣言和原则进行分析,讲解项目有时能做成,有时做不成,它们的原因所在。结合迭代开发和瀑布型开发的优点,我提出了混合式开发。 学习型团队建设,我讲了团伙与团队,让你对自己的团队做定位;分享了小企业的人才结构,让你知道员工修养低、能力差的前因后果;讲解用人之道和团队建设原理,让你知道怎么用人;通过案例来讲解如何运用生命力四要素,打造学习型团队。 第二部分,混合式开发流程节点讲解。 每个阶段,我从做什么、怎么做、谁来做、做的结果,几个部分详细讲解项目每个阶段要怎么来做。 除这四个部分,我还会讲解在每个阶段遇到的问题,如何提升效率的技巧,原则性的内容等。理解上的错误,方法上的错误,我会重点讲解。某些节点中,有需要讲项目成员的行为模式和思维模式,会拿出来做讲解。 第三部分,完整项目全流程剖析 我把做这个系列课程做为一个项目,从概念阶段开始到项目上线、总结复盘,我是如何做的,中间遇到问题是如何解决的,应用到哪些技巧等,进行完整的分享。

    141 人正在学习 去看看 陈华祥

敏捷宣言概览

犹他州(Utah)的雪鸟城(Snowbird)是一个不太可能发生软件革命的地方,它位于盐湖城外约25英里的地方,一点都不像硅谷:既不以阳光和温和的气候闻名,也不是什么科技创新中心,更没有那么多充满热情的企业家。但就在这里,一个滑雪胜地,一群具有反叛性的软件开发人员于2001年2月聚集在一起,经历了为期三天的讨论,他们制定并签署了行业历史上最重要的文件之一:敏捷宣言。

英文版:

We are uncovering better ways of developing software by doing it and help others do it. Through this work we come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documents
Customer collaboration over contract negotiation
Responding to changes over following a plan

That is, there is value in the item on the right, we value the items on the left more.

中文版:

我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。由此,我们建立了如下价值观:

个体与交互 优于 流程与工具
可工作的软件 优于 面面俱到的文档
客户协作 优于 合同谈判  
响应变化 优于 遵循计划

也就是说,尽管右项有其价值,我们更重视左项的价值

以上内容出自敏捷宣言:http://agilemanifesto.org/

我身边不少同仁对敏捷宣言中间的四句较为熟悉,往往最容易忽略了前后两句,久而久之,使得一些后来者曲了解敏捷宣言的精髓。而我恰恰觉得敏捷宣言的首、尾很重要。

第一句告诉我们敏捷方法论并不是凭空而谈,它源自于截止目前的实践积累,但它有可能没法直接解决你现在所面临的问题,所以不必将其神话论,盲目跟随。你要做的是,明晰敏捷的核心,挖掘和定义清楚问题,循序渐进地在组织中引入敏捷,并且在实践中不断去探索更好的方法。

也就是说,尽管右项有其价值,我们更重视左项的价值 这一句起到画龙点睛,敏捷方法论源于实践,它应回归实践,帮助我们解决实际问题,而不是一个框住我们思维的框架,沦为思想牢笼。所以在实践中,我们应该以开放的心态去接受右项的价值,并在探索中借用左项来帮助团队提升效率。而不是一味着否定一边而神话另一边。我们应该时刻警惕这一点。


敏捷宣言解读

以人为本

我相信没有比面对面交流更高效的沟通渠道了

一个人在团中的战斗力巅峰状态一定是在受到足够的尊重和信任的前提下产生的,尊重和信任激发个人内心的责任感和使命感,激发了个体的潜能。从团队角度出发,我们应该充分尊重每个人,激发个体的斗志给与他们所需要的环境和支持,并且相信他们能够完成任务,在团队内部建立彼此的信任。从个人角度出发,我们应该具备相当的专业能力,拥有较强的自管理能力,并不断提升自己,增强挑战困难和暴露问题的勇气。

基于互相信任的前提,敏捷提倡自治的全功能团队。在工作形式上,整个团队平时坐在一起工作,从物理空间上创造了更加便捷面对面的沟通机会。在团队职责上,团队内部具备完成软件交付的角色(能力),团队所有人对软件的质量负责,开发过程由团队内部把控,业务价值在团队内部快速流动并得到验证,在任何环节都能及时获得反馈。同时,每个角色都更容易从全局视角去思考软件,避免了传统部门墙模式下的视角割裂和协作障碍。

有了个体与交互,我们是否可以摒弃一切流程与工具呢?答案当然是不可以!

这里举一个我曾经的真实经历:

  1. 公司不同的角色分布在不同的部门。需求部门的分析师在前期会花上一个月甚至更久的时间跟客户讨论需求,编写详细的需求分析文档(开发人员和设计人员不参与)。
  2. 需求文档被部门经理审核通过之后,项目管理系统进行提交。
  3. 我拿到需求分析文档进行功能开发,设计部门根据需求文档设计原型界面。
  4. 后期的开发过程中,当我需要一个icon的时候,我不得不在系统中提交申请,并由设计部门的项目经理审批后,设计师才开始设计。
  5. 功能开发完成后,在预先的发布时间内,由项目经理授权将软件提交给测试部门,测试部门开始测试。
  6. 测试人员在系统中通过Bug跟踪来反馈测试结果,后期开发人员和测试人员的交互主要发生在Bug跟踪系统上。这就好比,两个人在使用邮箱在交流一个紧急的Bug。
  7. 等待和返工成了后期开发的家常便饭,更低效的是,返工的时候需要反向走流程。另外,整个过程从需求分析到交给测试团队历时了大半年之久。

在上述流程中,每个部门各自为政,好处是每个人在小黑屋里能专注、"高效"地做出一个用于被审批的中间产物,坏处是缺乏整体视角,很可能是以最高的效率做了一件错误的事情(效率低下的终极定义)。层层审批流程在重量级的项目管理和Bug跟踪工具下似乎运行得很良好,却扼杀了及时沟通和调整的时机,制造了彼此之间的隔阂、大大增加了成本浪费,于组织、于个人都无益。

所以,我们要摒弃这种重流程和重工具,提倡轻量级流程和轻量级工具,而这些流程和工具又在促进个体交互。比如,我们在日常工作中会使用Trello、Jira、Keynote等工具。

价值导向

可工作的软件最终交付物,是我们追求的核心价值,以价值为导向也是我们每个职业人力所能及在做的事情。在交付价值的同时,如何看待过程中的文档呢?可能就仁者见仁智者见智了。

提到文档,"敏捷神教徒"会跳出来指责并排斥一切文档,他们提倡开发人员应基于口头讨论后便开工,以最快的速度将业务功能实现,这是一种极端的思想,曲解了其含义。

为客户交付可工作的软件是我们的核心目标,我们应该尽早交付可进行端到端测试的代码,该目标决定了我们不应该花过多精力在面面俱到的文档上,但这不代表我们要抵制任何文档。实践证明,轻量级的文档策略有助于团队高质量交付可工作的软件。

在Scrum体系中,产品待办列表和Sprint待办列表就属于轻量级的文档。前者涵盖了产品的业务价值,后者包含了指导团队进行迭代开发的最优先的业务需求,并且在团队内形成知识共享,促进沟通协作。这类文档不应当省略。

在开发过程中,交互设计原型也是一种轻量级文档,交互设计师交付可以尽早地跟团队和客户进行确认验收的核心业务场景的原型,快速收集反馈。而不是一开始就将产品的所有功能界面进行分块,然后在内容、视觉、交互上设计到非常精美的程度。

以上两类文档都能够为团队中的个体交互提供基础支撑,大大的提高团队的协作效率。要不然,所有人都基于自己脑海里的信息去交流,很可能置身战场(舌战)的感觉。

除了以上促进价值交付的文档,还有如下几类文档也是有价值,甚至不避免的:

  1. 作为交付物的一部分,比如用户手册,安装指南等。
  2. 软件发布受法律监管强制要求的文档。
  3. 帮助新成员快速获取项目上下文的文档。
  4. 记录重要会议和重要决策的文档,以便回溯。

回到实际项目中,有一类文档会引起较多争议,比如:Troubleshoots、开发规范、交接文档、系统架构图等,这类文档更多是从项目管理的角度出发。而维护这些文档往往会提高管理成本,这是一个博弈的过程。怎么权衡也是需要根据不同的项目情况来定,我们要警惕的是盲目排斥一切文档,心中拿捏一杆秤:文档所创造的价值高于管理它的成本,它就值得去做。

客户团队

2015年,我去ThoughtWorks新加坡Office参与一个银行系统的交付。当时从中国区调遣人员过去支援,一来因为那边人员相对较为紧缺,二来因为跟客户关系处理得有些不妥,那边同事不愿意介入。近三个月的时间,软件成功交付上线了,但从销售那得知项目款很难要回来,后来我才知道这个项目一开始没有签下合同…感慨对优于合同谈判践行得不错!

当然这是个反例。为了避免误解,我们需要从两个视角去对待合同:商务视角和交付视角。从商务视角,企业与企业合作需要法律的保障,所以正常情况下需要有一份合法的合同作为保障,这种不常见的问题更多出在管理上(新加坡总经理后被更换了)。

我们更多从交付视角来出发。ThoughtWorks作为一家专业软件服务提供商,我们的终极目标是帮助客户实现他们真正想要的价值。基于业务从来都是捉摸不定的前提,在开发的过程中我们不可能固守一张死合同,遇到需求变更就谈判,面红耳赤最终只能关系破裂,导致双输。

我们提倡客户团队,客户也作为团队的一分子,跟客户建立信任的合作关系取代敌对的谈判关系。因为需求的变化往往来自客户,这背后往往也是因为不确定的业务模式导致。让客户参与进来可以在开发的过程中尽早的发现变化,从而尽早采取解决方案,避免更多的浪费,保证交付朝正确的方向前进。协作的前提是信任,客户直接参与能够让客户更清楚当前的交付状况,增强客户的信心以及对我们的信任,切忌采取合同互怼的下下策。

如果不能让客户成为团队的一分子,就要尽可能在其他的方面多做工作,比如提高Showcase频率,提高跟客户Catchup的频率,提供一个软件环境让客户始终能够在用我们交付的系统,等等。

另外,客户参与可以提升客户的责任感,从而避免客户不负责任的需求变动。

拥抱变化

在我看来,这一点道出了敏捷的精髓。我曾经给敏捷下过定义:通过高效的协作,获取快速的反馈,以便尽早做出调整,从而减少浪费,交付更大的价值

敏捷初衷并不是让我们更快速地交付软件,敏捷一词很容易让人们产生望文生义的联想:敏捷就是迅速,就是快。当我们在看两个武功相当的高手过招(非太极)的时候,除了眼花缭乱的动作(出手极快,咏春拳唯快不破),更核心的点是他们能够根据对手的出招来快速采取应对招式。回到敏捷软件开发,开发速度快慢与否取决于团队成员的能力以及团队协作的默契度等因素,所以不一定所有的敏捷团队开发速度都会很高。而她真正的威力在于,当面临业务需求变更的时候,敏捷开发方式让我们能够更早、更快的做出响应。响应变化的能力才是她的核心竞争力,而她恰恰巧妙了抓了业务复杂性和不确定性的核心属性。

敏捷团队的交付速度有可能在某些特定迭代比瀑布团队更慢,但需求发生变更时(通常一定会发生),响应变化的敏捷交付团队很早就做出了调整,而遵循计划的瀑布团队极有可能是一条道走到黑,最终交付一个让客户想哭又哭不出来的四不像。从最终价值成果来看,敏捷开发实践显然更容易帮助我们实现价值最大化。

如果说我们做任何事情的终极目标是实现价值最大化,那么敏捷的终极目标就是通过提升响应力来最小化浪费,从而最大化价值。敏捷的开发团队能够更快速响应业务需求的变化,敏捷的企业组织能够更快速相应市场的变化。

变化一词很好的描述了软件开发的本身属性,业务需求的不确定性给了敏捷软件开发方法用武之地。而对于流程非常稳定不变的工作,比如富士康某条成熟的iPhone生产线,遵循计划恐怕是更佳的选择。


写在最后

敏捷虽好,不要盲从,更不要迷信

敏捷开发方法有她的优势,也有她的门槛。市面上存在不少有形无神的伪敏捷组织。他们天天站会,甚至,他们也模仿Scrum搞了个3355,但他们仍然苦于对变化的龟速响应。

我认为敏捷更像一种文化价值的认同,相比于形式,更重要的是团队对敏捷价值观的理解和认同,以及指导他们做出日常行为是否体现了尊重勇气开放承诺专注反馈简洁这些核心价值观。在一个敏捷的团队中,每个成员都应该拥有持续改进的心态,他们会不断学习理解敏捷宣言的内涵,会不断提升自己的专业技能,并能够结合团队实际情况采取因地制宜的敏捷实践。


Posted by 袁慎建@ThoughtWorks

版权声明:自由转载•非商用•非衍生•保持署名 | Creative Commons BY-NC-ND 4.0

原文链接:https://sjyuan.cc/understand-agile-manifesto-deeply/

2012-12-29 14:07:51 weixin_33912246 阅读数 39
  • 项目管理从入门到精通:实践经验分享,实用套路讲解,...

    课程简介: 本系列课程主要讲三个内容: 1)讲解项目规律,解决项目延期和加班严重问题。 2)讲解事物或问题的背后逻辑,打造项目经理的方法论; 3)主动提升项目组成员能力,打造高效的学习型团队。 课程分为三个部分: 第一部分:项目管理的道法术,讲项目规律,讲如何打造高效的学习团队。 第二部分:混合式开发讲解,讲项目管理的方法论。 第三部分:通过对一个完整项目进行全流程的剖析,复习每个阶段的主要工作内容,学习课程上讲的技巧如何在实际项目中落地。 第一部分: 项目管理之道,我讲的是控盘式项目管理,掌握项目规律,根据产品定义、成员及能力和时间,灵活打造适合当下项目的管理方法。 针对项目管理之道,我提出了“灵活变通的流程管理”和“学习型团队建设”两个项目管理之法。 灵活变通的流程管理,我通过时代背景,对敏捷开发宣言和原则进行分析,讲解项目有时能做成,有时做不成,它们的原因所在。结合迭代开发和瀑布型开发的优点,我提出了混合式开发。 学习型团队建设,我讲了团伙与团队,让你对自己的团队做定位;分享了小企业的人才结构,让你知道员工修养低、能力差的前因后果;讲解用人之道和团队建设原理,让你知道怎么用人;通过案例来讲解如何运用生命力四要素,打造学习型团队。 第二部分,混合式开发流程节点讲解。 每个阶段,我从做什么、怎么做、谁来做、做的结果,几个部分详细讲解项目每个阶段要怎么来做。 除这四个部分,我还会讲解在每个阶段遇到的问题,如何提升效率的技巧,原则性的内容等。理解上的错误,方法上的错误,我会重点讲解。某些节点中,有需要讲项目成员的行为模式和思维模式,会拿出来做讲解。 第三部分,完整项目全流程剖析 我把做这个系列课程做为一个项目,从概念阶段开始到项目上线、总结复盘,我是如何做的,中间遇到问题是如何解决的,应用到哪些技巧等,进行完整的分享。

    141 人正在学习 去看看 陈华祥

 

历史:敏捷宣言诞生记

译者按

本文译自:http://www.agilemanifesto.org/history.html。要想了解敏捷软件开发,这篇文章是必读,对学习敏捷中的不少疑惑都给出了解释。感谢@AgileCoach@徐毅-Kaveri的审校。

正文

2001211日至13日,在美国犹他州瓦萨奇山雪鸟滑雪胜地,17个人聚到一起,交谈、滑雪、休闲,当然还有聚餐。他们试图找到共识,最终的成果就是《敏捷软件开发宣言》(Manifesto for Agile Software Development)。参会者们包括来自于极限编程、ScrumDSDM、自适应软件开发、水晶系列、特征驱动开发、实效编程的代表们,还包括了希望找到文档驱动、重型软件开发过程的替代品的一些推动者。

由全体参会者签署的《敏捷软件开发宣言》(Manifesto for Agile Software Development)成为了重要标志,因为这么大一帮无政府主义者能聚到一起实在是太不容易。只有英国人Martin Fowler表达了对“敏捷”这个词的担心,他认为多数美国人都不知道“敏捷”这个词如何发音。

Alistair Cockburn和很多参会者一样,最初有很大的担忧。“我个人没有期望本次敏捷达人们的聚会能够达成任何实质性共识。”会后,他再次分享了自己的感受。“对我来说,很开心宣言能够最终定稿。而让我感到惊讶的是其他人也同样开心,因此我们的确达成了某种实质性共识。”

这群有时存在相互竞争的软件开发独立思考家们共同签署了展示在网站(http://www.agilemanifesto.org/)首页的《敏捷软件开发宣言》,他们称自己为“敏捷联盟”。

但多数人(如果不是所有的话)成为联盟成员的动力不仅仅是因为宣言上列出的那些理由,他们还有着更深层次的考虑。在长达两天的会议临近结束的时候,Bob Martin开玩笑地说他打算谈点“虚的”,讲讲“空话”。Bob这话虽然有玩笑成分,却得到了几乎所有人的响应。因为我们都会非常乐于与一群拥有相似价值观的人一起共事,这些人会相互信任与尊重,会促成以人和协作为本的组织模式,能构建大家都愿意为之贡献的组织社区。本质上讲,我相信敏捷方法学家们确实要玩这些“虚的”东西。为了交付好产品给客户,他们会切实去,不止是口头上说“人是我们最重要的资产”,还要从实际中体现出人本身就是最重要的,去掉“资产”这个提法。因此在最后的讨论过程中,敏捷方法学家们对价值观和文化这些“虚的”东西表现出了极大的兴趣,有时甚至会进行激烈的争论。

例如,我认为,极限编程呈现出强劲的发展势头,其根源不在于结对编程或重构等实践本身,而是从整体上看,极限编程能让开发人员们摆脱“呆伯特”组织中那些腐朽观念的束缚。Kent Beck分享了他早年的一次亲身工作经历。当时他估算的开发工作量是2个人做6个星期。结果在项目开始的时候,经理临时换了另一个人和他一起工作,最后他们花了12个星期才完成项目。他的感觉很糟,因为在后面6个星期中间,经理一直喋喋不休,嫌他太慢。Kent有点沮丧,觉得自己作为一个程序员实在是太失败。到最后,他终于意识到最初2个人做6个星期的估计其实是相当准确的。这不是他的失败,是管理者的失败(指临时换人这件事),实际上是那些持续祸害着我们这个行业的,所谓标准化、流程化的“僵化”头脑的失败。

同样的事情每天都在重复发生市场人员、经理、外部客户、内部客户,当然,也包括开发人员,谁都不想难为自己,去做出那些艰难的、需要折衷的决定。于是他们利用组织的权责划分将难题转嫁给他人,甚至提出荒谬的要求。这不仅仅是软件开发的问题,在“呆伯特”组织中它无处不在。

想要在新经济环境下成功,并引领电子商务和网络时代,那么公司一定要去除“呆伯特”式的行为表现,不要没事找事做,不要搞出那些没人能搞懂的规章制度。敏捷是一种解放,让人不再虚度时光。这吸引了敏捷方法论的支持者们,却把传统主义者吓得屁滚尿流(专业文章中不能骂娘)。坦率来讲,敏捷方法吓到了组织中的官僚们,尤其是那些乐于为过程而过程,却不全力为客户着想,不想履行承诺按时交付可见成果的官僚们,因为这(敏捷)会让他们无处藏身。

敏捷运动并不是反方法论的,事实上,我们中的大多数人正在试图恢复方法论的名声。我们希望能重归平衡。我们乐于建模,但目的不是给无人问津的企业资源库增加几篇图表存档。我们要写文档,但那些从不维护、并很少用到的长篇大论不算在内。我们得做计划,但同时也要认识到在剧烈变化的环境中计划的局限。有些人给XPScrum或任何一种敏捷方法论的支持者们打上“***”的标签,这只表示了他们对方法论和***本意的无知。

2000年春,Kent Beck组织了一次会议,地点在俄勒冈州的罗格里夫酒店,参会者包括极限编程的支持者们和一些“圈外人”,正是这次会议导致了后来在雪鸟的聚会。在罗格里夫会议上,参会者们宣称了对一系列“轻量”方法论的支持,但没有发表什么正式声明。2000年期间一系列论文都被归类到“轻”或“轻量”流程,其中很多都提到“轻量级方法论,如极限编程、适应性软件开发、水晶系列和Scrum”。大家交流后发现,没人真正喜欢“轻”这个名号,但这似乎是当时约定俗成的称呼。

20009月,来自芝加哥Object Mentor公司的Bob Martin用一封电子邮件吹响了下次会议的集合哨。“我想召集一个为期2天的小型会议,时间是20011月或2月,地点在芝加哥,目的是让所有轻量级方法论的领袖们汇聚一堂。您们都被邀请了。如果您们觉得还有谁该来,请告诉我。”Bob建立了一个Wiki网站,由此开始了热烈的讨论。

很快,Alistair Cockburn就用一封书信加入了讨论,他表达了对“轻”这种提法的不满:“我不介意用‘轻’来描述方法论的轻重程度,但我并不愿意因参加一个轻量级方法学家会议而被看作是轻量级的。这听起来有点像一群干瘦、低能、并无足轻重的人在试图回忆起某个特定的日子。”

关于会议地点的争论最为激烈。芝加哥让人不爽,既冷又无趣;犹他州的雪鸟,虽然也冷,但至少对那些想滑雪的人来说还挺有意思,像Martin Fowler在第一天滑雪就滑个头朝地;加勒比的安圭拉岛,暖和又好玩,但路途太远。最后还是可以滑雪的雪鸟胜出,不过有些人(例如Ron Jeffries)还是希望下次能去个暖和点的地方。

我们希望,一起组成的敏捷联盟能够帮助到其他同行,帮他们用新的更“敏捷”的方式去思考软件开发、方法论和组织。做到这一点,我们就得偿所愿了。

Jim Highsmith,来自敏捷联盟

©2001 Jim Highsmith

参考

极限编程:敏捷软件开发方法的一种,缩写XP,英文全称Extreme Programming

Scrum:敏捷软件开发方法的一种。

DSDM:敏捷软件开发方法的一种,英文全称Dynamic Systems Development Method

自适应软件开发:敏捷软件开发方法的一种,缩写ASD,英文全称Adaptive Software Development

水晶系列:敏捷软件开发方法的一个方法系列,都用Crystal开头。

特征驱动开发:敏捷软件开发方法的一种,缩写FDD,英文全称Feature-Driven Development

实效编程:不是一个方法论,是一个流派,英文全称Pragmatic Programming

呆伯特(又名迪尔伯特):Dilbert美国 Scott Adams 的有名职场卡通人物。呆伯特法则:http://zh.wikipedia.org/wiki/%E5%91%86%E4%BC%AF%E7%89%B9%E6%B3%95%E5%89%87

敏捷开发宣言

阅读数 8

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