Tsak1 提出问题
快速通读教材《构建之法》，并参照提问模板，提出5个问题。
如何提出有价值的问题？
Q1.
- P107 :
“只用一次”的程序
“看过就扔”的原型
一些不适用的演示程序
但是，要写一个有实际用户，解决实际需求的软件，这个方法的缺点就太大了
许多学校的软件工程作业的要求符合上面那三点，所以难怪同学们觉得没有必要用其他的开发方法，“写了再改”足矣！
我的疑惑是除了“写了再改模式”其他的团队发模式是否真的适合大学生团队在学习软件工程这门课的初期进行团队开发？
我认为，对于我们学习软件工程这门课的同学们来说，大家都是第一次进行团队开发，而且技术参差不齐，即使一些成员有一些开发经验，可是他也未必能按照其他的开发模型按部就班的做下去，更何况大部分同学都是第一次做这种团队开发，所以“写了再改”这种模式就成为了大家的在不知不觉中的开发方法，而且每位同学对这学期的计划都不相同，如果这些同学志不在此，但是还要花费很多时间在其他的开发模式下，那么这些同学的开发进度可能反而还会拖累整个团队的开发进度。
Q2.
-
p353
"70%的创新者说，他们最成功的的创新，是在他们的拿手领域之外发现的"
对于这句话我想说，这些创新者是在他们所擅长的领域之外发现的“新大陆”，然而他们在不擅长领域创新的前提是，他们已经在其他领域摸爬滚打成为一个有经验的人亦或是专家；那么这些创新者是如何保证在拿手的领域里钻研后，又有精力去其他领域涉足，进行创新的，那么我们应该如何可以做到像上文提到的优秀创新者那样呢？
Q3.
-
p185第八章需求分析中，一个团队完成项目时可以采用“分而治之”的方法
对于这种方法，是做项目时的正常逻辑思维，但是将大的工程细化为一个又一个小的工程时，这些小的工程在做的时候又会存在千丝万缕的关系，我们应该如何处理呢
Q4.
-
p723页，“如果某个看似不明显的交互操作解释过一次之后，就很容易理解，那么这就是一个好设计”
我的疑问是，当所完成的软件不是那么容易理解，用户在按步骤操作了几步之后就可能会失去耐心转而寻找其他代替软件时，那么该如何进行UI的设计呢？
Q5.
-
P368
"一个产品在其生命周期有不同的阶段，每个阶段有不同的关注点，适时适当的功能点创新，就能改变竞争局面；不合时宜的创新，则往往隔靴搔痒，事倍功半"对于作者这句话，我非常赞同，但是如何把握创新的时机呢，创新早了用户接受不了，创新晚了则市场会被他人抢占，是通过定期的用户调查表，还是根据某些规律，或是项目经理的直觉？