2018-05-18 18:10:19 Tracy19890201 阅读数 251
  • 项目管理从入门到精通:实践经验分享,实用套路讲解,...

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

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

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


2020-01-07 12:53:04 qq_34640315 阅读数 7
  • 项目管理从入门到精通:实践经验分享,实用套路讲解,...

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

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

敏捷开发宣言

《敏捷宣言》

我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作,我们形成了如下价值观:

个体与交互 重于 过程和工具
可用的软件 重于 完备的文档
客户协作 重于 合同谈判
响应变化 重于 遵循计划

在每对比对中,后者并非全无价值,但我们更看重前者

敏捷宣言是对敏捷的高度总结和升华,即使现在不理解也没有问题,在实践的过程中我们会逐渐对它有一个深刻的认识。

敏捷开发十二原则

在敏捷开发中,我们遵循以下准则:

  1. 我们的最高目标是,通过尽早和持续地交付有价值的软件来满足客户。
  2. 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。
  3. 要不断交付可用的软件,周期从几周到几个月不等,且越短越好
  4. 项目过程中,业务人员与开发人员必须在一起工作。
  5. 要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务。
  6. 无论是团队内还是团队间,最有效的沟通方法是面对面的交谈。
  7. 可用的软件是衡量进度的主要指标。
  8. 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
  9. 对技术的精益求精以及对设计的不断完善将提升敏捷性。
  10. 要做到简洁,即尽最大可能减少不必要的工作。这是一门艺术。
  11. 最佳的架构、需求和设计出自于自组织的团队。
  12. 团队要定期反省如何能够做到更有效,并相应地调整团队的行为。
2012-06-14 09:08:00 weixin_33735676 阅读数 55
  • 项目管理从入门到精通:实践经验分享,实用套路讲解,...

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

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

敏捷开发4句宣言:

  个体与交互           胜过     过程与工具

  可以工作的软件   胜过     面面俱到的文档

  客户协作               胜过     合同谈判

  响应变化               胜过     遵循计划

敏捷开发12个原则:

      1、我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意

  2、即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势

  3、经常性的交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间间隔越短越好

  4、在整个项目开发期间,业务人员和开发人员必须天天都在一起工作

  5、围绕被激励起来的个来构建项目。给他们提供所需要的环境和支持,并且信任他们能够完成工作。

  6、在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈

  7、工作的软件是首要进度度量标准。

  8、敏捷过程提可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

  9、不断地关注优秀的技能和好的设计会增强敏捷能力。

  10、简单----使未完成的工作最大化的艺术----是根本的。

  11、最好的构架、需求和设计出自与自组织的团队

  12、每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整

转载于:https://www.cnblogs.com/yiwind/archive/2012/06/14/2548781.html

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

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

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

敏捷宣言概览

