posts - 59,  comments - 323,  trackbacks - 0
  我新到这家公司,就开始了一场死亡之旅,我们的项目开发周期是3个月,人员大概有3~6个不一定。而以我的经验,我们大概要做的,是一个3~5个人年的非常复杂的创新型项目。新加盟的技术总监,是一个崇尚文档交流的“老干部”,因此,我们花了一个月的时间,在写各种各样的设计文档。真正能够用于开发的时间,是2个月。
 
  我们这个小组的另外一位组员,也是一位经验丰富的项目经理,他崇尚的,是文档UML化描述。因此,我现在除了写文档,还要用Rational Rose画好多好多的图~~~
 
  在他们两位来这个项目组之前,我其实已经写出了一份基本完整的User Case列表,而且和另外一位组员已经进入测试驱动的、结对编程阶段了。。。
 
 
  大家可能已经看出来了,这其中的开发模式,简直就是混乱不堪。到底是文档驱动?UML驱动?用例驱动?还是测试驱动呢?
 
  问题还不止这些,我们的大老板比较喜欢和我们一起讨论设计,甚至会和我们争论具体的某个算法。开发文档没有统一的管理,汇报机制没有明确的定义,项目需求随时都可能变动,就连到底我们这个小组会有几个人,都还是一个未知数,这样的死亡之组,不知各位有什么好的建议?

 背景资料介绍完毕,抱怨结束,下面讨论正题:

  文档驱动、测试驱动、用例驱动、模型驱动、特征驱动。。。。他们都要解决的是什么问题?

  要回答这个问题,还真不容易。我们得问一个更加重要的问题,真正驱动项目的,究竟是什么呢?我想,应该是需求吧?

 

  那么,这些“文档”、“测试”、“用例”、“模型”、“特征”,究竟是什么呢?对于需求的描述!我们之所以不会直接用需求来驱动项目开发,而是要借助工具,来帮助我们描述需求,就是因为口语化的需求描述是非常模糊的,充满歧义的。所以,选择什么来驱动我们的项目,其实就是要看,以上这些工具,哪一个能够更好、更准确的描述需求?

 

  文档其实是最难准确描述需求的一种方式,如果是纯文字的文档,就更难。我们的技术总监,非常喜欢读写文档,我最近也创下了一天写47页文档的最新记录。但是,当我们开会的时候,我还是经常需要提醒我们的技术总监,麻烦他再仔细看看文档第XX页的第XX段,以及配合着另一份文档的XX小节,来确切的理解我的意思!如果没有我的解释,他就会误解我的文档。

 

  当然,如果要写出不需要我来解释,他就能理解的文档,那么文档的工作量,将会极其惊人!我以前写过一篇blog,《Jacobson博士演讲观后感》是我对UP的创始人的极度反感的集中体现。GHawk,以及交大林老师的所谓“UP”的观点,当然不可能获得我的赞同。在GHawk的最新一篇blog:《UP & XP之争,意义何在?(续)》中,GHawk说:“唯一的问题是:“如何确保测试用例的质量”。显然,我们不能把一把不直的尺子度量出来的结果作为可靠的参考依据。怎么解决呢?“结对编程”么?嗯,这是一个不错的方式,那么最终该信赖谁呢?是Pair中的A还是B呢?或者,是Leader么?那么又是谁提出的要求呢?是老板么?还是客户?政府?法规?市场?……问题没有终结了。”

 

  由此我可以推断,他对于XP的认识,基本上是停留在猜测的阶段。对于这篇blog的观点,我就不逐一反驳了,我的猜测是,他经历过一次失败的XP尝试,而究其原因,我猜测是因为他们那个所谓的XP Team中,没有一个人,曾经实践过一次正规的XP开发。

 

  再来看模型驱动,这中间有一个大问题,因为需求是“问题域”的范畴,而模型,则是“解答域”的范畴,试图通过解答域的精确描述,来实现对于需求的准确描述,肯定不靠谱啊。

 

  特征驱动,我认为FDD其实是老方法的新名词,具体的实践,可能更加接近测试、迭代式的过程。了解不过,所以我也不打算多说。

 

  用例驱动与测试驱动,其实我认为这是一个硬币的两面,用例要尽快的翻译为测试用例,而测试用例,正是为了更加准确的表述需求用例。这是我能够想到的,驱动项目开发的,最好的方法!

