敏捷开发框架下的软件工程/第一轮迭代/知识库
| 知识库 |
|
|
设计规范是将交互设计中看似模糊的想法细化为详细的蓝图，以便交给程序员。
在敏捷开发框架的第二轮迭代中，设计规范是我们可以给程序员的详细指令（认识到，在许多情况下，这实际上是我们戴着另一顶帽子）。在第二轮迭代中，我们将致力于第一个“功能交付”，并将开发详细的屏幕界面布局、数据结构和系统图表等等。类似地，在第三轮迭代中，其结果是“稳健交付”，我们将拥有所有这些，再加上详细的测试规范。
那么，我们在第一轮迭代中做什么？请记住，第一轮迭代的目的是在团队（包括客户）中生成信息流，并加深对我们正在处理的问题领域的理解。我们即将进行的实施是构建一个原型，以帮助我们实现这些目标。原型，根据定义，具有明确的目的：我们这样做是为了回答具体问题（而不是第一次尝试失败）。
这个原型有两个主要目的
1. 一个快速实现，用作与客户和用户交谈的模型，“如果我们构建这样的东西，它是否符合你的想法？”，“如果我们要构建这样的东西，它是否能满足你的业务需求（/机会）？”请注意，我们需要确保这定义了问题，而不是试图描述解决方案。
这里有一个类比：对于一个被描述为“帮我找到一种让一个家庭搬运400英里”的项目，一个原型可能类似于一辆卡丁车。如果客户然后说“哦，不，我忘了说它必须漂浮？”那么，我们就避免了一次可能令人尴尬的误解。
2. 为团队提供动手操作的机会。这对于学生项目尤其重要，原因有两个——首先，它为团队提供了一个了解其运作方式的机会（自称“枪支程序员”的团队成员是梦想家，还是团队的真正资产？）；其次，它让团队有机会体验他们在进行第二轮和第三轮迭代时可能会遇到的某些方法和工具——我们宁愿现在发现某件事在实现方面特别棘手，而不是在交付截止日期临近时才发现。在上面提到的卡丁车故事中——现在是时候发现团队中没有人有焊接经验了！
因此，在这个设计规范部分，我们正在将我们已经知道的一切，重新表述为我们需要为第一次实现了解的东西，或者也许更准确地说：在第一次实现可以设计用来回答的问题方面。我们通过创建一个“知识库”来做到这一点。这个“知识库”为我们提供了项目的现状快照，以及我们对项目了解了什么（以及我们不知道什么）。通过以结构化的方式完成项目，我们应该已经能够生成大量关于项目的陈述。我们对其中一些非常确定，对另一些有一些想法，还有一些需要我们自己编造。现在可能是回顾几个敏捷价值观的好时机：勇气和诚实。
我们提出的问题都是我们最终需要了解的，即使不是现在。勇气价值观体现在这里，因为我们认识到这是你的项目，不会有仙女教母出现并提供所有答案。谁编写功能需求？是你。谁编写验收测试？是你。谁编写用户手册？是你。（我可以整晚玩这个游戏，但你明白我的意思）。诚实价值观体现在我们认识到我们赋予每个陈述的确定性和重要性。
因此，你应该进行一项练习，写下你对项目了解的一切（或不了解的一切）。应检查每个陈述，以确定你能赋予每个陈述多少确定性。然后，看看它们有多重要。这些度量的矩阵为我们指明了下一步应该做什么。
|
这份问题清单旨在促使你思考项目的方方面面。 |
将答案写成独立的陈述，而不是对问题的回答。不要害怕写下其他由这些问题直接引发的陈述。
每个问题可能会产生多个陈述
客户是谁？
他们的业务是什么？（/他们的使命宣言是什么）
他们的关键绩效指标是什么？
他们的问题（或业务机会）是什么？
他们是如何产生这个业务问题/机会的？
在高层面上：项目成功将如何衡量？（从客户的角度/从你的角度……）
如果客户有无限资源，你会如何解决问题？
如果客户已经决定雇用一个人来解决问题（所以你的工作是找出那个人的职位描述），那个人会做什么？
你们制定了哪些小组流程（以确保沟通顺畅，解决分歧，促进创造力，促进工作质量……）
完成以下内容：“我们的证据组合是……”
完成以下内容：“我们的Scrum会议是……”
项目合适的系统隐喻是什么？
客户带来的利益是什么？（参与流程；待售产品；开拓新市场；改进业务实践等）。
哪些因素会限制项目的开发？
目前的实践是什么？（人们做什么？纸质系统是什么？计算机系统是什么？）
功能需求是什么？（“用户将……”）
系统的系统需求是什么？
用户是谁？（/他们的特点是什么？）
利益相关者是谁？（/他们与系统的关系是什么？他们会喜欢/不喜欢系统的什么方面？）
如果你们有无限资源，你会怎么做来解决问题？
如果指令是不要用计算机解决问题，你会怎么做？
用户会非常喜欢这个系统的________
用户会非常不喜欢这个系统的________
之前做过吗？之前做过单独的部分吗？
获取它的选择有哪些？
这个系统的成本是什么？（不仅仅是财务上的）
这个系统的益处是什么？
用投资回报率（ROI）来解释系统
你如何向记者解释问题/机会？
这个项目是否存在知识产权问题（侵犯他人的权利，或有商业化的可能性）
画一个系统草图
我们采用排名最高的陈述（确定性最低，重要性最高），并利用它们来推动原型实现。
有些问题不需要详细的原型。有些问题甚至在开始原型之前就需要得到解答。这里关键的问题是：这个问题之前解决过吗？有什么现成的解决方案？我们可以整合哪些组件？
对于学生项目，一个有效的问题是“我们有能力吗？”。因此，一个有用的第一轮迭代原型可能是“hello world”，使用可能的实现平台。
例如：在一个团队向外部行业小组展示他们的项目时，得到了这样的回应：“虽然我们不介意你重新发明轮子，但你应该知道你已经重新发明过轮子，而且你应该做得更好，相反，你重新发明了轮子，却没有参考圆形轮子，而是给了我们一个方形轮子”。
例如：对于一个开发博物馆“智能”机器人头的项目……
知识库可以作为整个项目的驱动因素。如果你要在一个白板或一系列卡片上写知识库（并在Scrum会议中不断更新它），每天选择一个任务就像选择排名最高的陈述（最重要的/最不确定的）并努力回答它一样简单。