第一次作业（个人作业）：阅读教材，提五个问题

2006040126-陈维 2022-10-05 21:20:35

这个作业的要求是：https://bbs.csdn.net/topics/608340396

问题一：

我阅读了8.1软件需求的第一点获取和引导需求，很清晰地介绍了软件团队如何获取需求，但我仔细想了一下，不断挖掘用户的需求是否会给项目带来更大的风险呢？

以我的经验，在项目开始阶段，用户没有真正看到，随着项目开发的推进，用户看到的东西越多，理解得也越深，项目需求可能发生变化，这会为项目带来风险。

我查了资料，综合了几篇期刊和个人的理解得出了以下思考结果：随着项目开发队伍对用户业务越来越熟练，开发人员也会发现原来的一些设计不够合理，需要对项目需求做一些调整，这本身也加大了开发成本，加大了风险。但是用户一旦认可需求的必要性，同意了形成项目的第二期工程，申请资金等流程就会顺理成章了，这样一来也减轻了风险。

问题二：

我阅读了16.1创新的迷思第二点迷思之二：大家都喜欢创新，这句话令我不解：不但大众不喜欢创新，甚至连创新者自己都不例外，有些创新者甚至恨创新。

以我的经验，从小到大好像创新这个东西都不至于说令人厌烦吧，为何这个作者的观点与我们所知相悖呢？

网路上相关的资料实在是少，为此我特地找了一本书《创新者的窘境》，对于高科技企业来说，仅仅跟上快速的技术变革是不够的。企业必须从价值网的全局考虑，综合考虑用户、组织、产品和市场等多种要素，才能理解颠覆性创新的本质，也才能防范其他企业利用破坏性技术对本企业的颠覆。但好像也没能消除我的疑惑。

问题三：

我阅读了9.4领导力——高效的团队讨论，也发现了在国内的开发团队其实经常会有开会问题，而好像较多国外企业没有类似的问题。

我查了资料，在国外的企业有专门针对如何散会的培训，对每个层级的员工都有足够的“会议训练”，而中国许多企业不足这样的培训：如何散会，如何主持，如何记录，如何追踪，如何看待一致，如何会场汇报等的。这些必要的训练，会让公司的会议变得高效。这些外企把培训是看成节约工夫老本的投资，让员工疾速成长。造就员工，让员工缩小犯错，提醒技能，实质是进步了工夫价值。

问题四：

我阅读了第6章的敏捷流程简介，从2001年开始，一些软件界的专家开始倡导“敏捷”的价值观和流程。那么传统项目管理和敏捷项目管理二者究竟有什么区别呢？

以我的经验，传统项目管理通常采用的是瀑布式、部分迭代开发模式，要求在项目建设时，需求足够明确、文档足够规范，迭代过程中需求变更越多、越晚，对项目影响越大，会影响到项目的交付质量。

我根据资料分析总结出了二者的区别：敏捷项目管理是固定的时间，固定团队，不固定的交付物；短期预期规划，误差小，交付早，反馈及时，拥抱变化；交付后项目团队进入下一迭代；更多的关注是借事修人，通过交付目标，修炼团队成员，达成更高的协作效率。

传统项目管理是固定的交付物，不固定的时间，不固定的团队；长期完整规划，误差较大，交付周期长，抗变化(需求+市场)能力差；交付后团队解散，再重组；更多的关注是管人理事，通过管理人员，达成交付目标。

问题五：

我阅读了第4章的4.1到4.3，不难看出在编程相关的书籍里，强调代码的规范性已经是家常便饭，这有什么必要性吗？

以我的经验，代码规范比比皆是，但是很少有公司做好代码规范的。我相信，如果代码规范能够做好的话，且不说开发水平提高多少，至少也会有很多出色的开源项目。

我结合了我前几个学年组队一起开发项目的实践经历，得到了这些经验：一个项目大多都是由一个团队来完成，如果没有统一的代码规范，那么每个人的代码必定会风格迥异。且不说会存在多个人同时开发同一模块的情况，即使是分工十分明晰的，等到要整合代码的时候也有够头疼的了。大多数情况下，并非程序中有复杂的算法或是复杂的逻辑，而是去读别人的代码实在是一件痛苦的事情。统一的风格使得代码可读性大大提高了，人们看到任何一段代码都会觉得异常熟悉。显然的，规范的代码在团队的合作开发中是非常有益而且必要的。

...全文