做网站空间和服务器的微信运营
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2023年北航敏捷软件工程 |
| 这个作业的要求在哪里 | 个人作业-阅读和提问 |
| 我在这个课程的目标是 | 学习并掌握现代软件开发和项目管理技术，体验敏捷开发工作流程 |
| 这个作业在哪个具体方面帮助我实现目标 | 通读《构建之法》，了解软件工程中基本概念，初步学习 CI/CD 的应用 |
提问 1
文章背景
文章第 4.3.2 节中写到：
函数最好有单一的出口，为了达到这一目的，可以使用 goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括 goto。
问题提出
我看了这段文字后有疑问。我们在学习 C 语言时都曾听说过 Dijkstra 提出的 “goto 有害论”。本人在编译原理课程上阅读类 pascal 代码时，确实感受到 goto 语句使程序难以理解。并且本人在阅读实际投入使用的高级语言代码时（github 上开源项目或者实习经历）也从未见到过 goto 语句。因此我仍持有疑惑，作者认为 goto 可能使程序逻辑清晰体现这种观点是否不符合主流？
提问 2
文章背景
文章第 4.5.3 节中写到，结对编程是“不间断地复审”：
结对编程让两个人所写的代码不断地处于“复审”的过程，程序员们能够不断地审核，提高设计和编码质量，可以及时发现并解决问题，避免把问题拖到后面的阶段去。
问题提出
我看了这段文字后有疑问。根据我在以往课程中的实践与观察，但有些人的编程习惯可能是有了大致设计后先搭起初步框架，之后具体实现每一部分时再调整，这个过程中可能发现之前的设计有考虑不周的地方进而做修改。这个过程是很自然的，效率可能比“试图想清所有问题再动手”的悲观方式更高。
但如果处于“不间断地复审”，同伴可能对最初起草的框架有诸多疑问、或者在实现上有不同想法，进而引入很多问答环节。那么我存疑，这样会不会导致了两人在实际动手前花过多时间讨论实现方案的各种细节？
提问 3
文章背景
在文章第 4.6 节中写到：
为什么这一节要讲这么多两人合作的反馈问题？因为，如果软件工程师连一对一的合作都做不好，不能有效地去影响同伴，让合作双方都能从合作中受益，提高水平，那大家就别扯什么团队合作这些事了。
问题提出
本人对这种说法持质疑态度。从文章描述的结对编程和敏捷团队合作流程可以看出，二者的合作模式是不同的：结对编程时两人轮流编程，另一人始终在旁复审，随时沟通，两个人几乎处于平等的角色；而团队合作时大家各司其职，有 PM、DEV、测试之分，DEV 可能还分前端和后端。我设想，在结对编程中，如果一个人的能力明显高于另一人，比如拥有 20 年 C++ 开发经验的程序员和 ta 新带的实习生，可能实习生并不能给 mentor 的代码提太多意见，反而还会因为各种问题不懂，需要讲解，而拖慢开发进度。但实习生未必不能参与团队合作，ta 可能可以很好地完成一些相对简单机械、 mentor 没时间亲自完成的部分；或者做一部分测试工作，在此过程中通过阅读代码提升自己。所以我对结对编程到团队合作的必要性存疑。
提问 4
文章背景
文章第 9.1 节这样描述 PM：
你是否觉得你的长处不在于写代码和debug，而是协调、沟通，让一个团队或组织有效运转起来？你是否喜欢表达，善于和各种专业背景的人沟通？你是否经常思考如何该井生活中点点滴滴的小问题？你是否会思考这样的问题么：新浪微博、豆瓣、qq、微信都可以社交，它们的定位、产品特性、用户群、解决的需求，有什么不同？你是否对以下领域感兴趣，甚至自己找过相关的书来看：心理学、社会学、组织行为学、统计学、商业模式？
问题提出
读了这段文字，我对 PM 这一岗位的选择标准有所疑问。想起来实习时组里的 PM 姐姐（CS 专业毕业）曾回忆往昔：“感觉我毕业时那阵 PM 这个岗位特别火，每个人都拿着一本《人人都是产品经理》，但产品经理哪是那么好做的啊！”根据文章所写，产品经理无疑是要懂得技术的，ta 需要“做开发和测试之外的所有事情”，但 ta 还需要协调沟通。那么成为产品经理最重要的特质是什么呢？或者说如何选择产品经理呢？是选择技术了解全面，还是善于统筹规划，或者是团队沟通、领导能力强的人呢？
提问 5
文章背景
文章第 14.6.1 节写到：
要尽量减少非开发时间，不要动不动就开“全体会议”。团队成员们自我时间管理也很重要。
但敏捷开发鼓励每日例会，在文章第 6.1 节中有写到：
每日立会强迫每个人向同伴报告进度，迫使大家把问题摆在明面上。
问题提出
读了这两段文字，我认为这两种观点看似有矛盾之处。本人理解为，作者反对频繁的程式化的大规模集体会议，但小型的敏捷团队需要随时和组员同步自己的动态。但我依然质疑在实际操作中这两者是否如此泾渭分明。在“会前苦心准备材料，会上汇报自己工作进度给老板听，其它同事汇报时就摸鱼”的累赘和“我昨天写代码-我今天继续写代码-我没碰到什么问题-散会”的草率之间的平衡点如何把控？