当敏捷开发遇上设计思维

首先说一下敏捷开发的价值观：
出处

• 个体和互动 高于 流程和工具
  • 花费大量时间观察个人用户和 弄清楚什么是有价值的
  • 多问问题，然后用它来推动叙事协作
• 工作的软件 高于 详尽的文档
  • 这里指的快速注释最终用户文档， 它们主要是指各种规格和计划。
  • 对于产品经理来说，这可能意味着有助于定义 关于什么对客户有价值的可测试的叙述，以便他们完成时 一次迭代
  • 保持叙述，这将告知我们接下来要做什么，以便我们能够获得有价值的结果。
• 客户合作 高于 合同谈判
  • 这里谈判只是意味着两个人达成协议， 不一定是实际的合同文件。 所以我们重视合作，你知道，你说过你这样做， 你最好在这个日期之前做到这一点。 我们重视，一起搞清楚对用户真正有意义的东西 什么是每个人一起做的最好，最聪明的事情。 我们重视遵循计划的变化。
    • 项目经理需要创造出关于成功结果的生动叙述，以及 给团队足够的空间，让他们知道如何 在迭代结束时完成工作，因为这仍然很重要。
• 响应变化 高于 遵循计划
  • 对变化的回应并不仅仅意味着，哦，我有一个新想法，所以让我们去做。 这意味着将变革纳入您的流程和 知道会发生什么变化，你应该走向何方。
  • 响应变化意味着知道什么是观察 将帮助你做出什么决定。
  • 我们要发布这个吗？ 我们怎么知道它是否好？

敏捷来自这个宣言，只有68个字。 宣言的故事是17个软件开发的先驱者聚集在犹他州的Snowbird。 他们发现他们遇到了很多相同的问题 软件开发过于计划驱动。 所以他们谈论了替代方案 他们创造了这个宣言。

创造优质产品有什么困难？

非敏捷开发

• 她认为 无论什么原因，我认为这不会与用户打成一片。
• 她对义务和日期都很不知所措 强调创造产出而不是推动良好的结果， 她只是想完成她的工作并回家。 当软件出来时，你知道， 用户不喜欢它。
• So that is the anti-pattern at the individual

敏捷开发

所以说

• 跨学科合作确实是成功的核心（所有不同角色的跨学科合作）
• 我们将真正专注于个人，我们将通过关于用户想要的可测试的叙述来关注用户以及团队内的人员
• 就相关问题而言，我们如何关注结果与产出？
• 我们如何才能将最有价值的东西带给用户和观察我们是否真的正确？
• 因此，如果我们的目标是创建高水平的用户参与度， 我们需要关注它，而不是我们下一个版本中的软件数量。

Agile user story

The user story has these three clauses.As a persona I want to do something so I can derive a reward.
用户故事是叙述性协作的背景，而不是预先指定需求的新格式。所以它的主要价值是创建并分享对用户有价值的理解。

比如脸书的一个例子： 作为一个社交妈妈，我想看看我的Facebook帖子 我可以决定是否要回去看看它。 所以他们得到一个文本，他们收到一封电子邮件，这是Facebook上可能有的一个功能 是针对这样的叙事而发展起来的。

• 按优先顺序对它们进行排序

• 根据我们认为可以做的工作量来削减它们，完成一次迭代。这些迭代通常需要两到四周，有时候会更长一些。（把y用户放在你的前面，做任何必须做的事情来评估软件的价值）

• 当然，如果你说每年只会发布几次软件，可以选择将它们批量发布到版本中。

• 产品团队的谈论

  5. 谁是我们的用户？
  6. 我们为他们做了哪些工作？
  7. 我们为他们提供了什么样的愿望或习惯？
  8. 关于用户想要实现什么的生动，可测试的叙述。
  9. 我们可以发布吗？
  10. 用户如何对其做出反应？

每日站立 Daily Standup

• 昨天我做了什么？
• 我今天会做什么？
• 阻碍我进步的障碍是什么？

这非常注重输出，因为在迭代中你 专注于你决定要生成的特定工作 你认为某种输出会带来有价值的结果。 所以团队这样做不仅可以跟踪事情的进展， 但更重要的是，敏捷团队是自我组织的。 个人互相支持，帮助消除障碍， 决定谁应该在做什么。 彼此之间而不是严格的命令和 控制方法与单一的产品经理。 所以这些站立帮助他们做到这一点

燃尽图 Burndown chart

每次我们完成一层楼，我们都会在任何日期标记该事件。

目前最流行的敏捷方法

• Scrum
• Extreme Programming(XP)
  • 侧重于编码方法扩展到项目管理实践。
• Kanban
  • 看板可以作为这些和替代品的替代品 实际上，这是一套减少正在进行的工作的方法。

关键软件实践的提升

