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