这个作业的要求是:https://bbs.csdn.net/topics/608340396
第一个问题:我阅读了材料第二章2.4的内容,我阅读了“对模块进行修改时,不必改变模块的本身”这一内容,有这个问题:软件实体是什么?为什么在产生了新的需求或要修改功能时不能直接修改模块呢,只是扩展不会留下一些已经没有用的部分吗?
我查阅了资料:对模块行为进行扩展时,不必改动模块的源代码或者二进制代码。模块的二进制可执行版本,无论是共享库、dll或者Java的jar文件,都无需改动。怎样可能在不改动模块源代码的情况下去更改它的行为呢?怎样才能在无需对模块进行改动的情况下就改变它的功能呢?——关键是抽象!
根据我的实践,我得到这些经验:有些底层基础的实体部分,虽然新功能可能用不到他们,但是大部分功能可以用到,就需要保留下来他们,不需要删除,这就避免了修改功能是的重复部署。但是我还是有一些地方不太懂就是,如果修改一次功能就进行扩展而不删减,能如果一直修改优化功能,最后那个软件实体不会变的非常庞大吗,那对于后期的维修优化不会造成很大难度吗?
第二个问题:我阅读了材料的第六章6.1敏捷的步骤第三步里“一切交流只能通过Scrum Master来完成。这一措施较好的平衡了“交流”和“集中注意力”的矛盾”。有这个问题:首先scrum master是什么。
我查阅了资料:ScrumMaster是组成Scrum团队的三个角色之一。产品负责人主要负责构建正确的产品,开发团队负责以正确的方式构建产品,ScrumMaster则主要负责帮助产品负责人和开发团队中的每个人理解和拥抱Scrum的价值观、原则和实践。对于Scrum团队中的开发团队和产品负责人来说,ScrumMaster履行的是教练职责。对于Scrum团队及团队所处的组织来说,ScrumMaster也履行主导过程改进的职责。
根据我的实践,我得到了这些经验:SM相当于整个团队的核心人物,负责整体沟通联系大框架。但是我还是有一些疑惑:感觉SM要负责的任务好多,而且一切交流只能通过SM会不会太麻烦了,直接内部人员进行交流不会更方便吗?
第三个问题:我阅读了材料第七章7.2.7投资质量:团队成员应该有共识:防止缺陷的发生成为团队控制质量的首要任务,所有角色都应该对质量保障负责。我的疑问是:“所有角色都应该对质量保障负责”这句,前文说道,有很多团队会把开发和测试有意无意的对立起来,就是说这会造成团队不能达到合作共赢,所以要讲集体有责,这个我可以理解,但是质量出了问题所有人负责会不会有点过于绝对,如果一个人频繁出错所有人担责会不会打架团队成员的积极性。所以我在想能不能出一个比较系统的问责制度可以既团结成员还能规避这个问题。
第四个问题:我阅读了材料第八章8,6,3项目的复杂程度有以下两个决定因素:1.需求的复杂程度:程序员是第几次实现类似的需求?有些外行看起来很复杂难懂的需求,如果一个程序员已经做过很多次相关项目,其实不像外人看起来那么难。2.技术的复杂程度:程序员是第几次用这个技术实现。我的问题是:第一点比较容易理解,但是第二句那句话我不是很明白它的意思。什么叫程序员是第几次用这个技术实现,这和技术的复杂程度有什么关系?
第五个问题:我阅读了材料第15章15.1.4招数:ZBB:团队要有把所有bug都搞定的执行力。团队在bug数量上上下下的过程中要让老的bug数量为零,而且当测试人员和用户使用到新功能时bug数量会以惊人的速度反弹。我有两个疑问:首先反弹难道不是数量越来越多吗,为什么会像阻尼振荡一样越来越少趋近于零,这些bug是怎么消失的。其次在bug出现的过程中要不断的消灭所有的老bug,这对于程序员来说会不会工作量过于的巨大,我对于这个具体的工作和解决办法没有过多的概念,这也是我比较想知道的问题。