posted on 2006-04-26 00:32 读书、思考、生活 阅读(29314) 评论(31)  编辑  收藏


FeedBack:
# re: 拿什么来驱动你啊,我的项目?
2006-04-26 00:41 | 原创专栏 开源学习
庄子可能是烦恼&&失望.

如果是我在这公司就好了,嘛也试试.  回复  更多评论
  
# re: 拿什么来驱动你啊,我的项目?
2006-04-26 00:52 | scud(飞云小侠)
项目一开始,就要明确 开发的方法,而且让leader,manager都知道. 千万别中间改  回复  更多评论
  
# re: 拿什么来驱动你啊,我的项目?
2006-04-26 09:12 | 寒晴天
您的队伍里缺乏一个法西斯,不知道您明白我的意思么,
您队伍最大的问题是在讨论问题而不是在解决问题,
也许您队伍里不存在如果项目搁置或者其他原因负全责的人吧,
否则怎会让如此多而繁杂的方法同时存在,
如果有一个人能把握全局然后安排工作,则不需要有任何讨论,在我看来,讨论是没有任何意义的,(这句话仅指部分,哪位被刺痛了请笑纳)毕竟没有哪个头会承认自己哪怕在任何一处不如下面的人想的仔细,他们会用,安全,效率,实际上...等等其实完全不需要在意以及可以解决的问题上否定你的方案,而这时,你也只有选择避让,最后项目失败了,
很多头又开始埋怨下面的人,一副恨铁不成钢的嘴脸,让上面和更上面的人以为是队伍本身素质的问题,实际上,太多所谓的头仅仅是在某个特定的时间和范围内为公司作出过贡献的很特定的人选,相信除非您很知名,或者你有很牛的背景,如出国XXN年,没哪个公司会相信一个外面的人,所以本着疑人不用,而非因才任人的原则,所谓的头衔就非常的次要了

所以,要项目成功,最根本的问题不是方法,而是人
所以老毛在的时候,狗屁都没有都搞出两弹一星
老邓在的时候还搞出改革开放,一国两制
现在呢?什么都有了,却什么都没有了....
  回复  更多评论
  
# re: 拿什么来驱动你啊,我的项目?
2006-04-26 10:12 | howard123456
>>>您的队伍里缺乏一个法西斯,不知道您明白我的意思么,

说的太对了,我喜欢在项目中有一个法西斯,讨论来讨论去一点意思都没有,只会带来不必要的修改,烦人。实际对于我们程序来说,事情很简单,就是算24点,给我4张牌,我给你一个24点表达式,仅此而已  回复  更多评论
  
# re: 拿什么来驱动你啊,我的项目?
2006-04-26 10:31 | 寒晴天
呵呵,Open的Leader很不错,但是我们需要懂得承担的Leader,
那次我去开用户需求分析会,Leader对着客户中一个捣糨糊的领导,说了一句,
"你不懂就回去喝茶,不要以为领导就应该什么都要插得上手,我们这是高科技,要想项目成功,就要听我的,除非您想回去跟您的领导说,"项目失败了,但是我尾款没给".
就因为这么一句话,一个可以让我们改上大半年的无理要求被否定了.而且更重要的是为我们公司赢得了一个"专业"的看法,这个企业再也没有找其他公司做项目,而那个捣糨糊的领导也和我的Leader成了朋友,"你做事,我喝茶,项目肯定没问题...."确定需求是分析员和Leader的任务和责任,假如因为Leader的原因导致项目重构或者失败,那么承担责任(加班改程序啊)的就不应该是我们程序员.  回复  更多评论
  
