2018-12-05 15:17:25 bruesz 阅读数 732
  • 项目管理从入门到精通:实践经验分享,实用套路讲解,...

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

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

敏捷方法论的前世今生

敏捷方法的历史:

  • 敏捷一词来源于2001年初美国犹他州雪鸟滑雪胜地的一次敏捷方法发起者和实践者(他们发起组成了敏捷联盟)的聚会。
    • 迭代和增量开发方法最早可以追溯到二十世纪三十年代非软件项目。
    • 二十世纪六十年代美国航天局水星计划使用了一些极限编程和测试先行的防范。
    • 在二十世纪九十年代,各种各种轻量级软件开发方法纷纷被提出,其中包括:
      • 1991: RAD (rapid application development)
      • 1994: UP (unified process) 和 DSDM(dynamic systems development method).
      • 1995: Scrum
      • 1996: Crystal Clear & XP(extreme programming)
      • 1997: FDD (feature-driven development)
    • 2001年,17位软件开发者齐聚在美国的犹他州的雪鸟(snowbird),讨论上述轻量级的软件开发方法,并写下了敏捷软件开发宣言。

敏捷宣言(Manifesto for Agile Software Development):

- 个体和互动高于流程和工具 (Individuals and interactions over processes and tools)
- 工作的软件高于详尽的文档 (Working software over comprehensive documentation)
- 客户合作高于合同谈判 (Customer collaboration over contract negotiation)
- 响应变化高于遵循计划 (Responding to change over following a plan)

敏捷12条原则中文版:

1. 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。 
2. 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。
3. 经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。 
4. 业务人员和开发人员必须相互合作,项目中的每一天都不例外。 
5. 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
6. 不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。
7. 可工作的软件是进度的首要度量标准。
8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9. 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
10. 以简洁为本,它是极力减少不必要工作量的艺术。
11. 最好的架构、需求和设计出自自组织团队。
12. 团队定期地反思如何能提高成效,并依此调整自身的举止表现。

敏捷12条原则英文版 (Twelve Principles of Agile Software):

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be ableto maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount  of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

评价一个敏捷团队是否合格的衡量标准(个人观点仅供参考)

- 迭代开发:整个开发过程被分为好几个迭代周期,每个迭代周期可以是定长或者不定长。
- 增量交付:产品在每个迭代周期内被增量交付使用,而不是在整个开发周期结束的时候一次性交付。
- 团队成员与用户积极反馈以推动产品的开发:用户全程参与到产品的开发过程中。
- 持续集成: 新的功能或者变化持续整合到产品中。
- 自我管理: 积极的,自我管理的,具备自由交流风格的团队。
2009-11-03 23:11:00 zhouqi724 阅读数 262
  • 项目管理从入门到精通:实践经验分享,实用套路讲解,...

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

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

       离第二篇已经很长时间了,今天终于能够重新来跟大家一起探讨下敏捷模式。

 

      上次谈论了有关敏捷的宣言和一些敏捷项目失败的原因分析。敏捷宣言只是敏捷创世团队提出的一种口号,即思想,并不是一种可抄袭、可复制的模式。因为敏捷并不是一个产品。敏捷的产生,是因为敏捷的创始者们在敏捷诞生之前的开发过程中犯了错误,所以他们总结出了4条原则,希望节省后来人的时间。但是,学习敏捷不能模仿,不是复制,更不能抄袭。敏捷是一种思想,它需要的是行动者(Actor)。也就是说,他们提供给了我们一些敏捷的实践总结(源于敏捷创始者),给出了我们可以参考的形式。而在我们自己的项目过程中,不会只出现他们遇到过的问题,这就需要我们自己去根据他们的经验和思想,来总结出我们自己的敏捷之道-----敏捷实例化。

 

      敏捷开发模式,有别于传统瀑布式的开发模式,而对于很多项目而言,瀑布式的模式是不适合的,而且很多项目都会以失败而结束。也许是大家习惯了瀑布式的思维模式,而忽略了软件开发的本质-----软件开发过程充满了创新性(novelty)和不可预见性(unpredictabiliby),因为软件属于-----新产品开发,而非预见性制造。

 

      传统瀑布式的模式,适合于预见性的制造,因为你知道最终的结果是什么,而且每个规定好的阶段结果是什么都是可预见的,如果在一个装配线上制造移动电话,那么预先定义的规格说明和生产步骤就可能很准确。当制造了一些电话,并且测量了相关进度之后,就可能准确的估算和调度未来电话的制造过程。(该例子引自《敏捷迭代开发-管理者指南》)。可以再说一个更贴近的例子,印钞厂的生产线。他们的需求就是印刷出合格的money(纸币或硬币),而他们的过程则是由多个阶段串联起来的。首先是刻制模板,其次是纸张选择,再次是印刷。这些都是可以预见的,因为需求明确,而且结果也清楚,加上批量生产的动作,因此,整个过程中几乎没有创新或变动。

       而软件却恰恰相反。过程变化频率高、创新性强。更何况没有以前的类似案例可供参考,那这样的一个生产过程就是一个新产品的开发或者叫创新项目。客户起初确定软件功能需求,然后开发人员开始编码、测试等工作。但突然交付前一周,客户又有了新的改变,原来某个功能不要了,需要换其他的一些东西。完了,直接崩溃。很多软件从业人员都有过这样的经历。其实,在瀑布式的生产过程中,没有一个人都是心里100%有底气的,因为他们无法预测到下一秒钟能发生的变化-----这就是创新。

    

     比较下预见性制造和新产品开发,我们就可以发现,其实,我们一直在犯同样的错误:

 

 

    

