五千年(敝帚自珍)

主题:【原创】闲聊敏捷编程——测试驱动开发(一) -- 代码ABC

共:💬55 🌺131
全看树展主题 · 分页首页 上页
/ 4
下页 末页
家园 客户这边的阻力极大,这个我下次说SCRUM详细说
家园 送花,小羊最近也在试着野路子的拥抱变化

小羊现在的项目实践主要在web应用方向,和开发组商量着用了几回“山寨版”的敏捷方法,还是受益匪浅的。就说说我们的山寨版敏捷过程吧。

小羊的理解,敏捷的路数,所谓的拥抱变化,是一个从没有需求到完成需求的过程,需求分析和软件开发的过程是合二为一的,拿web应用开发来说,我们的美工和客户肩并肩坐着,客户说这里要个banner,就出来一个banner,客户说这个button要是黄色的,就出来一个黄色的,客户说页面布局应该是两栏三行,页面就是两栏三行,对于一个一般规模的web应用而言,基本上一到两天结束战斗。

然后客户转战到前台程序员组,还是肩并肩,把页面上每一个交互元素都趟上一遍,客户说这个input丢失焦点的时候,应该在旁边提示输入是不是合法,程序员就随手写一段javascript代码,不管怎么样都在旁边提示一下,以此类推,一个凑合能动的“假”应用也差不多就是三五天的事儿。在这个过程中,后台组的哥们儿就在旁边站着,记下来每一个能动的玩意儿应该怎么动,行话说,叫用例吧。

到这里,客户可以退场了,开发组开始写测试用例,顺便说一句,如果稍微NB一点,跟着前台程序员观摩的时候,测试用例已经写的差不多了,从用例抽象出数据模型,然后找来玩儿后台数据库的,提出自己的数据模型需求,等到系统数据模型建立完毕,再找来前台程序员肩并肩,这个时候是前台程序员说需求了,前台的兄弟说这块儿我要一个包含什么内容的json,后台的兄弟就写一个controller返回一个包含什么内容的json,模型层满足不了controller的要求了?没关系,那哥们儿就在旁边一米远,立马改。完了跑跑测试,测试ok之后,不仅单元ok了,实际上集成也ok了。

最后一关,交活儿,客户就是不花钱的集成测试员,直接抓过来让他点鼠标,美工和前台程序员坐旁边,小修小改,顺带着就把浏览器兼容性问题解决了。

至于大的页面和功能调整,目前还没有碰到过,感觉整个过程中,用户也在根据面前的原型不断的调整和表述自己的需求,是一个思考固化的过程,所谓大的调整其实已经分解成了若干个小的需求。

同时,眼看着一个应用程序从无到有展示在自己面前,无论是客户还是开发人员都反映挺有成就感的,而且快速的需求——实现反馈会不断的增强用户和开发人员的信心,客户最后点鼠标的时候就是最high的时候,小羊一般在这个时候会找来业务人员,等客户high到顶点的那一霎那,就把项目验收确认书的字儿也签了,嘿嘿。

总结这个过程,小羊的心得是————要想玩儿的爽,客户要配合,需要客户配合,就得让客户有热情,要让客户有热情,关键是快速的需求——实现反馈,为了快速的反馈,就必须:

第一,开发工具必须能够快速的建立原型,快速的修改并且反馈结果,html,css,javascript,ruby,php,python这样的都行,java那样的就算了,building过程就能谋杀掉客户的所有耐心,要是完了再抛出几个错误,把戏就不用玩儿了。

第二,需求的获取、传递和使用要讲究传递的层次和传递过程中的解构,客户是消息的源头,美工、前台、后台、建模都是消息的消费者,消息的消费者各自从消息源获取对自己有用的消息,同时信息传递过程中,需要“翻译”的要求越高,距离消息源就应该越远,基本不需要加工的直接传递,像页面、前台,没什么专业术语,平时说的就是人话,就直接从客户处获取;稍微需要一点翻译是后台程序员,列席客户和前台的交流,记录用例,他真正需要的信息是前台程序员传递过来的;距离最远的就是建模,他完全不参与和客户的沟通(沟了也白沟,鸡同鸭讲),他仅仅从后台程序员处获取信息。

第三,由于需求信息分层传递和各取所需的设计,整个系统架构就必须充分解耦,当然这个是系统设计的正常要求,只不过如果使用敏捷编程的方法,就变成了强制要求,要不然经过这么复杂的反馈过程,项目足以成为一个超级焦油坑,不可收拾。

第四,项目组人员越少越好,敏捷编程对于项目人员的要求还是很高的,靠翻文档写代码的不成,打字慢的也不行,尤其是后台程序部分,要在客户和前台程序员建构系统原型的时候就做到对用例和功能模块心里有数,要求不是一般的高,项目成员——尤其是参与信息的获取和传递的——一块短板足以搞垮整个项目。越玩儿敏捷编程,越发现适合小项目组,最好就一个牛人,和客户商量着就把事儿办了

总而言之,小羊觉得,所谓敏捷编程,就是以我万变之不变,应对用户不变之万变,只要我写的快,改的稳,管你千变万化我都不怕,所以,敏捷编程,小羊觉得于其称之为软件工程的方法论,不如说是对软件业界的一份QA指南,对于语言、工具、分工都提出了自己独特的要求。

元宝推荐:铁手,
家园 其实是很有效率的

先写测试再写程序其实是最有效率的写法了。