# re: 拿什么来驱动你啊,我的项目?
2006-04-26 11:47 | 黄金时代已过
以下愚见,请随便看看。
--------------------------------------------
那要看你是什么角色了

如果你是老板,错了,你应该不是老板,下一个

如果你不是项目经理,
如果 你的银行账户上的钱还够用,则 做最后的努力去和大老板交流过程管理,如果失败就考虑另谋高就。成功则需要某种形式的任命。
如果 你的银行账户上的钱不够用,则 左右逢源,见风使舵。养家糊口要紧呀,在江湖上混,难免要夹着尾巴做人的。

以下假设你是项目经理,也就是项目的负责人,你就没办法逃,也没办法混了。
首先要把手下几个搞定,手下搞不定,这时就难办了,假如项目成员中还有技术总监的小舅子,那你肯定完了。然后对技术总监和大老板阳奉阴违,他们对于文档的要求可以用时间作为托词,或者花很少的时间找些资料填入。

对于那位喜欢画UML的,可以允许他在完成本职工作的前提下画,甚至可以每天抽出10到15分钟看看他画的东西,然后适当表扬。毕竟这样的个人爱好总比喜欢打游戏或者聊天泡妞健康。这些东西从项目的角度可能没什么用,但是可以用来应付技术总监。

尽可能的偷工减料,首先把测试用例减少,只对比较复杂和重要的部分作单元测试。然后尽可能把界面先开发,容易实现的先开发,业务逻辑先空着,这样有利于业务人员去糊弄对方的具体办事人员,有利于收款(否则收不到款,会影响各方面的情绪,导致矛盾激化)。

然后保持强悍的心灵和认真负责的态度来开发程序,等待项目延期。
如果一年内你被炒掉,恭喜你,你在职场上的经验还不够,需要再学习几年。
如果人员流动率>=75%,结果很难预测。
如果一年内你没有被炒掉的并且人员流动率<=75%的话,项目应该会顺利结案。
我看好你哟!  回复  更多评论
  
# re: 拿什么来驱动你啊,我的项目?
2006-04-26 12:06 | 非鱼
庄子还不快跳槽!!!

BTW,我来替GHawk回答你文中的一段话:

GHawk:“由此我可以推断,你对于UP的认识,基本上是停留在猜测的阶段。对于这篇blog的观点,我就不逐一反驳了,我的猜测是,你经历过N次失败的UP尝试,而究其原因,我猜测是因为你们那个所谓的UP Team中,没有一个人,曾经实践过一次正规的UP开发。”

注:我不想说UP/XP哪个好,只是对你的逻辑推理过程感兴趣。  回复  更多评论
  
# re: 拿什么来驱动你啊,我的项目?
2006-04-26 12:11 | 寒晴天
@黄金时代已过

高,实在是高!

学了一招高的.  回复  更多评论
  
# re: 拿什么来驱动你啊,我的项目?
2006-04-26 12:16 | 匿名
既然楼猪是这么厉害的人物,为什么你的团队也这么糟糕呢?
可见,团队不同于个人,好的团队有自己的风格,退而求其次,不同风格的队员也能很好的融合各自的风格。就算UP是想你说的这么一无是处的东西,如果你这么反感文档并且“爱屋及乌”地反感推崇文档的人,那只能说明你作为一个人,性格上存在着兼容性的问题。
从你驳斥别人观点的这一举动就能看出,你是个不具兼容性的设备,虽然性能很强。  回复  更多评论
  
# re: 拿什么来驱动你啊,我的项目?
2006-04-26 12:18 | 匿名
顺便说一句,如果一个人不认为自己有错,错的都是别人的话,那还是少与他说话为妙。
期待楼猪的项目出一个漂亮的结果  回复  更多评论
  
