快捷搜索:

关于项目管理的知识点

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么?

要有。能增强归属感。当然,T-Shirt要做的好看一些,最好用80支的棉来做。别没穿几回就破褴褛烂的。

25. 总经理至少每月参加几回项目组会议

要的。要让team member感觉高层关注这个项目。

26. 你们是给每个Dev开一个分支么?

否决。Branch的治理以及Merge的事情量太大年夜,而且轻易掉足。

27. 有人经久不Check-In代码么?

弗成以。对大年夜部分项目来说,最多两三天就应该Check-In. 28. 在Check-In代码时都填写注释了么?

要写的,至少一两句话,比如“办理了Bug No.225”。假如往高处拔,这也算做“设置设置设备摆设摆设审计”的一部分。

29. 有没有设定天天Check-In的着末刻日?

要的,要明确Check-In Deadline.否则会Build Break. 30. 你们能把所有源码一会儿编译成安装文件吗?

要的。这是逐日编译(Daily Build)的根基。而且必须要能够做成自动的。

31. 你们的项目组做逐日编译么?

当然要做。有三样器械是软件项目/产品开拓必备的:1. bug management; 2. source control; 3. daily build.

32. 你们公司有没有积累一个项目风险列表?

要。Risk Inventory.否则,下个项目开始的时刻,又只能拍脑袋阐发Risk了。

33. 设计越简单越好越简单越好。

设计时刻多一句话,将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫scope management. 34. 只管即便使用现有的产品、技巧、代码切切别什么器械都自己Coding.BizTalk和Sharepoint便是最好的例子,有这两个作为根基,可以把动身点前进很多。或者可以只管即便多用现成的Control之类的。或者只管即便用XML,而不是自己去Parse一个文本文件;只管即便用RegExp,而不是自己从头操作字符串,等等等等。这便是“软件复用”的表现。

35. 你们会隔一段光阴就停下来夯实代码么?

要。最好一个月阁下一次。传言去年年头?年月Windows组在Stevb的敕令下停过一个月增强安然。Btw,“夯”这个字念“hang”,第一声。

36. 你们的项目组每小我都写Daily Report么?

要写。五分钟就够了,写10句话阁下,奉告自己小组的人本日我干了什么。一则为了沟通,二则怂恿自己(如果好逸恶劳一天,自己都邑欠美意思写的)。

37. 你们的项目经理会发出Weekly Report么?

要。也是为了沟通。内容包括今朝进度,可能的风险,质量状况,各类事情的进展等。

38. 你们项目组是否至少每全面部开会一次?

要。必然要开会。法度榜样员憎恶开会,但每个星期开会光阴加起来至少应该有4小时。包括team meeting, spec review meeting, bug triage meeting.切切别大年夜家闷头写code. 39. 你们项目组的会议、评论争论都有记录么?

会前发meeting request和agenda,会中有人认真主持和记录,会后有人认真发meeting minutes,这都是effective meeting的要点。而且,每个会议都要形成agreements和action items. 40. 其他部门知道你们项目组在干什么么?

要发一些Newsflash给全部大年夜组织。Show your team‘s value.否则,当你坐在电梯里面,其他部门的人问:“你们在干嘛”,你回答“ABC项目”的时刻,别人全然不知,那种感到不太好。

41. 经由过程Email进行所有正式沟通Email的好处是免得狡赖。但也要避免矫枉过正,最好的措施是先用电话和当面说,然后Email来确认。

42. 为项目组建立多个Mailing Group假如在AD+Exchange里面,就建Distribution List.比如,我会建ABC Project Core Team,ABC Project Dev Team,ABC Project All Testers,ABC Project Extended Team等等。这样提议Email来方便,而且能让该收到email的人都收到、不该收到不被骚扰。

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. 你们有没有专职的软件测试职员?

要有专职测试。假如人手不敷,可以peer test,互换了测试。切切别自己测试自己的。

47. 你们的测试有一份总的计划来规定做什么和怎么做么?

这便是Test Plan.要不要做机能测试?要不要做Usability测试?什么时刻开始测试机能?测试经由过程的标准是什么?用什么手段,自动的照样手动的?这些问题必要用Test Plan往返答。

48. 你是先写Test Case然后再测试的么?

应该如斯。应该先设计再编程、先test case再测试。当然,工作是机动的。我无意偶尔候在做第一遍测试的同时补上test case.至于先test case再开拓,我不爱好,由于不习气,太麻烦,至于别人保举,那碰命运运限也无妨。

49. 你是否会为各类输入组合创建测试用例?

不要,不要搞界限前提组合。警惕组合爆炸。有很多test case对象能够自动天生各类界限前提的组合——但要想清楚,你是否有光阴去运行那么多test case. 50. 你们的法度榜样员能看到测试用例么?

