敏捷开发需要计划吗

2016-03-19 10:39:56 zzhdi 阅读数 4304

easypm-敏捷开发

在产品研发过程中经常需要编写很多文档,例如:需求文档、设计文档、API文档、验收文档等等。团队成员要花费很多精力去维护众多的文档,甚至有“兄弟,我替你写代码,你替我写文档”的无奈。

敏捷开发宣言
* 个体和互动 胜于 流程和工具
* 可以工作的软件 胜于 详尽的文档
* 客户合作 胜于 合同谈判
* 响应变化 胜于 遵循计划

敏捷宣言的第二条“可工作的软件胜于详尽的文档”,很多人理解为敏捷开发不重视文档,甚至以此为借口逃避写文档。同样,在对待”敏捷开发是否需要架构设计”的问题上也有类似极端的看法。

敏捷宣言在写什么样的文档以及如何写方面并没有给出任何刚性的指导原则,那么在敏捷管理的项目中我们该如何编写文档呢?

首先,我们需要理解敏捷宣言背后的思想。
敏捷4条宣言都是在强调“价值”、“快速交付价值”、“为客户提供价值”的理念。换句话说,研发团队要把精力放在能够为客户带来价值的地方,避免在不产生价值或者ROI(投入回报率)低的任务上浪费时间。

其次,我们要理解文档的作用是什么?文档是用来准确传递信息,帮助理解事物,沉淀知识。

基于以上理解,在遇到是否要写文档的疑问时,可以通过回答两个问题来判断

  • 是否有比写文档更高效传递信息的方式?
  • 简陋的文档是否满足需要?

从文档的读者来划分

  • 读者是项目组外人员
    这类文档往往是需要编写的而且不能“简写”的。例如:用户手册、验收文档、API文档等。

  • 读者是项目组内人员
    这类文档能省则省,能简则简。如果能够在每天站会上沟通的,就可以不写。建议高层的系统架构图、内部API文档可以简写。
    如果项目Leader通过类似EasyPM这样管理工具能够查询到的信息,可以在周报中简写甚至省略。


对于可以“简写”的文档,可以考虑使用Markdown格式。

Markdown是一种简单易用的标记语言,用户可以使用这些标记符号以最小的输入代价生成极富表现力的文档。

EasyPM 的文档编辑器使用Markdown语法,并且实时保存/预览、支持代码高亮、文档评论以及全文搜索。在版本管理上,支持手动和自动进行版本管理。文档评论也支持@功能,可以高效地对文档进行评审。

2014-02-19 00:00:56 zs15932616453 阅读数 3515

        上次的博文敏捷开发之道(四)Scrum概述中,我们简单介绍了一下Scrum的相关内容,重点针对XP和Scrum进行了相关对比和分析。接下来我们讲解敏捷开发中的计划。


1、计划简介

        开发计划是一个项目实践过程中非常重要的工作,它能够保证我们开发的方向性和可预期性,为此通常我们会制定一些文档和注意事项。


        传统的开发过程中,我们会制定一个关于整个项目的开发计划,但随着项目的开发,需求的不断变化,开发进度会慢慢与计划不符,开发的过程中也会一点点调整开发计划,这样的结果导致很多时候,制定的计划变得流于形式,为此我们浪费了很多的时间和金钱。


        与传统意义上的开发计划类似,敏捷开发也非常强调计划的重要性,但制定的过程却非常灵活。在敏捷开发迭代初期,开发人员会和客户一起按照需求的优先级和依赖关系制定一个2-6周的开发计划。这个计划的灵活性在于计划的构成不是按照任务数量来规定时间,而是根据时间来制定任务量,这就解决了需求变更导致的计划改变等问题。

2、制定计划

        简单了解了敏捷开发计划的特点之后,我们来自己制定一下敏捷开发的计划。具体步骤如下:


        a、确定工时。

        制定开发计划首先需要确定本次迭代我们能够使用的开发时间。以两周时间为例,参与人员5人,每天每天的有效开发时间为6小时,系数暂定为0.7(系数主要考虑在开发过程中,开发人员可能会出现各种问题和特殊情况,所以计划工时往往会打一个折扣,一般系数的范围在0.5~0.7之间),则有效工时为2*5*5*6*0.7=210小时


        b、确定用户素材。

        工时确定之后,接下来就是根据用户素材换言之就是我们通常所说的需求的优先级和需求之间的依赖关系,筛选出一批足够本次迭代的用户素材。  


       c、估算用户素材所需时间。

        用户素材确定之后,并不意味着所有的用户素材都需要完成,这一点需要根据所需时间和实际工时自由决定。


        一次敏捷开发的计划制定完毕之后,剩下的就是两周的迭代。通过上述内容看敏捷开发的计划也不过如此,其实还有很多内容是需要我们在计划执行的过程中去学习和实践的,具体都有哪些内容?

        敬请期待下一篇!

