Ch03

415

是否一定按照这14个步骤来完成一个项目，有哪些步骤是可以跳过或者可以将几个步骤合在一起么？

 

对于我们做的一些项目是否也需要这么复杂的流程，我们之前做大作业的时候，也没有什么具体的PM, Dev什么的，只是大家讨论分配一下代码工作就行了，那MSF开发的14个工作流程对我们是不是就没有用呢？

 

参与项目的人不能保证每个人的水平都一样，有些问题可能只有其中的少数人能够解决，这时候是不是能够灵活改变一下工作流程，以提高工作效率？

 

绞刑架的启示：虽然开发软件变得越来越容易，但是用户和社会的要求越来越高，挑战时刻存在着，软件开发工具和方法的升级只是一种辅助，软件开发仍然面临诸多挑战，也正是这些挑战才让我们有了进取的动力和决心。

 

412

这一章我读的很认真，这也让我想起了我们team在做项目之前曾共同参与了一次小型PM培训，是由微软亚洲研究院高校关系经理管刚组织的。在会上管刚提到了项目管理的五个过程：启动、计划、实施、控制、收尾。而作为刚刚接触项目管理或者刚刚开始做项目的我们最常忽略的就是项目的启动与收尾阶段，因为很多人会认为项目就是前期策划，中后期编码实现的过程，期间构架师与PM都要对项目起到控制作用，而项目的启动与收尾只是草草的例行公事罢了，这是一个很不好的工程习惯。但对于我们学生阶段的项目与微软这样的商业公司做项目的规模、大小显然是不可同日而语的，这方面我有些疑问，对于微软公司，是怎样协调项目启动与收尾阶段在整个项目过程中的角色的？或者说，对于一个商业项目，微软公司会在启动与收尾阶段投入多少？

 

制定项目远景方面，是要创建项目典型用户，对于创建典型用户也要做很多工作，包括收集用户信息、按用户类别创建、并最好让典型用户形象丰满，这方面要考虑的很多，但是不太明白的是电影用户在项目进行中的生存期多长（从什么时候开始创建，什么时候结束他的作用）？伴随他的生存期间其作用是什么？我现在的理解就是我们有一定范围的用户群体，在这个用户群体中凝结出几个代表性的角色作为典型用户，我们项目进行中会不断的和他们的行为、意愿（也就是用户、市场）进行预期与比对，进而改进项目，在项目最后的验收测试中可以拿典型用户作为白箱测试的依据，不知这样的理解对不对？

 

指导项目进展方面，这里邹欣老师首先提到的就是回顾目标和进展，但这里的回顾是指拿项目刚刚过去一阶段的进展与成果与我们指定的最低接受标准进行对比，我不是很明白为什么要以现有成果与最低接受标准来对比这样会不会让我们在做下一阶段任务时把标准卡的过低？项目运行过程中是需要阶段性的收获与鼓励的，但我觉得这样回顾进展不是一个激励的方式，会不会降低我们做项目时心中的标准降低我们的积极性呢？所以这方面我不是很理解，或者可能我们的最低接受标准在制定的时候卡的还是比较高的，或者我们会有多重标准（底线、期望值等）？

 

事后诸葛亮会议（回顾会议）时，邹欣老师的期望是会议主持人最好是团队之外的人士，同时能够让与会的成员有信任感和安全感，没有太多顾忌。我很理解邹欣老师的良苦用心，因为这样的总结性会议（包括之前的一些项目讨论）如果能够在一个平等的环境下进行的话，会更容易把问题、优劣剖析出来，判断清楚，这样才能达到会议的目的。但这方面操作起来难度还是有的，因为这样一个靠谱的主持人要了解项目的阶段性情况，同时兼顾与会人员的熟悉程度，应该不会很好找，邹欣老师也没说明该怎么去找这样一位主持人。如果没有项目之外的人员参与的话，项目中什么角色会比较适合呢，PM？事后诸葛亮还是一个继续重视起来的会议，具体操作层面的还是希望得到更多指导。

 

产品发布阶段，由于我还没有接触过商业产品的运作，所以这方面还有几个问题想请教一下：产品基本完成后的验收阶段大概会有几轮测试，分别针对哪些方面？如果这个项目团队是属于在项目开始阶段组建的，然后随项目结束而解散，那么产品的维护将要怎么做？或者说项目结束后的产品维护是要在那个阶段定出方案的？

 

本章最后的部分“小飞的牢骚”也说出了我的一部分疑问：

1)      很多关于项目管理的讨论中都会提到，PM并不一定很懂技术，但这就产生里一个疑问，如果PM不是很懂的话要怎样让项目成员信服他的决策？当然这可能是管理方面的问题了。

