如何有效编写软件75条建议.docxVIP

  1. 1、本文档共7页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  5. 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  6. 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  7. 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  8. 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
1.?你们的项目组使用源代码管理工具了么? ?应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的选择是VSS。2.?你们的项目组使用缺陷管理系统了么? ?应该用。ClearQuest太复杂,我的推荐是BugZilla。?3.?你们的测试组还在用Word写测试用例么?? ?不要用Word写测试用例(Test?Case)。应该用一个专门的系统,可以是Test?Manager,也可以是自己开发一个ASP.NET的小网站。主要目的是Track和Browse。4.?你们的项目组有没有建立一个门户网站? ?要有一个门户网站,用来放Contact?Info、Baselined?Schedule、News等等。推荐Sharepoint?Portal?Server?2003来实现,15分钟就搞定。买不起SPS?2003可以用WSS?(Windows?Sharepoint?Service)。?5.?你们的项目组用了你能买到最好的工具么? ?应该用尽量好的工具来工作。比如,应该用VS.NET而不是Notepad来写C#。用Notepad写程序多半只是一种炫耀。但也要考虑到经费,所以说是“你能买到最好的”。?6.?你们的程序员工作在安静的环境里么? ?需要安静环境。这点极端重要,而且要保证每个人的空间大于一定面积。?7.?你们的员工每个人都有一部电话么? ?需要每人一部电话。而且电话最好是带留言功能的。当然,上这么一套带留言电话系统开销不小。不过至少每人一部电话要有,千万别搞得经常有人站起来喊:“某某某电话”。《人件》里面就强烈谴责这种做法。?8.?你们每个人都知道出了问题应该找谁么? ?应该知道。任何一个Feature至少都应该有一个Owner,当然,Owner可以继续Dispatch给其他人。9.?你遇到过有人说“我以为…”么? ?要消灭“我以为”。Never?assume?anything。?10.?你们的项目组中所有的人都坐在一起么? 需要。我反对Virtual?Team,也反对Dev在美国、Test在中国这种开发方式。能坐在一起就最好坐在一起,好处多得不得了。?11.?你们的进度表是否反映最新开发进展情况?? 应该反映。但是,应该用Baseline的方法来管理进度表:维护一份稳定的Schedule,再维护一份最新更改。Baseline的方法也应该用于其它的Spec。Baseline是变更管理里面的一个重要手段。12.?你们的工作量是先由每个人自己估算的么? 应该让每个人自己估算。要从下而上估算工作量,而不是从上往下分派。除非有其他原因,比如政治任务工期固定等。?13.?你们的开发人员从项目一开始就加班么? 不要这样。不要一开始就搞疲劳战。从项目一开始就加班,只能说明项目进度不合理。当然,一些对日软件外包必须天天加班,那属于剥削的范畴。?14.?你们的项目计划中Buffer?Time是加在每个小任务后面的么? 不要。Buffer?Time加在每个小任务后面,很容易轻易的就被消耗掉。Buffer?Time要整段的加在一个Milestone或者checkpoint前面。?15.?值得再多花一些时间,从95%做到100%好值得,非常值得。 尤其当项目后期人困马乏的时候,要坚持。这会给产品带来质的区别。?16.?登记新缺陷时,是否写清了重现步骤? 要。这属于Dev和Test之间的沟通手段。面对面沟通需要,详细填写Repro?Steps也需要。?17.?写新代码前会把已知缺陷解决么? 要。每个人的缺陷不能超过10个或15个,否则必须先解决老的bug才能继续写新代码。?18.?你们对缺陷的轻重缓急有事先的约定么? 必须有定义。Severity要分1、2、3,约定好:蓝屏和Data?Lost算Sev?1,Function?Error算Sev?2,界面上的算Sev?3。但这种约定可以根据产品质量现状适当进行调整。19.?你们对意见不一的缺陷有三国会议么? 必须要有。要有一个明确的决策过程。这类似于CCB?(Change?Control?Board)的概念。?20.?所有的缺陷都是由登记的人最后关闭的么?? Bug应该由Opener关闭。Dev不能私自关闭Bug。?21.?你们的程序员厌恶修改老的代码么? 厌恶是正常的。解决方法是组织Code?Review,单独留出时间来。XP也是一个方法。22.?你们项目组有Team?Morale?Activity么? 每个月都要搞一次,吃饭、唱歌、Outing、打球、开卡丁车等等,一定要有。不要剩这些钱。?23.?你们项目组有自己的Logo么? 要有自己的Logo。至少应该有自己的Codename。?24.?你们的员工有印有公司Logo的T-Shirt么? 要有。能增强

文档评论(0)

jdy261842 + 关注
实名认证
文档贡献者

分享好文档!

1亿VIP精品文档

相关文档