杰思敏软件开发流程Word文档下载推荐.docx
《杰思敏软件开发流程Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《杰思敏软件开发流程Word文档下载推荐.docx（11页珍藏版）》请在冰豆网上搜索。
10、没处理完2~5个BUG，需要保存一次项目。
11、解决完所有的BUG后，才算做是完成一个阶段的工作，其成果纳入受控库管理。
在此基础上再开展下一个阶段的开发工作。
12、每个阶段需要做一次测评和总结，并纳入绩效考核和能力考核（有系统自动生成），同时修订下个阶段需要完成的需求。
1.2老项目完善
老项目，一般都有原项目的开发人员担任产品经理，主线负责人。
任务不重时，指导新人开发，新人负责辅线。
主线负责人非常重要，主线负责人的能力将直接导致项目最后的质量。
主线负责人的权力和责任：
1、项目开发人员的分配和调整。
2、技术决策权。
公司主要是审查和批准重大技术措施和技术方案，以防决策失误，造成重大损失。
3、申请协作权。
项目发展出现不能解决的问题的时候，可以向上级申请协作。
4、考核成员权。
考核项目组成员。
5、测试组只考核主线负责人。
在一个产品发布并使用之后，其中肯定有许多地方不如意和值得改进的地方。
老项目的完善开发动力在于以下几点：
1、客户在使用的过程中会发现一些问题，提出更高的需求；
2、市场也在发生变化，竞争对手有；
3、管理层可能从市场的角度来提出新的特性；
4、新的技术不断地产生。
5、开发人员本身提出某些改进要求。
这些因素推动着我们的产品不断地向前发展，使它的版本不停地往上增长。
这些发展的需求不是一下子提出来的，因此需要按轻重缓急，安排工作：
1、紧急程度1：
在客户使用的过程中发现某些BUG，导致不能正常使用，加急处理，加班加点，也要在48小时内解决。
结果先纳入产品库管理，处理完后，纳入受控库。
2、紧急程度2：
在客户使用的过程中发现某些不如意、不方便的地方，提出建设性的改进意见，1~2周内解决。
结果先纳入产品库管理，处理完后，再纳入受控库。
3、紧急程度3：
需要补充、完善的功能，1~2月内解决。
结果纳入受控库管理。
4、紧急程度4：
管理层可能从市场的角度来提出新的特性，依据任务饱和度，和紧急程度，进行安排，3~6月内解决。
5、紧急程度5：
新的技术应用，对产品有帮助，带来质的飞跃，半年~1年内解决。
6、紧急程度6：
开发人员本身也可提出某些要求来纳入新版本开发的计划中，如要求对某部分代码进行重构以使其结构更清晰更容易维护，执行效率更高。
在任务不紧急时，进行重构优化。
依据紧急程度，将BUG和需求划分为八级，另外两级是：
7、紧急程度7：
优化项目，优化后的效果不明确或提升幅度不大，工作量却很大。
8、紧急程度8：
可做、可不做的。
需求BUG登记时，需要标注需求BUG来源和紧急程度，同时，明确需要完成的最后时间期限。
主线负责人应分解需求BUG，并预估时间，其中主要包括写文档的时间、开发时间和单元测试的时间，一般要求精确到30分钟~2小时。
当开发时间超过2个工作日，主线负责人应将任务和预估时间发送给管理层，由管理层对此任务及进度进行评估审核。
若预估出来的时间同需要完成的最后时间期限有较大冲突，而且此功能是本版本中必须得做的，则需要多方协调，整合资源，重新预估时间，加快开发速度来达到这个要求或与用户沟通推出发布。
虽然这个开发进度时间是一个大概的估计时间，但需要尽力按照这个开发进度来执行。
依据处理状态，需求和BUG的状态有：
1.New:
新创建的
2.Fix:
程序员完成
3.Close:
解决了的
4.Reopen:
被重新打开
5.Defer：
推迟解决，以后再解决，等其它解决后再做处理
6.Cancel:
取消
1.3协同平台改进
协同平台是一个老项目，主要工作围绕既定目标来开展。
1.4基于平台的构建开发
依据客户需求开发构建。
开发过程与步骤与“1.1新项目开发”基本相同。
1.5项目协同
每个星期五下午，需要有一个StatusMeeting。
在此会议上，根据项目进度来review我们每个人手上的工作，看工作是否按照计划在走，是否有人延后了，是否影响其他人的工作了。
在此会议上每个人都要报告自己的进度，同时还要报告上个星期做了什么，正在做什么，以及下个星期打算做什么、风险有那些、需要那些人帮助自己？
通过StatusMeeting，会让你觉得有人在监督你，无形之中迫使你不断地督促自己不要使任务延后，如果有延后的迹象也要尽早发现，即时赶上。
1.6项目计划变更
若某些经过努力不能赶上，那也没有办法，只能修改原先的进度表，因为那是我们的估计与现实发生了偏差，我们必须使我们的进度表符合实际情况。
当然这种情况应当尽力避免，尤其在项目后期遇到新的需求，不管怎样，都应重新规划进度，而不是仍旧依照原先的进度去执行，因为老的进度已不能反映现实的情况，要与时俱进，不被条条框框锁住。
要注意许多项目发生最后的20%的工作量会占据整个项目的80%甚至更多，项目一直拖延，因此，在项目计划制定时，需要全面考虑，留有一定余地。
2.开发文档
在项目进度安排中我们已经把写文档的时间也规划进去了，这里虽然是写文档，其实是设计程序，整理一下思路与架构，磨刀不误砍柴工，这样在实际写代码时会流畅很多，节省时间，因此可以说真正有思想性的东西都在写文档这段时间内完成了。
当然我们这里的文档格式不像ISO那样规定了条条框框，文档格式相对自由，基本上能随意发挥，但对于几个主要点一般来说是需要说明的。
要求写的文档能让他人比较容易地看明白，能把问题讲清楚，能反映你的设计思想。
文档的数量也不多，开发文档有三类：
1、FunctionSpec
需要写明的是本模块完成的任务，解决什么问题，有什么作用，为什么要这些功能，此外我们还会添加进适用范围，有什么不足，注意点是什么，还有哪些地方在以后可以进行改进。
FunctionSpec中不涉及到任何非常详细的算法。
文档不光给开发人员看，还让项目其他成员以及后来的新人能根据此文档来了解此模块的大致功能。
同时也会给文档编写者看，他们会根据这些FunctionSpec整理出一份用户手册、产品介绍PPT、培训教案，告诉用户此版本中新增了哪些功能，各功能模块有什么作用，如何使用等信息。
在我们的开发过程中FunctionSpec是很重要的文档，此文档完成后会抽出一段时间同相关人员一起review这个文档，让测试人员了解设计者的意图，同时熟悉新的功能模块，为接下来的测试作准备。
如果其中有误解或不明之处，大家会提出来探讨并由开发者修正。
2、DesignDocument。
主要描述实现此模块所涉及到的主要算法、数据结构、类的层次结构及调用关系。
这个文档的阅读者主要是开发人员，包括任何想了解详细实现代码的人，帮助人们理解代码。
在某些功能模块比较简单的程序中，此文档所描述的信息会比较少甚至不写。
此文档不像FunctionSpec，要在开始写代码前就编写完成，它可以随着代码编写的进行而增加，但基本上遵循文档先行原则，也就是要增加新的代码或修改代码前若有涉及到文档部分的应先修改文档，然后再修改代码。
3、需求和BUG登记
依据FunctionSpec和DesignDocument，在系统中按编制计划列出需求并细化。
然后，依据次序编写代码，实现FunctionSpec。
一般，每天需要先将需求细化到10分钟~2小时，安排好工作次序。
每天最后一次提交可运行的代码后，应认真整理第二天要完成的需求与BUG。
每一次保存项目时，需要关联已处理好的需求和BUG。
3.
编写代码
我们用C#语言进行开发，直接采用VisualStudio开发工具。
关于代码风格，我们用VS中自动的代码格式编排，类与类之间间隔2行，方法与方法之间间隔2行。
写代码时不必提供详细的注释及说明，以最快的速度编码。
不在注释及说明上花费时间。
程序员的时间是宝贵的，因为主要的算法、调用已在需求BUG中描述了。
每次保存项目时，只要关联上需求BUG就行了。
利用JSMSoft，可以将它们的说明放入锚点，就能知道这个类或函数的功能以及主要算法的实现原理。
而不用将说明放入代码中。
代码说明，一般有测试人员和新员工编写。
程序员不写注释，但需要写前期规划，需求和BUG的细化工作由程序员负责。
4.代码管理
我们采用自己开发的JSMSoft进行版本控制，其中存放了此产品的所有源代码、库文件、文档及release时的安装程序，各个部分存放在不同的目录中。
每天早上要求开发人员从JSMSoft中下载最新的源代码，然后进行编译并开始一天的工作。
在下班之前，理论上要求员工checkin所有当天修改的代码，在checkin之前要保证编译是能通过的，并能运行的。
5.测试
按B/S和C/S项目，测试分两种：
每日自动化测试，和项目提交测试。
2
3
4
5
5.1每日自动化测试（B/S）
对协同平台做升级开发时，有时我们编写的代码涉及到多个文件，而且此改动是比较复杂需要花费多天的工作量，如果现在checkin进去可能会导致BVT（BuildVerifyTest）测试通不过，因为有些代码没有完全完成，而之前的代码能使BVT测试通过，而且这些代码基本上不会涉及到他人，在这种情况下可以不checkin进去，直到全部代码完成能提交BVT测试时再一起checkin进去。
每天我们都会做dailybuild，一般是在凌晨4点进行，那时有个程序会自动从JSMSoft中拉下最新的代码并进行编译。
如果想要把修改的代码进入到这个build中去那就需要在凌晨4点之前把相应的代码checkin进去。
若有人checkin进去的代码导致编译通不过则会在本步骤中被发现。
他将被扣分并通报。
当编译完成之后，由自动化测试程序进行测试，如果发现了什么BUG就能自动反映出来，即时通知测试人员处理。
测试部门首先会依据程序员前一天提交程序所解决的BUG和功能点，先手动测试一遍，若有问题，直接登记到JSMSoft的需求BUG中，然后，编制自动化测试程序，对这些代码进行自动化测试。
主要平台和组建更新，自动化测试就会进行，看新加入的代码或修改是否会影响系统的基本功能，便于及早发现错误。
5.2项目提交测试
对C/S软件开发，在程序员完成了FunctionSpec后，提交测试、审核、批准、归档流程。
测试部门应提前开始测试规划，确定需要测试哪些方面，如何测试及进度安排。
测试人员需要写许多测试代码，有些测试代码需要集成进BVT测试，有些可能需要进行单独的测试，目的都是为了使产品符合要求，找出问题所在，并即时通知程序员改正。
产品功能是否符合了要求，是否能被发布是由测试人员决定的，因此测试人员也比较辛苦，责任重大。
还有一些性能测试、兼容性测试、灾难测试等需要在产品发布前进行。
在完成这些测试之后由测试人员决定本产品是否能release出去了，如果没有什么问题则会给某些关系较好的用户进行β测试，之后再最终release出去。
5.3BUG管理
由于我们每天进行着测试，因此经常有BUG被测试部门发现，一旦发现了新的BUG，就会被添加进JSMSoft需求BUG中。
JSMSoft需求BUG是开发人员和测试人员之间的纽带，开发人员和测试人员通过需求BUG联系着。
每个BUG有其类型、来源和级别，这些代表了重要性及紧急程度，重要且迫切的BUG需要很快fix，在本版本release之前必须fix掉，若真的不能或不重要则由测试人员确定并降低优先级进入到下一个版本中去fix。
测试人员发现一个BUG后在JSMSoft需求BUG中增加一个BUG，同时填入相关信息并即时通知给相应的程序员，程序员收到BUG分析并fix后再提交流程，其中要填上分析的结果以及如何解决的详细说明，有测试人员再测试，直到所有计划中的需求和BUG都被Close。
每星期在StatusMeeting上会进行BUG状况报告，主要由测试人员报告BUG的状况，主要是新增BUG数，Close掉多少，还有多少处于open状态，有多少处于等待verify的状态，据此可以了解开发及测试情况。
在StatusMeeting上我们还会进行BUGReview，BUGReview一般在一个小组内进行，其主要作用是重新明确每个人头上的BUG以及了解每个BUG的状况，如开发人员对这些BUG将作何处理等，以此来了解开发中是否有碰到比较棘手的问题和各类风险。
通过JSMSoft的统计功能，可以展示像股市曲线一样BUG的数量曲线图，一般总体趋势是前期BUG放量攀升，后期震荡下挫，若到了后期新Open的BUG数量一直上升则说明风险在增大，有可能无法控制，也就是说Close了一个BUG导致了多个新的BUG产生，这时，需要考虑人员是否胜任，是否需要好好整理思路，放两天假也许是个好主意。
在量化开发进度中也可以用代码数量的曲线图来粗略的呈现。
在有大量新功能增加时可能代码量的增加会较快，当在处理bug阶段，代码的修改较多，因此代码数量的增幅会降低，而修改量会增加，依据代码量可以分析出开发的状况处于何种阶段。
需要指出的是我们对BUG的定义比较广泛，一些新功能也可以作为BUG被提出，只不过这些BUG级别比较低，让它们进入到下一个版本中去实现。
因此BUG的创建者也可以是技术支持人员、市场人员甚至开发人员本身。
关于开发人员本身，因为他可能会找出一些BUG，有些是其他开发者的，有些可能是此开发者本身的，把这个BUG添加进BUG库中可以帮助开发人员在以后产生新问题时或类似的BUG时有一个借鉴和思路，但此BUG的验证必须要让测试本模块的测试人员来做。
5.4CodeFreeze
当BUG都被修复了，这时离release日期也就不远了，一般是2个星期后就能release产品，这时要对JSMSoft中的代码进行freeze，以保证代码库的稳定性。
Codefreeze阶段一般会把各开发人员的checkin和checkout的权限关闭，若在这时仍有BUG报告上来并经讨论确定是重大的且必须在本版本中Close的，则需要经管理层同意并特殊地授予权限，在修改完成后修改者要把修改了哪些文件，影响了哪些文档等信息上报给各部门如测试、文档编写者等。
在codefreeze阶段，测试部门在紧张地进行着各种测试，得出各种数据，并决定本版本是否可以release了。
6.技术沙龙
计算机知识更新速度非常快，经常有一些新的术语、新的名词、新的思想、新的技术所产生，如过离开此行业几个月后重新回来就会对这些新的事物不解，而我们平时为了自己的项目埋头苦干可能忘了周围的世界发生了什么。
技术沙龙就提供了一个让我们了解新知识和最新发展趋势的机会，让大家把知识共享，共同提高。
技术沙龙一般会在项目不是太忙碌的周末进行，主持人会提前一个星期指定某个人去准备一下某个主题，一般此人可能对某方面比较感兴趣，然后他会花一些时间去了解这方面的情况，写成一个文档如PowerPoint并上传到局域网内，同时通知大家可以先去浏览。
技术沙龙的内容非常广泛，不一定同我们的项目紧密相关，任何新的思想、新的知识（当然一般是限在计算机领域内）都可作为技术沙龙的内容，而在主讲人讲完之后还有一段时间被大家提问，共同对这个话题进行讨论，答疑解惑。
当然技术沙龙也可同我们的项目相关，如研究一下产品技术、产品的架构等。
研究本公司的产品架构可以使大家对本公司的产品有一个全局的概念，从整体上来看自己的产品，顺便整理一下产品的架构使之更加清晰有条理。
平时大家都只注重于自己负责的其中的一小块，在TechTalk中可以跳出自己的小框框来了解全局，同时这也是新员工了解公司核心技术整体框架的好机会。
每个模块的负责人需要阐述此模块的方方面面，让大家来了解并回答问题。
7.CodeReview
当进行工作移交时我们会进行CodeReview，在碰到棘手的BUG时也会进行CodeReview，CodeReview是大家了解其详细实现的一个好机会。
在CodeReview之后会对此代码产生亲切感而不是陌生惧怕感，相信很多人在读他人代码时会有非常痛苦的经历，通过JSMSoft来CodeReview是减少此痛苦感的好药方。
在进行CodeReview前，主讲人会提前发出一个通知告诉相关人员要review哪些代码，这样参与者可以抽出时间提前了解相关代码，对不懂的地方做个笔记以便在CodeReview进行中提出疑问。
在我们碰到比较棘手的BUG没有什么思路或大惑不解时，这时找几个相关人员或对此代码也熟悉的人进行一次CodeReview，这时形式比较随意，大家可以临时提出问题，让主讲人解答，在这个过程中可能听的人并不会非常快地了解其中的详细过程，但是讲的人在这个过程中重新理了一下思路，对所写的代码被迫重新审视了一遍，在其中可能就会发现出解决问题的办法。
在CodeReview时有时代码非常多，但可以一个功能模块一个功能模块地从总体到局部，由浅入深层层递进的方式进行。
一次CodeReview的时间不要太长，但可以分多次进行。
CodeReview中大家会提出问题和建议，集思广益，多个人共同出主意，有些可能一个人没有想到的问题会被大家发现，互相学习，共同进步。
8.沟通与交流
大部分员工的大部分时间是在公司里度过的，因此公司的生活成了大家主要组成部分。
员工之间关系的融洽，交流的畅通显得非常重要，同时大家也不想自己的生活这样枯燥乏味，一直同机器打交道。
沟通无处不在，交流随时发生，有许多关系是在工作之外建立起来的。
软件公司内是很容易产生各种矛盾的，因为这是由你的工作性质所决定的，比如QA或用户会对你的实现不满意，提出各种要求时，我相信你有时会有所抱怨的，无形之中就产生了对立，发展到后来会有抵触心理。
我相信大部分人都会有此感受，这不是你的错，这主要是由我们的工作性质决定的。
如果你的工作是把财富带给对方，则对方会非常欢迎你的到来，把你奉为财神爷来对待，同你的关系会非常融洽友好。
因此我们需要在工作之外来消除这种对立矛盾的关系，建立一种融洽的工作氛围。
我们在平时吃饭的时候饭桌上大家互相聊天沟通。
我们建立了happy邮件列表，其中会发一些幽默笑话之类的邮件，给我们紧张的工作增加点轻松的氛围。
在下班后大家可以组织一下活动，增加了公司的凝聚力。
一个产品发布后组织一下旅游，让绷紧的神经松弛一下，更好地迎接下一个挑战。
9.
售前售后服务
6
7
8
9
公司管理采用双轨制管理模式，#字型管理：
⏹项目经理负责售后服务
⏹专业部负责开发
⏹质量部负责测试、文档、网站、宣传
开发组1开发组2
项目1-----------|-------------------------|---------------\
项目2-----------|-------------------------|--------------->
质量
项目3-----------|-------------------------|---------------/
9.1项目经理
售后服务采用项目经理负责制，项目经理的工作是：
1、基本职责就是确保项目目标的实现，领导项目团队准时、优质地完成全部工作。
2、与客户沟通，了解项目的整体需求。
并与客户保持一定的联系，即时反馈阶段性的成果，和即时更改客户提出的合理需求。
3、制定项目需求和计划文档。
4、跟踪项目的进度，协调项目组成员之间的合作。
5、监督产生项目进展各阶段的文档，并与质量管理员即时沟通，保证文档的完整和规范。
6、开发过程中的需求变更，项目经理需要跟客户了解需求，在无法判断新的需求对项目的整理影响程度的情况下，需同项目组成员商量，最后决定是否接收客户的需求，然后再跟客户协商。
确定要变更需求的情况下，需产生需求变更文档，更改开发计划，通知质量管理员。
7、项目提交测试后，项目经理需了解测试结果，根据测试的bug的严重程度来重新更改开发计划。
8、向上汇报。
向上级汇报项目的进展情况，需求变更等所有项目信息。
9、项目完成的时候需要项目总结，产生项目总结文档。
9.2专业部
专业部下设开发小组，开发组依据实际任务进展，进行组合。
组长工作：
1．每天下午5:
00――6:
00，项目经理召集该项目的相关人员（包括开发人员、美工等）作项目每日总结，内容包括：
（1）了解每个成员的工作进度情况。
（2）了解成员在工作中遇到的困难，并寻找资源解决。
（3）成员之间的配合是否协调一致（比如，需要提交的物件没有按时提交或遗忘等）。
（4）如有需要，根据当前的进展情况调整开发计划。
（5）安排每个成员第二天的工作。
（6）如果考虑到项目当前的进展状态可能会导致项目延期，则组长有权安排项目组加班，以保证工期。
2．如果接收到新的需求，则应该在下午的每日总结会上提出，并分配安排工作。
除非新来的需求特别紧急或影响到项目组当前正在进行的任务，需要召集项目组成员紧急讨论外，否则不应打断小组的当前工作。
如果新的需求是在每天下班后接收的，则项目经理应在第二天早上召集小组成员讨论并安排任务。
升级会员 