预见性制造 新产品开发
在第一次完成规格说明后,就进行构建 不可能在前期创建一成不变的、详细的规格说明
在开始阶段,就能够估算出具有参考价值的工作量和成本 在开始阶段,很难进行预期分析,随着经验数据的出现,

计划与估算的可能性才会相应增加

有可能识别、定义、调度和安排所有的细节活动 在开始阶段,识别、定义、调度和安排所有的细节活动是不可能的。

通过构建反馈周期,推动自适应步骤

一般情况下是不去适应没有预定义的变动,并且改动率比较低 一般情况是主动适应没有预定义的变动,并且改动率比较高

       
  

     可见,我们在使用瀑布式的开发模式时,暴露了很多我们已经看到但并没有思考如何去解决的问题。正如许多项目一样,采用新的带有bug的技术,加剧了创新性和不可预见性。

 

     瀑布式的生命周期形式,有着笨重的前期规格说明、估算、推测计划等适用于预见性的生产项目的条件,却无法在软件项目上很完美的诠释其优势。在此,我并不是要完全否定瀑布式的模式,只是就软件项目而言,瀑布式并不适合。而在我们开始拒绝采用那些瀑布式流程的前期规格说明时,我们的理由就是:

 

    1、客户或者用户不能明确他们到底要什么。

    2、客户或用户很难陈述所有的需求和知识,因为他们不是专业技术人员。

    3、客户们想要的细节只能在开发过程中逐步的加强和展现。

    4、软件细节对于客户来说算是比较复杂的东西了。

    5、一旦客户们看到产品的开发,那么他们就很有可能会改变最初的想法,而给出“奇思妙想”。

    6、对于同行间同类产品的竞争,客户势必会因为商业上的压力而改变一些需求,甚至是加强某些方面功能点。

 

    所以说,在软件开发过程中,因为不可预见性等因素,我们需要更加高效的手段和方法-----敏捷-----构建软件是复杂的过程,属于新产品的开发,修改频度很高,而不是仅仅预见性的批量生产活动。这是敏捷和迭代方法动机的核心所在,也是我们实行敏捷前必须要了解的点。

 

    敏捷,是一个概念,一种思想,一些总结,并不是一个实体或一个实物。敏捷意味着成功与收益。所谓成功,就是指在与对手的竞争中脱颖而出;而收益则是说,在许多公司望而生畏的竞争风暴中,获得利润、市场份额和客户。这才是生产软件的最根本的动力和因素。

 

 

    OK,今天写了些关于敏捷和传统瀑布式的区别和优势,下一次会开始逐步对几种敏捷方法分类进行一个概念性的说明和解释,让敏捷的概念深入到实际开发过程中。下周见!

    

 

     

2017-05-04 11:44:58 jongde1 阅读数 228
  • 项目管理从入门到精通:实践经验分享,实用套路讲解,...

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

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

