Ch12-16

412

在项目中，该如何看待参与者总是说太忙，来不及做的情况？这一般都是什么原因造成的？或者说会有相关责任人吗？

如何处理团队讨论中的争论问题，每次讨论有什么技巧来保证讨论的目标能够达到，或者说能够解决问题？因为争论时不可避免的，brainstorming是讨论的一部分，是不是要在每次讨论之前就要定好类似讨论原则的制度？

项目计划中我们会遇到“会海”的情况，书中也说了需要多次开讨论会才能制定出较完整的项目计划，但该怎么摆脱会议冗杂这一现象呢？

406

在如何决定各种功能的优先级一节中，价值与紧迫性是否关联过强以至于不太适合作为优先级评价的两个独立的方面？

当我们使用上述方法做决策时，我们找的各个方面最好是“正交的”（即不相关的，是信号与系统的课程中学到的对标准正交基的一个应用）。因为所选的评价的各个标准的相关性越弱，评价就越全面。但是紧迫性与价值的关系似乎有些太密切了（我认为在价值上“很重要”的东西用户往往哭着喊着要；而且我相信用户哭着喊着要的东西往往很有价值），以至于要用价值、技术可行性、紧迫性为轴建立决策空间的话得到的结果可能与实际不符，可否将价值换为前景（一分为这方面技术很成熟，发展它没什么太大前景；四分为这方面功能在市场上还没有成型，发展一下有可能会让软件更容易占据更多的市场；七分为该功能很有用却几乎没人考虑过，实现它很可能会让软件大赚一笔）？

323

P224 “给每个管理员人少量的银弹”。

有银弹固然好，但当同时有多个人对某一个问题有不同的看法，都坚持用银弹那应该怎么办？这时候的冲突应该怎么解决？

P226 “加班不能是常态”。

这对于程序员来说，当然是好事，但是我在网上看到很多篇文章痛诉了程序员的工作生活没有规律，加班是常态。不知道Microsoft里面是否有这样的问题？如果有了，领导人是怎么样调节的？对于程序员来说又是应该怎样调节呢？

P227 “模块的最终质量决定了开发人员的工作绩效”。

不同的模块有不同的要求，如果A负责的模块是很难的，B负责的模块是很容易的，那应该怎样比较？总不能一概而论吧？         同理对于测试人员，若是本来开发人员写的模块就不怎么样？那能怪测试人员么？另一方面，质量需要经过长久的考验才能得出结论，那么总不能等到那时才进行评审吧？

P228 表12-1

有些角色不能合并，应该给出理由呀？

P243 “日期驱动的项目，必须从软件发布之日倒推回去”。

如果我们想要倒推，那么就应该有很详细的设计了，可是软件工程项目的需求，很多时候是要改变的。这是否是相互矛盾的呢？遇到了这种矛盾，我们应该如何解决？Microsoft内部是怎样解决这种问题的。

P269 “设计场景入口”。

场景入口是否要作为一个模块的入口？

P273 “流程图左边有一个‘新建缺陷’”。

是否是指自动测试工具帮助我们生成的bug案例，以便我们可以重现bug呢？

P303 “不要重复提交Bug”。

怎么做到呢？不会让测试人员把所有的bugs看一遍吧？

319

P221：12.2收集意见 为了了解员工的情况…无记名调查表

需要了解员工的哪些方面？

P224：谈话中阿超和大栓的最后三次发言

有关团队成员之间的不同意见及解决办法，这里提到了“银弹”和团队讨论，我觉得“银弹”有很多弊端，产程很多隐患，而完全依靠与讨论协调会造成效率低下，究竟有没有比较完美的方案？

由上一条延伸：

P34：阿超第一次发言：（1）平等协作——成员之间、团队之间是平等协作的关系

有关充分授权和信任中平等协作原则：成员之间、团队之间是平等协作的关系，我觉得在遇到不同意见时会造成效率低下。

P228及课程相关：阿超发言：对于小型的团队和小型的项目，可以根据表12-1来这样合并角色

如何决定团队成员角色（根据什么标准）？我们的团队是否需要专门进行管理的角色？

P264：14.1.1怎样定义典型用户 “Persona可以包括以下内容”

对于不同的项目，如何得到有关persona的内容？调查途径是什么？如何确定我得到的信息是准确的具有代表性的？

P288：15.1似是而非的测试观念 “（3）测试人员当然也写代码，但是质量不一定要高”及阿超发言

测试人员被要求代码质量高,为什么能写高质量代码的不去专门写代码呢？写代码功底低的做开发人员，再由写代码功底高的测试人员补漏，这不是浪费资源吗？

P292：阿亨最后的发言：…一个好的Bug应该是这样的…

有些BUG发现时没有足够时间记录详细信息怎么办？

119

在十二章第七节中分析了“移山公司”的网站任务的用户分析，其中用户包括了赞助者，重大关系人，最终客户等。在实际开发中如果用户之间出现了矛盾（就比方说重大关系人的要求可能会影响到最终用户的使用的方便性等），我们应该优先去考虑谁呢？如果违背了重大关系人的利益，我们就可能会丢掉机会，如果最终用户不能认可，我们的产品就会失去意义。就像领导的政绩工程和老百姓的日常需求一样，我们到底应该先考虑哪一个呢？

在书的第224页讲到了“银弹”。银弹者的掌握着有什么条件呢？不是所有的人都能有权利掌握银弹吧。所有的项目组都该有一样的数目，还是有所区别呢，例如测试组应该具有比代码组更多的银弹呢？