犹他州(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/

2018-06-23 13:33:30 weixin_35641320 阅读数 491
  • 项目管理从入门到精通:实践经验分享,实用套路讲解,...

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

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

【转载】:

敏捷宣言以及敏捷开发的特点 - 鸿鹄当高远 - 博客园

敏捷宣言的简单介绍 - SuperZhang828 - 博客园

http://agilemanifesto.org/iso/zhchs/manifesto.html

http://agilemanifesto.org/iso/zhchs/principles.html


最近在复习软件工程,对敏捷宣言并不是很理解,因此搜集并整理了一些资料,方便自己复习。

敏捷宣言

敏捷宣言,也叫做敏捷软件开发宣言,正式宣布了对四种核心价值和十二条原则,可以指导迭代的以人为中心的软件开发方法。
 
敏捷宣言强调的敏捷软件开发的四个核心价值是:
  • 个体和互动高于流程和工具
  • 工作的软件高于详尽的文档
  • 客户合作高于合同谈判
  • 响应变化高于遵循计划


1、个体与互动高于流程和工具 

       敏捷开发的第一条价值观就是“ 以人为本”,强调“ 个体(人)” 及“ 个体” 间的沟通与协作在软件开发过程中的重要性。这个顺序不是偶然而为之的,敏捷开发将重视个体潜能的激发和团队的高效协作作为其所推崇的第一价值观。这意味着虽然流程和工具重要(尤其是大型组织),但是它们无法替换有能力的个体和高效的互动。个体的技能和他们之间的互动才是最关键的。

  • 当我们开发产品、解决问题或改进工作方式时,我们要寻找改进互动和提高能力的方法
  • 在项目期间,产品管理和开发团队必须在一起工作
  • 在项目期间,架构师、设计师和测试人员必须每天在一起工作
  • 面对面沟通是极其重要的,它不能被其它形式完全替换

2、工作的软件高于详尽的文档 

    敏捷开发的第二条价值观就是“ 目标导向”。同其他众多管理理论和模型一样,敏捷开发认同目标导向是成功的关键,因为没有目标也就无所谓成功。敏捷开发的价值观中清楚地阐明,软件开发的目标是“ 可工作的软件”,而不是面面俱到的文档。而遗憾的是,很多软件项目已经在纷繁的文档之中迷失了自己的目标。这意味着已集成、已测试、潜在准备发布的产品才是关键度量,它能够有效地跟踪项目进度和对发布做出决策。

  • 要以小步增量的方式构建产品:做一些分析、设计,然后开始编码和测试以验证设计
  • 设计需要做,比如敏捷建模工作坊(设计与文档不一样)。如果需要传递信息给客户、维护工作的人员,简易文档还是必要的
  • 好架构是持续开发产品的关键,架构是设计出来的,建立一个可实现的简单架构是持续化开发的第一步。随着时间的推移,架构会演进,所以持续追求卓越技术和好设计能够增强产品敏捷性。

3、客户合作高于合同谈判 

        敏捷开发的第三条价值观就是“ 客户为先”。虽然敏捷开发强调的第一价值观是“ 以人为本”,但敏捷宣言的缔造者们并没有忘记客户,相反他们真正的理解客户的需求、懂得如何与客户合作。敏捷价值观里强调的“ 客户为先”即不是简单地把客户当作“ 上帝”、刻板的推崇“ 客户至上”,客户要求什么、我们就做什么;也不是把客户当作“ 谈判桌上的对手” 甚至“ 敌人”,去斗智斗勇。敏捷价值观把客户当成了合作者和伙伴,把自己的使命定位为“ “ 帮助客户取得竞争优势”。这意味着我们应该超越谈判并尝试提升与客户的合作。我们还应该建立以合作为基础的关系,而不是靠公司内的正式接口。

  • 在实践中,意味着产品经理、市场或销售人员在产品开发期间要经常从客户那里请求反馈并排列优先级。
  • 在与我们自己的业务方合作中,我们应该寻找开发期间增进和改善合作的方法。
  • 产品管理和开发应该密切合作,而不是通过契约或手续。

4、响应变化高于遵循计划 

  敏捷开发的第四条价值观就是“ 拥抱变化”。人们常说“ 世界上唯一不变的就是变化”,大多数人也相信事实确实如此。而以往很多的软件项目却忽视了这一点,或者更准确地说是他们不愿意“ 正视”。他们总是试图用详尽的计划去预先穷举这些变化,然后又试图通过严格遵循计划来控制变化的发生,而结果往往是被不断涌现的变化击垮。敏捷开发价值观中承认变化是软件开发的一部分、并相信正是客户在不断变化其需求的过程中明晰了其真正的需要。因而敏捷开发欢迎变化、拥抱变化,并可坦然应对变化,正是这些变化为客户和项目带来了价值。这意味着欢迎需求变化,哪怕是开发后期。

  • 首先,预先知道所有需求是不可能的。每个项目都会有浮现和继承的需求。
  • 如果我们对客户需求变更做的好,我们就会增强客户的竞争优势还有我们自己。
  • 为了鼓励响应变化并使其更容易操作,需要建立流程和工作方式。承认计划的不确定性
  • 计划是必要的,但计划必须适应变化:我们需要持续调整计划。前期花很长时间制定详尽的计划的结果会导致大量的返工。同时,我们需要有足够的计划水平来评估业务需求和对其长期影响的判断。这是一种平衡的艺术。

最后,还应记住敏捷宣言中的最后一句话:“ 尽管右项有其价值,我们更重视左项的价值”—敏捷宣言并未否定或贬损“ 右项” 的价值,在敏捷开发的价值观中承认“ 流程和工具”、“ 详尽的文档”、“ 合同谈判” 以及“ 遵循计划” 的重要性,只是两相比较,“ 更重视左项的价值”。


敏捷软件的十二条原则

1.我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。

      客户满意和有价值的软件是关键词。要确保我们开发的软件产品能够给客户带来真正的价值,这完全取决于在开发期间与客户的密切合作。产品管理是确保客户需求在开发期间被正确理解的关键。我们应该集中精力在对客户最有价值的工作上。

       尽早并持续交付的能力是满足客户的关键。及时交付部分功能比最后交付全量功能更好,至少我们应该给我们客户一个选择。

2.欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。

  我们的目标是为了开发能够帮助客户提升价值的产品,要支持任何变化。变化不是一种否定,它体现了团队和产品负责人在敏捷开发过程中的一种工作方式。

3.经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。

     开发周期和发布周期完全不同。尽管有发布周期,但我们的目标是短开发周期。发布周期的长度依赖业务决策,并且和客户的期望紧密关联。短开发周期的频繁交付缩短了反馈周期并增强了学习。频繁交付还能让团队及早暴露弱点并及时移除障碍,增加了敏捷性和灵活性。   

4.业务人员和开发人员必须相互合作,项目中的每一天都不例外。

     只要在业务和研发之间建立起桥梁,我们就能从中受益。业务人员和产品管理知道市场状况、客户需求和客户的价值。开发团队知道产品和技术可行性。如何将这两方面结合?我们需要作出睿智的决策。

5.激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。

     知识类工作(比如软件开发)是由具有技能和激情的人来做的。为了激发个体的斗志和创造力,自由是最重要因素。要让角色去适应人而不是让人去适应角色。   

6.不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。

      面对面交谈在分布式开发中尤为重要。当我们看到人们彼此交谈时,信息更多以听说的形式被传递。文档(虽然它很重要)不能代替交谈,将每件事都写下来简直是不可能的。我们不应该只依靠写文档来传递重要信息。

7.可工作的软件是进度的首要度量标准。

     跟踪有多少功能已经实现,集成,测试是一种更可靠的进度度量。   
8.敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。


9.坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。

10.以简洁为本,它是极力减少不必要工作量的艺术。

11.最好的架构、需求和设计出自自组织团队。

12.团队定期地反思如何能提高成效,并依此调整自身的举止表现。

 

敏捷开发的主要特点

与传统开发方法相比,在敏捷开发的整个过程中,有以下几个主要的特点:

(1)敏捷开发的过程有着更强的适应性而不是预设性,从敏捷宣言的第四条响应变化高于预设计划便可以看出来。因为软件开发过程的本身的不可预见性,很多用户在项目开始时不可能对于这个项目有着一个完整而明确的预期。很多对软件的预期都在后期的修改和完善过程中产生。因此高适应性显然更加符合软件工程开发的实际。而敏捷开发实现其适应性的方式主要在于,第一,缩短把项目提交给用户的周期;第二,增加用户,业务人员,开发人员这三者之间的交流;第三,通过减少重构的成本以增加软件的适应性。

(2)敏捷开发的过程中,更加的注重人的因素。在传统软件工程中,个人的因素很少的被考虑到分工中,每个个体都是只是整个代码开发机器的一个小小的螺丝钉,个人的意志和创造力很大程度上的被抹去为了更好的为集体服务。而在敏捷开发过程中,每个个人的潜力被充分的考虑,应用什么技术很大程度上直接由在第一线开发的技术人员决定;每个人的特点和创造力都可以充分地发挥,这样开发出来的软件更加的具有生命力,因为他融入了开发者的心血和创意,开发者不再是进行机械的乏味的堆砌,而是创造属于自己的艺术品,这样的条件下产生的代码必然在质量上更占优势。

(3)在敏捷开发的过程中,整个项目是测试驱动的而不是文档驱动的。不仅每个模块有着自己的相应的测试单元,开发人员在开发自己的模块的过程中必须保证自己所开发的模块可以通过这一单元的测试,并且集成测试贯穿了整个开发过程的始终。集成测试每天会进行十几次甚至几十次,而不是像传统方法一样只有当各个模块的编码都结束了之后再进行联合调试。这样,在软件开发的进程中每一点改动所引起的问题都容嘉容易暴露出来,使得更加容易在错误刚刚产生的时候发现问题从而解决问题。这样就避免了在最后整个系统完成时错误隐藏的太深给调试造成极大的困难。

 

敏捷开发与传统开发方法的比较

优势

敏捷开发的高适应性,以人为本的特性,和轻量型的开发方法即以测试为驱动取代了以文档为驱动,这三个主要的特点,也就是敏捷开发相对与传统开发方式的主要有点。因为它更加的灵活并且更加充分的利用了每个开发者的优势,调动了每个人的工作热情。

 

敏捷确实是项目进入实质开发迭代阶段,用户很快可以看到一个基线架构版的产品。敏捷注重市场快速反应能力,也即具体应对能力,客户前期满意度高。

劣势

与传统开发方式相比,敏捷开发的最主要的劣势在于敏捷开发欢迎新的需求,而在每次新的需求产生时都可能引起整个系统的大幅度的修改。因为开发者在开发上一个版本的时候,完全没有考虑以后的优化将要如何进行。这样的开发方式实际的软件开发过程中,并不一定总是有效的。

而另一个方面,敏捷开发因为缺乏很多在敏捷开发中被认为“不重要”的文档,这样在一个大型项目比如一个操作系统开发的时候,由于其项目周期很长,所以很难保证开发的人员不更换,而没有文档就会造成在交接的过程中出现很大的困难。

 

敏捷注重人员的沟通,忽略文档的重要性,若项目人员流动大太,又给维护带来不少难度,特别项目存在新手比较多时,老员工比较累。

需要项目中存在经验较强的人,要不大项目中容易遇到瓶颈问题。




浅析敏捷开发

阅读数 161

敏捷开发4句宣言

阅读数 513

敏捷开发宣言

阅读数 362

   敏捷背后的原则 

博文 来自: liuruifei2009
没有更多推荐了,返回首页