这个作业的要求是：https://bbs.csdn.net/topics/608340750
问题一
问题提出
我阅读了教材的这内容：
这些复审可以在伙伴之间进行，也可以在团队内部进行。（教材P80）
有这个问题：面对同一段代码，不同的人的理解速度不同（即使在作者的讲解之下），若速度过快会导致有些人跟不上，难以融入其中发挥作用，若太慢则会拖慢项目进度。那么该如何提升代码复审的效率呢？
相关资料
有这些说法：
1.控制每次审查的代码数量
2.带着问题去进行审查
3.使用好的工具进行轻量级的代码审查
4.提交代码前自我审查，添加对代码的说明
经验
代码审查的过程中，对某段代码，当大部分人都理解后便可进行下一步，没必要等每一个人都理解之后再前进。对于那些理解较慢的成员，可以自己做好相关记录，先明白此段代码的功能后跟上团队的节奏，回头在慢慢思考。
困惑
伙伴审查和团队审查都有各自的优缺点，如何更好的选择合适的审查方式？
问题二
问题提出
我阅读了教材的这内容：
整个产品的实现被划分为几个互相联系的冲刺。产品订单上的任务被进一步细化了，被分解为以小时为单位。如果一个人五的估计时间太长（如超过16个小时），那么它就应该被进一步分解。（教材P109
有这个问题：如何更好的进行任务分解，以保证各个子任务的难度、复杂度不会相差很大，避免造成团队成员抢着认领那些容易完成的任务，复杂的任务却无人问津的局面。
相关资料
1.软件开发中任务怎么分解比较好？
2.软件开发：控制复杂度
有这些说法：
分配任务是一个重要的决策。在做决策之前，主管应该充分认识任务本身，充分了解开发者。了解好双方之后再做决策，才能提高决策的成功率。决策失误的概率就会小很多。
主管应该全面掌握各个任务，并划清什么是主要任务，什么是次要任务。还要清楚什么是紧急任务，什么是非紧急任务。在有些时候，主要任务和紧急任务是同一件事情。有些时候，主要任务和紧急任务是两码事。主管应该掌握其中的技术难点、业务难点，掌握开发人员主要会把时间花在哪个环节。
主管应该充分了解每个开发人员的长处和短处，了解他们的开发习惯和兴趣点。效率和意愿是两个重要的因素，前者决定开发者能不能干，后者决定他想不想干。只有在既能干又想干某件事的时候，开发者才能做好某个任务。此外，除了了解每个开发者，主管还应该知道，开发者之间是否能顺利地合作。很多类型的合作都是不成功的，不顺利的，这不光体现在做不同任务的团队之间的合作中，也体现在做相同任务的同事的合作之中。如果合作不是那么有效，就会出现人多反而不如人少的局面。这不利于复杂度的控制。
经验
根据自己的工作经验去评估各个任务的难度，在任务划分时实时调整。任务划分时充分考虑每个团队成员所擅长的领域，扬长避短，让擅长某部分的人去完成相应板块的任务。
困惑
有时团队成员中会存在经验、能力都不是很足的新手，如果每次都让他做一些容易实现的任务，那可能不能很好的提升他的个人能力，如果安排有些难度的任务给他，则可能存在任务不能按时完成而拖慢项目进度的情况，如何划分任务才能保证既不拖慢项目进度，又能让新手得到更好的锻炼？
问题三
问题提出
我阅读了教材的这内容：
软件工程，唯一不变的是变化。所以干脆别幻想客户的需求会在第一时刻很明确，然后保持不会变。但要注意，我们是预期变化，不是期望变化（教材P135）
有这个问题：软件开发过程中遇到的“变化”往往会对项目进度产生一定影响，严重时甚至需要重新规划后续的工作计划。有时，突然的变化也会影响开发人员的心态，例如：你好不容易加了几天班完成的功能，现在突然需要大改动或者不需要了，这听起来就很令人抓狂。那我们该如何应对短剑开发过程中的变化呢？
相关资料
谈谈如何应对软件开发中的需求变更
有这些说法：
设计之初，充分理解需求，更好对需求进行整理和规划，预测可能变更的需求。需求难做，业务难做，非功能性的需求变更更是难做。所以当我们在收集了用户需求后，不仅仅是简单的分类，然后按部就班的开发，而是要深入挖掘需求，一些看似固定业务的需求，可能由于业务的变更而使得你的系统不能使用。我们要做的就是拆分需求，把一些可能会发生变化的需求拆开，改成工作流程可配置的。就像面向过程转向面向对象的那样，面向过程是死的，而面向对象重新组合后，就特别简单。
经验
开发前要提前对用户需求进行分解分类，深入剖析需要实现的核心功能（这些部分通常不会发生较大改变），划分好各个功能的重要程度，再根据这些规划自己投入各个部分的时间和精力。
困惑
除了根据自己的经验去判断哪些可能是核心功能之外，还有没有更好的方法？
问题四
问题提出
我阅读了教材的这内容：
A/B测试当然也有弱点：用户的情绪反应你看不到，你只能看到交互的行为，但是交互的行为不是用户的全部反馈……用网站往前的用户做实验，万一引起巨大的反感，用户就真的流失了。(P264)
有这个问题：
通常，若为了获取用户的反馈强行或反复弹窗提醒让其填写问卷等行为会让用户产生反感情绪，若采用自愿填写的方案，很多用户可能就直接忽略问卷，导致最终的结果参考价值低。那么如何在用户不那么反感的情况下或许有效的反馈结果呢？
相关资料
产品经理们，你们是如何做用户调查和反馈的？
有这些说法：
问卷投放方式：
1、用户访问超过30秒后才显示（如果浏览时间太短，收集的数据是无效的）
2、每个用户30天内只收集一次（避免频繁收集，对用户造成打扰）
3、只在官网页面显示，在后台不显示
通过应用内消息模块，回复客户的反馈，满足他们的需求
1、增加博客板块，增加更多内容介绍；
2、增加客户案例板块，帮助用户了解实际应该怎么样去用
经验
有些游戏会以发放道具为奖励鼓励用户填写问卷，我们也可以仿照这个方式，给填写问卷的人发放一些小的奖励（如网站7天VIP、少量虚拟货币等等），以此吸引更多用户完成问卷。
困惑
如何确保问卷内容的真实性，而不是用户一时兴起随便选的。(有些问卷会设计“这道题选请选A”这样的题目来确保结果的真实性，但时如果用户并不是一眼都不看，而是在读完题目的基础上随便选一个的话，这种方式不也分辨不出哪些是用户的真实体验了嘛？）
问题五
问题提出
我阅读了教材的这内容：
这些事真的要让与项目无关的专业人士来做么？（P315）
有这个问题：
软件开发过程中如果遇到某些板块，交给团队成员做的话能完成但是质量、效果一般，交给与项目无关的专业人士完成的话可能会得到更好的结果，且更加省力，但需要先让对方了解项目，这会造成额外的开销，也会带来新的风险。这该如何抉择？
相关资料
https://www.zhihu.com/question/59063608/answer/2413680584
有这些说法:
要具体情况具体分析，例如：资金紧张时肯定暂时选择前者，资金充裕且该部分内容较为重要时，选后者可能更好。
经验
看项目进度而言，如果进度紧张，团队成员手头的工作安排都很紧凑，那可以选择外包出去，反之可以先尝试内部解决，若结果实在太差则考虑外包。
困惑
如何更好的应对交给专业人士去做的任务最终完成结果与预期成果差距较大的情况？
129
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
