软件管理74条体会自我检查

今天看到了一遍这样的文章，就试着回答一下这些问题，与大家共勉。

有些是同意原作者的观点，基本为本人观点。

 

1 你们的项目组使用源代码管理工具了么？
采用SVN进行源代码管理，同时启用开发，测试两个分支。
 
2 你们的项目组使用缺陷管理系统了么？
使用BugFree管理缺陷和变更
 
3 你们的测试组还在用Word写测试用例么？
采用BugFree对Bug以及测试问题进行管理和交流，阶段性的总结使用Excel进行。
 
4 你们的项目组有没有建立一个门户网站？
项目有专门的论坛进行大篇幅的不同组的交流。但实际效果并不理想。
原因在于他们懒得发帖，更希望直接交流。
 
5 你们的项目组用了你能买到最好的工具么？
能够买到。主要是VS.Net和PL/SQl Developer.其它辅助工具全部用开源工具。
 
6 你们的程序员工作在安静的环境里么？
不，我们采用的是大厅式的开放的开发环境。小空间开发环境，容易使领导和员工脱节，
容易使部门脱节，我希望我的员工能看到别人都在做什么，做的怎么样！这样的效果要好些。
 
7 你们的员工每个人都有一部电话么？
通过RTX进行沟通。这样很容易进行相关人员了解问题的内容。
除了批评外，不要单独沟通。现在项目的规模和复杂度很少说能有独立完成的。
 
8 你们每个人都知道出了问题应该找谁么？
开始时，还是不知道具体的负责人或者具体的制作者是谁。熟悉后基本能找对人，可偶尔还是出现找不对人的情况。。
 
9 你遇到过有人说“我以为…”么？
有时候会遇到，但情况不多。
 
10 你们的项目组中所有的人都坐在一起么？
都在大厅中，但按照组分开（美术，策划，程序，测试）。通过RTX即时通讯。
 
11 你们的进度表是否反映最新开发进展情况？
有及时准确的进度表，但不是每个项目成员都很容易看到。进度表有专门的基线和里程碑的定义。
应该将每周的进度表的更新，贴在开发大厅的显眼位置。让所有人都知道项目的整体情况。
 
12 你们的工作量是先由每个人自己估算的么？
先由制作者本人估计，再由项目的估算小组进行估算。即考虑个体差异，也要顾全整体开发进度。
主要问题是通过先由本人估算，来确认其对自己能力的认知水平，并且给其一个完成的自我压力，
然后评估组估算，来进行内容调节和工作安排，确保按期完成。
 
13 你们的开发人员从项目一开始就加班么？
基本不会。
 
14 你们的项目计划中Buffer Time是加在每个小任务后面的么？
这个情况要看制作者水平以及内容的难易程度。较难的内容会提前预留10%。总体进度有5-10%的余量。
 
15 值得再多花一些时间，从95%做到100%好值得，非常值得。
尤其当项目后期人困马乏的时候，要坚持。这会给产品带来质的区别。
 
16 登记新缺陷时，是否写清了重现步骤？
是的，有明确重现步骤描述，并配合屏幕截图。
 
17 写新代码前会把已知缺陷解决么？
要。每个人的缺陷不能超过10个或15个，否则必须先解决老的bug才能继续写新代码。
 
18 你们对缺陷的轻重缓急有事先的约定么？
缺陷有验证性和解决时限的明确定义。
 
19 你们对意见不一的缺陷有三国会议么？
有，意见不一致的时候由项目的经验丰富的人员进行统一讨论和决策。
 
20 所有的缺陷都是由登记的人最后关闭的么？
不是,提出者提交缺陷,制作者解决缺陷,返回给提交者,解决后,由提交者关闭缺陷。
 
21 你们的程序员厌恶修改老的代码么？
厌恶是正常的。解决方法是组织Code Review，单独留出时间来。XP也是一个方法。
希望他们能在考虑成熟的情况下,对局部代码进行重构.
 
22 你们项目组有Team Morale Activity么？
这个要因人而异,作为领导层必须重视,并最少按月执行一次.并为此拨出专款.
 
23 你们项目组有自己的Logo么？
有系统的Logo,项目组没有Logo.
 
24 你们的员工有印有公司Logo的T-Shirt么？
有。
 
