文章频道为您提供Leangoo实践，以及Scrum,敏捷,精益创业,产品创新等领域专业文章。
很多项目都不会一开始就完全就绪——例如，需要分配人员和准备工作。为了处理这些项目开始前的任务，很多团队使用了“迭代0”的做法。虽然理解其由来，但我仍然感到担心。以下是我的理由。
停止“迭代0”的三个理由：
首先，尽管很难相信，但绝大多数的项目都是可以立刻启动的。我所听过的所有声称需要在Scrum项目启动前完成的事项有：需要组建团队，包括调配人员到项目上或雇佣新人；需要获取或者设置硬件设备；需要写一个初始的产品待办列表（即使只是高度概要的）。然而现实情况是：诸如技术环境、初始产品待办列表之类的事项都可以在第一个迭代中完成（一个完全是正常的和传统模式的迭代一），同时至少还可以交付了某些潜在可发布产品增量。
Read more →
尽管我尽了最大努力来澄清，但是仍然流传这样一种说法：故事点数是对复杂度的度量。这种说法是完全错误的。真相是，除非复杂度已经对完成用户故事的工作量造成影响，否则其复杂度并不重要。
让我举个例子。假设你和我一起观察离一栋建筑物的距离。你认为需要走5分钟，而我因为正拄着拐杖所以需要走10分钟。
很少有Scrum文献会说每日站会需要按团队成员逐个发言。然而大多数团队恰恰都是这样做的，但这可能不是最好的方式。
当每日站会是逐个团队成员进行的时候，团队成员会很容易丢掉所讨论的待办事项的上下文。例如，可能第一位团队成员正在处理前两个产品待办事项，第二位团队成员正在处理第二个和第五个产品待办事项，第三位团队成员也在处理其中这些待办事项中的一个，同时花费少量精力处理另一个无人的待办事项。
Sprint评审会议长期以来一直是Scrum的一个很重要的部分，它是团队为迭代交付的产品增量获得反馈的一种机制。在Sprint评审会议上，产品负责人根据收到的反馈来决定接下来的Sprint的需求的优先级。
那么，到现在Sprint评审是否已经过时了呢？
十年前，差不多每个Scrum团队都是按照Sprint，Sprint，Sprint，Release（发布）这样的模式交付的，每个做几个迭代上线一次，极端情况是每个迭代都上线，很少听说在Sprint中间发布上线。
而现在，很多团队都在实践持续交付和持续发布，一天发布多次也是很普遍的。
我们设想一下，针对一个进行持续发布的团队，我们按照原来的思路进行Sprint Review的场景：
Read more →
在Scrum项目中，产品负责人可能是最有挑战性的角色之一。在所有项目中，产品负责人都需要把精力平均分配到对内和对外两个方面。
产品负责人对内的主要任务有：
产品负责人对外的任务包括：
产品经理处于沟通枢纽的位置，工作中需要跟各种岗位的人打交道，比如：领导、开发、运营、客户、用户、合作伙伴…
沟通能力是产品经理的一项重要技能，很大程度地决定了产品经理的工作能否顺利开展。
那么，产品经理应该采用什么样的沟通策略？
产品经理的沟通策略，形象点来说，就是：见人说人话，见鬼说鬼话。
产品经理跟不同角色的人沟通，要采用不同的沟通方式：
Read more →
四年前，我在QCon上演讲了一个《建一支强大的小团队》（整理后的PPT分享于这里）提到了工程师文化，今天，我想在这里再写一篇关于工程师文化的文章，一方面是因为我又有了一些想法和体会，另一方面，因为我也正走在创业的道路，毫无疑问，要建一个有浓重的工程师文化的团队或公司，所以有必要把自己的相关想法形有成白底黑字的“字据”，以供打自己的脸——“要是未来没有做到，这篇文章就打我未来的脸” || “这篇文章太幼稚了，未来的我会打我现在的脸”，当然，如果要打脸，我希望是前者。
Read more →
话说：不想做产品经理的程序猿不是好厨师，这几年随着产品经理这个岗位的火热，越来越多的程序猿、设计师、项目经理等专业人士转型去做产品经理。
做专业技术出身的人，往往会养成一种思维习惯，看问题的角度也会形成惯性，我们把这种思维习惯叫做工程师思维。
Read more →
1. 产品的用户体验可以衡量吗？
用户体验是一种用户在使用产品过程中建立起来的纯主观的感受。
纯主观的感受能衡量吗？ 可以。
人体的疼痛也是纯主观的感受，目前医学界关于疼痛强度的分级，最简单常用的分级方法是NRS数字分级法，疼痛分为0~10级。
Read more →