互联网产品发展的速度越来越快,人们对于产品的要求也在不断的升级,这直接地导致了用户体验设计的重要性不断提升。与此同时,过去的流程冗长的设计开发模式已经不能够满足快速迭代的需要。《敏捷宣言》给设计师和开发者提出了更多的要求和准则,但是很多设计师还并不明确,敏捷UX到底是怎样的一个过程。本文将讲解敏捷ux设计步骤中的主要四点。


Step 1. 扁平化团队


想要剖析一个敏捷ux设计的步骤,必须先要从他们的团队开始。敏捷ux设计的团队基本都是通过扁平化进行管理的,原因也很简单。首先,命令直接传达。相比于层层地转达,直接传达的命令,更准确,更有效,不会因为转述而改变原本的意思。设计的意义就是在与向人们传递表述设计师的思想。如果设计团队成员内部之间彼此都不理解,那么还如何让你的用户去理解?其次,控制范围扩大。扁平化的团队省去了很多的中间步骤,这也使上层更容易控制下层。设计团队的合作过程不会仅仅是表述思想,同样也需要检查测试,扁平化的团队可以使问题更直接地暴露在所有人的视野内,方便团队领导者、主要设计师对于设计的调整和纠正。




Step 2. 清晰的设计路线


在设计过程初期,敏捷ux设计团队就需要拿出一个相对比较完整的设计路线,或者叫做设计方案。这个方案需要考虑到很多的方面,要确保在工作过程中不会轻易的被耽搁、被停滞。在设计的过程中,要严格的按照计划和方案来进行,就像在设计原型的时候需要遵守一定的原则,只有在有效的框架范围之内,才能更好地、更快速地进行用户体验设计,也就是进行敏捷ux设计。关于设计路线的制定,需要关注的方面至少有两点:一是清晰的项目树,一个好的项目树能够起到统领全局的效果。二是坚定的设计原则,只有遵循一定的原则,才能够判断取舍。


Step 3. 寻找正确的工具


对于敏捷ux设计来说,简单有效的设计工具实在是太重要了。在灵活性和机动性极高的敏捷设计中,如果工具的选择不恰当,很容易造成工作效率低下,节奏拖沓。


在图像制作的工具中,Sketch明显以其轻量级的工作方式在Mac的众多应用中脱颖而出。


而线框图和原型设计工具,BalsamiqMockplus则更占据优势。如果目的仅在于线框图,那么这两款工具会让你体验到快速制图的乐趣。如果涉及到交互,Mockplus则以其更小的体积和更简单可视的工作原理给设计师更多的时间和自由。




Step 4. 更多关注迭代和创造


敏捷ux设计更多的应该是迭代,而不是手中设计是否完美无缺。敏捷设计本身就是一种以速度为主的设计模式,通过迅速的产出最小可行性产品来呈现产品的可用性以及价值。从某种程度上来说,敏捷ux设计允许一些冒险性的尝试,即便是失败了,凭借着其迅捷的设计模式,也一样可以在最短的时间内完善其自身的不足。只有按照敏捷ux设计的步骤逐步进行,并且大胆创新,才能为产品创造出更多的可能。


Step 5. 不断测试


测试,对于敏捷设计来说是必不可少的。作为敏捷ux设计本身,就已经舍弃掉了很多东西,如果不及时加以测试,很有可能与实际脱节。对于敏捷ux设计测试的主要部分,主要集中在对于最小可行性产品的测试,以及原型的测试。看似这里已经是敏捷ux设计步骤中的最后一步,但是实际上,测试是ux设计的另一个开始,只有如此不断地突破、不断地测试、不断地完善,才能够是敏捷ux设计发挥更大的作用,为后期的设计和开发提供更多的支持。




关于敏捷ux设计的步骤,这四点是主要的核心。敏捷的开发和设计,是行业发展的必然趋势,希望大家能够抓紧机会,在敏捷ux设计的帮助下开发出更优秀的产品。

2016-01-12 17:16:00 cpongo4 阅读数 4
  • 项目管理从入门到精通:实践经验分享,实用套路讲解,...

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

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

1995年,Ken Schwaber和Jeff Sutherland共同提出了Scrum框架\

1996年,Ken Beck总结出了极限编程的一系列方法\

2001年,17位大师共同提出了划时代的敏捷宣言和12条原则\

2003年,Poppendieck夫妇所著的《精益软件开发》第一次将源自丰田TPS的精益思想引入软件开发领域\

2010年,Jez Humble提出了持续交付\

2011年,Eric Ries提出了精益创业\

