读《构造之法》有感
| 这个作业属于哪个课程 | https://edu.cnblogs.com/campus/zswxy/computer-science-class1-2018 |
|---|---|
| 这个作业要求在哪里 | https://edu.cnblogs.com/campus/zswxy/computer-science-class1-2018/homework/11813 |
| 这个作业的目标 | 阅读构建之法并提出自己的疑问 |
| 学号 | <20188384 |
1. 敏捷开发软件的时候为什么秉持着发布时间能短就短的原则？
-
在阅读p108敏捷开发原则的第三条“经常发布可用的软件，发布间隔可以从几周到几个月，能短则短”的时候，根据我的实践，我得到这些经验：，对此我在阅读了6-8章后有了一些自己的感悟：迭代要受到时间的限制，必须在规定的时间完成才能保持迭代的作用，就像老师讲敏捷流程中每天都要进行的站会一样，通过短暂的时间来快速同步进展，从而了解本项目的整体进展只要我们可以保证交付的软件可以很好的工作。
-
从需求分析的方面来说，交付时间越短，我们和客户协作就越紧密，对产品质量就更有益。虽然经过多次迭代，但并不是每次迭代的结果都更贴近用户的需求，但是敏捷开发的目标是让他们可以交付。这意味着开发小组在每次迭代中都会增加—些功能，增加的更多的编码、测试，从而提高了可发布的质量标准的。
查阅资料后资料显示：团队通过每一轮迭代，发布可工作的软件。每一轮迭代结束时，回顾、探讨本轮迭代的过程并吸取教训，并且通过客户的尽早反馈(需求变化或本次交付的某些特性不满足客户需求等)进行可预测的进度安排，让团队尽早掌握变化，把接下来一轮迭代中最有价值的特性优先开发。所以，欣然接受变化的同时不引入混乱的关键，在于频繁发布可工作的软件。 查阅资料后资料显示：团队通过每一轮迭代，发布可工作的软件。每一轮迭代结束时，回顾、探讨本轮迭代的过程并吸取教训，并且通过客户的尽早反馈(需求变化或本次交付的某些特性不满足客户需求等)进行可预测的进度安排，让团队尽早掌握变化，把接下来一轮迭代中最有价值的特性优先开发。所以，欣然接受变化的同时不引入混乱的关键，在于频繁发布可工作的软件。
————————————————
版权声明：本文为CSDN博主「云中洞」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/janeqi1987/article/details/102831528
这也呼应了敏捷开发原则的其他几个原则，非常清晰的体现出敏捷开发原则的优点。这也呼应了敏捷开发原则的其他几个原则，非常清晰的体现出敏捷开发原则的优点。
2. 敏捷软件开发在scrum理论上来看美妙无比，但是实际运用当中会出现哪些问题哪？又有哪些局限性？
-
阅读p109“理论上看，这个方法论真是美妙无比，如图6-1”敏捷软件开发在scrum理论上来看美妙无比，但是实际运用当中会出现哪些问题哪？又有哪些局限性？
-
根据我的实践，我得到这些经验：敏捷软件开发团队就像水桶一样，每个人能力都需要很高，要不很容易在开发过程中因技术差距和开发经验出现巨大问题，而导致过程中出现很多问题，难以全部运用敏捷开发来进行软件开发，组建这样的团队也比较困难，想要确定敏捷程度也需要团队磨合一段时间后才能确定，所以scrum因为太过于理想化而导致容易出现问题。基于国内的环境，我觉得这只能是一种后现代化管理方式，只能代表未来的趋势而绝大部分难以实现。
查看了一些资料后更加确定了我的想法：
特定于我国，敏捷开发最大的问题不是不敏捷，而是太敏捷。
你肯定看过这样的对联：“这个功能很简单，怎么实现我不管。”横批：“明天上线。”
江湖上流传的也是这样的传说，某某团队听说竞争对手在做什么功能，于是加班加点，一晚上就把这个功能抢先做出来了。
从商业角度出发，敏捷肯定是有好处，但是现在敏捷被滥用了，这屈指可数的几个“敏捷案例”被无限夸大，说得好像敏捷压倒一切，敏捷就是快，敏捷就是上午有个点子就撸起袖子干，下午就要实现完，晚上就上线最好。愚蠢！幼稚！和所有正常的开发流程一样，敏捷的终极目的是让开发过程可控，而不是失控，这么疯狂“试错”，拍脑袋就干，不是失控是什么？可是现在我国就是有一帮这样愚蠢幼稚的家伙在自行解读敏捷。宇宙之道，在于阴阳平衡，敏捷应该兼顾快速反应和团队的长期成长，什么都只要快就行了，还要估计story point干嘛，还要统计load factor干嘛，现在我国敏捷实践的问题就是只偏向快速反应，至于方向判断和精细设计全都不要，阴盛阳衰。
作者：程墨Morgan
链接：https://www.zhihu.com/question/33651587/answer/282469647
敏捷是用来提升协作效率的，而无法提升技术能力。国内技术研发团队普遍存在的问题是团队成员的技术能力不足以应对项目需求，这时候任何开发流程都无法实现理想效果，甚至会有负面作用。比如：篮球比赛中发现对手内线防守太强，外场远投才是王道，但是队员的远投命中率惨不忍睹，这就没的玩了。战术都是在技术达标时才能有效用。需要评估下团队目前是缺流程还是缺技术能力，能力提升主要靠培训，技术分享和人员结构调整。技术能力达标后流程的效用才能发挥出来。
作者：姚冬
链接：https://www.zhihu.com/question/33651587/answer/282124088
3.敏捷软件开发是否一定优于传统软件开发？
在阅读完第六章和老师上课讲了一些传统模型后对这个问题非常好奇- 在阅读完第六章和老师上课讲了一些传统模型后对这个问题非常好奇、
根据我的实践，我得到这些经验：
- 敏捷的反义词是笨拙，所以敏捷开发对于传统软件开发的最大有点就是敏捷，但我个人不觉得传统软件（传统软件开发模型主要有瀑布式、迭代式和螺旋开发这几种开发方式）开发是笨拙的。
- 敏捷开发敏捷看来，很多情况下，我们都无法去了解到客户的全部需求，或者即使是了解到，客户的需求。所以先根据主路径，完成主要功能后，我们再通过不断地迭代，去完善我们的工作，这样当我们产生变化的时候，我们推翻的工作量也是少量的，可以很快的去完成新的需求变更。通过这样的不断地变更、重构，我们可以获得一个相对客户满意的产品。但是如我上个问题所说敏捷开发还是有许多局限性的。
- 我也查阅了一些关于敏捷开发的成功案例，其中很少有提到敏捷开发对比传统开发是快速的，缩短周期的，所以我觉得传统开发在现阶段某些项目中也是有作用的。下面是我综合了观点后从资料中引用总结的一些观点
从团队的角度来进行分析，敏捷开发强调直接沟通，如果在团队人数众多，以及人员变动的情况下，就要花费许多时间使团队达成一致。因此敏捷开发更适合稳定的，以及容易达成共识的团队。而人员变动频繁，则适合瀑布流开发中强调的文档及管理工具方法。
敏捷开发适合那些需求不明确的需求，如果需求明确，就像航空航天工业汽车军事领域的开发，就用瀑布开发。
在实际的软件开发项目中，我们的初衷是交付更好的软件，所以我们应该在该敏捷的时候敏捷，该瀑布的时候瀑布。在实际的软件开发项目中，我们的初衷是交付更好的软件，所以我们应该在该敏捷的时候敏捷，该瀑布的时候瀑布。
4. 敏捷开发团队成员觉得某个任务太难或者觉得有些任务太费时间，都不想认领的时候怎么办?
p111书上提出的问题，挺有意思的。
- 根据我个人的理解，这个问题感觉挺难解决的，解决不好很容易导致团队凝聚力下降，甚至解散。
- 关于任务太难，这种就需要团队中有能力很强的人，能认领这些较难解决的问题，或者是将这个难的问题拆分成简单的问题再次进行选择。
- 关于任务太多，团队的领导人物可以将自己的工作与他交换，这样会显得公平一些。- 关于任务太多，团队的领导人物可以将自己的工作与他交换，这样会显得公平一些。
在真正的实际项目中，每个公司或团队的情况都不尽相同，无法穷举所有，应具体情况具体分析。比如，当一个公司首要考虑的是存活问题时，又比如一个刚刚转型的敏捷团队，在开发任务的领取上可能会更偏向于半指派半领取的方式，就像FAQ《从敏捷管理的角度来说，是团队主动认领任务好还是通过管理任务分发好》中所提到的，当团队敏捷成熟度较低时，可先由团队认领再让领导管控。这就好比中国经济一样 “以市场经济为导向，适当进行宏观调控”。但不管这个“调控”的力度如何，我们都应该鼓励团队成员能积极主动地领取任务,并随着任务的进展情况灵活调整，及时做好风险把控，必要的时候需要其他渠道的协调帮助或相关领导的介入，以保证迭代的目标不受影响。
5大量开发后，在形成了自己的开发习惯后我们该怎么保持自己的创新能力哪
- 第16章中，说到现在不管是IT行业还是别的行业人们就某些事物已经形成了习惯，有一些给人们提供更高效率的创新似乎并不被认可，那我们该怎么保持自己的创新能力哪
