软工个人总结博客
对于原来提出的问题的解答
的确，如果以这样的形式进行结对编程，出现bug的概率会大大降低，也有助于遵守各种编程规范。但是，这样的方式无疑舍弃了“并行”的优势，尤其是在进行到逻辑简单，难度较低的部分时，出现bug的概率不高，若两人分工同时进行，无疑可以大大提升完成速度。我的疑问是，结对编程是否更适合在学习、培训过程中采用？在实际生产中结对编程真的能取的更高的投入产出比吗？
回答：经过一个学期的实践，我认为结对编程在面临复杂问题、复杂算法、或个人状态不佳时，的确对效率有着正面影响。因为在实际工程中，某一功能或某一页面出现了一个小bug，往往非常难以发现，常常会在产品上线后，碰巧对某位用户的使用产生了影响、进行反馈后才能发现。
而即使在检查中就发现了BUG，要将BUG现象的原因具体定位到某行代码也是需要花费非常大量的时间的。此时，通过结对编程的方式可以非常有效的减少bug的产生。
需求的变化一直是乙方最为头疼的问题之一。我理解敏捷流程中通过快速迭代的方法来适应需求变化的原理，但是，对于那些已经定好、实现完成的需求的变化，仍然需要推翻原本的设计与实现，再进行更改。对于这类已经确认过、且实现完成的需求的更改，我认为多少是有些不合理的。那么在实际生产中，对于这种需求变化，也应无条件接受吗？或者说对于需求变化的欢迎的极限应该在哪里？
答：根据最后实际开发小程序的经验，甲方的基本需求，或者说所提需求的实际目的一定是为了满足用户的需要，这一点是永远不变的。因此，无论如何甲方的基本需求是不会动摇的，因为这是用户决定的，而非甲方决定。
在一个创新想法，尤其是一个颠覆性的创新、跨度较大的创新想法出现时，在当时的场景下常常出现“找不到应用场景”、“短时间内不知道有什么用”的情况出现，某种程度上也符合上述书中列举的理由。那么对于这样“短期内不知道能有什么用”的创新想法，应如何客观的评价其前景？应投入多大的时间、精力在其中？
答：我认为，对于一个“暂时找不到应用场景”的创新想法到底具有多大的潜力，是一个非常难判断的问题。我认为这往往极其依赖于管理者的经验和个人能力，尤其是对用户需求，甚至是用户自己都不能清晰表达出来的更原始、更基本的需求的理解、掌握能力。
作为计算机专业的学生，将来必然是“领域内”人士之一，那么如何避免形成如同“领域专家”的固化思维，导致自己的创新思维收到限制呢？
答：创新所需要的必要条件，并不是身为“非领域内”人士。而是拥有与大部分“领域内”人士不同的，独具一格的思维方式。这一点可以通过了解一些其他领域的知识作为爱好来实现。
在这学期的软工中，由于作为PM需要进行大量页面设计工作，因此我去了解一些设计、视频制作等方面的知识。在这一过程中，许多拍摄、剪辑的巧妙手法都让我叹为观止，这些手法的基本思想非常非常具有启发性。
这里附上视频链接。这种类似魔术的误导手法在视频拍摄中也起到了非常神奇的作用，而实现方法又非常简单粗暴，让人惊叹。
全书中多处提到，在团队合作中应多交流、多沟通，才能提到合作效率。这一点我非常赞同。但是在团队中的成员们相互沟通的过程中，对于一个问题，即使达成了共识，也常常因为每人的思维方式不同，导致双方心中的答案并不一致。书中提到的尽量面对面交流确实相比文字、语音交流的效果更好，但也不能避免这一问题的出现。那么有什么好方法能尽量降低理解误差，确保大家达成”共同意见“时，每个人脑中的理解都是相同的呢？
答：每日例会的存在让我们进行了大量的交流。这一过程中，我发现，以下两个方法可以非常显著的降低理解误差：
能面谈的尽量不要通过文字、语音方式进行。
面谈可以有效降低理解误差。面谈时，对方对你传达的消息的反馈更加直接，同理，对方的表达的信息缺失也会更少。相比在线的文字、语音等间接交流方式，面谈的效率高得多，准确率也同样更高。
尽量多的使用画示意图等方式表达
许多时候口头交流无法满足我们所需要的精确性，尤其是对一些比较复杂的问题。利用手边的纸笔，绘画一些简单的示意图，可以非常有效的提高表达的准确性。
新的问题
在这学期的软工实践中，我的分工是PM。在之前的一些合作中，由于大家比较熟悉，往往都没有指定明确的管理者，基本靠大家讨论进行决定，各自主动完成各自的任务。但是，这学期的软工中，由于明确分配的PM这一管理者角色，因此就出现了其他成员思考、计划的主动性降低的问题。往往需要PM向成员极其详细的说明任务的具体内容、DDL后，才能按时完成任务。对于团队其他成员来说，既然有了PM，那么计划、规划就不是我的责任，不是我的责任就不用我操心去想，PM有给我布置任务我就完成，PM没有布置我就不管。对于PM没有布置的任务，成员此时似乎不再会考虑“这个东西我不做的话是不是会影响最终的成果”，而是想“PM没给我布置就不是我的任务，最后影响了成果是PM的问题，和我没关系”。没有PM时大家的上级是老师，因此考虑的是如何满足老师的要求，也就是产品本身。而有PM后，成员只考虑如何满足PM的要求，对于产品整体的考虑似乎变少了。
我的问题就是，作为管理者，如何提高大家思考的积极主动性，尤其是对于产品长期规划的思考主动性呢？
我学到的知识点
需求阶段：
需求分析是产品的基石，详细完整的需求分析可以保证产品大方向的正确性。
需求分析做的越详细、越彻底，就越能帮助团队弄清用户的实际需求是什么，用户想要的是什么样的产品，使用这个产品去做什么样的事。只有明确了用户的需求，才能确定产品的定位、产品的核心功能。有时，甚至用户自己都不能将自己的需求明确、清楚的表达出来，这就需要团队在详尽的需求调查的基础上，花费足够的心思进行分析。
设计阶段
对于没有美术设计经验的程序员来说，设计的难度不亚于具体的实现难度。一定不能低估设计类、美术类工作需要的时间。
在Alpha阶段我们一度认为设计不需要太多时间，因此直接交给前端负责实现这个页面的同学进行设计。但是在实际工作中，开发人员被设计工作大大拖慢了开发进度，并且最后完成的页面美观度也不高。但是在接下来的两个阶段中，我们专门分配了人员（我）去完成设计工作，这时才发现，想要有好的UI、布局、配色是一件非常难的事情。
实现
积极使用搜索引擎，能有效提升开发效率
目前我们需要实现的大多数东西，都是相对简单，并且已有前人实现过的。因此，积极使用搜索引擎，避免重复造轮子，不但能减少大量的开发时间，提高效率，且大部分情况下，优秀的，经过多次修改的开源代码质量往往也比自己在短时间内实现的成果更高。
测试
只有实机测试才是唯一的可靠标准
我们产品的开发适用的是微信小程序。微信小程序的开发是不区分操作系统的，即对于安卓和IOS完全相同。但是，在我们的实际测试中，我们发现许多微信小程序自带的功能、控件在IOS下都会出现问题。因此，即使在编程时完全正确，最后也有可能出现问题。因此，只有实机测试才是唯一的可靠标准。
发布
提前了解产品所要部署的平台有何限制是非常重要的
由于我们没有了解透彻个人版微信小程序在功能上有何限制，导致了我们在Beta阶段的发布延后了一段时间。因此，提前了解所要发布的平台对于产品有何限制，并且在发布阶段留出足够的缓冲器，对于顺利、准时完成发布是非常重要的。
维护
后端服务器中的内容一定要备份
在我们Beta阶段末尾，由于未知原因，我们的服务器一度被墙了。。墙了。。。。。。。幸好最后通过后端同学的努力，挽救回了数据库中的数据。不然可能需要大量的时间重新录入数据。因此，为了避免意外的发生，最好数据库中数据的备份是非常重要的。
个人理解与心得
在团队项目中，我担任了”Water_T“团队PM的角色。在团队中，我负责几乎所有博客的撰写，和绝大部分规划、策划、设计的工作。因此，我基本不用进行多少编程工作。但是，相比于开发，这份工作也绝不轻松。在大多数时候，PM需要更多的考虑、操心接下来要做什么、如何做、多久做才能把产品做的更好。这是一个相比开发工作来说抽象的多、不确定因素更多的工作。可能负责开发的同学在完成了某个页面、某个功能的实现后，下个任务开始前就可以开心摸鱼，将这门课抛之脑后，但是对于PM来说，需要随时都关注每个任务的进度、每个任务的完成质量，考虑是否需要修改计划、如何修改能让结果更好等等等等。对于PM来说，压力是长期的，持续的，这一点与之前承担的大部分工作都有一定区别。
同时，担任PM也让我再次意识到了管理所需要的知识、经验、技术，任何一项都不亚于编程。如何考虑到每个人的不同性格、不同能力，让所有成员作为一个整体顺利的运转，并且通过合作实现一加一大于二的结果，是一个非常抽象，且对于每个团队都是完全不同的问题。这个问题往往没有任何可供复制的前人经验，而任何网络上、其他人能提供的意见也都是抽象的，虚无缥缈的，往往包含“适度的”、“恰当的“等等定义模糊的词汇，只能通过自己的实践去摸索，寻找答案。我认为这些是在计科教育中极其缺乏，但在工作中又非常重要的，值得每位同学都去尝试、学习。
给软工课程的一点小建议：不同老师的软工课程，教授的课程内容、布置的课程作业完全不一样，而所需要付出时间据我了解也有非常巨大的区别，可以说不同老师的软工课程完全不是一门课。但是，软工又是一门人人必选的必修课。这样的话，在最后的评分上难免会有一定的不公平，尤其是在大三下，无论是考研、保研、还是工作都至关重要的这一学期，可能对于个别同学还是会有比较大的影响。
最后，能与团队的大家共同努力是我的荣幸，最后完成的产品也让我非常有成就感。这一学期的软工课程尽管辛苦，也真的学到了很多。祝软工课程将来越办越好！