25 总经理至少每月参加次项目组会议要的。
有。一般在需要参加的时候参加。
 
26 你们是给每个Dev开一个分支么？
没有，只有一个共有的开发分支，容易管理些。
 
27 有人长期不Check-In代码么？
不会，最长不会超过1周，一般要求是修改完成,并自己测试后,就Check In.
 
28 在Check-In代码时都填写注释了么？
必需填写注释，并在RTX中进行通知.
 
29 有没有设定每天Check-In的最后期限？
不设定每天的Check-In的时间,但设定该功能何时完成的时间,这个时间以check-in的时间为准,最长的为1周.
 
30 你们能把所有源码一下子编译成安装文件吗？
不是,有专门负责发包的流程.
 
31 你们的项目组做每日编译么？
跟测试策略有关系，当项目计划选择的策略是每日构建时候就必须进行。
 
32 你们公司有没有积累一个项目风险列表？
有，并在每周例会上对分析进行分析。
 
33 设计越简单越好越简单越好。
有些人认为:设计时候多一句话，将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫scope management。我的认为是:设计的时候,任其发挥,但要整理成文,或者图表并貌，在这个过程中，设计和制作人员就会有大量的沟通，这样他们自己会砍掉很多,然后评估组评估后再砍掉一些.
这样做
一、可以发挥他们的想象力，增进设计和制作人员的了解和默契，并能使制作人员了解到设计人员的初衷;很反对按单子做事的方式。
二、可以让他们自己在整理的时候,发现问题、漏洞和制作的难度,明白内容的轻重缓急,自身得到提高;
三、评估组的任务也会减轻，可对制作内容进行更加详细的分析和评估。
 
34 尽量利用现有的产品、技术、代码千万别什么东西都自己Coding。
BizTalk和Sharepoint就是最好的例子，有这两个作为基础，可以把起点提高很多。或者可以尽量多用现成的Control之类的。
或者尽量用XML，而不是自己去Parse一个文本文件；尽量用RegExp，而不是自己从头操作字符串，等等等等。这就是“软件复用”的体现。
 
35 你们会隔一段时间就停下来夯实代码么？
会的。必须这样做。第一：个人的夯实代码，我希望他们能在自己的系统制作中，针对自己的模块提出重构方法，并能在最多一周的时间内重构。
第二：如果是整体结构的话，在版本阶段开始的时候，进行评估，看是否必要进行夯实，如果需要全组合力在半个月制作，半个月测试的情况下，
完成整体夯实。以便下个版本的开发。
 
36 你们的项目组每个人都写Daily Report么？
使用周报的方式。报告本周制作的内容。
 
37 你们的项目经理会发出Weekly Report么？
有项目周报。内容包括目前进度，可能的风险，质量状况，各种工作的进展等。
周报应在每周贴出来进行公示，项目进度则按月进行公示。要让每个成员都了解项目的进展情况。
 
38 你们项目组是否至少每周全体开会一次？
一直没有开展起来，这也是我最大的心头之患。但每周的各组周会还是比较有成效。
可对于全体大会的周会，我的个人感觉是：人员多的情况下，而且他们还有自己的各组周会，领导周会等，确实比较耗时。如果开，很多人都是想节约时间，就成了无事会，把握不好就成了多事会。所以，比较合适的是上周的各组报告由各组长总结，大会作组工作报告，然后是问题报告。让所有成员了解情况，做到成员了解成绩和问题，还有进度即可。

 
39 你们项目组的会议、讨论都有记录么？
有，有专门的会议记录人员。
 
40 其他部门知道你们项目组在干什么么？
要发一些Newsflash给整个大组织。Show your team’s value。否则，当你坐在电梯里面，其他部门的人问：“你们在干嘛”，你回答“ABC项目”的时候，别人全然不知，那种感觉不太好。
 
41 通过Email进行所有正式沟通
是的。Email的好处是免得抵赖。但也要避免矫枉过正，最好的方法是先用电话和当面说，然后Email来确认。
这个根据使用的确认方式来定。我们是通过确认后的工作单来认定，要设计和制作都签字的，一式三份，设计者、制作者、备案（交项目经理）
 
42 为项目组建立多个Mailing Group
邮件只有一个Group,但RTX及时通讯有多个Group.
 