• 查尔斯泰勒于1909年撰写了这篇论文，即科学管理原理。
• 像工业设计，消费者使用的产品设计这些术语， 是在1919年创造的。
• 像Ada Lovelace这样的数学家开始提出关于计算和思考的想法 。在19世纪和1935年的时候 通常被认为是我们第一次看到现代计算机的时候，由阿兰图灵和他的团队创建，目的模仿游戏中戏剧化。
• Unix在1970年左右创建的
• 1991年，IDEO公司成立，他们做了很多工作 关于设计实践对商业问题的一般应用。
• 1994年，你看到像雅虎这样的互联网公司被广泛使用
• 谷歌成立于1998年
• 提供必要的目录和敏捷宣言出版于2001年，但变化很慢，它仍然相对较新。
• 史蒂夫布兰克(创业教父)在2005年首先提出客户发展概念（关于如何实际管理创新的想法）和 由Eric Ries在他的书“精益创业”中进一步阐述。
• Instagram在2011年以10亿美元的价格售出，与13人团队一起工作15个月。

Scale Friendly vs. Innovation Friendly

• 规模友好
  • 目标是实现规模，而且计划与预测的结恶果也是一种规模友好的东西
  • 假设希望我们有一些值得扩展的东西。
  • 在数字时代，实现规模非常容易。
  • 我们需要首先找出有价值的东西（最困难，最烧钱）
  • 写一个计划，筹集资金，构建这个东西的最佳版本，降低成本
  • 必须确保将它出售给许多零售商，以便我们能够实现规模化
  • 我们可能会花费大量时间和金钱来处理极高风险的事情
• 创意友好
  • 这就是你要学习的内容和敏捷的意义所在。
  • 首先观察我们的买家，去理解深层次的原因。
    • 他们为什么需要这个？他们为什么想这样做？
    • 什么工作，习惯，欲望围绕着他们的这种活动或者说是需求
    • 那里有没有那么好的东西来帮助解决他们的问题？
    • 他们做的工作，他们有的任务对他们来说很难吗？
    • 我们的解决方案是否能帮助他们，他们在乎吗？
  • 如果我们发现那是真的
  • 我们有一个重点主张，即我们围绕这个产品构建产品。
  • 我们建立一个真正，非常严格定义的 我们决定的是这个命题的重要部分
  • 然后我们迭代对敏捷非常重要的小批量，和 在成功的基础上，我们扩大规模
  • 关键是我们一直在关注是否或 不是我们创造的东西对用户有价值

什么使敏捷变得困难 ？

• 用户参与度
  • 了解你的用户和 弄清楚什么对他们有价值。 当我与团队合作解释对我们设计驱动意味着什么时， 对于我们来说，使用敏捷实现这些以人为本的设计意味着什么。 我发现的其中一件事就像这两种失败的反极点。
  • 一个是好的，我们说，好吧，用户告诉我们该做什么，我们只是这样做。 所以我们是用户驱动的，但是发生的事情是你只是不知道它们是什么 想要， 它可能无法解决他们真正拥有的问题。
  • 然后另一个反极点就是我们很聪明。 我们的最后一个产品成功了,所以我们只会做我们认为最好的给用户， 如果他们太愚蠢到不喜欢我们的产品，那就是他们的错。 好吧，那也是因为显而易见的原因也不起作用。
• 内部协作
  • 相互关联的方式是叙事合作 让我们能够密切关注对用户有价值的东西 用一种对整个团队来说可以理解的方式描述。
  • 发展实验文化。 我们要尝试一下， 我们将把观察结果用于我们的迭代。
    

团队环境

在敏捷中，实际上什么构成了有价值的结果 这些事情非常具体。但是这并不意味着你得到了具体要求或 关于使它成为蓝色，或制作红色，或使其变圆，或其他什么的规格。 但是你会得到关于这个用户是谁的非常具体的观点 他们的生活是什么样的，对他们来说有什么价值。 你得到的是输入，而不是要求， 随着公司更加注重创新和创新，这种情况正在逐渐减少 不那么重视大的，长期的，可靠的计划。 我们的投入与叙事协作有关。 、

• 首先关注的是确保我们理解正确的问题。
• 可能引起共鸣的处置或描述的数量。 我们希望扩展这些内容，与我们的合作者进行比较，以及 然后将它们浓缩成我们认为重点的东西。
• 测试和验证是该周期不可或缺的一部分。 所以小批量做事很好，它可以帮助你避免走得太远 ，你不断看到交付的东西，这有点强迫每个人 封装和完成他们的工作，因为他们走的很好。

实验文化

实验文化，是区分事实的能力， 假设和意见。 所有这些都没问题，但重要的是要明确哪个是哪个，哪个 识别它们并帮助您的团队识别它们。

• 从一个想法开始，我们想知道我们知道买家是谁， 我们对他们是谁有一个生动的看法吗？ 这有助于我们培养和构思想法 找出哪些最有可能是有价值的。
• 然后我们创建一个假设。
• 你应该至少能够冒险猜测
• 通过观察在小迭代中工作
• 添加功能，发布它，观察用户
  

风险设计框架

1. 用户画像
2. 问题场景/替代方案
3. 价值主张/假设
4. 执行发现/实验
5. 用户故事/原型
6. 产品/推广