要。让Dev看到Test Case吧。我们都是为了同一个目的走到一路来的:前进质量。

51. 你们是否随便抓一些人来做易用性测试?

要这么做。自己看自己写的法度榜样界面,怎么看都是顺眼的。这叫做审美疲惫——臭的看久了也就不臭了,未方便的永远了也就习气了。

52. 你对自动测试的期望精确么?

别期望太高。依我看,除了机能测试以外,照样暂时先忘掉落“自动测试”吧,忘掉落WinRunner和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. 你们有统一的代码书写规范么?

要有。Code Convention很多,搞一份来发给大年夜家就可以了。当然,如果有FxCop这种对象来反省代码就更好了。

61. 你们的每小我都懂得项目的商业意义么?

要。这是Vision的意思。别把项目只当成事情。无意偶尔候要想着自己是在为中国某某行业的信息化作前驱者,或者时时时的奉告team member,这个项目能够为某某某国家部门每年节省若干若干百万的纳税人的钱,这样就有动力了。平凡的工作也是可以有个高贵的目标的。

62. 产品各部分的界面和操作习气同等么?

要这样。要让用户感觉全部法度榜样似乎是一小我写出来的那样。

63. 有可以作为鼓吹亮点的Cool Feature么?

要。这是增强团队凝聚力、信心的。而且,“一俊遮百丑”,有亮点就可以掩饰笼罩一些问题。这样,对付客户来说,会感到产品从质量角度来说照样acceptable的。或者说,cool feature或者说亮点可以作为质量问题的一个事后增补步伐。

64. 尽可能缩短产品的启动光阴要这样。软件启动光阴(Start-Up time)是客户对机能短长的第一印象。

65. 不要过于重视内在品德而漠视了第一眼的外在印象法度榜样员轻易犯这个差错:太珍视机能、稳定性、存储效率,但漠视了外在感想熏染。而高层经理、客户正相反。这两方面要兼顾,和谐这些是PM的事情。

66. 你们根据具体产品功能阐明书做开拓么?

要这样。要有设计才能开拓,这是必须的。设计文档,应该说清楚这个产品会怎么运行,应该采取一些讲故事的措施。设计的时刻切切别钻细节,别钻到数据库、代码等详细实现里面去,那些是后面的工作,一步步来不能发急。

67. 开始开拓和测试之前每小我都仔细审阅功能设计么?

要做。Function Spec review是用来统一思惟的。而且,review过今后形成了同等意见,将来再也没有人可以说“你看,当初我便是否决这么设计的,现在吃苦头了吧”

68. 所有人都始终想着The Whole Image么?

要这样。项目里面每小我虽然都只是在制造一片叶子,但每小我都应该知道自己在制造的那片叶子所在的树是怎么样子的。我否决软件蓝领,否决过分的把软件制造当作流水线、车间。拜见第61条。

69. Dev事情的划分是纯真纵向或横向的么?

不能纯真的根据功能模块分,或者纯真根据体现层、中心层、数据库层分。我保举这么做:首先根据功能模块分,然后每个“层”都有一个Owner来Review所有人的设计和代码,包管consistency. 70. 你们的法度榜样员写法度榜样设计阐明文档么?

要。不过我据说微软的法度榜样员1999年曩昔也不写。以是说,写不写也不是绝对的,偷懒无意偶尔候也是可以的。拜见第56条。

71. 你在招人口试时让他写一段法度榜样么?

要的。我最爱好让人做字符串和链表一类的题目。这种题目有很多轮回、判断、指针、递归等,既不方向过于考算法,也不方向过于考特定的API. 72. 你们有没有技巧交流讲座?

要的。每一两个星期搞一次内部的Tech Talk或者Chalk Talk吧。让组员之间分享技巧心得,这笔费钱送到外貌去培训划算。

73. 你们的法度榜样员都能专注于一件工作么?

要让法度榜样员专注一件事。例如说,一个部门有两个项目和10小我,一种措施是让10小我同时参加两个项目,每个项目上每小我都花50%光阴;另一种措施是5小我去项目A,5小我去项目B,每小我都100%在某一个项目上。我必然选后面一种。这个事理很多人都懂,但很多引导实践起来就把属下当成可以随意率性拆分的资本了。

74. 你们的法度榜样员会夸大年夜完成某项事情所必要的光阴么?

会的,这是常见的,尤其会在项目后期夸大年夜做某个change所必要的光阴,以次来抵制change.办理的措施是坐下来逐步磨,磨掉落法度榜样员的逆反生理,一路阐发,并把估算光阴的颗粒度变小。

75. 只管即便不要用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的。拜见第73条。73条是针对法度榜样员的,75条是针对Resource Manager的。

您可能还会对下面的文章感兴趣: