一个软件项目。项目的主要内容和实现的主要功能说明区别

2008-02-04 13:23一个项目团队管理。您的项目团队使用源代码管理工具了吗？ 应该被使用。 vss，cvs，pvcs，clearcase中，ccc /丰收，萤火虫即可。我的选择是vss。 2。您使用的项目团队缺陷管理系统了吗？ 应该被使用。的clearquest太复杂，我的建议是bugzilla的。 3。你还在用word来编写测试组的测试呢？ 不写使用word（测试用例）测试用例。应该是一个专门的系统，可以测试管理器，你也可以开发自己的小一个asp.net网站。其主要目的是追踪和浏览。 4。你的团队还没有建立一个门户网站？ 有一个门户网站把联系方式，基线时间表，新闻和更多。推荐的sharepoint portal server 2003来实现15分钟就搞定了。可以买不起sps 2003 wss（在windows sharepoint服务）。 5。您的项目团队，你可以买它的最佳工具？ 应该尝试一起工作的好工具。例如，编写c＃应该用vs.net而不是记事本。用记事本写程序大多只是表演。但也要考虑到经费，所以说是“最好的，你可以买到。” 6，你在一个安静的环境中工作的程序员？ 需要一个安静的环境。这一点是非常重要的，而且要保证每个人的空间大于一定大小。 7。你的员工每个人都有手**？ 需要一个电话的人。和语音信箱最好的手机。当然，对电话系统开销这么一套带留言不小。但每个人都至少有一个手机，人们往往不站起来喊：“某某某的电话。” “人的因素”，这将强烈谴责这种做法。 8。每个人都知道谁应该是出了问题？ 应该知道。任何feature至少都应该有一个owner，当然，业主可以继续派遣到其他人。 9。你有没有曾经有人说，“我想......”什么？ 要消灭“我以为”。永远不要假设任何事情。 10。在所有这些项目中的团队和你坐在一起？ 需求。我反对虚拟团队，在美国也反对开发，测试这种开发方式在**。能坐在一起就最好坐在一起，好处非常非常多。 11。你的日程安排是否反映最新开发进展情况？ 应该反思。但是，如果基线的方法来管理进度：维持一个稳定的计划，然后保持近期的变化。基线也可用于参数的其它方法。基线是变更管理的重要手段里面。 12。你的工作量是留下了每个人自己估算？ 应该让每个人自己估算。下来的工作量，以前的估计，而不是从上往下分派。除非有其他原因，比如**任务工期固定。 13。你们开发人员从项目一开始会加班吗？ 这样做。不要一开始就搞疲劳战。从项目加班一开始，只是项目进度不合理。当然，有些软件外包必须天天加班，那属于剥削的范畴。 14。你的项目计划缓冲时间将被添加到它的每个小任务后面？ 没有。缓冲时间添加的每个小任务后面，很容易轻易食用。缓冲时间增加一个里程碑全部或检查点前方。 15。值得花一些时间，从95％至100％，以达到良好值得，非常值得。尤其是当，当后者成为该项目用尽，要坚持。这将带来一个质的区别。 16。登记新缺陷，是否写清了重现步骤？ 要。这属于dev和测试之间的通信手段。面对面沟通需要，填补重现步骤需要。 17。写新代码前将已知缺陷解决？ 要。每个人的缺陷不能超过10或15，否则旧的错误必须以继续写新代码来解决。 18。你必须优先考虑的缺陷事先约定呢？ 必须有定义。严重程度分1，2，具有较好的一致性：蓝色和数据记不清西弗1，功能错误数西弗2，在界面西弗3指望然而，这项协议可以适当根据产品质量状况进行调整。 19。你不同意的三个会议的缺陷有吗？ 必须具备的。有一个明确的决策过程。这类似于ccb（变更控制委员会）的概念。 20。所有的缺陷都关闭了谁注册了它的最后一个人？ 问题应该由遥控器关闭。开发不能私自关闭的bug。 21。程序员不喜欢你老的代码？ 厌恶是正常的。解决的办法是组织代码评审，单独留的时间。 xp是一个方法。 22。你的项目组团队士气的活动，为什么呢？每月过一次，吃饭，唱歌，郊游，玩，卡丁车等等，一定是。不要把钱。 23。你有自己的队徽是什么？ 有自己的标志。至少应该有自己的代号。 24。印有你的员工，公司标志的t恤，为什么呢？ 有。能增强归属感。当然，t恤都好看，棉最好用80做的，不要穿几次破烂。 25。总经理至少每月参加次项目组会议想要的。让高层团队成员感到关注这个项目。 26。开发是给每一个你打开它的一个分支？ 反对。分支和合并管理的工作量太大，而且容易出错。 27。有人长期入住的代码？ 没有。对于大多数项目来说，最多两三天应该入住。 28。在入住注释代码来填充呢？ 至少写一两句话，比如“解决问题225”。如果上坡拉，这也算做的“配置审计”的一部分。 29。已为入住天天没有设定最后期限？ 要清除入住截止时间。否则生成中断。 30，你可以一下子所有的源代码被编译成安装文件吗？ 希望。这是一个每日编译（每日构建）的基础。并且必须能够进行自动的。 31。您编译项目团队每天做呢？ 一定做到。有三样东西一个软件项目/产品开发必备：？1 bug管理; 2源代码控制; 3每日构建.... 32。你的公司已经积累了项目风险列表？ 要。风险清单。否则，下一次的项目开始，只有拍脑袋风险分析。 33。设计越简单越好越简单越好。当设计多字，未来可能会带来无穷的后患。应该从一开始就勇敢的砍。所谓的范围管理。 34。最大限度地利用现有的产品，技术，代码的没有什么自己的编码。的biztalk和sharepoint就是最好的例子，并以此为基础这两项，可以提高很多起点。或者你可以尝试之类的许多现有的控制。或尝试使用xml，而不是试图解析一个文本文件;尽量用regexp的，而不是自己从头操作字符串，等等等等。这就是“软件复用”的体现。 35，你会定期停下来夯实代码？ 要。最好一个月左右一次。去年年初，windows组的谣言停止了一个月来增强安全性的stevb命令。顺便说一句，“夯”这个字念“挂起”，第一声。 36。你的项目团队每个人都写了每日报告呢？ 写。五分钟就足够写10句话，这帮人告诉自己，我今天所做的一切。一个为了沟通，二鞭策自己（如果空闲的一天，不好意思自己会写）。 37，你的项目经理会发出周报吗？ 要。同时进行通信。包括目前进度，可能的风险，质量状况，进度等各项工作。 38。你的项目团队是否符合一个星期至少一次呢？ 要。必须得到满足。程序员讨厌开会，但会议时间在一起，每星期至少应该有四个小时。包括小组会议，规范审查会议，错误会审会议。我们不闷头写代码。 39。满足你的项目团队讨论什么已被记录？ 将发行前的会议要求和议程，将负责进行和记录人，后有人负责发会议纪要，这是有效的交汇点。此外，每个会议应形成协定和行动项目。 40。其他部门知道你的团队是做什么的？ 要送些快讯给整个大组织。显示您的团队的价值。否则，当你坐在电梯里面，其他部门谁问：“你在做什么，”你回答“abc项目”的时候别人全然不知，那种感觉不太好。 41。通过电子邮件电邮利益进行所有正式沟通是如此抵赖。同时也避免矫枉过正，最好的方法是使用电话和当面说，和电子邮件确认。 42。建立多个邮件组如果ad +交换内，始建分发列表的项目团队。比如，我会建abc项目核心团队，农行项目开发团队，农行项目所有测试人员，农行项目扩展团队，等等。电子邮件发起这样一个方便，允许接收邮件的人接受，不应该被骚扰接收。 43。每个人都知道在哪里可以找到的所有文件？ 每个人都应该知道。这就是所谓的知识管理（知识管理）。最方便的是在一个集中的文件共享文件，一个更好的方法是使用sharepoint。 44。你决定做出改变的时候，要告诉你的原因是什么？ 来告诉你为什么。授权团队成员的手段，以提供足够的信息，这是无国界医生开口的几个原则之一之一。事实上，告诉我为什么是人，告诉我为什么为了有了解。**人喜欢从事的工作限制，限制信息，人们似乎能够看到该文件的副本是有该人的身份。错了。权威，权力，没那么不能够访问的信息/数据，因而不能在资源的控制权。 45。保持灵活，并期望改变如此。需求必须成为，并且已经编写的代码会被要求。心理上不抗拒变化做好准备，但预计变化。 46。你有一个全职的软件测试人员？ 有一个完整的测试。如果人手不够，可以点对点的测试，交换测试。不要测试你自己的。 47。测试你有一个总体规划，指定做什么和怎么做呢？ 这是一个测试计划。或做性能测试？还是做可用性测试？你什么时候开始测试性能？什么是标准的测试？通过什么手段，自动的还是手动？这些问题需要一个测试计划来回答。 48，你是先写测试案例，然后测试它？ 应该的。设计应重新规划，重新测试了第一个测试用例。当然，它是柔性的。有时候我做第一遍测试的同时补测试用例。作为第一个测试用例重新开发，我不喜欢，因为不习惯，太麻烦，所推荐的其他人试试也无妨。 49。你是否会创建一个测试案例为各种输入组合？ 不要搞边界条件组合。当心组合**。有许多工具，可以自动生成各种边界条件的测试案例组合 - 但要想清楚，你有那么多时间来运行测试用例。 50。程序员，你可以看到测试呢？ 要。让我们看看开发测试案例吧。我们一起拿出一个目的：提高质量。 51。你是否只是抓一些人来做易用性测试？ 这样做。看到自己写的程序界面，怎么看都是顺眼。这就是所谓的审美疲劳 - 臭找了半天也没有臭，不方便永久要去适应它。 52。你正确地期望自动测试？ 不要期望太多。在我看来，除了性能测试，或暂时忘记了第一个“自动测试”吧，忘掉它的winrunner和loadrunner的。对于国内的软件测试的现状，它只能“矫枉必须过正”了。 53。你的性能测试已完成，这样做之前，所有功能都开发了？ 不能。性能测试不能被分类成一个所谓的“系统测试”阶段。早期测试早期矫正，圣母升天早早。 54。你有没有注意到农药在测试的效果呢？ 抗虫，错误了。发现一些新的问题是正常的。在这个时候，最好大家交换试验区，或使用其他工具和用于看技巧，你会发现一些新的bug。 55。有人在你的团队可以说该产品是当前形势的整体质量？ 有。当老板问怎么这个产品的质量目前，测试引线/经理应该负责回答。 56。你有一个单元测试呢？ 所需的单元测试。然而，单元测试是不，不，不，我没有单元测试的项目，也做成功了 - 可能是侥幸，也许我们都精通的关系。同样，软件工程的实践是非常，非常的作品非常灵活的一套方法，某些方法会更好在某些情况下比其他方法，反之亦然。 57。程序员，你都扔在墙上完成的代码就可以了？ 禁忌。写在未来的一个程序，即使我不做单元测试，应该启动和运行自己的。虽然有了专门的测试人员，开发谁不不能做一个小测试。微软测试版本文件说，该计划很烂，然后进行测试，踢回右边。 您输入了所有的功能，以检查它58。计划？ 没有。虽然输入检查点做编写安全的代码，但不要做太多的输入检查，有些内部函数之间的参数传递就不必检查输入，并保存一些努力。由于同样的原因，并非所有的功能被写入，得到评价。写作的主要部分是足够的。 59。产品有一个统一的机制，错误处理和错误的接口？ 有。最好是有一个统一的错误信息，那么所有为每个错误编号的错误消息。以这种方式，用户可以根据自己的号码在用户手册误差里面去看看错误和可能的原因，例如，sql server错误的具体描述。同样，asp.net必须有一个统一的异常处理。您可以参考相关的应用程序块。 60。统一的代码，你必须写规范呢？ 有。许多守则公约，搞上了一个分布式的每一个人。当然，如果有这样的工具来检查代码的fxcop更好。 61。你们每个人都明白这个项目什么样的商业意义？ 要。这是视觉的意义。这样做不仅可以作为一个工作项目。有时你想认为自己是在**的先驱变成某一个行业的信息，或不时地告诉团队成员，如何纳税人的钱数以百万计，每年为这个项目可以节省**的某些部门，所以激励它。平凡的事情也是可以有个崇高的目标。 62。产品的界面和操作实践的各个部分与它保持一致？ 这一点。让用户感觉仿佛整个程序写成一个人。 63。有宣传的很酷的功能亮点呢？ 要。这是为了增强团队凝聚力和信心。而且，“一俊遮百丑”，有亮点就可以掩盖一些问题。因此，对于客户，会感到该产品是可接受但从质量的点。或者，很酷的功能或亮点可以作为衡量质量问题亡羊补牢。 64。可以缩短启动时间如此。软件启动时间（启动时间）是客户的第一印象是好的或坏的表现。 。 65，不要过于注重外部第一眼印象而忽视内在质量程序员容易犯这个错误：太看重性能，稳定性，存储效率，但忽视了外在的经验。和高级管理人员，客户相反。考虑到这两个方面，协调这些工作是pm。 66。你就根据详细的产品功能规范发展呢？ 这一点。设计应以开发，这是必须的。设计文档，应该说清楚这个产品会怎么运行，应该采取一些讲故事的方法。在设计的细节时，不要钻，不钻到数据库，代码等具体实现里面，这些都是后面的事情，一步步来不能着急。 67。开发和测试功能设计它开始之前，每个人都仔细审阅？ 做。功能规格审查的目的是统一思想。此外，在审查的共识形成后，未来没有人能说，“你看，当我反对这样的设计，现在就忍受” 68。每个人都一直以为整个图像为什么？ 这一点。虽然该项目只是大家在一片树叶的制造里面，但每个人都应该知道，树本身在制造业，其中叶是怎么样子。我反对软件蓝领，太多的反对作为软件制造商流水线，生产车间。参见第61条。 69。师开发工作是纯粹的垂直或水平为什么？ 不是简单地根据功能模块分，或者单纯根据表现层，中间层，数据库层的点上。我推荐它：首先，根据功能模块分，然后每个“层”都有一个owner来检查所有的设计和代码，以确保一致性。 70。程序员写程序设计说明文档呢？ 要。但我听说微软的程序员1999年以前也不写，所以不写来写也不是绝对的，偷懒有时候也是可以的。参见第56条。 71。当你让他写一个程序来招人面试是什么？ 希望。我喜欢的人做一个字符串，主题类别的列表。这个主题有许多自行车，判断，指针，递归等，既不偏向过于考算法，也不偏向过于考特定的api。 72。你有没有技术交流讲座？ 希望。每两个星期一次搞内部或座谈技术讲座吧。允许成员之间共享的技术思路，这个钱去培训费用之外。 73。程序员可以专注于一件事情么？ 让程序员专注一件事。举例来说，有两个项目和10个人一个部门，一种方法是让10个人同时参加两个项目，每个项目每个人都花50％的时间;另一种方法是亲自去项目5个a，5个人，项目b，每个人都100％在某些项目。我会选择后者。很多人都明白这个道理，但花了大量的实践的领导下，作为一种资源，可任意分割。 74。程序员会夸大需要完成一个任务了你的时间？ 是的，这是常见的，尤其是在项目的后期会做夸大需要换一换，以次来**变革的时间。解决的办法是坐下来慢慢磨，磨掉程序员的逆反心理，一起分析，以及颗粒大小的估计时间变小。 75，尽量不要使用虚拟头最好不要使用虚拟头。虚拟元首意味着资源是不安全的，共享的资源会减少资源的效率，容易增加出错的机会，做一个头脑没有太多的时间来审查规范，审查设计谁。一个专门的人，强于2只有50％的投人的时间和精力。我所遭受的损失：7部分时间在测试仪，干燥的bug发现还活着，还不如加起来两名全职的。请参阅第73 73是程序员，75是资源管理器。 20210311