??xml version="1.0" encoding="utf-8" standalone="yes"?>
2、数据库的频J移?校验非常ȝ?
我的解决Ҏ(gu)Q?
对于上面两个问题Q我自己惛_的解x法是Q?
1、徏立持l集成机Ӟ~写环境部v脚本和文档,采用q两U方法可保证从开发环境到正式环境的部|是非常单的Q?
~写自动验收试脚本Q可以基于Seleniumq行~写Q这hơ在升版本的时候就不需要再人工的进行回归测试了Q这里面的问题是如何在测试完毕完毕后清除q些试数据Q因些测试数据是不能和正式数据共存的?
2、徏立数据库升UL机制Q每ơ升U时做增量的升Q不q这需要徏立在对原库徏立版本记录,q个Ҏ(gu)对于我们的项目而言不太可行Q?
W二U方案就只能每次q行全面的重新移植了Q但q个带来的一个巨大问题就是存储过E的重复修改Q目前我q没惛_什么解x法,而且Q?
至于如何校验数据库移植是否成功,我觉得可以徏立数据库UL校验的CheckpointQ除了保证数据库l构、数据量{的 阅读全文
]]>
java语言的优势到底在哪?我觉得目前来说java最大的优势仍然是它良好的开源氛_(d)而这个氛围能够保证java在技术领域一直保持业界的领先CQ但软g是面向服务的Q这个思想大家都接受的Q^_^Q不能L想着从技术上降低开发的隑ֺQ而忽略对于用戯(g)言很重要的易用性这点,易用性其实很多时候除了交互还体现在功能上Q这些功能往往是需要有_的经验积累才能Ş成出来的Q而java界的pȝ往往是看h功能强大Q而那些功能其实很多未必是用户所惌的,再加上功能强大往往带来的另外一个弊端就是系l过于灵z,没法用,如何领先的优势转化为真实的东西才是最为关键的....
"做到以用h待的操作方式的系l才是好pȝ"Q呵呵,H然觉得引导用户交互?fn)惯的系l才是真正有潜力的系l,^_^Q让用户L了习(fn)惯的pȝ是一U很可怕的pȝQ典型的莫过于windows、office
一. 概述
本文主要对于软gq程的整体规范进行较为完整的描述Q来源于个h的项目经验、所?/SPAN>team使用的Y件过E以?qing)个人的一些想法ȝ而成?/SPAN>
文章按照寚w目中采用的Y件过E进行描qͼ之后对保证整个Y件过E有效执行的工具、制度等q行描述?/SPAN>
本文意ƈ不在标明q个软gq程是多么的优秀Q关键是要找到适合自己团队的Y件过E,没有最优秀的,只有最合适的?/SPAN>
? 软gq程
此Y件过E是Ҏ(gu)Team以及(qing)XP制定的,囄如下Q?IMG height=437 alt="Triones产品pd软gq程 1.0.jpg" src="http://m.tkk7.com/images/blogjava_net/bluedavy/Triones产品pd软gq程%201.0.jpg" width=641 border=0>
2.1. 里程计划制?/SPAN>
控制在一个月范围内,每个里程应有突出性进展的部分Q里E碑版本的发布具有很强的意义Q每个里E碑版本在功能或非功能性方面应有明的Ҏ(gu)?/SPAN>
在每个里E碑l束时发布里E碑版本q同时给予项目组一定的休息旉?/SPAN>
2.2. q代计划制定
控制在一至两周范围内Q每个P代周期结束后对客户发布P代版本?/SPAN>
2.3. q代q程
2.3.1. 需求分?/SPAN>
在P代的需求分析中主要为对划定在此q代阶段的需求进行详l的分析Q生出用户故事?/SPAN>
2.3.2. 设计
设计主要通过对用h事进?/SPAN>OOAD产生出符合此用户故事的领域设计,以此建立的领域模型结合架构构成完成用h事的设计Q?/SPAN>CRC CardQ最后进行情景测?/SPAN>(Scene Test)?/SPAN>
设计旉要遵循的三个原则Q?/SPAN>
l Domain Model驱动
?/SPAN>Domain Model作ؓ(f)驱动q行设计Q通过对用h事的OOAD产生用户故事?/SPAN>Domain ModelQ基于此Ҏ(gu)架构完成整个用户故事的设计?/SPAN>
l Simple
单够用,q个是最为难掌握的,说的直白点就是先采用能够惛_的一个最单的设计d现功能,至于q个设计是不是那么的合理先不要太多的ȝ?x),在完成了功能后可以不断的对其q行重构Q其实其原理是?/SPAN>一步一个台Ӟ直至云霄Q而不是一步登?/SPAN>?/SPAN>Q每个团队的不同仅在于这一个台阶能q多高而已?/SPAN>
l 集体参与
q代q程的设计由目l共同参与,目l成员可随意的发表各自对于系l实现的设计的想法?/SPAN>
2.3.3. 开?/SPAN>
开发过E中涉及(qing)的有Q?/SPAN>
l ~码规范
~码规范需在项目开始时卛_定,q个需要根据每个公总?qing)团队的情况来决定,?/SPAN>Java~码规范中通常要涉?qing)的有类文g规范(主要是文件的版权、文件格式等)、命名规?/SPAN>(包名、类名、方法名、变量名{?/SPAN>)、注释规范?/SPAN>
l TDD
按照先编写单元测试后q行代码~写的原则,在单元测试中主要需要对代码的逻辑、性能以及(qing)边缘q行试?/SPAN>
l PP
双h~程Q在q行代码~写时必MZ赯行,一人操作键盘,一人旁边观看,同时q行思考?/SPAN>
l Code Review规范
代码复查规范需要按照各个公总?qing)代码规范来q行制定?/SPAN>
2.3.4. 重构
在开发结束后需要考虑代码的重构,主要?/SPAN>OO的各原则以及(qing)设计原则来进行提升,复用性、性能{都是考虑的因素?/SPAN>
重构时可采用IDE提供的重构支持来快速完成,对于设计的重构可以通过设计?x)议来共同讨论,在重构时甚至可考虑推翻原有所有的设计而进行?/SPAN>
2.3.5. 持箋集成
持箋集成采用感应版本控制工具变化而进行的原则Q即有变化提交至版本控制工具时即q行持箋集成Q在持箋集成p|或成功的情况下均发送邮仉知相关人员Q项目组所有h员均可通过|站查看持箋集成的情c(din)?/SPAN>
持箋集成中主要需要进行的工作是编译所有源码、运行单元测试、按照系l手动部|方式自动完成部|工作、运行功能测试、发布测试报告ƈ通知相关人等?/SPAN>
持箋集成的原则ؓ(f)谁造成p|谁负责?/SPAN>
? d规范
3.1. d分配
在对用户故事完成设计时即可进行Q务的分配Q每个Q务拆分到1?天的范围内,对于难以估计的Q务先q行spike之后再行分配Q?/SPAN>spike的时间限制在1周以内?/SPAN>
由项目组成员自行挑选Q务?/SPAN>
3.2. d完成
在完成Q务的q程中成员需q行d完成旉的跟t,原则为在开始Q务时填写d开始时_(d)在停止编写Q务的时候填写时间点Q在d完成时勾选完成Q务?/SPAN>
此时间也作为将来分配Q务时旉的估计,以得对于Q务的完成旉的估计能够越来越_?/SPAN>
3.3. d跟踪
d跟踪通过d跟踪工具来完成,主要是Q务完成的旉、Q务统计等?/SPAN>
? 工具
涉及(qing)的工具主要有Q?/SPAN>
l d跟踪工具
l 版本控制工具
l 持箋集成工具
l Bug跟踪工具
l 开发工?/SPAN>
? 制度
5.1. 早会(x)
早会(x)旉大概?/SPAN>10---15分钟Q主要是Ҏ(gu)日Q务的回顾、难点的提出、今日的计划以及(qing)partner的挑选?/SPAN>
5.2. 发布?x)?/SPAN>
发布?x)议为里E碑计划的宣布,以ə目l成员能够明里E碑的目标以?qing)时间点Q同时也听取目l成员的意见?/SPAN>
5.3. q代?x)?/SPAN>
q代?x)议为每个P代周期前q行召开Q以佉K目组成员明白q代目标以及(qing)旉点,同时听取目l成员的意见?/SPAN>
5.4. 设计?x)?/SPAN>
设计?x)议在每个P代周期开始的时候进行召开Q以认q代中需求的设计实现、Q务分配等?/SPAN>
5.5. 目周报
目于每周五下班时提交项目周报,主要是向客户、公司相关h员、项目组通报目的进展情c(din)下一步工作计划?/SPAN>
5.6. 目成员U分制度
目成员U分作ؓ(f)寚w目组成员的考核以及(qing)奖金分配的依据?/SPAN>
目成员U分主要从Q务的完成旉、质量、Q务过E中表现出的团队合作、责d、态度{进行评P对表现特别出色或不合人意的进行适当的奖惩?/SPAN>
目成员U分制度作ؓ(f)目成员工作评h(hun)以及(qing)目奖金分配的唯一依据?/SPAN>
U分采用如下Ҏ(gu)q行考核Q以目d核点,Zd的技术难度、时间紧急性来作ؓ(f)d的客观分敎ͼ对于d承担人则l合客观分数q行d完成的时间、质量、在完成d中表现出的责d、造成日构建的p|ơ数作ؓ(f)评估依据Q表格如下所C:(x)
d?/SPAN> | |
技术难?/SPAN> |
分ؓ(f)三档分数Q?/SPAN>1~~5?/SPAN>5~~10?/SPAN>10~~15 1~~5Q技术难度低 5~~10Q技术难度中{?/SPAN> 10~~15Q技术难度高、需要预研或业务复杂度高 |
旉紧急?/SPAN> |
分ؓ(f)三档分数Q?/SPAN>1~~5?/SPAN>5~~10?/SPAN>10~~15 1~~5Q时间充?/SPAN> 5~~10Q时间适当 10~~15Q时间紧?/SPAN> |
d按时完成 |
按时完成l予5分,提前完成l予10分,推迟完成按天数计,每推q一天扣1?/SPAN> |
d完成质量 |
分ؓ(f)三档分数Q?/SPAN>1~~5?/SPAN>5~~10?/SPAN>10~~15 1~~5Q勉强符?/SPAN> 5~~10Q质量中{?/SPAN> 10~~15Q优U的代?/SPAN> 质量考核要点Q?/SPAN> 是否遵@代码规范?/SPAN>TDD、功能的完成、代码的闭?/SPAN> |
责Q?/SPAN> |
分ؓ(f)三档分数Q?/SPAN>1~~5?/SPAN>5~~10?/SPAN>10~~15 1~~5Q表现尚?/SPAN> 5~~10Q表C{?/SPAN> 10~~15Q体现出了充的责Q?/SPAN> 责Q心考核依据Q?/SPAN> d完成q程中的d性、问题出现时的及(qing)时沟通、压力的承受能力 |
造成日构建失败次?/SPAN> |
p|一ơ扣1?/SPAN> |
产品q程之品规划篇
本文针对产品q程中的产品规划q程q行描述Q说明此q程的要炏V注意事等?/SPAN>
一. 概述
M事情在开展之前往往都有一个规划,规划又分为长期规划、中期规划和短期规划Q在规划中制定了在当前阶D需要达到的一个目标、基本的工作思\以及(qing)工作计划Q对于事情的利开展具有方向性的指导意义?/SPAN>
产品规划作ؓ(f)产品q程的第一个正式的q程Q此q程对于产品的发展方向、发展过E等h指导性的意义Q品规划所做的是一个长期的规划Q所以在制定的时候需要考虑多方面的因素?/SPAN>
? 要点
产品规划作ؓ(f)产品发展方向、发展过E等的指导性文Ӟ产品的v因、品的定位、品的蓝图规划、版本规划、里E碑规划、市场同cM品的Ҏ(gu)、推q方式是其要炏V?/SPAN>
2.1. 产品的v?/SPAN>
此部分中阐明对于产品的构思的来源Q品的起因通常来源于两U,一是公叔R目的U篏Q二是市场潜力的挖掘?/SPAN>
对于公司目的积累的起因则需要阐明历史项目的l验q说明ؓ(f)什么可发展成ؓ(f)产品?/SPAN>
对于市场潜力的挖掘方面则需说明市场潜力体现在了哪些地方?/SPAN>
2.2. 产品的定?/SPAN>
产品的定位至关重要,在一开始有个明的定位能帮助品按照一定的方向q行Q而不至于偏离方向或(f)时摸索方向,虽然在品的后期发展中适时调整方向也是必须的,但至在一开始的时候树(wi)立一个定位不至于在说赯个品的时候还说不出它的一个适用方向?/SPAN>
2.3. 产品的蓝图规?/SPAN>
产品的蓝图规划则Z品按照未来发展方向制定的一份发展蓝图计划,在蓝图中需要有效的描述产品的未来,臛_要让得这个品的来实是非常的光明Q如果连蓝图都不能给别h信心的话Q那q个产品是否要做真的需要仔l商酌?/SPAN>
产品的蓝图规划中甚至可以举些吸引人的场景Q让得品确实非常的实用?/SPAN>
产品的蓝图规划中q需要有对于产品优点的一些突出描qͼq些描述也就成ؓ(f)产品来的卖点,也是开发过E中首先需要把握的部分?/SPAN>
2.4. 版本规划
产品往往是一个长期战略目标,虽然可能已经惛_了很多的可做的有前途的部分Q但不可能划分在一个时期内全部做完Q需要按照品的卖点q行重点的攻养I往往来说对于产品的第一个版本在于突Z品的卖点所在,之后的第二个版本在易操作性、友好性等斚wq行加强Q之后的版本也许是更加的H出产品的优ѝ每个版本都需要有非常明确的目标和令h感觉明显的差别,q且在每个版本中都应该有H出的卖炏V?/SPAN>
2.5. 里程规?/SPAN>
产品的里E碑规划是指对于版本规划的分解,毕竟版本规划是一个大的目标,对于版本的里E碑规划主要按照产品的Y件过E制度来q行划分Q里E碑的划分同样需要依照一个重要的思想Q保证每个里E碑的到N是那么的振奋人心?/SPAN>
2.6. 市场同类产品的对?/SPAN>
Ҏ(gu)产品的定位以?qing)目标和市场同类产品q行Ҏ(gu)Q在Ҏ(gu)中最好列Z份关于两者功能的Ҏ(gu)点,分析清楚Ҏ(gu)的优势以?qing)己方的优势Qƈ需要分析对手的潜在走势?/SPAN>
2.7. 推广方式
推广方式则主要针对品的宣传、推qѝ市销{略q行规划Q品是否能够带来实际的利益依靠于此阶段的制定?/SPAN>
? ȝ
产品规划文档作ؓ(f)产品发展q程中的指导性文档,光要性体现在以上的几个要炚w分,产品规划文档臛_重要Q在后期产品发展q程中品的需求文档,产品的理忉|档,产品的发展计划文档,产品的白皮书文档{都需要从此文档中诞生?/SPAN>
软g界经q多q的发展Q一直都朝着一个搭U木的目标,希望软g能够通过对积木的拼凑快速的搭徏出应用Y件或者说产品Q当然和搭积木ƈ不完全相同,一个比喻而已Q如今流行着各种各样的这L(fng)思想Q如Z插g式的、构件式的,Portal中的Portlet式的Q无非都是希望Y件的重用性以?qing)可快速用性得到提升。在q些思想中,Portal的Portlet式以?qing)Eclipse的Plugin机制无非是其中的g者,非常的显|一定程度上来说也是q个推动了之前的面向lg、面向服务的软g思想的推q,也做C以前希望做到的和g一L(fng)E度Q即插即用?/P>
Plugin机制的好处不a而喻Q但Z插g式系l在插g交互的问题上好像一直就没有得到很好的解冻Iq点和搭积木不同,U木之间不需要共享数据等{,^_^Q而Plugin之间则相对不同,Plugin的互盔R讯、共享数据这个是很正常的需求,我们q不能指望Plugin完全独立的实C个部分,q个在少部分的Plugin可以如此Q但l大部分是不行的Q想必大家还记得IoC的一个原则:(x)"don't call me"QPlugin之间的相互通讯也通过IoCcM思想去解冻IQ?Q通过IoC容器注入所依赖的PluginQ?Q?Q?/P>
其实说v来如今有很多插g式的pȝQ这也不是什么新概念Q象media player的插件、Maven的插件等{,太多了,在Plugin的通讯、数据共享方面好像都q需要进步,不知道各位有什么看法?Q?