# re: 拿什么来驱动你啊,我的项目?
2006-04-26 12:45 | netfishx
庄老大,不要太羡慕charles。他是boss,否则xp难啊。  回复  更多评论
  
# re: 拿什么来驱动你啊,我的项目?
2006-04-26 12:47 | renyfox
对你们的争论,我觉得很索然,UP也好XP也好,都只是搭建软件大厦的工具而已。
我不是搞软件的,但我觉得很多事情都可以触类旁通。ghawk自始至终没有说过UP好或者XP好,只是在讨论对于什么样的情况,用哪种工具比较合适。我喜欢摄影,但是我不觉得用了单反,我的摄影水平会提高多少,关键还是使用工具的人,不是么?
你不喜欢使用的工具,就说它不好,而且认为使用这种工具的人也不好,实在是有点可笑。况且,你喜欢的XP,与UP在本质上有什么区别呢?在我看来,只是把一些繁琐的、大家都已经了然于心的东西给简化了,把原本应该书面化的东西,都放在人的脑子里了。
你的水平已经很高了,高到使用XP游刃有余,那么让那些初级人员怎么办呢?就算要提高他们的水平达到可以用XP的水平,那用什么来提高呢?我想应该还是UP吧。不知道庄兄在初级的时候是怎样提升自己的,有什么好的意见不妨给大家介绍一下,不要吝啬哦~~~

(小弟非专业人士,言语不妥之处,还请精英们宽大处理~)  回复  更多评论
  
# re: 拿什么来驱动你啊,我的项目?
2006-04-26 12:49 | netfishx
@renyfox
恰恰相反,我认为xp才是让新手提高的最好办法。up大概还是要高手去玩或者是领着玩比较好。  回复  更多评论
  
# re: 拿什么来驱动你啊,我的项目?
2006-04-26 12:52 | renyfox
@netfishx
是吗?能否将个中理由稍稍详细地给我分析一下?(好让我考虑去买单反,哈哈)  回复  更多评论
  
# re: 拿什么来驱动你啊,我的项目?
2006-04-26 13:20 | nake
lz火气好大,希望你不要把火气带到工作中,少说话多干活。  回复  更多评论
  
# re: 拿什么来驱动你啊,我的项目?
2006-04-26 17:37 | wolfsquare
>用例要尽快的翻译为测试用例,而测试用例,正是为了更加准确的表述需求用例。
说的不错,这次我支持你.  回复  更多评论
  
# re: 拿什么来驱动你啊,我的项目?
2006-04-26 22:22 | 读书、思考、生活
to:scud

没办法呀,我去的时候,已经一团乱麻的,现在也没见好转~~~

to:寒晴天
法西斯?我们大老板就是典型的“独裁式管理”,而乱源也就出在这里。
你们那个Leader真不错,是条汉子!

to:黄金时代已过
谢谢你的建议,非常的中肯,保持强悍的心灵和认真负责的态度来开发程序,等待项目延期。
这就是我目前的基本心态了。

to:非鱼
你怎么把我的话里的XP,都改成UP了?恶搞吧:)

to:匿名
"既然楼猪是这么厉害的人物,为什么你的团队也这么糟糕呢?"

这不是我的团队,这正是无奈之处啊。
另外,我非常不喜欢你回帖里的那种骂人的小花招!
一个只敢匿名的家伙,我就不来跟你计较了!

to:netfishx
我的确是羡慕啊

to:renyfox
UP是一种过程管理工具,而XP不是~~~
这是我要提请GHawk注意的地方,当然也提请你注意这一点。

to:nake
放心,我工作还是不会耽误的

to:wolfsquare
谢谢你的支持  回复  更多评论
  
