提出问题

快速通读教材《构建之法》，并参照提问模板，提出5个问题

Q1.P94早期软件行业采用瀑布模型：

它从别的成熟行业（硬件设计，建筑工程）借用了不少经验和模型。在那些“硬”的行业中，产品大多遵循[分析->设计->实现（制造）->销售->维护]这个流程。

众所周知，在当今社会，对于软件工程师的职业，瀑布流程已经不能适应时代的发展，于此，作者在书中列举了瀑布模型的变形，那么在实践中应该如何快速选择可行性的模型，而不需要自顾自地摸索浪费时间，即大概的一个定义。

Q2.P107 根据微软MSDN上的敏捷流程图所得出的敏捷的步骤中第三步Sprint冲刺阶段中提到：

冲刺期间，每天要开一个每日例会（Scrum Meet-ing）， 团队成员大多站着开会，所以又称每日立会。大家依次报告：每日立会强迫每个人向同伴报告进度，迫使大家把问题摆在明面上。同时启动每日构建，让大家每天都能看到一个逐渐完善的版本。

对于该点我有一个疑惑，每日立会明令要求每个人每天向同伴报告进度，但是我们都知道，不论是对于何种工程项目，实施到最后的冲刺阶段可以说是举步维艰，思维和创新都将受到极大的阻碍。前文有言，该阶段中外部人员不能直接打扰团队成员，那么成员将很有可能因为没有外界新鲜事物的灌输而停滞不前。那么对于此阶段真的有太大的必要进行每日的例会吗？就算前一天的工程量不多也要去耗费这宝贵的时间去应付该例会吗？

Q3.P121 软件匠艺宣言：

不仅要让软件工作，更要精益求精。不仅要响应变化，更要稳步增加价值。不仅要有个体与交互，更要形成专业人员的社区。不仅要与客户合作，更要建立卓有成效的伙伴关系。也就是说，左项固然值得追求，右项同样不可或缺。

“不仅要响应变化，更要稳步增加价值”是不是说只要有可见的变化就要响应，为什么不是在计划实施的前期和过程中预见种种变化的可能性并预留可提升空间，而不是把希望寄托在“随机应变”的不确定性呢？

Q4.P329IT行业的创新中的迷思之五：

要成为领域的专家，才能创新。

百度百科上就创新一词有此解释：它是指以现有的思维模式提出有别于常规或常人思路的见解为导向,利用现有的知识和物质，在特定的环境中,本着理想化需要或为满足社会需求，而改进或创造新的事物、方法、元素、路径、环境，并能获得一定有益效果的行为。就个人而言，我认为在很多方面各行各业创新这种东西已经是略显困难的事情了，因为人的社会经验愈来愈多，想法与行为就会愈来愈墨守成规，但是却不乏许多初出茅庐的人，他们没有太多的社会经验，反而能有更多前无古人的精妙点子，所以说“成为领域的专家，才能创新”这句话本身就是片面的。

Q5.个人看法：