73
社区成员
发帖
与我相关
我的任务
分享[I.3] 个人作业：结课总结
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2024年北航敏捷软件工程 |
| 这个作业的要求在哪里 | 个人作业-提问回顾与个人总结 |
| 我在这个课程的目标是 | 学习敏捷开发 |
| 这个作业在哪个具体方面帮助我实现目标 | 回顾学期开发经历，回答先前疑惑，总结并提升。 |
Q1：在开发过程中，我们应该如何分析问题，又不陷入分析麻痹的思维误区中
当时的提问是：对于软工，我们应该需要全面分析任务的可行性才开始动手编码？比如想要添加某一个新的功能或优化，我不应该是弄清楚该优化部分的所有细节吗？那我应该如何处理分析问题和分析麻痹之间的界限呢？
经过一学期的软工经历，我再次读这篇文章，发现写的确实很正确。书中介绍了分析麻痹，形容开发者想弄清楚所有细节，所有依赖关系之后再动手，不想修复问题。经过这学期的实践，我认为这个经验非常宝贵，我们在软件开发中也是先完成最小可用，然后不断增量开发，不断解决问题！对于之前的疑惑，我目前的答案是：
- 我们不需要全面分析任务的可行性，但我们需要认真地做好需求分析。需求分析会深刻影响后续的开发的方向。包括系统设计、技术栈等内容。
- 假如需要做优化，确实需要熟知该优化的细节，但我们并没有必要去想着实现该优化和所有功能的结合。我们可以先把优化开发出来，再不断debug和拓展支持更多的模块。正如书中第三章所说，我们不能过早地去实现扩大化，一个通用的解决方案也必然会带来极大的复杂性。
- 分析问题是理性的，是一条为了寻找解决方案的道路。而分析麻痹，我个人认为在你调研过后，有了一个广泛的认知，且找到了一条合适且可行的开发路线，就可以着手如何进行后面的实现了，而不是继续卡在分析技术之上。另外，分析问题不应该进行一个泛化的思考，不要想着完美的通用性。
Q2：结对编程中如何更好地做好领航员的责任
当时的提问是：对于一名代码水平较高的成员，应该如何去做好领航员的责任呢？不应该会有自己动手，以便于更高效率地完成任务吗？而对于一名代码水平较低的成员做领航员，又应该如何更好地配合同伴编码呢？在知识储备不如同伴的情况下，是否会发生跟不上队友的情况呢？那就更不必谈及领航了。
结对编程的本意是写出更短的程序，更好的设计，以及更少的缺陷。一名代码水平较高的成员，确实可能在结对编程初期获得更高的编码效率。并且，有的不恰当的组队方式肯定会导致效率低下或没有结对编程效果。这是合理的，结对编程本来就不是一件可以百分百让开发效率提升的事情。但两位成员一起结对编程，潜在会有很多作用体现在成员可以分享系统细节，学习编程技巧；成员可以互相监督，提高效率；成员可以交换思路，减少设计的缺陷。
假如一名成员知识储备低，他就可以做些辅助性的工作，比如测试、重构、检查缺陷之类的。并且，我们需要对结对编程更包容一点，给予一些其他成员成长的时间。当能力较弱的成员在在交换思维中获得了成长，慢慢他也就可以达到领航的要求了。这样对于一个团队来说，也是一个良性的发展。
Q3：在工程开发初期用户调研有什么好方法
当时的想法主要是我们平时问卷收集信息，也会发现我们经常收集到无用的信息，大部分用户不喜欢花费时间去反馈信息给软件开发者。除此之外，在工程开发初期，目标用户的体验不足，很有可能会造成目标用户对痛点的体验不够深刻，目标用户面临着无法总结出应用程序的痛点的情况。那么，我们应该如何在工程开发初期来收集更有用的信息，深入挖掘用户痛点，更好地引导用户总结出使用体验，从而解决这个问题呢？
开发团队可以从社会发展趋势之类凝结出需求。比如我们团队，在本下次软件工程需求分析时，就通过观测当前编程教育愈发普及的社会现象，且许多中小城市的编程教育远不如北京等大城市的背景，凝结出”教育水平落后的中小学可能需要一款课堂上可以使用的编程对战游戏来推动编程知识的普及“。
Q4：采用轮值PM时如何解决混乱问题
PM主要需要负责的工作是正确地协调团队内部外部，调配各部门资源和时间，有效进行风险管理，保证一个项目顺利按计划结项。经过一学期的体验，我得出的结论是：轮值PM不可行（悲）。假如采用了轮值PM，每个人对项目的理解、认识和投入度都不一样，一旦采用这种方案，导致混乱的可能性非常大。不过我们团队也没有实现真正意义上的轮值PM，只是在建队初期没有得出谁当PM的结论。到后面开发过程中，就基本前后端都有类似负责人的角色，来推动、协调整体工作的完成。所以我们在真正开发中并没有因为采用了轮值PM而导致混乱。
Q5：如何评定绩效，促进团队更加积极地合作？
采用量化的工作汇报！量化非常重要！这学期从课程组学习到的宝贵经验就是采用量化的工作量汇报！我认为需要收集可量化的工作量，对于一个团队来说是可以良性发展的。比如我们团队就非常良性。并且，这个经验不仅在软工团队中可以收益，在其他团队合作中都可以收益。从我个人来说，假如采用不量化的工作汇报，我过去就很容易没干什么事情就糊弄过去，比如组会之类的；但本学期的软工开发就不会出现这种问题。非常有效的一个方法。
实践中学习到的知识点
- 需求
我认为需求分析可能是软件工程中最为重要的事情。这会深刻影响后续的设计和实现，没有一个好的需求分析，软件项目可能是无用功。
设计
分层设计很重要！对于以后的开发和维护都很有作用。可以直接采用一些成熟的设计方法。
实现
开发中尽量减少团队成员之间的耦合度，各自钻研一个领域或一个功能，在敏捷开发中可能会效率更高。
测试
单元测试对于开发过程十分重要，可以排除非常多小的问题，对于系统稳定性很重要。
发布
建立用户反馈渠道很关键，在发布过程中很容易遇到很多问题，提前提供好渠道有利于迅速解决问题。
维护
维护过程中的修改也需要经过测试再进行发布！不然很容易为了解决问题而引入另外一个问题。
个人心得
本学期的软件工程还是收获非常大的。无论是从团队合作、项目开发，还是从需求分析、用户调研，都能学习到非常多新的观点和知识。同时，在开发过程中，也会遇到一些安全性不佳、题库质量不够好的问题，也让我意识到一个好的软件需要具备这么多内容。但总体来说，体验良好，收获颇丰。
...全文
请发表友善的回复…
发表回复