我做工程的时候,以前不懂这个。最后测试的满头包,debug还很困难。

另外,接口什么的,不是应该在一开始就协调好吗?

家园 您这个就是一般的方法吧,算是敏捷吗?

系统设计的好,需求变化的压力自然分散到了各个开发节点,但是如果客户不按常理出牌,不断新增需求,还是受不了的。

家园 可是这么干的话,大一点的项目就不成了吧

1。文档没有,回头客户一拍脑袋不认帐。

2。规模稍微大一点,多个客户的需求各有想法,冲突在所难免。

3。大一点的系统,客户所需要花的时间也不少,尤其是测试这一块。

家园 敏捷是一个原则,可以有不同的实现方法

总结这个过程,小羊的心得是————要想玩儿的爽,客户要配合,需要客户配合,就得让客户有热情,要让客户有热情,关键是快速的需求——实现反馈

这里就体现了敏捷的两个原则:合作与沟通。

家园 大一点的系统,小羊也存在疑虑

而且不光是我,兄弟们也是这样,我们目前还坚持这样的做法,主要原因在于

1、目前我们用这种方法操作过的项目,最大的是一套OA,周期是半年,运作的很好,如果有更大的方法,我们也非常愿意试试看。

2、从客户的反馈看,以前经常头疼的需求分析问题和纠纷居然神奇的消失了,我们总结是在开发的过程中就消解了。

至于您的几个问题,小羊斗胆回复:

1。文档没有,回头客户一拍脑袋不认帐。

文档还是有的,每个环节完成的工作都会形成文档交付客户确认,就是怕客户不认帐,不过从实践看,基本就是轰轰烈烈走过场,认认真真搞形式了,因为这些工作是和客户一起完成的,还没碰到客户否定自己的,至于过段时间拍脑袋不认帐的,这事儿得分两头说,真是恶意的,没辙,要是确系当时没想明白的,快速原型法恰恰避免了这个问题,在建模修正的过程中,用户也在一步一步完善和修正自己的看法,即便是后面有遗漏,也不多了。

2。规模稍微大一点,多个客户的需求各有想法,冲突在所难免。

巧了,我们的OA项目,也存在多个功能模块,我们干脆把项目组也拆了,每组跟一个,每日完成的原型开会讨论,结果————客户自己干起来了,这个呵呵,俺们不管,直接回避,第二天,他们就有统一结果了。

3。大一点的系统,客户所需要花的时间也不少,尤其是测试这一块。

何止不少阿,简直超长,我们直接把这段时间称做上线试运行,哈哈。

家园 碰上不按照常理出牌的,神仙也没办法

小羊觉得,不管是瀑布还是敏捷,目标都是按照常理出牌的客户,区别仅在于需求获取和响应的方法上面,如果碰上了捣蛋的客户,软件工程没办法解决,得靠社会工程了,嘿嘿

家园 Dijkstra成天和这家伙的程序打交道

eigrp ospf......

家园 敏捷开发,

每次迭代开发,都需要明确需求,开发过程中,需求不能再变更。完成当前有限的需求开发以后,才能进入下一轮的迭代开发。每次迭代完,都是可以提供给客户一个稳定的软件系统.迭代早期,开发出来的是一个功能简单软件,有一个简单稳定的东西总比复杂但充满BUG的东西好吧。

迭代开发的周期也不能太长,一个久拖不决的项目,对开发人员,容易造成心里疲劳,后期就在应付差事(深有体会);对用户来说,看不到项目的结果,造成失望.

每次迭代开发完,用户根据预先写好的测试用例验收当前迭代的代码,可见,敏捷开发对客户的参与是有一定的要求的。

家园 现在做的一个很小的内部开发

我一个人,反正是内部,文档全省了,有过程中来往的Email,不怕他不认账,根本不做test case,管杀不管埋,测试全交给客户做,用下来不满的出问题的给我一个email,我阅读之后把大概的可解决性回个email请客户确认,然后出下一个版本...

大概比野路子还野路子,结果客户满意度感觉上高于之前做过的任何项目...

家园 个人体会,难点恰恰是客户参与
家园 Refactoring

没有Refactoring,谈不上拥抱变化。

家园 用户的变化,小羊算是抱结实了,重构。。。确实碰到问题了

小羊这几个项目用的是ruby ,必须承认,在重构方面,找不到java重构那种很爽的感觉,小羊不知道这是动态语言先天的问题,还是小羊工具或者方法上面的问题,还请zhonghm兄台指教,小羊拜谢了

家园 测试驱动也有适用范围

测试驱动则向导弹,发射的时候只要大致对准就可以了,在飞行过程中不断有修正指令——逐步发掘出来的测试。这样不管固定目标还是移动目标,通杀。

这主要是针对飘忽不定的“小需求”而言,有人曾经根据需求范围把需求分为兔子、奔马、大象三个级别,针对大象级的需求用敏捷方法、测试驱动就有些力不从心了,灵活有余,而力道不足。况且由于需求范围的扩大,势必造成,测试的用例剧增,抓住问题域核心的难度加大。这也是域驱动开发提倡的重点,认为用户才是真正的行业专家,通过和用户的接触,捕捉问题的核心,然后辅以成型的业务模型和开发框架,搭起系统架构,然后利用敏捷方法,局部进行重构,避免过度设计

全看树展主题 · 分页首页 上页
/ 4
下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河