欢迎进入微简园地
开放的舞台
[微简法]当前用户2017/3/16 9:50:10

微简开发方法简介

1 概述  

微简开发方法简称微简法。微简法采用迭代方式,以界面为核心引导整个开发过程,是基于实践的软件开发方法。
在需求过程中,使用可用型原型工具将界面快速成型,以界面为主进行沟通。用户看到直观界面之后,会主动、快速、准确的提出需求,从而加速了需求的进程。

微简法提出了可用型原型工具的概念,用它可以极快的速度搭建界面原型。同时提倡原型即界面的理念,制作的界面原型可直接用于开发,从而避免了原型、界面需要二次设计、用户二次确认的过程。

可用型原型工具大幅优化了需求过程,提前看到结果使需求的变更降到最低,需求的准确同样会大幅降低设计、编码、测试、维护等环节的成本。

编码测试过程中,将工作拆分为1到3天的开发任务,通过众人参与、公开评审的方式,基本保证了工作量估算的准确。这种方式一定程度上将开发工作量化,从而使编码过程管理变得简单、透明、可控,人员配备更为合理,任务分配更加均衡,极大的提高了开发效率。
微简法要求编码时先写注释,通过注释即可清晰的看出程序的基本逻辑,并由超级需求人员进行检查。很大程度上避免了需求与编码不一致的问题,从而使编码测试过程更为准确。清晰的注释也使程序员思路更清晰、编码连续性更好,人员流动时代码交接、后期维护也变得相对容易。

微简法强化了单元测试过程,并提倡在一定范围内采用测试驱动方式进行开发。同时要求搭建持续集成环境,每天自动构建可运行系统,边编码、边测试、边体验。

微简法强调用户的直观体验。需求过程中用户每周一次通过界面模拟来体验系统,直到需求完成。编码测试过程中每个开发任务完成之后由超级需求人员代表用户进行体验;每月一次发布周期用户亲自进行体验,直到系统完成。

微简法使开发过程控制变得简单、清晰。在需求过程中主要通过界面完成情况、用户体验界面进行进度控制,编码测试过程中主要通过开发任务完成情况、超级需求人员体验系统、用户体验系统进行进度控制。

微简法认为人员的培养与项目工作同等重要,提倡在项目中采用一带一的模式进行学习。使每个人都可胜任项目经理、超级需求人员等角色,人员综合利用,用更少的人做更多的事。

微简法也让用户从头到尾都清清楚楚知道系统在做什么,使软件系统能最好的为用户服务,大大提高了软件质量和用户满意度。


 

2 角色  

微简法中只有一个特殊角色:超级需求人员。其它都是传统角色,如项目经理、程序员、测试人员等。

超级需求人员是项目中的超人,直接参与系统的绝大部分细节,是项目组中对系统最熟悉、理解最深刻的人。

需求过程中,超级需求人员负责与用户的沟通,制作系统界面原型,编写需求文档,甚至数据库的设计,同时还要帮助一个程序员成为超级需求人员。编码测试过程中,超级需求人员代表用户对系统的每个功能进行体验,与程序员一起进行设计,同时负责检查代码的注释,并配合测试人员确定每个细节。同时在各种会议中负责向用户演示系统。

每个项目中至少必须有一个超级需求人员。多数情况下,项目经理也应该是超级需求人员之一。超级需求人员不可中途退出项目。
编码测试过程中超级需求人员代表用户,编码人员与测试人员发生业务或系统方面的分歧时,超级需求人员有裁决权。


 

3 开发
 

3.1 整体流程
 

项目经理制定项目计划,并组织召开总体计划会议。项目计划是粗略的整体计划,是迭代模式的计划。项目计划中应包括大的功能划分列表,以及各部分的需求完成时间、编码测试完成时间。

总体计划会议之后开始需求过程。通过售前资料、产品规划或用户调研整理出需求清单,需求清单是需求阶段的详细执行计划。需求过程中每周召开一次正式的需求讨论会,周期也可以是3-5天。用户、超级需求人员、程序员都要参加。会议内容主要是汇报上个周期的需求工作成果,确定下个周期的需求工作计划,并确定下次需求讨论会的时间。会议中由超级需求人员为用户讲解、演示系统界面,通过界面模拟让用户提前体验系统。用户提出的具体修改意见,可以直接在会议上快速修改并确认。

部分需求完成后,这部分内容就可以进入编码测试过程。其它需求工作应该继续进行,以便让用户在最短时间内看到整个系统的概貌。
进入编码测试过程后,首先要根据界面、需求文档整理出详细的开发清单。开发清单必须由项目组、项目总监、有经验的外部人员等共同评审通过。评审完成后进入第一个发布周期。每个月为一个发布周期,也可以是2-4周。每个发布周期开始时召开计划会议,确定本周期的开发任务。每个发布周期结束时,举行评审会,向用户演示本周期的开发结果,并确定下个周期的开发任务。每个周期结束时发布可用系统供用户体验。直到系统完成。每个周期的计划、评审会用户必须参加。