随着软件开发行业的飞速发展和成熟,这20年来有志者们不断在思考IT行业自身的特征和最有效的管理模式,而不再像几十年前的懵懂时期面对当时对所有人来说都是新兴事物的软件领域匆匆从其它行业借鉴来一套管理方法。\

然而20年过去了,我们看到敏捷和精益的思想尽管非常活跃,但仍没有在这个软件行业大范围内产生足够的影响力。有Google,Facebook,Netflix等优秀企业在持续提供创新的产品和服务,并且有较高的员工满意度;然而对大多数企业来说敏捷和精益仍然在摸索和试探阶段,或者在局部的团队、产品层面运用了个别实践,但整个企业要将这样的理念大范围贯彻下去总是困难重重,像IBM,HP这样曾经成功的企业现在总是被人诟病臃肿缓慢,缺乏对市场的适应力。\

如果你是一位企业或组织的领导者,必然感同身受,我们面临着以下挑战:\

  • 根据德勤的分析,企业平均寿命已经从1920年的65年骤降到了2015年的15年\
  • 社会与科技飞速发展,使得企业的既有竞争优势迅速弱化,任何企业都面临被颠覆的危险\
  • 大型企业对市场趋势和用户喜好的变化不敏感,错失机会\
  • 即便巨额的投资也经常产生不了预期的收益,难以发展出成功的新业务\
  • 随着企业规模扩大,员工的工作满意度不断降低,企业内耗巨大,产生大公司病

不过,最近几年IT行业的经营管理之道正在显露出巨大的变化,很多优秀的组织已经意识到员工的工作满意度是影响组织绩效的重要指标(引自2015年DevOps行业报告),激发员工的内在激励,而非通过胡萝卜加大棒,才是关键;建立去中心化的组织结构,以愿景目标一致前提下的自治为原则,形成差异化的管理。Google在创新的道路上战线很长,从已经成熟的搜索广告业务、视频业务,到充满未来色彩的无人驾驶汽车、机器人,为了支撑其长期发展更名Alphbet,建立了以完全不同方式运作的多个公司;Netflix所有服务都基于亚马逊的公有云且提供着很好的用户体验,开发团队任何人都可以将自己的修改推向生产环境,立即看到它产生的效果,并且他们将自己用于开发运营产品的各种工具框架完全开源贡献给整个行业。Facebook的数据中心设计方案,特斯拉的电动汽车技术也以某种开源形式贡献给整个社会。\

未来的路在哪里?今天我们为你介绍一本必将影响深远的新书《精益企业》——高绩效企业如何规模化创新。这本书由《持续交付》的作者Jez Humble和Joanne Molesky、Barry O’Reilly三位所著,基于在很多大型企业和创业公司工作的经历,为我们提炼出一种务实的、系统性的适用于大型企业环境下的创新与转型方法,为我们讲述了那些非常成功的公司为了从根本上提高组织绩效是如何重新思考以下这一切的:投资组合管理、产品开发流程、IT系统架构、风险与合规管理、财务、采购、组织结构与文化等各方面,以及如何有效推动变革\

作为组织的领导者,如果你以打造有持续生命力的卓越企业和优秀产品为目标,你应该阅读《精益企业》。这本书从组织管理的层面将几年来浮现的各种优秀思想和已经证明成功的方法系统性地融合为一体,告诉你如何将精益的思想根植到组织的各种活动从而真正产生它应有的巨大影响力,产生持续创新和发展的动力。除了企业管理,该书也为你系统性地呈现了一种全新的和生机勃勃的产品开发模式,在产品的探索期、拓展期和成熟期采用不同的工作方式,并顺利实现从一个阶段到另一个阶段的跨越,以设计思维、实验性交付、精益看板,持续交付和持续改善等方法最大化产品所创造的用户成效和业务成效。\

一个概要的全景图如下:\

0cf65a273b38bd5960c2d1dd3116eb55.png

\

《精益思维》和《精益软件开发》系列合著者Mary Poppendieck这样评价:\

\

“关于如何创造出色的软件产品与服务,这本书整合并以一种令人信服的方式为我们呈现了当今最优秀的思想。书中描述的方法既很有挑战性,也很要求纪律性,对有些组织来说要遵循这种方式简直无法想象。但那些一旦走上这条道路的组织和人也完全无法想象再回到老的方式去工作——而他们如果碰巧是你的竞争对手,那你的市场和人才就将被他们偷走。忽略这本书,你将损失巨大。”