# re: 拿什么来驱动你啊,我的项目?
2006-04-26 22:45 | mixlee
一般对技术不在行的LEADER就特别喜欢文档,因为这是他的工作成绩的体现。这也是他对技术没有把握,没有信心,所以只能靠文档来安慰安慰自己。
我认为文档还是有用的,在开发的时候可能效果不是很明显,在后继开发中就能体现出来。
比如换了一拨开发人员,如果没有用例,没有功能的需求说明,那么新来的人光在需求里就得摸上大半个月,还弄不明白。而且需求阶段的文档写清楚了,也就可以让开发人员好干活。
所以需求阶段的文档一定得写清楚。这个阶段的文档我认为还是得主要靠文字描述,尽量写详细。
至于设计方面,代码就是最好的文档。写详细设计文档简直就是浪费时间  回复  更多评论
  
# re: 拿什么来驱动你啊,我的项目?
2006-04-27 11:47 | 非鱼
@读书、思考、生活
不是恶搞啊。你说的话,只做一点修改就可以用来还击你,这说明它非常的不严谨。重要的是我觉得你很多推理过程本身是存在问题的,提醒你注意一下,否则会让人感觉你不够理智。直言了,请别见怪。  回复  更多评论
  
# re: 拿什么来驱动你啊,我的项目?
2006-04-27 17:18 | Arbow
庄大叔阿,你一边在maillist里面招人,一边在blog透露那么“混乱”的情况,还不把人吓跑了么,hoho :)  回复  更多评论
  
# re: 拿什么来驱动你啊,我的项目?
2006-05-07 00:01 | 不曾真实
死亡之旅 我看了好几遍,多年以来一直在努力不让自己的项目成为死亡项目。

其中一开始就讲政治:黄金时代已过 所分析的就是项目中隐藏的政治选手,以及他们的政治目的。我觉得讲得非常的好,很有参考意义。

第二条讲的是谈判,我觉得你最好尽早的和其他人进行深入的谈判,或者称之为“关于项目发展方向的沟通”。
我注意到你说了一句“等待项目延期”,我觉得实为不妥,倘若可以提出可以遵循谈判游戏的规则,陈述利害,提出可以接受的底线,顺便向老大表忠心,推心置腹,必将对你的工作有很大的帮助。
当然不要指望一次谈判可以解决问题,谈判的诀窍在于锲而不舍,退而再攻,攻莫忘退。
谈判,就是要摸清每个人的想法,划清每个人的定位,为项目发展争取时间,最低限度必须要让大家所有人知道你尽最大努力了。能做到这些,我想,无论成败,而且不管是谁,也不可能对你有恶言了吧。

切记,其他,工具,方法,都不如谈判这件事情重要。


“任何主要指挥官都不应该执行连自己都认为有错的计划,否则就应该受到谴责;他必须提出自己的理由并坚持对计划进行修改,最终还要宁愿辞职也不愿成为导致自己的军队失败的工具”--拿破仑
(当然最后一句话说得有些绝对了,个人认为,呵呵)  回复  更多评论
  
# re: 拿什么来驱动你啊,我的项目?
2006-05-07 00:03 | 不曾真实
管理项目总是最考验一个人的智慧的。希望你能安全渡过难关。  回复  更多评论
  
# re: 拿什么来驱动你啊,我的项目?
2006-05-07 15:12 | 读书、思考、生活
to:不曾真实
谢谢你的回复和劝诫。

1、谈判的前提是,谈判双方处在一个能够对谈的地位上,现在的问题是,我们的老板几乎不接受任何建议和意见。当然,我也应该尝试更加有策略的言谈方式,不过,希望不大。

2、辞职不是我的选择,因为这个项目我不是负责人,也可以说,这个项目,由于混乱,目前还没有一个负责人。“宁愿辞职也不愿成为导致自己的军队失败的工具”,这句话的前提是,这个军队是自己的,目前的情况是,没有人觉得这个项目是自己的。

3、所以,以我的经验,这个项目一定会延期,一方面是因为进度要求本来就非常的离谱,另一方面,现有的管理并未理顺各种混乱,而是在制造更多的混乱。所以,我在其中,更多的是一种“尽我所能,不为所累”的态度,如此而已。