其它需求完成后,对应的开发任务可在当前发布周期完成,也可放在其它发布周期完成。开发清单可根据实际需要调整。发布周期内用户可随时修改需求。


 

3.2 需求过程  

微简法要求在需求过程中,至少完成90%的界面,以界面为主进行沟通,不断让用户通过界面模拟来体验系统。用户看到详细的界面之后会主动进行沟通,并且能够快速提出准确的需求细节。加快了需求的进程,并使需求的变更降到最低。

通常制作界面是比较复杂的过程,所以微简法提出了可用型原型工具的概念,能够以极快的速度搭建系统界面,并且生成的代码可直接用于开发,原型即界面,二者合二为一。从而避免了传统开发中原型、界面分离,需要二次设计、用户二次确认的过程。

界面制作时坚持先粗后细、先快后精的原则。尽量使用现成的模板。

界面为主进行沟通,并不是说完全用界面沟通。必须结合其它方式才能完整的描述全部需求。比如:复杂业务流程更适合用图来描述,大量运算适合用文字来描述。

除界面之外,必须通过需求规格说明书来详细描述系统需求,需求文档应该是可测试的。

多数项目中,用户并不能很明确的知道自己需要什么。不能完全依赖于用户去提需求,应该通过半咨询的方式引导用户的需求。同时尽量用减法来确定功能点,集中精力把常用的功能做的简单、实用,真正把用户从软件中解放出来。

由于各种原因,不可能完全确定需求的所有细节,所以在需求基本完成之后就可以进入编码测试过程,然后在编码测试过程中逐步完善需求细节。

整个需求阶段,用户要大量参与,需求人员最好能与用户在一起工作,随时面对面沟通。


 

3.2.1 需求清单  

需求清单是需求过程的详细执行计划。需求清单可以提前梳理出来,如果对项目了解不够,也可在的需求调研的过程中逐步整理出来。
需求清单格式:


  vj23827213.jpg

 

说明:

1、 编号:需求任务的编号,在项目中唯一,并且始终不变。

2、 需求内容:需求任务的名称。

3、 界面数量:需求任务对应的界面数量。

4、 已完成界面数:已经完成的界面数量。

5、 文档是否完成:需求任务对应的文档是否完成。

6、 开始时间:需求任务计划开始时间。

7、 完成时间:需求任务实际完成时间。

8、 责任人:负责该任务的超级所有人员。

9、 优先级:需求任务的优先级。1到5级,1级最高;5级最低。
 


 

3.3 编码测试过程  

编码测试过程中,项目组成员应该坐在一个办公区域内进行工作,保证面对面的沟通。

项目组首先要制定详细的开发清单。开发清单由一系列开发任务组成,每一项是一个独立的开发任务,每个任务只能由一个人来完成。每个开发任务通常是1-3天的工作量,最多不超过5天。开发任务至少应该包括所需的工作量、优先级等内容。

开发清单是项目组内部使用的详细开发执行计划,由项目组成员共同制定,并由项目组、主管项目的负责人、经验丰富的项目外人员等共同评审通过。

开发任务可由项目经理统一分配,也可由程序员自己选择。必须从最高优先级的任务开始分配。在同一优先级内,先分配容易开发、工作量小的。每人同时只能分配一个任务,当前任务完成之后才可以分配下一个任务。如果有待修改的bug,应该优先修改bug,然后再分配新任务。

设计可以由超级需求人员与程序员一起完成,尤其数据库设计,部分数据库设计工作可以在需求过程中完成。多数情况下,可以没有专职的设计人员。

编码时,程序员应该先写注释后写代码。注释要清晰、详细,通过注释即可理清程序基本逻辑。由超级需求人员负责检查注释,以保证业务逻辑的正确性。

程序员必须重视并做好单元测试,每次提交代码时应运行完整的单元测试代码,并保证单元测试都能通过。对于有接口、较为复杂的功能,可采取测试驱动的方式,先写测试代码,后写功能代码,边开发边验证。

每个开发任务完成后,应及时进行测试,同时超级需求人员代表用户进行体验,边编码、边测试、边体验。

应搭建持续集成环境,每天自动构建可运行系统,以保证能够及时测试、体验。

测试人员可根据实际情况,在手工测试的基础上结合一些自动化测试方式。

在编码测试过程中,需求文档必须随时更新,保证与系统一致。测试人员应以需求文档为测试的标准,并监督需求文档与系统的一致性。
 


 

3.3.1 开发清单  

开发清单是从需求规格说明书、界面原型中提取出来的,是功能需求、非功能需求的重新划分。开发任务包含了设计、编码、数据处理等工作。

开发清单只是一个标题列表,具体内容需要根据功能说明、界面原型来开发、测试。开发清单与需求规格说明书的功能点划分可以一致也可以不一致,可以根据任务量重新拆分、合并。

开发清单主要根据界面功能进行划分。

优先级的划分:被依赖的任务、可能成为瓶颈的任务应该有更高的优先级。

开发工作考量:工作量代表了实际完成的工作任务,开发人员对应的工作量的总和就是所完成的任务总量。