2018-08-08 19:18:20 xiajun2356033 阅读数 43117

简介

这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢?

目录

  1. 什么是敏捷开发?
  2. 传统的开发模式和敏捷开发模式的对比?
  3. 敏捷开发scrum的实施。

什么是敏捷开发

敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。

在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

传统的开发模式和敏捷开发模式的对比

瀑布模型:
这里写图片描述
优点:
1. 为项目提供了按阶段划分的检查点。
2. 当前一阶段完成后,您只需要去关注后续阶段.
3. 它提供了一个模板,这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

缺点:
1. 各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。
2. 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险。
3. 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4. 瀑布模型的突出缺点是不适应用户需求的变化。

敏捷模型:
这里写图片描述
优点:

  1. 敏捷开发的高适应性,以人为本的特性。
  2. 更加的灵活并且更加充分的利用了每个开发者的优势,调动了每个人的工作热情。

缺点:

  1. 由于其项目周期很长,所以很难保证开发的人员不更换,而没有文档就会造成在交接的过程中出现很大的困难。

敏捷开发scrum的实施

Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作;把一个开发流程的名字取名为Scrum,相当于大家像打橄榄球一样迅速、富有战斗激情。而Scrum就是这样的一个开发流程。

Scrum开发流程中的三大角色
– 产品负责人(Product Owner)

主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果。

– 流程管理员(Scrum Master)

主要负责整个Scrum流程在项目中的顺利实施和进行,以及清除挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发。

–开发团队(Scrum Team)

主要负责软件产品在Scrum规定流程下进行开发工作,人数控制在5~10人左右,每个成员可能负责不同的技术方面,但要求每成员必须要有很强的自我管理能力,同时具有一定的表达能力;成员可以采用任何工作方式,只要能达到Sprint的目标。

scrum开发流程图

这里写图片描述

1、我们首先需要确定一个Product Backlog(产品需求列表),这个是由PO负责的(如图(一));

2、有了Product Backlog列表,我们需要通过 Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog;

3、Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成);

4、在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图)(如图(二)和如图(三));

5、做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本。

6、当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品。

7、最后就是 Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中;

如图(一):
这里写图片描述

如图(二):
这里写图片描述

如图(三):
这里写图片描述

如图(四):
这里写图片描述

敏捷开发管理工具:teambition
teambition

参考

敏捷开发之Scrum扫盲篇
百度百科
敏捷开发 模型讲解

2015-09-22 10:02:54 cym492224103 阅读数 13156

敏捷开发

包括了XP(Extreme Programming:极限编程)的四个价值观:沟通简单反馈、勇气,此外,还扩展了第五个价值观:谦逊。
敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式,目标是提高开发效率和响应能力。除了原则和实践,模式也是很重要的,多研究模式及其应用可以使你更深层次的理解敏捷开发。
敏捷开发宣言——
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
虽然右项也有价值,但是我们认为左项具有更大的价值。
以上的宣言比较抽象,基于该理念,以下是ThoughtsWork咨询公司的推崇的n个敏捷开发实践:



Iteration
迭代开发。可以工作的软件胜过面面俱到的文档。因此,敏捷开发提倡将一个完整的软件版本划分为多个迭代,每个迭代实现不同的特性。重大的、优先级高的特性优先实现,风险高的特性优先实现。在项目的早期就将软件的原型开发出来,并基于这个原型在后续的迭代不断晚上。迭代开发的好处是:尽早编码,尽早暴露项目的技术风险。尽早使客户见到可运行的软件,并提出优化意见。可以分阶段提早向不同的客户交付可用的版本。


IterationPlanningMeeting
迭代计划会议。每个迭代启动时,召集整个开发团队,召开迭代计划会议,所有的团队成员畅所欲言,明确迭代的开发任务,解答疑惑。


Story Card/Story Wall/Feature List
在每个迭代中,架构师负责将所有的特性分解成多个Story Card。每个Story可以视为一个独立的特性。每个Story应该可以在最多1个星期内完成开发,交付提前测试(Pre-Test)。当一个迭代中的所有Story开发完毕以后,测试组再进行完整的测试。在整个测试过程中(pre-test,test),基于Daily build,测试组永远都是每天从配置库上取下最新编译的版本进行测试,开发人员也随时修改测试人员提交的问题单,并合入配置库。
敏捷开发的一个特点是开放式办公,充分沟通,包括测试人员也和开发人员一起办公。基于Story Card的开发方式,团队会在开放式办公区域放置一块白板,上面粘贴着所有的Story Card,按当前的开发状态贴在4个区域中,分别是:未开发,开发中,预测试中,测试中。Story Card的开发人员和测试人员根据开发进度在Story Wall上移动Story Card,更新Story Card的状态。这种方式可以对项目开发进度有一个非常直观的了解。
在开发人员开始开发一个Story时,ta需要找来对应的测试人员讲解Story功能,以便测试人员有一致的理解,同时开始自动化系统测试脚本的开发。