4、这的确是一个考验智慧的挑战,我想,这个机会从更加正面的意义而言,是很难得的。  回复  更多评论
  
# re: 拿什么来驱动你啊,我的项目?
2006-05-07 20:25 | 不曾真实
1. 是啊。谈判的形式有很多种,我比较擅长和领导打太极拳。吃饭的时候和他说说,讨论问题的时候和他说说,汇报工作的时候和他说。。。 不行的话,我再换个说法,继续磨。而且,我会和其他小组成员也说。放出预言说,这么下去将会怎么样怎么样,但是注意不要搞僵了。一直搞得领导怀疑自己,反省他自己。

2. 恩。是啊。这样,辞职可以作为一个让别人知道自己的坚定的信念的方法。但是没有必要实际去试的,简单的说就是一个噱头而已。让别人认识到你是真心为项目好,而且做事情有原则。

另外如果说没有一个人认为这个项目是自己的,在这种情况下,你很容易出头的。向项目负责人努力,就要拿出老大的做法来,想象一个真正的团队老大,在这个时候应该做什么。这样以后自己做了老大,说话自然有人听。


3. 其实项目做好做坏,都是一种经验。不光是你一个人的,而且是全部人的,包括大老板在内。经常和大老板沟通吧,否则他会把责任赖到你头上的。“尽我所能”虽然你做了,但是要大家都能看见才对。“不为所累”你也要做努力,但是不要让别人看见了,否则有拖后腿的嫌疑。

4. 大事要有大智慧,死亡之旅讲究尽可能减小一切损失。这次项目不是你的,但是你要思考,如果这个项目是你的,你该怎么办。以后你很可能有机会再碰到这样的项目的,希望下次你就是整个项目的管理者,可以把项目拉出“焦油坑”。  回复  更多评论
  
# re: 拿什么来驱动你啊,我的项目?
2006-05-09 23:55 | 黄金时代已过
有人说在失败中更能学到经验,对这句话我很犹豫。
我曾经历一个项目,最开始预计是半年完成(14个开发人员,其中项目经理1人,开发经理1人,系统分析员4个,其他大多是高级程序员,可谓是公司的重量级组合,豪华阵容),后来历时3年半才勉强结案。坚持到最后的人算辈分,有的说经历了四代人,有的人说经历了五代人。我自认为应该是第三代中的一员,在项目中熬了1年,混不下去了,觉得对项目的余热都已经发挥完了,最终含恨离开。说起在项目中学到的东西,可能最大的经验就是能忍耐。在得不到公司领导、客户、以及任何人的信任的时候还努力为项目做一点点贡献,没有奖金,没有加班费。至于其他,则是仁者见仁,智者见智了。
所以如果注定要失败,我觉得还是早点退出比较好,毕竟人的黄金时代没有几年,经历成功比经历失败好多了。大老板有钱烧,但是我们却浪费不起青春。
附注:因为这个项目导致一个项目总监,2个部门经理离职。在这个项目中写过代码的人数达...(算了,太难统计了)。昨天他们系统上线,祝各位兄弟们一路走好!  回复  更多评论
  
# re: 拿什么来驱动你啊,我的项目?
2006-05-11 12:40 | dowei
技术总监,项目经理,还有你~~
这个项目的问题就在这里吧。文档,画图,还有你那种xp,即使是3条通往罗马的路,但每条路都需要大家齐心协力。
现在是发牢骚的时候吗?打败他们连个,或者帮助其中一个打败另一个,总之选一条路再说。  回复  更多评论
  
# re: 拿什么来驱动你啊,我的项目?
2006-05-15 19:21 | tony_chow
1、...需求是“问题域”的范畴,而模型,则是“解答域”的范畴...
模型怎么会是“解答域”的范畴?建立模型的目的反映事物的本质,说到底还是对“问题域”更清晰、更易理解的描述!对需求建模形成用例模型。由于模型有时也不能精确地描述需求,因此,我们必须还采用文字式的描述,即你说的文档进行详细说明与补充。模型是属于文档的一种形式,终极目的是更清楚地描述事物的本质。因此,本人认为应该采用以用例为驱动。