2)      PM在管理中总是存在一个“催”的问题，就是说每次会议后PM总是觉得自己布置下去的任务没有得到按时的完成，就要一次一次的催，这到底是成员执行力的问题还是目标定太高的问题？

3)      如何做到平等交流的问题。因为包括李开复的创新实验室，一些项目管理经验都谈到了在项目进行中的讨论会、事后诸葛亮会上都要做到平等交流，这是一个让大家brainstorm的方式，也是让大家更好地总结创新的方式，但具体怎样保证一定程度（显然不是全部）的平等交流？这方面还有很多要探讨的，可能需要实践来推动。

 

406

这些工作流程的各部分的参与者和实施者在团队中都扮演什么角色？

以我个人的感觉来说，指定项目的远景应该是由MM和PM挑大梁，全体成员共同参与制定的；指导项目进展的工作应该交给项目管理人员；计划与指导项目的迭代过程除了需要PM外，还需要Dev lead的支持。至于制定解决方案架构和发布产品我认为还是要整个团队的参与。当然，团队中各成员的工作不是独立的，所以工作流程中的各部分在理论上应该欢迎任何成员的参与，那么这个时候谁说的划分量重些呢？

 

如何避免在软件开发过程中这种工作流程的喧宾夺主？

通过果冻的讲述我认为这个问题不仅是存在的，而且可能会比较严重。尤其对我这种缺乏经验的大学生更是如此。

 

323

 

P63 “我们都应该先重现这个缺陷”。

如果是在多线程环境下，或者是实时系统，这个条件如何满足？如果满足不了，那么这个缺陷就一直呆在那里吗？

 

“到底缺陷有多严重”。

其中衡量缺陷严重程度的标准是什么？

 

P66  “调迭代计划”。

有时候只是微调就能够解决问题了吗？前面提到的Sql server不是在不断地微调之下，最后只好重新来过?

 

P69 “迄今发现的Bug都要重新验证是否能够通过”。

这是不是有点太花时间，精力和成本了，况且有些bug是只在某一个版本里头出现过，是否也要重新验证呢？验证的意义何在？

 

产品的外包是不是大部分盗版的根源呢？

 

“PM因不写代码好多年了，不熟悉项目用到的技术”。

作为一个PM级别的人物，不应该不了解项目用到的技术呀！不了解技术，怎么能控制项目的进展，和给以员工得力的帮助？

 

117

一个最大的疑问：对于非计算机专业人士，能否很快上手使用MSF敏捷模式的项目管理流程。貌似书中管理方面并没有设计太多的专业知识。

 

Ch04

415

正如4.4的本章讨论中所说的，大部分的工作项纪录都是一些没有用的或者是无人理会的，只有少部分的工作项是正经事，这样工作效率是不是会降低，如何才能保证高效的完成？

 

406

工作项是否赋予了团队成员过多的权利（可以随时创建，并有权决定其激活和关闭）？有没有一套行之有效的管理方式来管理各工作项使其在正确的时间被正确的成员创建、激活或关闭？

这个问题是我在阅罢这一章后最想弄明白的问题。因为在开发过程中过高的自由度会导致开发过程的混乱。会给队友带来一些不利的影响和而外的工作（比如说突然创建一个无效的缺陷或风险）。这一点对我们这种没有明确管理层的学生团队来说影响会更大（作为学生，谁都喜欢尝试一下新特性，往往会在无意中造成这种新特性的滥用）。

 

323

P83 表4-2 有一项“延迟”的动作。

我们知道每一次的延迟都会给整个项目带来风险，而这时分清楚每一个任务的优先级是很重要的，那么我们应该如何来给每一个任务设定优先级呢？有没有什么好的方法吗？

 

P86 表4-5 有一项动作“无法重现”。

这真的应该忽略掉么？

 

117

这章概念很多，不太好记忆，很抽象，对工作项对于软件开发的便利体会的不是特别的深。估计等实践之后，会有进一步的体会吧。

 

对于工作项中的冗余信息，有没有什么好的方法去有效的处理？比如说自己刚更新了个状态，觉得不太好，立马又更新了一个，那个之前那个就没有什么用了，类似这样的冗余信息我觉得不会少，所以不知道有没有什么方法及时有效的处理这些信息。

 

Ch05

406

如果可以，能否在具体的情境中讲一下源码控制的各个方面？

可以看到，每当读到关于解释如何使用软件的特定功能时我的问题就很少，这并不代表我全明白了。我认为这些具体的技术性的问题的答案可以通过网络和相应的文档获得，时段时间内可以解决的。对于这个问题，我的意思是：读完这章之后我大致了解了VSTS提供的各个功能，但是对在团队项目中如何在正确的时间使用正确的功能还是不太清楚。所以希望能在具体的情境中感性地认识这些功能。

 