Standup Meeting
站立会议。每天早上,所有的团队成员围在Story Wall周围,开一个高效率的会议,通常不超过15分钟,汇报开发进展,提出问题,但不浪费所有人的时间立刻解决问题,而是会后个别沟通解决。


Pair Programming
结对编程是指两个开发人员结对编码。结对编程的好处是:经过两个人讨论后编写的代码比一个人独立完成会更加的完善,一些大的方向不至于出现偏差,一些细节也可以被充分考虑到。一个有经验的开发人员和一个新手结对编程,可以促进新手的成长,保证软件开发的质量。


CI/Daily Build
持续集成和每日构建能力是否足够强大是迭代开发是否成功的一个重要基础。基于每日构建。开发人员每天将编写/修改的代码及时的更新到配置库中,自动化编译程序每天至少一次自动从配置库上取下代码,执行自动化代码静态检查(如PCLint),单元测试,编译版本,安装,系统测试,动态检查(如Purify)。以上这些自动化任务执行完毕后,会输出报告,自动发送邮件给团队成员。如果其中存在着任何的问题,相关责任人应该及时的修改。
可以看到,整个开发组频繁的更新代码,出现一些问题不可避免。通过测试部又在不停地基于最新的代码进行测试。新增的问题是否能够被及时发现并消灭掉,取决于自动化单元测试和系统测试能力是否足够强大,特别是自动化系统测试能力。如果自动化测试只能验证最简单的操作,则新合入代码的隐患将很难被发现,并遗留到项目后期,形成大的风险。而实际上,提升自动化测试的覆盖率是最困难的。


Retrospect
总结和反思。每个迭代结束以后,项目组成员召开总结会议,总结好的实践和教训,并落实到后续的开发中。


ShowCase
演示。每个Story开发完成以后,开发人员叫上测试人员,演示软件功能,以便测试人员充分理解软件功能。


Refactoring
重构。因为迭代开发模式在项目早期就开发出可运行的软件原型,一开始开发出来的代码和架构不可能是最优的、面面俱到的,因此在后续的Story开发中,需要对代码和架构进行持续的重构。迭代开发对架构师要求很高。因为架构师要将一个完整的版本拆分成多个迭代,每个跌倒由拆分成很多Story,从架构的角度看,这些Story必须在是有很强的继承性,是可以不断叠加的,不至于后续开发的Story完全推翻了早期开发的代码和架构,同时也不可避免的需要对代码进行不断完善,不断重构。


TDD
测试驱动开发。正如上面讲的,迭代开发的特点是频繁合入代码,频繁发布版本。测试驱动开发是保证合入代码正常运行且不会在后期被破坏的重要手段。这里的测试主要指单元测试。

继续深了解可以查看: 

敏捷开发实战问题

2017-01-12 17:36:11 huadian417 阅读数 14913

一:敏捷式开发(极限编程思想的体现)
敏捷开发(AD:Agile Development )以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。
敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式,目标是提高开发效率和响应能力。除了原则和实践,模式也是很重要的,多研究模式及其应用可以使你更深层次的理解敏捷开发。
下图简单说明了敏捷开发的关键要素:

总图:

这里写图片描述
这里写图片描述

这里写图片描述

这里写图片描述
相关概念解释:AM:(敏捷建模)

二:瀑布式开发(传统开发模式)
瀑布式(WM:Waterfall Model)开发是一种老旧的,正在过时的计算机软件开发方法。最开始的软件行业普遍采用这种方法,但是这种方法套用自传统工业生产,不适应计算机软件开发的具体情况。
大体分为这几个阶段:制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动。
这里写图片描述

个人体会:
楼主个人参与的系统为 工程项目管理系统,是施工企业的业务管理系统。施工企业业务非常复杂且多变化,想要一次性进行完整的调研几乎是不可能的,因此使用传统的瀑布开发模式会带来极大的工作量,延长项目周期。而采用敏捷式开发模式,可以与业主就业务系统及时反复的多次沟通,小版本多次迭代,更能保证项目执行的质量和进度。

什么是敏捷开发?

阅读数 38007