\

《丰田套路》作者Mike Rother评价:\

\

“我的工作是支持人们实践一种科学模式,帮助人们在商业、政治、教育和日常生活中重塑思想和习惯。二十一世纪越来越需要一种新的工作方式。这种方式基于人的认知复杂性,需要我们沟通协作,迭代式前进,甚至强调企业家精神。通过《精益企业》这本书,Jez Humble,Joanne Molesky,和Barry O’Reilly解释了软件如何能够并正在转变我们的工作方式,而这将进一步改变我们的思考方式,帮助我们去适应围绕着我们的这个新兴世界。”

\

《凤凰项目:一个IT运维的传奇故事》合著者Gene Kim,Tripwire公司创始人也积极评价该书:\

\

“这本书就是数字时代的《企业再造》。它注定会成为一部指导组织如何计划、构成、实现、和度量其工作的经典和权威参考。《精益企业》描述了组织如何通过成功驾驭和提升员工能力来赢得市场。任何关心通过技术和建立创新文化来产生竞争优势的企业领导者都应该阅读这本书。”

\

《精益企业》主要针对的是以下读者:\

  • 对组织战略、领导力、组织文化和良好治理感兴趣的高层管理;\
  • 负责应用开发或者基础设施与运维的IT总监;\
  • 任何从事项目或项目群管理的人,包括项目管理办公室(PMO)成员;\
  • 那些与交付相关的财务、会计,或治理、监管及合规管理人员;\
  • 首席市场官、产品经理以及其他参与(涉及软件开发的)产品和服务设计的人。

该书英文版“Lean Enterprise”于2014年末出版,中文版也即将问世,敬请期待。\


感谢崔康对本文的策划,张凯峰对本文的审校。