43 每个人都知道哪里可以找到全部的文档么？
知道。应该每个人都知道。这叫做知识管理（Knowledge Management）。最方便的就是把文档放在一个集中的File Share，
更好的方法是用Sharepoint。
 
44 你做决定、做变化时，告诉大家原因了么？
要告诉大家原因。Empower team member的手段之一是提供足够的information，这是MSF一开篇的几个原则之一。
的确如此，tell me why是人之常情，tell me why了才能有understanding。中国人做事喜欢搞限制，限制信息，
似乎能够看到某一份文件的人就是有身份的人。大错特错。权威、权力，不在于是不是能access information/data，
而在于是不是掌握资源。
 
45 Stay agile and expect change 要这样。
需求一定会变的，已经写好的代码一定会被要求修改的。做好心理准备，对change不要抗拒，而是expect change。
 
46 你们有没有专职的软件测试人员？
一些人认为：项目有专门得测试人员，一般配置比例在1比6个左右开发人员。
但实际上：每个人都是测试人员。首先是制作者，自己做的东西能不能用，这是第一，其次，有没有按照设计清单来完成所有的功能。
第二，就是设计者，做出来的东西是不是按照自己的设计正常运行，第三，测试人员除了进行指定的功能测试之外，
使用不正规的，随意的操作是否出现问题；第四，其他成员在玩或者使用该功能时，即在无指导无说明的情况下，随意使用是否造成bug和问题。
 
47 你们的测试有一份总的计划来规定做什么和怎么做么？这就是Test Plan。要不要做性能测试？要不要做Usability测试？
什么时候开始测试性能？测试通过的标准是什么？用什么手段，自动的还是手动的？这些问题需要用Test Plan来回答。
有专门得测试计划。
 
48 你是先写Test Case然后再测试的么？
有专门得测试用例，要求测试必须根据测试用例进行。鼓励其发现测试用例以外的问题。
因为测试用例是制作者提出或者设计者提出，则
 
49 你是否会为各种输入组合创建测试用例？
这点项目组强调了测试数据得准备和路径分支得分析，这块做得不是很好待改进。
 
50 你们的程序员能看到测试用例么？
可以，但开发人员不会特别去关注这些测试用例，一般根据软件需求自测。
 
51 你们是否随便抓一些人来做易用性测试？
没有，需求开发阶段已经有标准得DEMO
 
52 你对自动测试的期望正确么？
不期望自动测试，LoadRunner只用来录制简单得冒烟测试脚本。
 
53 你们的性能测试是等所有功能都开发完才做的么？
不是。大规模和频繁使用系统，性能测试是在阶段功能完成后，就进行。而且尽可能的向地层抽象，确保其功能的稳定和高效。
 
54 你注意到测试中的杀虫剂效应了么？
虫子有抗药性，Bug也有。发现的新Bug越来越少是正常的。这时候，最好大家交换一下测试的area，
或者用用看其他工具和手法，就又会发现一些新bug了。很赞同这种交换测试的方法。
 
55 你们项目组中有人能说出产品的当前整体质量情况么？
要有。当老板问起这个产品目前质量如何，Test Lead/Manager应该负责回答。
 
56 你们有单元测试么？
有单元测试，但和自测，黑盒测试界限不明确。项目成员自测关注重点放到黑盒测试上了而忽略了百盒的分支，条件和代码的覆盖。
 
57 你们的程序员是写完代码就扔过墙的么？
不会，必须自测通过。写好一块程序以后，即便不做单元测试，也应该自己先跑一跑。虽然有了专门的测试人员，做开发的人也不可以一点测试都不做。微软还有Test Release Document的说法，程序太烂的话，测试有权踢回去。
 
58 你们的程序中所有的函数都有输入检查么？
不要。虽然说做输入检查是write secure code的要点，但不要做太多的输入检查，有些内部函数之间的参数传递就不必检查输入了，省点功夫。
同样的道理，未必要给所有的函数都写注释。写一部分主要的就够了。
 
59 产品有统一的错误处理机制和报错界面么？
有，在项目中已经复用。最好能有统一的error message，然后每个error message都带一个error number。
这样，用户可以自己根据error number到user manual里面去看看错误的具体描述和可能原因，就像SQL Server的错误那样。
同样，ASP.NET也要有统一的Exception处理。可以参考有关的Application Block。
 