进度控制:项目开发中的进度由项目经理控制,开发清单由项目经理维护。项目进度指标有三个:应完成率、开发完成率、实际完成率。应完成率=(当前日期-迭代开始日期)/(迭代周期)。开发完成率=实际开发天数总和/工作量总和。实际完成率=已完成状态的工作量总和/工作量总和。项目经理、超级需求人员每天都要比较这三个数据,根据情况找到问题并及时解决。


vj28837872.jpg

 

说明:

1、 汇报周期指的是一个时间段。汇报周期是可以重合的。结束日期就是提交用户的日期。

2、 编号:开发任务的标识,在整个项目中是唯一的,始终不变。

3、 开发任务:开发任务的简单描述。

4、 未开始:任务尚未分配。开发中:程序员编码、单元测试过程。测试中:已交给测试人员测试。已完成:完成测试、bug修改。
 

5、 开始开发日期:程序员分配任务的日期。

6、 完成开发日期:编码及单元测试完成时间。

7、 工作量:编码及单元测试的时间。不含测试、改bug时间。

8、 实际开发天数:当前日期—开始开发日期,但不能大于计划开发天数。

9、 开发人:负责开发该任务的人员。

10、 测试人:负责该任务的测试人员。

11、 优先级:开发任务的优先级。1到5级,1级最高;5级最低。


 

4 可用型原型工具  

可用型原型工具是微简公司提出的新概念,它不同于传统的原型工具和软件开发工具。传统的原型工具所做的原型多是示意性的,和最终的界面不同,而且是抛弃型原型,生成的代码不可用。而开发工具只有开发人员才可以使用,易用性不足,开发速度也比较慢。可用型原型工具介于原型工具、开发工具之间,是更为直观的需求沟通工具。

可用型原型工具至少应该有以下几个特点:

1、可以极快速度制作系统界面;

2、生成的代码可以直接用于开发;

3、原型即界面,二者保持一致;

4、很强的易用性,不懂开发的人也可使用。

可用型原型工具将界面设计简化到极致,使得需求人员能够快速的通过界面来响应用户的需求。

通常需求人员使用传统原型工具来制作原型,但这些都是抛弃型原型,生成的代码不可用,必须由美工、前端工程师再次设计、实现,还需要用户再次进行确认。整个过程中需要与用户、美工、前端工程师、设计、开发等进行反复沟通,每个环节都可能伴随着漫长的等待、无效的沟通。而使用可用型原型工具制作web系统界面,与用户沟通、确认之后,生成的代码可直接用于开发,避免了二次设计、二次确认的过程,大大提高了整体开发效率。


 

5 项目中学习  

微简法坚持学习与工作同样重要的原则。实践中主要采用一带一、边工作边学习的方式。

需求过程中,每个超级需求人员可带一个程序员一起进行需求工作,并帮助其掌握各个需求技能。

分配开发任务时,项目经理可根据实际情况安排两人结对工作,将技术相同的两个不同任务分配给二人。熟悉该技术者有责任帮助另一人学会并掌握该技术,另一人则边学习边工作。结对工作时,两个人使用两台电脑,坐在一起工作。

超级需求人员与程序员一起进行设计工作,也从一定程度上帮助程序员进步。

稀缺技术不应该只有一个人熟悉。只要项目中用到,必须采用一带一、甚至一带多的方式让更多人熟悉。

项目组必须规定明确的学习要求,并严格执行,学习效果纳入考核范围。

将更多的项目经理、需求人员、架构师变为超级需求人员;将更多的设计人员、程序员升级为超级需求人员;将更多的人变成项目经理。每个人都可胜任各种角色,实现人员综合化,用更少的人做更多的事,将人员成本降到最低。


 

6 文档  

微简法提倡尽量少写文档。但有些文档是必须写,并且写的很详细。如:需求规格说明书、数据库模型、测试用例等。


 

7 团队  

要建立一个好的团队,并在项目过程中将团队变得更好。

每个人都应该有明确的责任、分工。同时每个人不应局限于自己的角色,而是可以帮助其他人做任何工作。

团结协作,和别人的配合优先于自己的工作。

每个人都有权利在项目中做一些自己不熟悉的工作,也有责任帮助别人在工作中学习。帮助别人熟悉新工作优先于自己的工作。

工作中不能只靠项目经理一个人去监督,而是建立有效的众人监督机制。比如:用户监督界面制作情况、系统发布情况;超级需求人员监督注释情况;测试、超级需求人员监督程序员的开发情况;项目经理监督整体进度;测试人员监督需求文档的完整性等。

有问题必须尽快、主动沟通。尽量面对面口头沟通,对于沟通的结果要通过邮件等文字形式明确确定下来。

提高效率,尽量不加或少加班。

健康工作,劳逸结合,任务完成、效率低下时可以主动休息。


 

8 微简法的使用  

微简法并不是一套完整的开发方法,可以独立使用,也可以和其它方法结合使用。微简法提倡灵活使用微简法的全部或部分内容,结合每个项目的特点进行开发,而不拘泥于形式。

项目较大拆分为几个子项目时,每个子项目可独立使用微简法,也可合并使用微简法。独立使用时,各子项目之间发布周期应保持一致。