323

P97 “分支和合并”

合并源代码的操作的权限是谁？

 

320

（表格）适用队伍2-500人以上，……

问：2个人的队伍，和500人的队伍差异还是很大的，TFS在保证大规模队伍的时候，如何还能保证2，3个人这样的小队伍呢？

 

319

P104：表5-1的TFS“适用团队”一项

表5-1说TFS适用于2~500人的团队，这个跨度未免太大，我感觉2人团队和500人团队不能用统一标准衡量，而且对于2人团队，我觉得TFS会产生资源浪费。TFS真的适合2人这种极小型的团队吗？

 

Ch06

406

构建成功的程序必须要能够运行吗？

比如说团队成员各自都写出了自己负责的模块的框架但没实现任何功能，只是想知道组合在一起是否能通过编译。这种情况下可以认为是构建成功了吗？或者必须等到各成员实现了一些简单的功能之后在进行构建？

 

项目的进度是否要以成功构建为前提？

我的意思是在软件开发的过程中，开发人员是以开发出一个最近的能够成功构建（且运行）的版本为目的，还是以开发出一个稍微完善一些的版本为目的？因为前者可能导致迭代次数过多，而使得每一次迭代中真正做的代码修改比较少；而后者可能会引来更多的bug影响到构建的成功。如何在二者之间做出权衡？

 

319

P117：6.5每日构建

每日构建，构建是否需要测试，会不会工作量太大？

 

Ch07

415

测试的方法有很多，而且不同的测试方法在不同的时候使用也有不同的效果，是不是每个项目都需要使用这些所有的测试方法都测试一遍？我们平时做的小项目，在没有这么多人力物力资源的情况下，使用哪种测试方法是比较有效的？

 

如果测试完成发现BUG很少是不是说明这就是一个成功的软件？BUG很多这个软件就不成功呢？

 

412

对于黑箱、白箱测试，我不是很明白在一个项目进行的过程中，一般由哪些人员来做黑箱测试，又由那些人来做白箱测试？或者随着项目进行的不同阶段会有不同的角色来担任？

 

代码覆盖率测试能起到多少作用，是不是投入产出比会比较低？因为代码覆盖这部分要由dev来做，而dev会有下一阶段的编写任务，做这方面测试会占用他们一部分精力与时间。

 

如果我做的一个项目在验收阶段发现一个重要功能模块出了问题，而且问题比较大甚至会导致这部分推倒重做，这种情况下谁应该为此负责（或者说那些人应该负主要责任）？

 

集成测试要安排在什么时候比较好，是不是越早越好？

 

这章最后提到了如果一个bug在实际应用中根本不可能发生（或者开发人员意识到这个问题，但认为这是不可能发生的），这还算一个bug吗？

 

406

对于一个小的团队（比如说一个学生团队）来说，这些测试都是必须包括的吗？如果不是，那么哪些测试是必要的？

作为一个学生，我没有多少编程经验，目光也并不像专业人士那么长远，这就是我关注小团队中如何运用软件工程知识的原因。对于我们来说，我们所接触的项目一般规模较小，开发时间较短，功能和非功能需求的要求较为简单。故这种系统的测试会占用大部分的开发时间，导致开发过程时间分配的不合理。那么应该如何精简这种测试使其既能达到测试目的又适合我们这种小团队进行敏捷开发？

 

一款软件即使到了可以发布的阶段仍然会不可避免的有一些bug，如果存在少量已知的bug但是不得不发布（比如说到了规定的期限），那么是应该公开这些bug还是先保密并在后来出补丁包悄悄修复？

这一点我很想知道。公开bug虽然能在一定程度上防止该bug造成严重后果，但是也会带来诸如安全性、用户对该产品的信任等问题。而如果不公布，则当bug出现后会带来更大的问题（个人认为应该会比公布bug带来的后果更严重），那么是不冒险而去承担必然会发生的，但是较小的损失呢，还是冒这个险，要么没有损失，要么承受较大的损失，这是个问题。

 

323

P126 “不同的代码是否被执行，有很多的组合”。

不会是要求每一行代码都必须被执行把？如果是这样，为什么不把其设置为模块呢？这样只要满足每一个模块的输入输出条件就可以了，这样省了不少事不是跟好吗？

 

319

P123~P125：7.1.2从测试的目的分类和7.1.3按测试的时机和作用分类

这一节列举了很多种测试，对于不同的测试，具体用哪种测试方法好？不同的测试方法各适用于什么场合？