论文部分内容阅读
【摘 要】许多软件公司的开发人员仅10人左右，开发人员从软件的需求、软件开发、测试、实施、培训、后期维护，一整个流程，都是由开发人员承担，甚至很多项目就一个开发人员负责，在开发过程中，软件的可靠性没有保障、维护费用不断地上升等因素使软件作坊的危机不断地呈现出来。以面向对象技术为手断，以工业化生产方式和管理支撑体系为核心的软件新变革，推进软件开发的构架平台化、组件化、编码自动化、管理工厂化，为小规模软件公司提供了解决方案。以现代软件企业的开发、管理为目标，结合软件工程的出发点，寻找一个适合小规模软件公司开发的软件工程流程是开发人员不断探索、学习的指导方向。
【关键词】小规模软件公司 现代软件工程 软件作坊
一、概述
传统软件工程采用的“生命周期法”，是从时间角度对软件开发和维护的问题进行分解，把开发过程划分成若干个阶段，每个阶段有各自的解决方案，进行逐步实施、管理。立项、需求开发、概要设计、详细设计、编码、单体测试、集成测试、系统测试、最后交付使用。公司应该完全按照如此步骤流程，而我们需要有多少的工作量呢？三四人10个人/月的的项目就是写这样的文档，从项目开始到最后至少需要6个有人/月的时间进行撰写，完全按照CMMI的标准，对于小规模软件公司来说成本花费比较大，我们一直都在寻找一个平衡点，平衡公司的质量与成本。
如何成立一个核心开发小组，小组的如何构成是小规模软件公司急需解决的课题。针对这样的问题提出由业务架构、技术架构、测试兼技术支持、文案兼培训组成核心开发团队，在开发过程当中，每个小组都承担了不可或缺任务，这四个小组协调工作，对提高软件项目的鲁棒性、稳定性、适用性都起到相当大的作用。
二、业务架构
业务架构，就是搞客户需求。开发经理在开发过程中就是业务架构师，对于客户为什么要提这样的需求，客户要根本解决什么问题，这些问题谁来想，谁来想解决的办法？我们不能靠咨询公司来做这些工作，所以工作需要我们用更多的时间去思考这些问题，只有从客户哪里解决需求的问题，后期的开发才有质量的保证，减少需求更改迭代的次数，降低软件的开发成本。
（一）首先找到客户企业的部门组织结构图，把全体部门都纳入需求思考范围内，了解这个项目和各个部门的关系。最后按项目关系紧密程度把客户各个部门排了一张表，每个部门的负责人的名字，联系电话都要到，找到熟悉公司并且健谈的员工问问他们经理是怎么看这个项目的，想要达到什么样的目标。
（二）收集报表：通过客户工作填报的表格，大致了解他们的工作岗位的工作内容。哪些表格是最常用的，挑出影响他们考核的报表，他们最关注哪几个指标，然后我拿着这些报表、指标向客户咨询，这些指标是什么样的数据、是怎么得来的，最好能让他们解释怎么输入的。然后对着每一个单据询问这些表格的使用频率，是每天、每周、每月、每季还是每半年、每年。是每天（周、月、季、半年、年）的期初做、期末做、还是平时做？哪个频率高？高到什么程度？这样，我们就明白了每个人主要真正做哪些事，怎么做，最后怎么考核，哪些事最重要，哪些事每天做，哪些事频率最高。
（三）优化流程：画好组织结构、人员岗位角色说明、业务流程图，通过调研，用红圈标好了业务处理漏洞和矛盾的地方，并且对这些地方都提出了改进建议。把目标使用客户认为最想解决的问题都考虑进流程和业务单据报表中，建议增加什么流程、建议增加什么单据、建议增加什么报表，谁来做，怎么做，谁来监督，怎么考核。
（四）组织部门座谈会。给他们整个部门都讲解了我们梳理过的流程现状，给他们说明漏洞和矛盾、说明我们提出的方案。这样一份优化好的流程就展现出来了。
需求在软件项目开发中的地位越来越重要的时候，如何理清客户的实际需求，理解客户的工作流程，项目已经成功一半了。
三、技术架构
如何保证稳定性？很多人第一反应就是招测试人员，当然小规模公司的领导是不希望养几个专业的测试人员得。就是招到了测试人员软件的稳定性就得到了提高？即使能提高稳定性也不多。如何从代码的质量下足功夫才是保证软件稳定性最佳的方法。
我们在这里提出共通代码开发员，为什么在开发过程中引入共通代码开发员？共通代码开发员的作用是什么呢？我在下面作一个分析。
每个人的技术水平都是参次不齐的，每个人对自己代码的负责认真性也都是不一样的，所以要想提高稳定性，必须专门从队伍中找一个人，作为公共代码开发员。每个产品或项目的开发、需求的修改，必须首先经过他的思考，哪些模块可以做成公共代码、封装成函数，就他来做，其他的程序员只管调用函数，实现客户UI操作和辅助功能。作为公共代码开发员必须具备以下能力：
（一）参与过几个主要项目的开发、实施、支持。这样，他对客户需求有综合、理性的把握。如果队伍中没有这样的人，那么接到客户需求，分析客户需求，作成公共代码，就由开发经理自己或者安排其他开发人员分别来做。
（二）公共代码开发员具有负责认真的工作态度，代码细心严谨考虑周详异常保护做的到位，内存创建释放有头有尾，代码优美，代码可阅读性强，代码重构，代码性能和稳定都高。
（三）公共代码开发人员的技术能力高，知道封装成什么样的函数接口，在灵活性，以后的修改变化性上都做得非常好。
做这样的工作需要找一个技术能力好的，工作认真负责的人专门做这件事，不让他参与各种杂事，他是应该能干好这件事的，而且会越做越好，这就是术有专攻。共通代码开发员掌握着整个开发技术要点，而共通代码开发员在整个开发过程中就是技术架构师。
四、测试兼技术支持
测试人员，一般也兼任服务部门技术支持人员。如果有服务部门解决不了的技术问题，可以转给他。而且测试人员还兼任配置人员，在产品打包、产品安装测试、产品发布、版本分支管理、源代码备份、历史版本归档方面都由他来管理。兼职是有好多好处的。如果他不兼任技术支持，他就不了解客户是怎么使用的，他测试也是瞎测试。如果他不管理产品打包发布，程序员就会自己私自发布版本。可能版本还有问题，为了修补问题，就赶快修改完再打包一个，但版本号却不改变，引起了一个版本号代码不同错误不同，让服务支持起来很莫名其妙。由测试人员控制产品版本发布，能不能发布，就是测试员说了算。测试员感觉质量没有达到，就有权不发布。很多软件作坊，程序员权力很大，一个开发人员从头到尾负责整个项目，项目质量如何，全看这位开发人员自己的素质和责任心了。为了不让项目质量和特定人密切相关，使公司研发保持连贯性水准，必须做到分工专业，互相配合互相牵制。 一般，开发部门也就配1-2名测试人员，根据同时并行的项目和产品开发和开发的强度来定。我们并不生产向国际上的产品那样的质量。我们做行业企业管理软件开发，是在客户质量要求、客户签单额、竞争对手质量水准这三者平衡上做到一个质量的认可。我们无法做到微软那样一比一的开发测试人员比例。开发部门所有的产品和项目，都由这1-2名测试人员负责所有的测试工作，包括编写测试案例，编写测试结果，参与项目的需求测试、设计测试。
对于开发部门的文档方面，如文档的正规化，都由文案来负责。项目经理经常要提交给客户一些文档，而项目经理往往是技术出身，文档工作不是很高，于是文档的正规化、美化、文字校对、空格段落措辞标点符号，都由文案制作。帮助文档，也由文案负责。帮助方面，有版本更新说明帮助、安全配置帮助、系统维护管理帮助、基础数据配置与维护帮助、业务功能操作帮助、软件操作演示视频、产品简介PPT、产品演示版，都由文案来做。为了防止文案不懂产品而写产品帮助，在需求说明书、设计说明书这些文档性的工作上，如果有什么文档体力活之类的工作，也由文案人员来做。文案人员还兼任产品辅助测试，主要是作为一个普通的操作者来测试，在制作演示版的过程中模拟客户流程客户数据来进行操作录入，测试出普通使用中的BUG。一般，一个专业的测试，经常呆在软件的环境中，思维就有一种定势，但实际的用户并不那样操作，但测试人员自身感不到。而文案人员就能充当普通用户来测试。我们招聘文案人员也没有强调会什么软件，文案写的好就OK。他们确实是最普通的用户，他们的困惑和操作手法代表了大量的普通用户。而一个开发部门，文案人员也往往是1-2名，随并行的项目数量和规模来定。
五、文案兼培训
对于培训来说，软件本身的使用简单最为关键。帮助文档写的再详细，相信看的人都不多（只有开发人员才会去钻研那些详细API帮助）。软件易用，培训的工作就轻。
公司开发的很多软件，没有演示版，没有操作视频录像，没有最新版本帮助文件，没有新版本更新说明。就凭培训人员结合着投影仪对着电脑屏幕讲。作了更新，培训人员还仍不清楚哪些功能发生了改变，还照着过去功能讲。客户亲手一操作，发现讲的和看到的不一样就有了疑问。培训人员都脸红，自己都不知道怎么使用，也解释不了。所以培训文档对于培训人员来说也很重要。
好的软件产品，需要有好的文档和培训资料，否则开发部就是开发的再好，也是没人能用的产品。有一个文案人员，写帮助说明，制作操作视频，制作学习版数据库，参与辅助测试。有了这些文案的基础，最熟悉产品的非开发人员就有了两个岗位：测试兼技术支持，那么文案就兼起培训工作（由于是培训人员用自己写的文案做培训，在培训中会有各种提问，会更加增进对文案和产品的理解，能写出更好的文案。而且他不是开发人员，他能站在使用者的角度上来写来讲，而且他属于开发部门，他会给产品开发带来更多更好的产品易用性建议）。
文案的任务就是：每当新版本发布，对照新版本的更新书写变动说明、操作说明书、操作视频、演示版、搞个集中培训。并且可以结合考试的模式，给受训人员考试、打分。但给他们做培训的时候，必须有正规的签到表，正规的培训教材，正规的培训PPT，掌握好一节课的时间，掌握好一节课的重点，掌握好一节课的快慢与难易程度的节奏。下了课还必须让他们填写本课的培训反馈。优秀培训人员完全可以成为优秀的咨询顾问或者培训老师，如果有可能，也会成为优秀的市场人员或销售人员。这是对文案这个岗位的职业发展期许。
六、思考
软件开发人员从各个开发语言的优缺点，设计模式、框架、重构、单元测试，到软件开发过程管理。都想改善软件生产状况。软件开发人员想把产品开发好，把开发过程管理的井井有条，但是都心有余而力不足。由业务架构、技术架构、测试兼技术支持、文案兼培训四个部分组成一个开发项目团队，循序渐进进行开发工作，就能比过去产出更好的软件，软件的质量，软件的进度，软件的竞争力就都上来了，再加上各种管理软件：如项目管理软件、版本管理软件、BUG管理软件、自动测试软件，就水到渠成了。
所以一个项目开发，一名开发部门经理，1-2名开发人员，一名项目经理，一名公共代码开发人员，一名测试，一名文案，也就是5-6人完全符合一个软件作坊的人员数量。有时候团队小了，开发部门经理就是项目经理，公共代码开发人员就是主程，这样，一个开发团队也就是3-4人。但方法照样能用起来。因为我所讲的方法也就是适应于这四套马车的组织架构的。每个人都身兼数职，而且都对自身的提高非常有好处，而不是给他身上堆砌毫不关联的工作内容。每一项职责都是能互相互补的，整体提高他的岗位专业性。
参考文献：
[1]《现代软件工程》，张家浩，中国，机械工业出版社， 2009.1
[2]《走出软件作坊》，阿朱，2008-07-24，http：//blog.csdn.net/david_lv/
【关键词】小规模软件公司 现代软件工程 软件作坊
一、概述
传统软件工程采用的“生命周期法”，是从时间角度对软件开发和维护的问题进行分解，把开发过程划分成若干个阶段，每个阶段有各自的解决方案，进行逐步实施、管理。立项、需求开发、概要设计、详细设计、编码、单体测试、集成测试、系统测试、最后交付使用。公司应该完全按照如此步骤流程，而我们需要有多少的工作量呢？三四人10个人/月的的项目就是写这样的文档，从项目开始到最后至少需要6个有人/月的时间进行撰写，完全按照CMMI的标准，对于小规模软件公司来说成本花费比较大，我们一直都在寻找一个平衡点，平衡公司的质量与成本。
如何成立一个核心开发小组，小组的如何构成是小规模软件公司急需解决的课题。针对这样的问题提出由业务架构、技术架构、测试兼技术支持、文案兼培训组成核心开发团队，在开发过程当中，每个小组都承担了不可或缺任务，这四个小组协调工作，对提高软件项目的鲁棒性、稳定性、适用性都起到相当大的作用。
二、业务架构
业务架构，就是搞客户需求。开发经理在开发过程中就是业务架构师，对于客户为什么要提这样的需求，客户要根本解决什么问题，这些问题谁来想，谁来想解决的办法？我们不能靠咨询公司来做这些工作，所以工作需要我们用更多的时间去思考这些问题，只有从客户哪里解决需求的问题，后期的开发才有质量的保证，减少需求更改迭代的次数，降低软件的开发成本。
（一）首先找到客户企业的部门组织结构图，把全体部门都纳入需求思考范围内，了解这个项目和各个部门的关系。最后按项目关系紧密程度把客户各个部门排了一张表，每个部门的负责人的名字，联系电话都要到，找到熟悉公司并且健谈的员工问问他们经理是怎么看这个项目的，想要达到什么样的目标。
（二）收集报表：通过客户工作填报的表格，大致了解他们的工作岗位的工作内容。哪些表格是最常用的，挑出影响他们考核的报表，他们最关注哪几个指标，然后我拿着这些报表、指标向客户咨询，这些指标是什么样的数据、是怎么得来的，最好能让他们解释怎么输入的。然后对着每一个单据询问这些表格的使用频率，是每天、每周、每月、每季还是每半年、每年。是每天（周、月、季、半年、年）的期初做、期末做、还是平时做？哪个频率高？高到什么程度？这样，我们就明白了每个人主要真正做哪些事，怎么做，最后怎么考核，哪些事最重要，哪些事每天做，哪些事频率最高。
（三）优化流程：画好组织结构、人员岗位角色说明、业务流程图，通过调研，用红圈标好了业务处理漏洞和矛盾的地方，并且对这些地方都提出了改进建议。把目标使用客户认为最想解决的问题都考虑进流程和业务单据报表中，建议增加什么流程、建议增加什么单据、建议增加什么报表，谁来做，怎么做，谁来监督，怎么考核。
（四）组织部门座谈会。给他们整个部门都讲解了我们梳理过的流程现状，给他们说明漏洞和矛盾、说明我们提出的方案。这样一份优化好的流程就展现出来了。
需求在软件项目开发中的地位越来越重要的时候，如何理清客户的实际需求，理解客户的工作流程，项目已经成功一半了。
三、技术架构
如何保证稳定性？很多人第一反应就是招测试人员，当然小规模公司的领导是不希望养几个专业的测试人员得。就是招到了测试人员软件的稳定性就得到了提高？即使能提高稳定性也不多。如何从代码的质量下足功夫才是保证软件稳定性最佳的方法。
我们在这里提出共通代码开发员，为什么在开发过程中引入共通代码开发员？共通代码开发员的作用是什么呢？我在下面作一个分析。
每个人的技术水平都是参次不齐的，每个人对自己代码的负责认真性也都是不一样的，所以要想提高稳定性，必须专门从队伍中找一个人，作为公共代码开发员。每个产品或项目的开发、需求的修改，必须首先经过他的思考，哪些模块可以做成公共代码、封装成函数，就他来做，其他的程序员只管调用函数，实现客户UI操作和辅助功能。作为公共代码开发员必须具备以下能力：
（一）参与过几个主要项目的开发、实施、支持。这样，他对客户需求有综合、理性的把握。如果队伍中没有这样的人，那么接到客户需求，分析客户需求，作成公共代码，就由开发经理自己或者安排其他开发人员分别来做。
（二）公共代码开发员具有负责认真的工作态度，代码细心严谨考虑周详异常保护做的到位，内存创建释放有头有尾，代码优美，代码可阅读性强，代码重构，代码性能和稳定都高。
（三）公共代码开发人员的技术能力高，知道封装成什么样的函数接口，在灵活性，以后的修改变化性上都做得非常好。
做这样的工作需要找一个技术能力好的，工作认真负责的人专门做这件事，不让他参与各种杂事，他是应该能干好这件事的，而且会越做越好，这就是术有专攻。共通代码开发员掌握着整个开发技术要点，而共通代码开发员在整个开发过程中就是技术架构师。
四、测试兼技术支持
测试人员，一般也兼任服务部门技术支持人员。如果有服务部门解决不了的技术问题，可以转给他。而且测试人员还兼任配置人员，在产品打包、产品安装测试、产品发布、版本分支管理、源代码备份、历史版本归档方面都由他来管理。兼职是有好多好处的。如果他不兼任技术支持，他就不了解客户是怎么使用的，他测试也是瞎测试。如果他不管理产品打包发布，程序员就会自己私自发布版本。可能版本还有问题，为了修补问题，就赶快修改完再打包一个，但版本号却不改变，引起了一个版本号代码不同错误不同，让服务支持起来很莫名其妙。由测试人员控制产品版本发布，能不能发布，就是测试员说了算。测试员感觉质量没有达到，就有权不发布。很多软件作坊，程序员权力很大，一个开发人员从头到尾负责整个项目，项目质量如何，全看这位开发人员自己的素质和责任心了。为了不让项目质量和特定人密切相关，使公司研发保持连贯性水准，必须做到分工专业，互相配合互相牵制。 一般，开发部门也就配1-2名测试人员，根据同时并行的项目和产品开发和开发的强度来定。我们并不生产向国际上的产品那样的质量。我们做行业企业管理软件开发，是在客户质量要求、客户签单额、竞争对手质量水准这三者平衡上做到一个质量的认可。我们无法做到微软那样一比一的开发测试人员比例。开发部门所有的产品和项目，都由这1-2名测试人员负责所有的测试工作，包括编写测试案例，编写测试结果，参与项目的需求测试、设计测试。
对于开发部门的文档方面，如文档的正规化，都由文案来负责。项目经理经常要提交给客户一些文档，而项目经理往往是技术出身，文档工作不是很高，于是文档的正规化、美化、文字校对、空格段落措辞标点符号，都由文案制作。帮助文档，也由文案负责。帮助方面，有版本更新说明帮助、安全配置帮助、系统维护管理帮助、基础数据配置与维护帮助、业务功能操作帮助、软件操作演示视频、产品简介PPT、产品演示版，都由文案来做。为了防止文案不懂产品而写产品帮助，在需求说明书、设计说明书这些文档性的工作上，如果有什么文档体力活之类的工作，也由文案人员来做。文案人员还兼任产品辅助测试，主要是作为一个普通的操作者来测试，在制作演示版的过程中模拟客户流程客户数据来进行操作录入，测试出普通使用中的BUG。一般，一个专业的测试，经常呆在软件的环境中，思维就有一种定势，但实际的用户并不那样操作，但测试人员自身感不到。而文案人员就能充当普通用户来测试。我们招聘文案人员也没有强调会什么软件，文案写的好就OK。他们确实是最普通的用户，他们的困惑和操作手法代表了大量的普通用户。而一个开发部门，文案人员也往往是1-2名，随并行的项目数量和规模来定。
五、文案兼培训
对于培训来说，软件本身的使用简单最为关键。帮助文档写的再详细，相信看的人都不多（只有开发人员才会去钻研那些详细API帮助）。软件易用，培训的工作就轻。
公司开发的很多软件，没有演示版，没有操作视频录像，没有最新版本帮助文件，没有新版本更新说明。就凭培训人员结合着投影仪对着电脑屏幕讲。作了更新，培训人员还仍不清楚哪些功能发生了改变，还照着过去功能讲。客户亲手一操作，发现讲的和看到的不一样就有了疑问。培训人员都脸红，自己都不知道怎么使用，也解释不了。所以培训文档对于培训人员来说也很重要。
好的软件产品，需要有好的文档和培训资料，否则开发部就是开发的再好，也是没人能用的产品。有一个文案人员，写帮助说明，制作操作视频，制作学习版数据库，参与辅助测试。有了这些文案的基础，最熟悉产品的非开发人员就有了两个岗位：测试兼技术支持，那么文案就兼起培训工作（由于是培训人员用自己写的文案做培训，在培训中会有各种提问，会更加增进对文案和产品的理解，能写出更好的文案。而且他不是开发人员，他能站在使用者的角度上来写来讲，而且他属于开发部门，他会给产品开发带来更多更好的产品易用性建议）。
文案的任务就是：每当新版本发布，对照新版本的更新书写变动说明、操作说明书、操作视频、演示版、搞个集中培训。并且可以结合考试的模式，给受训人员考试、打分。但给他们做培训的时候，必须有正规的签到表，正规的培训教材，正规的培训PPT，掌握好一节课的时间，掌握好一节课的重点，掌握好一节课的快慢与难易程度的节奏。下了课还必须让他们填写本课的培训反馈。优秀培训人员完全可以成为优秀的咨询顾问或者培训老师，如果有可能，也会成为优秀的市场人员或销售人员。这是对文案这个岗位的职业发展期许。
六、思考
软件开发人员从各个开发语言的优缺点，设计模式、框架、重构、单元测试，到软件开发过程管理。都想改善软件生产状况。软件开发人员想把产品开发好，把开发过程管理的井井有条，但是都心有余而力不足。由业务架构、技术架构、测试兼技术支持、文案兼培训四个部分组成一个开发项目团队，循序渐进进行开发工作，就能比过去产出更好的软件，软件的质量，软件的进度，软件的竞争力就都上来了，再加上各种管理软件：如项目管理软件、版本管理软件、BUG管理软件、自动测试软件，就水到渠成了。
所以一个项目开发，一名开发部门经理，1-2名开发人员，一名项目经理，一名公共代码开发人员，一名测试，一名文案，也就是5-6人完全符合一个软件作坊的人员数量。有时候团队小了，开发部门经理就是项目经理，公共代码开发人员就是主程，这样，一个开发团队也就是3-4人。但方法照样能用起来。因为我所讲的方法也就是适应于这四套马车的组织架构的。每个人都身兼数职，而且都对自身的提高非常有好处，而不是给他身上堆砌毫不关联的工作内容。每一项职责都是能互相互补的，整体提高他的岗位专业性。
参考文献：
[1]《现代软件工程》，张家浩，中国，机械工业出版社， 2009.1
[2]《走出软件作坊》，阿朱，2008-07-24，http：//blog.csdn.net/david_lv/