锁定老帖子 主题:为你的项目加入一个阶段--技术研究
该帖已经被评为良好帖
|
|
---|---|
作者 | 正文 |
发表时间:2006-10-16
--项目管理的一种“最佳实践” 摘要:以一个明确的“技术研究阶段”来提高开发效率、规避开发风险、提高项目管理的可控性,是一个简便易行的“敏捷”项目管理手段。 1、什么是“技术研究阶段” 这是我在项目管理实践中总结出的行之有效的一种“最佳实践”,技术研究这个词很自然就能理解了,“技术研究阶段”通过本文的描述也很容易理解。关键是“实践”。 2、明确一个“技术研究阶段”的动力 * 规避技术风险 * 提高开发效率 * 提高项目管理可控性 这是在项目管理中实行“技术研究阶段”最原始的动力。 3、“技术研究阶段”的适用情况 有几种比较典型的情况非常适合加入“技术研究阶段”: * 项目中引入新技术、框架 * 项目有复杂的新型需求(比如:未遇到过,而且不确知与实现相关的性能问题,等等类似情况) * 项目开发团队“以老带新” * 锤炼、优化已有的相关技术积累,以应用到当前项目 这几种情况是我验证并收到良好效果的,并且我认为可以适用但不限于以上情况。 4、怎样开展“技术研究阶段” 4.1 什么时候实行“技术研究阶段” 项目的开发团队一组建,或者主要全职开发人员一到位,就可以开展“技术研究阶段”。可以和需求分析并行,最好开发环境、平台等已经选定。 4.2 “技术研究阶段”实行原则 一定要明确这个阶段,参与者有明确的目标和任务,可以动用“卑鄙”的考核手段(主要是提高重视程度,而不是考核)。 目标和任务由项目经理、teamleader、资深开发人员等共同讨论决定。以老带新的情况下,“老人”为主要责任人,同时也负责指导“新人”。至于指导手段,什么结对编程等等都可以。 目标任务要明确下来,你写在公示的白板上可以,用邮件发任务书也可以,总之要让每个人明确自己的研究任务、时限。 4.3 “技术研究任务书” 上面提到,用来明确目标任务。载体可以灵活,格式要简单明了,任务、时限、责任人是核心内容。不要放太多东西。 4.4 研究目标实现手段和提交物 一定要结合眼下项目的具体业务场景。 业务场景由项目经理、核心开发人员等(团队不是很大的话最好是全体人员参加)选定典型、难点场景,不要很完整,针对估计的技术实现难点最好。 所有类型的技术研究,提交物都是一个现实开发、运行环境下的demo,不关心界面友好等等一切修饰性东西,最关心的是实现该场景的技术难点,它不必是bug free的。 4.5 “技术研究阶段”的“研究结果宣讲” 这是非常重要的一个环节,每个人,或者每个研究任务都要有一个代表,讲解自己的“研究成果”,项目组开发团队都要参加。 这种最佳实践行之有效,你也可以在此基础上衍生自己的相关手段 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2006-10-16
很好的想法。
不过对于技术“新手”甚至于“中手”来讲,是没有能力做“技术研究”的, 我以为还是不要参加的好。 |
|
返回顶楼 | |
发表时间:2006-10-16
rtdb 写道 很好的想法。
不过对于技术“新手”甚至于“中手”来讲,是没有能力做“技术研究”的, 我以为还是不要参加的好。 有新人更是必须要参加“技术研究”,因为新手身上的技术不确定因素和风险更大,以老带新就行了,呵呵 |
|
返回顶楼 | |
发表时间:2006-10-16
我的客户公司的技术总监, 最讨厌"研究"这个词, 我现在都用别的词来描述. :-)
|
|
返回顶楼 | |
发表时间:2006-10-16
确实,项目开发的前期,必须要降低构架风险.构架师这时,显得格外重要.
|
|
返回顶楼 | |
发表时间:2006-10-17
有人带的话效果会好很多
|
|
返回顶楼 | |
发表时间:2006-10-17
感觉和XP中的探针试验有异曲同工之处,或许称之为“技术原型”更贴切。
快速搭建一个不依赖于业务、但是可以实现所需业务的系统框架,确定技术关键点,从而找出可能的技术风险,的确是提高项目成功率的好方法。 |
|
返回顶楼 | |
发表时间:2006-10-17
引用 可以和需求分析并行,最好开发环境、平台等已经选定。
对一个项目的技术研究,是不是在项目的开始,进行平台和技术的选型,这个时候需要对各个技术进行比较,权衡,考察各个技术实现项目需求的效果,这个时候也是应该需要对技术进行研究的吧。 因为我感觉在选择具体实现技术时,一个项目组可能在宏观上对某些技术有一些了解,觉得适合该项目,但是对更具体一点的需求,可能发现实现起来并非所想的那样简单,而某候选技术对这个的实现则更方便一些,不知道各位有没有这种感觉。 所以我觉得在选择平台,技术时也需要进行技术研究。 在项目的开发过程中,我觉得需要有一些人专门来负责整个项目的技术难点,这样的话才能很好的把握项目的进展。这是我的一些想法。 |
|
返回顶楼 | |
发表时间:2006-10-17
不错,以前在公司的时候,就是负责这部分的工作。
我觉得做这个工作有下面几个好处; 1,减少技术风险。 很多时候,如果在项目前期加上这样一个过程的话,能够更全面把握项目中技术风险,而且会更加有把握。 2,为项目引入更合适的技术,还可以带动项目组内部的技术交流的习惯和氛围。 研究出来新的东西,可以做成文档和PPT,每周和项目组成员交流,让大家共同学习进步。 我在上个公司的时候,在空闲期间,会把整个team分成几个小组,然后每个小组去研究一个小的方向(当然大方向要限定,要不太泛了),然后每个星期由每个小组来给大家讲解研究的结果,然后大家来讨论,这种情况下学习的速度是最快的。很喜欢这种方式。 3,让技术人员会更有工作热情。 不知道大家怎么认为,我觉得一个技术人员,肯定是热衷于学习新技术,研究技术的,如果公司内部,或者是项目组内有这么一个机会和氛围,肯定大家都会有工作热情。 4,嘿嘿,更能吹。。 通过这个阶段,肯定会对一些新技术更了解、熟悉、深入。以后写标书的时候可有大大滴用处。 泛泛而谈,可能有点偏离主题,不过中心的思想还是一致的:) |
|
返回顶楼 | |
发表时间:2006-10-17
wainwen 写道 感觉和XP中的探针试验有异曲同工之处,或许称之为“技术原型”更贴切。
快速搭建一个不依赖于业务、但是可以实现所需业务的系统框架,确定技术关键点,从而找出可能的技术风险,的确是提高项目成功率的好方法。 这是可以的。主帖并非提供一个“普适”的方法论,作为一种最佳实践,是可以根据不同情况灵活运用的,完全可以衍生。 名称是一个代号,不同的名称可能代表应用的侧重点有所不同。对照主帖的原意,“技术原型”这个名称感觉对“已有技术的锤炼、优化”有所忽略。并且在这个阶段目标和任务很具体,在涉及的技术点上要相当深入,“原型”感觉有些泛泛了。 |
|
返回顶楼 | |