用例----->用例模型(模型)+用例规约(文档)----->分析&&设计&&编码等等。

在这里,模型、文档等只不过是描述事物本质的载体而已,不是关键,关键的是需求,是用例,以用例为驱动。

2、以架构为中心,规划好你的项目软件

3、以迭代式增量开发,推进你的项目软件进度

由于时间有限,就不多说了。
  回复  更多评论
  
# re: 拿什么来驱动你啊,我的项目?
2006-05-30 18:17 | 工具并不重要,
先说工具与方法(过程)

工具和方法不在哪个先进与否,而是适合,适合才是问题的关键,什么是时候呢,就是你采取的方法和工具能达成所有项目干系人的满意度就是适合。
ok。居于这样的原则个原则咱们展开来分析考虑。

1,楼主推崇的XP,首先请问你的项目组里的人员对XP都了解吗?你老板认同吗?如果答案都没有,甚至你都没有一个完整成功的实践案例。你如何达到干系人的满意度呢?那就是儿戏,说客观一点连你都不知道能否成功的方法和工具你就在项目里使用的话,何况依你所言该项目非常紧的情况下采用一个你的成员都不清楚,老板不了解,你没有成功的经验的一种方法和经验来进行,说不好听点就是拿老板的钱来开玩笑来练兵,在这样的项目里尝次是肯定不被允许的。
2,若你有过成功的经验,那就需要你跟你组员沟通,甚至培训指导,获得组员的理解和信任后在推行,至于你们的技术总监你完全告诉他该工具或过程的好处,当然必须理解到他需要文档的真正目的,以便配合他,否则是你的不对。因为每个老板都需要你有足够的理由说服的,不是说我要XP。

关于项目管理
1,尽早的进入正轨,无论是按那种做法(方法重要要统一、协调)来做,都要统一,不要有等待着回到你喜欢的XP中来,只有这样才有成功的可能,换位思考,如果是你们项目组每个成员都坚持自己的做法,那你的XP也推进不了。
2,不管什么工具方法,问题域定清楚是很重要很重要的,这与工具无关,XP只是开发的方法,但他无法定义出问题域,按你的说法是Xp过程于测试驱动的案例来描述每个用例,我是不敢苟同的。
3,尽快的定义好你们组员之间的接口,就如tony_chow所说,以架构为中心,以迭代式增量开发,推进你的项目软件进度 。

预祝楼主能够成功。


  回复  更多评论
  
# re: 拿什么来驱动你啊,我的项目?
2006-05-30 21:49 | 读书、思考、生活
to:dowei,tony_chow,工具并不重要,

谢谢三位的意见,我现在是一个普通的项目组里的程序员,埋头写好自己的code,不问其它。

无论管理、文档还是过程,都不再是我的考虑范围。

明天,我们会再次开会,重新商量进度计划,因为,好多需求都已经变了。当然,我就安心做一个旁观者吧~~~  回复  更多评论
  
# re: 拿什么来驱动你啊,我的项目?
2009-05-22 17:33 | 藏獒
@nake
你说的是什么意思啊?不是好明白的.你说细一点好吗?  回复  更多评论
  
# re: 拿什么来驱动你啊,我的项目?
2009-05-22 17:35 | 藏獒价格
我现在是一个普通的项目组里的程序员,埋头写好自己的code,不问其它。  回复  更多评论
  

只有注册用户登录后才能发表评论。


网站导航:
 
<2006年4月>
2627282930311
2345678
9101112131415
16171819202122
23242526272829
30123456

常用链接

留言簿(20)

随笔档案

友情BLOG

搜索

  •  

最新评论

阅读排行榜

评论排行榜