60 你们有统一的代码书写规范么？
有专门的编码规范文档，但是写多了，特别是人员流动后，很难坚持。这个需要改进。
 
61 你们的每个人都了解项目的商业意义么？
要。这是Vision的意思。别把项目只当成工作。有时候要想着自己是在为中国某某行业的信息化作先驱者，
或者时不时的告诉team member，这个项目能够为某某某国家部门每年节省多少多少百万的纳税人的钱，
这样就有动力了。平凡的事情也是可以有个崇高的目标的。
 
62 产品各部分的界面和操作习惯一致么？
基本一直，还在不断改进中。
 
63 有可以作为宣传亮点的Cool Feature么？
有。工作流，权限模型，多层分布式架构，队列使用，自我开发的数据访问组件都是可以宣传的亮点。
这个需要因项目而异，未必需要新颖复杂的技术，而最关键的是稳定和高效。
 
64 尽可能缩短产品的启动时间要这样。
软件启动时间（Start-Up time）是客户对性能好坏的第一印象。
 
65 不要过于注重内在品质而忽视了第一眼的外在印象程序员容易犯这个错误：太看重性能、稳定性、存储效率，
但忽视了外在感受。而高层经理、客户正相反。这两方面要兼顾，协调这些是PM的工作。
 
66 你们根据详细产品功能说明书做开发么？
要这样。要有设计才能开发，这是必须的。设计文档，应该说清楚这个产品会怎么运行，
应该采取一些讲故事的方法。设计的时候千万别钻细节，别钻到数据库、代码等具体实现里面去，那些是后面的事情，一步步来不能着急。
 
67 开始开发和测试之前每个人都仔细审阅功能设计么？
有专门的同行评审和多人复审。
 
68 Dev工作的划分是单纯纵向或横向的么？
不能单纯的根据功能模块分，或者单纯根据表现层、中间层、数据库层分。我推荐这么做：
首先根据功能模块分，然后每个“层”都有一个Owner来Review所有人的设计和代码，保证consistency。
项目是根据功能来分的，按层来分还需要进一步实践。
 
69 你们的程序员写程序设计说明文档么？
有设计文档输出，但用处不大，更多设计内容直接体现在代码注释中。
比较推崇代码即文档的做法。一般情况下，要求程序员将实现思路直接写在代码的文件的开头。
 
70 你在招人面试时让他写一段程序么？
现在很多都是通过网络进行第一次接触，笔试问卷，先发，过了再面试。
如果笔试的人，连抄袭或者寻找答案都不会的话，这个人的学习能力有问题。
面试的时候，才能体现其真实的水平。一般以问为主。

 
71 你们有没有技术交流讲座？
专门的没有。但是我们使用技术问题共享做法，就是任何人有问题，鼓励其将问题发在RTX上，大家进行讨论，有专门的技术文档整理人员，进行整理；如果整理人员意识不到这是个技术问题的话，组织者会明确要求记录。并放在技术问题讨论的专门目录下，供大家参阅。
 
72 你们的程序员都能专注于一件事情么？
要让程序员专注一件事。例如说，一个部门有两个项目和10个人，一种方法是让10个人同时参加两个项目，
每个项目上每个人都花50%时间；另一种方法是5个人去项目A，5个人去项目B，每个人都100%在某一个项目上。
我一定选后面一种。这个道理很多人都懂，但很多领导实践起来就把属下当成可以任意拆分的资源了。
 
73 你们的程序员会夸大完成某项工作所需要的时间么？
会的，这是常见的，尤其会在项目后期夸大做某个change所需要的时间，以次来抵制change。
解决的方法是坐下来慢慢磨，磨掉程序员的逆反心理，一起分析，并把估算时间的颗粒度变小。
比较少跨大的情况，因为跨大必须要说明明确的理由。
 
74 尽量不要用Virtual Heads 最好不要用Virtual Heads。
Virtual heads意味着resource is not secure，shared resource会降低resource的工作效率，容易增加出错的机会，会让一心二用的人没有太多时间去review spec、review design。一个dedicated的人，要强过两个只能投入50%时间和精力的人。我是吃过亏的：7个part time的tester，发现的Bug和干的活，加起来还不如两个full-time的。