用户体验

如何衡量产品的用户体验？

/分类： /编辑：

1. 产品的用户体验可以衡量吗？

用户体验是一种用户在使用产品过程中建立起来的纯主观的感受。

纯主观的感受能衡量吗？ 可以。

人体的疼痛也是纯主观的感受，目前医学界关于疼痛强度的分级，最简单常用的分级方法是NRS数字分级法，疼痛分为0~10级。
Read more →

敏捷体验设计工作坊模版

/分类： /编辑：

和以往的那种简单粗暴的“头脑风暴”，或者索然无味的“需求评审”不同，敏捷体验设计中的过程永远是开放的，强调在和客户的互动中识别需求，并产出设计，最终对项目交付内容达成共识。过去的五年里，我参与了几十次和客户的设计工作坊，这里把我经常使用的五种设计工作坊形式分享给大家。
Read more →

ScrumMaster需要了解的7件事

/分类： /编辑：

当一个组织开始使用Scrum时，被选为担任Scrumaster角色的人通常来自于那些有管理背景的人。组织期望那些管理人员，所谓的“大师”，能够交付Scrum项目因为她有管理的专门知识——并且可以同时管理其他两个项目。

设定期望本身就是需要解决的第一重阻碍。另外，几乎可以确定的是如果脱离Scrum项目，组织得不到他应得的益处。记住，错误的期望是不会被满足的。

当我刚开始成为一位ScrumMaster的角色时，我希望我已经知道了这个事实。以下的7件事，是我希望在我作为Scrumaster时已经知道的：
Read more →

产品负责人的职责

/分类： /编辑：

很难给出产品责任人的一个完整职责列表。这跟公司文化、个人和团队的能力、竞争对手等等上下文环境相关。这种上下文环境极大地影响着产品责任人在不同的公司如何开展起工作。因此我不会试图提供一份产品责任人的职责检查列表（“比如必须参加sprint计划会议”），而是认为更有价值的是，思考产品责任人给团队提供的两样东西：愿景和边界。
Read more →

敏捷教练的26项修炼

/分类： /编辑：

敏捷方法学带来了新的角色——“敏捷教练”，它不常见于传统方法学中，甚或不曾为之提及。已驾轻就熟的实践者，可能会视之为浑然天成，羚羊挂角、无迹可寻；而初窥门径的新手则会心生疑云：“敏捷教练为何如此重要？‘部门经理’、‘团队领导’、‘技术领导’，他们的问题何在？Monster.com为此提供54个职位，又是何故？”奇文共欣赏，疑义相与析，当是吾等本色。且与笔者同游于本文中，或可领会敏捷教练之所思、所行，更要知其意义所在。
Read more →

文档撰写者如何在敏捷环境中生存

/分类： /编辑：

“最开始的时候，这一套方法并没有任何文档，但是很多公司都找到了正确的解决方案…”摘自Alyssa Fox和Meredith Kramer的《Mobile and Agile: The Floating Writer’s Survival Kit》。

很文档的撰写都想尽办法要找出如何能按期交付，如何能完成质量文档和如何在软件公司从传统的瀑布式模型过渡到日渐流行的敏捷流程时保持平稳。虽然我们的管理层和敏捷教练都决心帮助我们在敏捷的道路上成功，但是我们的文档和用户协助团队仍然觉得没有足够的资源能够帮助我们拥抱敏捷。从我们的经验看来，我们可以建立一些制度和最佳实践来帮助我们在敏捷的环境中更好地生存。
Read more →

软件开发：一种专业

/分类： /编辑：

我们经常将自己当成是专业人士。ScrumMaster的中级评估中问到，“你将软件开发当成一种专业吗？” 答案毫无疑问，“是的。”我们会给出许多理由来，主要是关于我们的技术、不同的技术头衔以及我们做出来的软件的重要性。我们的顾客指望着我们。
但是，我也不那么确信。如果我们是专业人士，那么我如何能够说一个人是很专业地做事，而另一个人不是呢？那么什么是非专业行为呢？是一些不那么透明的行为吗？是质量打折扣？是有升级了依旧没有重新设计？这个问题真令我头痛。
Read more →

Scrum团队中的架构师

/分类： /编辑：

 很多架构师在努力了很多年才得到这个威严的头衔“架构师”。他们确实应该为他们的知识、经历和能针对技术和业务挑战提出一流的解决方案的能力而骄傲。我发现很多架构师在面临采用Scrum时提出的担忧可以归纳为下面2类：

•大家仍会按照我告诉他们的架构去做实现吗？

•我如何能在没有一个提前设计架构的阶段后保证我们构建了一个架构不错的产品？

Read more →

PMO在scrum中的角色

/分类： /编辑：

参与并支持向Scrum转型的项目管理办公室（Project Management Office，PMO），对于Scrum团队来说，将是一个极大的福音。PMO的成员常将他们看作是一项实践的保护者和支持者，所以PMO能帮助在组织内实施和扩大敏捷实践。但是，当PMO不恰当地参与时，PMO也是抵制的来源，因为它会尝试保护当前的流程，而不是改善它。

PMO大部分人的自然反应是抵制Scrum转型其中一个原因是个人和职业的恐惧。Scrum将传统的项目管理责任分散到ScrumMaster、产品负责人和团队，留给项目经理来思考他们的角色是什么。在大部分Scrum和敏捷著作中PMO的缺失，也增加了PMO成员很自然的担心。

我们将考虑PMO在下面3个方面的贡献和工作：人员、项目和过程。
Read more →

产品负责人不是代理

/分类： /编辑：

很多时候，产品经理们选择不去做产品负责人（PO, Product Owner）。他们谋划着由一个业务分析员或者产品分析员去“代理”产品负责人。当然，也是因为大部分关于产品负责人的书籍和培训都把他或者她当成是scrum团队的一个附属物：他们要做的只不过是写写用户故事和玩玩计划扑克，要按照INVEST原则而已。所有的这些关于产品负责人的定义都是从开发者的角度来的。
Scrum并没有定义如何使用产品backlog，或者是产品负责人应该做什么。而且，我也确实 认识有人没有用Scrum却在很好的写着用户故事来优化他们的产品管理工作。他们成为了很好的业务分析员，或者需求工程师。
将产品负责人的职责授权出去会进一步增加开发团队与客户之间的距离。我对Scrum Master的期望是他们能缩短这个距离。Scrum Master可以去教会业务如何行使PO的角色来做到敏捷。Scrum Master能帮助PO去理解如何抓住机会，去优化价值，如何与团队合作。在我看来，PO无论如何也不会因为要去做需求开发而变成业务分析员。
Read more →