在一个技术产品的不同生命周期都有他不同的动量和加速度，当进入衰退阶段以后甚至是成熟阶段的时候，如果通过加入颠覆性的革新，来使得他的加速度猛增（有点像老树开新花的情况），此时这个技术产品生命周期是否算是回溯了，还是应该把新加入的技术部分当作一个独立的技术产品来看待？比如前几年很多的自走棋玩法，游戏Dota2再加入自走棋玩法以后，用户量和用户粘性激增，迅速拉拢了一大批的下棋玩家，甚至一度超远原来的成熟期的高峰。虽然后来热度又被其他的自走棋游戏瓜分掉了无独有偶，游戏英雄联盟也推出云顶之奕玩法，炉石传说推出酒馆战旗玩法，我很喜欢这个模式，至今有在玩，甚至是王者荣耀也推出过类似玩法。再比如有很多游戏也都效仿PUBG的成功案例，加入了大逃杀的玩法。这些个情况是否算是同一个技术产品的生命周期，如果算，其中很多产品已经到达用户量下降，但仍然有收益的衰退阶段了，焕发第二春以后要怎么算他的生命周期。
认领和分配任务是一件很难权衡的事，对于同样的一个要求，大牛和狗熊程序员需要的时间和精力肯定是不一样的，可能对于有的人来说很简单很快完成的工作，换另一个人就要处理很久，那这种时候是该考虑重新安排任务，还是考虑更换就职人员？假如说没有可换人员的情况下，按能力分配任务，将会出现每个人虽然花的时间精力差不多，也没怎么摸鱼，做的内容却不一样多，会不会导致一些人心里不平衡？此时又要怎么安排薪酬？我自己之前和同学一起做项目就遇到过这种情况，一开始对于要做的任务的难度和体量没有太大的认识，导致后面有的人很划水，有的人却忙不过来。最后好歹是把项目完成了，可是心里却挺不平衡的。
在非常小规模的代码时是否还需要在单元测试上花费大量的时间提高覆盖率呢？
PM和乐团指挥的作用是一样的吗？在查了资料以后发现，大部分乐团指挥都是精通乐理，对音乐会有自己的理解，并不会精通每一种乐器，但是一个人可以提升整个乐团的水平，所以我觉得PM和乐团还是有区别的，在教材中看到更多的是PM是在交流和沟通；根据在之前的写代码实践经历以及UML项目设计经历中，每个成员都在沟通，就像大家全是PM一样。
看了十六章的IT行业创新的16.1.6 迷思之六：技术的创新是关键。我有一个问题，最关键的是技术创新还是好点子呢。在查了资料以后发现，大部分的人都认为技术创建是关键，在曾经的学习中也曾学过“科学技术是第一生产力”。但是在看到如今社会上很多例子并不像这样，如一些外卖程序和共享某某物的程序。并不是在技术上的创新而是有一个超前的思想把握了当下的热点而取得的成功。所以我的困惑是，在以后的从业生涯中，如果想创新是把握机会还是刻苦攻坚技术突破呢？
我有一个问题，我们在创新时是应该寻找一个没人涉及的地方还是从已经广为流传的方面下功夫想创新呢。
在二人合作时是要互相了解并介入对方的工作时刻监督对方还是完全信任，注重反馈互相鼓励呢？
既然我们学会了单元测试之后，那么应该在什么时候进行测试呢？又比如像C++、java这类面向对象的语言，我们是应该每构造玩一个函数之后再测试还是在每一个类完成之后统一测试？如果每完成一个很小模块就进行测试不久会很繁琐且费事吗？但是如果在整合小模块之后再测试，虽然会减小工作量，但是万一出错的话不就很难查找到问题所在吗？这两者之间该怎么权衡呢？
像“将六面魔方还原然后再将其打乱成原样”一般地两者都精通自然是好，但是鱼和熊掌不可兼得，那么在我们学生时代结合当代的软件开和未来的就业形势，当前我们更需要哪一种技能来提升自己呢？
用户的反馈显得非常重要。不断完善功能的过程很冗长，这样不就会使得软件开发周期很长吗？而且如果市场反馈不是很积极的话，该软件的开发就十分被动和艰难，甚至有可能会消失，遇到这样的情况该怎么处理呢？
小强地狱讲的是开发人员可以忽视一定量的bug，优先保证核心功能的实现。
然而在我看来这是一种不太好的开发模式，开发人员往往会受到心理惯性的作用从而导致bug的堆积，测试人员处于长时间空档期或者突然一大堆东西需要测试，很浪费时间和精力。而且经历过修改bug的我们都知道，这是一件很容易让人心态崩掉的事，所以会降低开发人员的工作积极性。所以在软件开发的过程中，同时进行一些简单的数据测试，同时修改bug，通过了之后再拿到测试人员处进行更精密的测试，找出更棘手的bug，再统一修改，而不是一昧地开发。这是不是一种更好的开发模式呢？