软工总结
一、课程初阅读提问博客
link
Q1.1： 敏捷开发对于产品的可靠行要求不高？
这里的可靠性应当是相对而言，对于安防国防领域的软件，由于自身特性，在软件设计时首先考虑可靠性。相对来说，敏捷开发对于产品的可靠性要求要低一点点，容忍度好一点。
Q1.2: 这本书适合作为教材吗？
我个人还是觉得，这本书和教材的定位并不同，让我选，是不会用这本书作为教材的。如果从开始筹划一本教材，那么它一定是完全针对于某一门具体的课，融合进多年的教学经验，凸显学习过程中的重点难点的，旨在为同学们构建一个完善的牢固的知识体系。而这本书，感觉要点在于对于已经有一定经验的产品经理，通过优化很多方面的细节，让其水平得到全面的提升。
Q1.3: 大学生如何创新？
现在觉得，创新可大可小，大学生的创新可以在很多小的方面，比如在科研上的小尝试，做web时的界面优化，做算法是的小优化，都可以算是创新，就算其中很多可能失败，也能够为将来更大的创新奠定基石。
Q1.4: 如何评价软件的道德与否？
写软件的人可以道德，也可以不道德，用软件的人可以道德，也可以不道德，软件本身的衡量更多在平庸还是excellent.
Q1.5: 软件说明书写的多详细为好？
能够清晰讲清楚软件的功能和需要注意的细节即可，项目小，那么说明书也可以小，项目大，那么说明书也需要相对大一些。
二、学到的知识点
请问你们在项目的 需求/设计/实现/测试/发布/维护阶段（一共6 个阶段）中都学到了什么“知识点”，每个阶段只要说明一个知识点就可以。
- 需求：对用户的需求的主动了解，不止在项目初期才有，而是贯彻项目始终的，甚至用户也可以参与到项目的开发中来。
- 设计： 设计阶段，项目的划分非常关键，针对组员的特长，合理划分项目，常常能够使得项目开发事半功倍
- 实现： 实现中，面向对象编程的技巧，多线程，进程间交互的细节，都非常重要，这些需要一定的技术上的经验积累。
- 测试： 好的测试，需要对于语言本身，框架本身，或者说技术本身，了解得足够透彻，才能在不破坏测试对象的基础上，构建出优雅的测试。
- 发布： 发布和推广十分重要，实际上，发布是要及早提上日程规划的，有一定的不可控因素在其中。
- 维护： 如果项目设计的足够好，那么日常的维护应当是轻松的，更多在于监控项目是否有异常状态，这对软件的安全性提出了一定的要求。
三、理解和心得
结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得。
- 个人：个人开发中应当注意磨炼自己的技巧，努力提高自己的代码水平。
- 结对：阶段编程中的沟通应当占首位，最好能做到每日check一次进度。
- 团队：组建一个好的团队不容易，应当努力开发出每个人的潜力，激发组员的热情。
总的来说，终于是完成了一个比较好玩又挺有用的项目，过程非常艰辛，此处不提。惯例的感谢和总结，也不想说。想写的东西，只有对于敏捷软工这门课的建议了。我想我作为一个上了这门课的同学，是可以说一些话的。以下。
四、 课程的形式
能够理解，整个课程是想要真实模拟产业界团队开发管理模式，让学生能够在以后的任职过程中有备无患，提升软件工程素养。一学期体验下来，觉得课程更加偏重管理, 比如项目流程控制, 质量监督, 人员管理，项目资源管理。团队协作没有问题，但是锻炼不到所有人，很多组锻炼到的是“背锅侠”， 还不如，仍然个人为单位，把后端、前端、 测试、PM都学到，或者可以轮转角色。课程把很多东西全都丢给团队，团队再把繁重的任务丢给少数个人，这无法让人专心于软件工程，处理各种琐事花费了大量的时间。
4.1 阶段划分
三个阶段真的太多，相比于嵌入式软工、ai软工，敏捷软工这边的工作量明显大很多，这是问过很多同学了的。那么我们应该骄傲吗？明明是一门课，工作量差别太大是不合理的。分程两个阶段会好一点，也少写一些博客。
再之前的个人作业和结对编程对后面大团队作业有帮助吗？我想应该是有一定的作用的，不过我觉得直接开始团队作业，更加节约时间，也有更多功夫去把一个项目真正做好。
- 两个阶段 alpha & beta 足够了。
- 直接开始团队作业，取消结对。可以在个人作业阶段教开发规范，测试规范，用评测机来测评。或者取消个人作业，直接结对编程，然后上评测机。
4.2 评分细则
我想计算分数的助教一定非常累，结对作业中，博客50分程序60分，评分的单位小到0.5，评测过程中的问题也是有很多，可以仿照面向对象课程做一个评测机。一个两学分课的一次小作业，评分这么细碎，有点不合适。alpha阶段的评分，虽然也细碎，但是综合多方的评价是非常可取的。
主要问题在于，似乎，在alpha阶段结束了才放出评分规则, 4月25日好像展示完了，然后分数和评分细则是5月12号发的，令人困惑。
其次，学生互评似乎是只做了参考，用来印证老师和助教的给分？学生更应该是给分的主力军，毕竟学生是大多数，至少应该把分数算进去。
然后，博客占分是否太多，展示分数总共150分，博客分数130，而且博客写的好还能加分，这................................
我一个高中语文课代表实在觉得有失远迎（开个玩笑）。讲道理，课程组让我个人觉得有一点点太过于重视博客，在这次过程中，博客确实是一个团队展示自己的一个途径，但是博客写的不好，也可以创造出一个好的软件。
- 展示150，博客50，会好很多。
- 评分细则要在课程最开始就放出来，让学生有方向，不要放在助教博客，放在博客园班级置顶。
- 评分可以再简化一点，不必那么细碎，当然这是课程组自定义的事情。
4.3 项目选题
为什么要按照黄金点选题呢，自主选题会更好吧。
选题本来就应当自由选题，会有更好的项目和idea涌现，比如做pytorch的可视化模型构建。往届项目应当作为没有好的idea的组来备选的。还是说课程组往届遇到大量的自主选题的情况？那是好事啊我觉得，大家都很creative，有想要实现自己东西的欲望，通过软工课上学到的东西让这些点子很好地被完成，会是很有成就感的事情。好的项目是有生命力的，好的idea会一直有人想要去做，让学生自主选题，发挥自己的创造性，会有更多有生命力的吸引着一届又一届学生的好项目出现的，甚至有得项目能够真正落地，开创一个公司，甚至是王朝。当然课程组给出的几个项目都不错。
所有团队都自主选题。
好的项目，结束后投票决定谁能传承给下一届。
4.4 博客
一共大概24次的博客作业，实际团队一共47篇博客，个人博客3篇包括内容比较少的30篇每日例会博客。负担太大。
（统计于6.17）
- 每日例会有必要或者说有用吗？讲道理，在课程中团队推进项目时，是非常有用的，因为团队成员很可能划水，及时开会可以了解进度.
- 那么有必要写成博客吗？我觉得没有必要，很多东西在github上都有记录，而且要想伪造博客，也很容易，但是现在我们却需要专门的写文档的人去负责搞定。
- 发布博客，发布博客是有必要的，毕竟要展示给课程评分人员我们做了一个什么样的东西
- 测试博客，这可以合并到发布博客，为了评分需要单独划分，也行。
- 展示博客，这真的是个有点匪夷所思的东西，博客是一个适用于阅读的载体，在展示能力上，它完全比不上PowerPoint， alpha阶段用博客讲演的时候，真的是要多别扭有多别扭。
- 总结博客，有必要的，可以和下一阶段的预期计划(这个博客要求没有，课上通常说加在功能规格说明书中)可以合并在一起，总结完了，计划和展望未来不是很合适嘛？
- 采访博客就...没必要了，形式上好，似乎有种承接前人经验的感觉，后面自己做项目感觉帮助也不大，对于做往届项目的组，想采访也行..，还有很多组直接重构重来。
- 技术博客可以有更多要求，每个团队拿出3，5篇好的应该都不成问题。
团队作业结束后，团队管理经验博客也可以有，课程中学到的东西，什么有用，什么没有用，讲个清楚，给我们的课程组更多的经验。
功能规格说明书x1 + 技术规格说明书x1 + 2x阶段x(发布博客 + 上阶段总结与下阶段计划博客) = 6
功能规格说明书x1 + 技术规格说明书x1 + 2x阶段x(发布博客 + 测试博客 + 总结与计划博客) = 8
功能规格说明书x1 + 技术规格说明书x1 + 3x阶段x(发布博客 + 测试博客 + 总结与计划博客) = 11
采访 + 项目选择 + 功能 + 技术 + srcum_meetingx30 + 贡献分规则 + 3x阶段x(展示+测试+发布+分析) + 博客目录 + 团队贡献分汇总 = 47
- 博客应当大幅减少，写博客不是目的，学到了什么才是目的。
- 博客的内容也可以有调整，形式化的博客要尽可能少。
4.5 人员及转会
转会这个制度好吗？我觉得很好，如果是三个阶段，应该两个次换人，谁表现差换谁。社会只会比大学里要残酷，要模拟真实环境，那么转会制度应该更强力。团队留不住人，组员自己不努力，都自己负责，甚至使用淘汰制度也不是不行。（当然这里可能考虑不周）
另外，一开始的组队的规则太严了一点，比如说，如果我现在想要找一个好的前端，但了解到班级里面前端做的好、态度又端正的就那么一个，还和我同系或同班或同寝室，那就完全没办法。
课程组的初衷我猜想是模拟真实条件下，我们总会遇到新的成员，模拟磨合的过程，那么问题来了，我们一般是不会遇到所有人都是完全新的状况，而且公司招聘，一个组内的人，大家水平通常都差不多，谁也不会太坑，招聘是拿着需求去挑人的，我们组队也是拿着需求去挑人的，但是公司招聘他们有的选，还要选好的，而我们组队，就这一个班，在相对严格的组队要求下，我们没得选。而且就算是自由组队，也几乎都会遇到不熟悉的人，况且再不济，也还有换人制度，容易换到陌生的人，仍然可以模拟真实团队。
- 完全的自由组队。
- 更好的转会制度。
五、 课程的内容
《构建之法》很有水平，技术也很好。
但我更想看到更多我们北航老师自己的经验，如何投标，如何引资，如何拿到关键技术，如何监督团队进展，什么什么什么局需要什么什么功能规格说明书，所以我们需要会写技术规格说明书，什么什么技术是我们将来一定会遇到的，git的常用指令和高级用法，统计一下目前世界五百强使用的项目管理方式，技术，开发与测试与PM的比例，要看到数据最好，是吧，学生你看你未来是一定要用到git的，一定会需要开组会的，一定会遇到各种各样的测试，而且产品经理会很烦人，怎么个烦人法呢，巴拉巴拉，可说的东西一定是很多的。软件开发环境国家重点实验是在我们北航，一定有非常多东西可以教给学生们。
如果讲开发的时候请一线大厂程序员来讲45分钟会不会更好，讲测试请专门做测试方面研究的老师来讲或者请一线测试人员讲讲自己真实做测试的时候用的什么工具，一个项目写了多少测试用例，他们一线工作的PM用过哪些软件工程方法，觉得什么方法更使用于他们的项目，这就很有价值了吧。
模拟终究是模拟，不是真实的工作实战，如果软工能够和生产实习挂个勾，找个合作单位，让年轻的程序员们去当免费劳动力，锻炼一个学期，会不会更好？或者让企业中毕业的北航自己的学长回校当一个学期的助教，甚至直接带一个项目，带一个团队，带个一周也好，薪资给够，会有人来的吧。和企业合作，那么企业一定会对表现突出的苗子非常有兴趣招揽吧，而且代码风格差的人，码力弱的人，也可以通过企业的标准来认识到自己的不足。（当然都是理想化的猜测，只是觉得这学期的课上下来，总觉得还可以更好，和企业合作或许很难完成）
以上。