\

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入InfoQ读者交流群06e1fec4a87eca3142d54d09844c629f.png(已满),InfoQ读者交流群(#2)06e1fec4a87eca3142d54d09844c629f.png)。

2015-06-10 15:57:22 bamboolsu 阅读数 545
  • 项目管理从入门到精通:实践经验分享,实用套路讲解,...

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

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



Ken Schwaber是敏捷软件开发运动的领导者之一。他还是一位开发者、产品经理,以及产业咨询师。Ken和Jeff Sutherland(Scrum波士顿公司CEO)共同建立了最初版本的Scrum开发方法,在OOPSLA'95的年度会议上,他们第一次把Scrum作为正式方法提交出来。

Schwaber和Sutherland是敏捷宣言的最初签署者之一。他们是权威的《Scrum指南》的作者。如今Schwaber掌管着Scrum.org,这个网站提供Scrum资源、培训、评估,以及向“Scrum Masters”、“Scrum开发者”、“Scrum产品拥有者”,以及使用Scrum的机构发放证书。


图灵社区:你建立Scrum的最初动机是什么?

Schwaber: 因为Srum管用。当时我的公司正在忙于交付一个高级产品,这个产品的市场正火,需要有经常性的改动。如果我们采用长开发周期,我的公司就会破产。所以我们设计了Scrum,它让我们涅槃重生。


图灵社区:你觉得在中国推广Scrum有文化障碍吗?

Schwaber: 不会比其他文化更困难。一种文化是否能接纳并利用Scrum的关键点在于对可预测性的相信程度。


在文化中更理解和接纳可预测性的人会相信他们可以预测未来。他们工作的目的就是通过利用人力和资源让未来变成真正的现实。


使用Scrum的人们都曾有过这样的看法,像软件开发这样充满复杂性和创造性的工作是毫无预测性可言的。这样的结果很可怕:糟糕的软件,赶不上的进度,浪费的金钱,泄气的工作者。所以他们知道最重要的就是预测什么才是真正的需求,让员工们都认识到这点,然后竭尽所能帮助人们实现这个目标。Scrum之道的核心在于“有可为”,利用机会,避开障碍,敏捷起来。


图灵社区:经常有人会抱怨舍弃瀑布模型的困难重重,你认为有必要把敏捷和瀑布模型结合起来吗?为什么?如果可行的话,如何做到?

Schwaber: 这两个模型分别适合于两种极端不同的情况。


对于瀑布模型,我们预测我们要建的是什么,怎么制作,建立计划,然后按照进度完成。所有事情的关键都在于界定想要什么的准确性,以及直到产品最终成型前的有效沟通的准确性。如果沟通环节完美无缺,没有改变的需要,这么做是可行的。


Scrum的假设是沟通是有缺陷的,而改变才是永远不变的。在不超过30天的短周期中,人们建立起他们认为最终想要的东西。这在周期的最后会被检查。根据结果与需求的和谐程度,要做出下一个周期的计划。这是一个一直在改变的持续反馈环,根据检查结果和需求变化做出改变。


有人曾尝试结合两种方法,结果让人失望,毫无意义。还不如分开的好。


图灵社区:一家公司如何知道Scrum是否适合他们的企业以及他们产品?

Schwaber: Scrum几乎从来不会和某些软件公司的企业文化契合,这些公司因为不适当的瀑布模型而压力山大,他们在过去30年中一直都使用毫无新意的技术。


Scrum确实适合某些企业文化,为了年度预测而模仿销售周期,然后年度预测变成了月度预测,然后检查结果,并作出合适的变化。


多数公司对给他们开发软件的部门都不甚满意,因为浪费、失败、糟糕的质量屡见不鲜。那些极度绝望或者有真知灼见的人们会努力转移到Scrum上,这是一种更加适宜的方法,它可以反映出这家公司其余部门运作的方式。


图灵社区:在现实开发中,有些公司执着于死板的方法,而不调整方法以适用于他们自身的环境,你对这些公司怎么看?你对他们有什么建议吗?

Schwaber: 软件发展之迅速,已经成为了公司是否能存活的关键,这不仅关乎公司运转的方式,也关乎已经被嵌入到他们产品中的软件。那些不进化的企业,不在软件和产品开发中应用敏捷方法的企业,就无法有效竞争并存活下来。


我的建议就是敏捷就是一场关于适者生存的进化。


图灵社区:Product owner有很大的责任,有时候,他们会成为整个团队的瓶颈,如何解决这个问题?

Schwaber: 这个问题确实存在。所以我们要解决它。要解决这个问题有很多方法,包括为团队增加更多的领域知识。如果团队没有领域知识的话,product owner就不存在,那么我猜测整个开发就会慢下来,直到问题解决。否则就要等发布糟糕产品,丢人现眼之后再解决了。


图灵社区:番茄工作法是提高个体效率的方法,可以在Scrum中使用番茄工作法吗?

Schwaber: 如果你愿意的话,Scrum是一种可以内嵌番茄工作法的框架。但是,不加调整地盲目应用任何技术都是有害的。


图灵社区:如何控制和管理技术负债?

Schwaber: 在你写每条功能的时候,都要假设你后半辈子要一直维护和提升这个功能。就算你要上手一条烂到骨子里的老程序的时候,也要这么做。否则,那部分用来维护和支持老产品的开发预算就会吞噬所有要花在新工作上的费用。


图灵社区:你认为敏捷方法过分强调了 YAGNI(你不会需要它)吗?这样会造成忽视远期目标吗?

Schwaber: 敏捷方法并不包含 YAGNI。但是敏捷确实需要清理不需要的东西。比如,为什么要在有记录文档的情况下和别人沟通,而不是直接和他们交谈?无论如何,维护一个产品所需要的文档应该在每个周期都有发展。做有用且需要的事,剔除所有其他。


图灵社区:有人认为敏捷方法现在在走下坡路,你认为为什么会有这样的声音?你的看法呢?

Schwaber: 我曾听见有人问,敏捷是一种潮流吗?我认为敏捷是一系列的价值观和原则。而Scrum建立在敏捷之上,Scrum也建立在聚焦,勇气,开放,承诺,和尊重这些价值观之上。


价值观不是潮流。在我的想法中,在这些价值观和原则下工作的人们会成为潮流,他们的方法远远超过其他的方法,或潮流。


图灵社区:你怎么看敏捷的派别之争?你认为他们之间有冲突和矛盾吗?他们的不同来自哪里?

Schwaber: 敏捷和Scrum是非常非常简单的方法。不同和冲突来自想通过制造工具、方法,以及创造基于敏捷理念的新方法而赚钱的机构。一旦金钱进入了等式的一端,冲突就会发生。这些冲突并不是非发生不可的。用你的眼睛选择对你来说有用的方法。试验,并持续改进。




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