摘要: 参与了一下某个项目,这个项目是这样做的:第一天,产品人员写了一份几十页长的需求文档,然后召集开发人员开始做需求评审,然后需求文档被截掉了若干页,并且确定7天后上线(含量天周末休息和一天公众假期)。第二天,开发人员开始照着一整份需求分档开始做技术设计,写了一份能够覆盖全部需求文档功能点的技术方案。第三天,早晨刚上班,技术人员与产品人员就开始进行技术方案评审,做了分工。技术人员说:这个时间太紧;测试人员说:我们没有多少时间可以测试了;研发经理说:那就把时间往后延一天。想想:我们能做的更好吗?1、让开发人员多关注需求(客户与诉求)并且让解决方案(要实现的功能)可商量可以尝试吗?2、需求拆分可以尝试吗 阅读全文
posted @ 2014-04-04 12:12 李淳 阅读(181) 评论(0) 推荐(0) 编辑
摘要: 在开发过程中,难免会有人问,我们的需求改拆分到多细才算合适我与火星人陈勇在聊天时,我们有过这样一种共识:按团交付更合理那么什么叫按团交付呢?简单来说,就是每次交付刚好可以且仅可以交付一个完整的客户价值——达成一项客户诉求。(注意区分客户与用户——奶瓶的客户是家长,用户是儿童,客户价值是家长以此来简化喂奶,这种价值以家长购买奶瓶的价格来体现)怎么才能防止拆的过粗?需要明确定义一项需求的客户是谁、这个功能对客户有什么样的价值,直到每一项仅满足一个完整的客户价值。怎么才能防止拆的过细?拆分到技术、部署上可以独立发布版本——确保是个潜在可部署的增量 好的需求拆分可以带来好的优先级排序,而好的优先级排. 阅读全文
posted @ 2014-04-04 12:11 李淳 阅读(930) 评论(0) 推荐(0) 编辑
摘要: BDD是TDD的一种衍生,通过特定的BDD框架,用自然语言或类自然语言,按照编写用户故事或者用户用例的方式,以功能使用者的视角,描述并编写测试用例。BDD源于TDD并优于测试驱动开发。之所以说BDD优于测试驱动开发,并非空穴来风,主要原因如下:1、更加以人为本:TDD更多关注于测试接口实现逻辑正确性,而BDD重点关注用户使用功能时的行为和结果是否与符合预期。2、更加以人为本:TDD基本上是使用编程语言来描述测试用例,而BDD则是用自然语言来描述测试用例。3、更加以人为本:TDD不关注客户价值,而BDD从客户价值开始书写4、更加以人为本:TDD的需求文档和测试用例是分别存储的,而BDD的需求文档 阅读全文
posted @ 2014-03-31 16:55 李淳 阅读(2463) 评论(0) 推荐(0) 编辑
摘要: 源:http://www.tuzei8.com/2014/02/workablity-research-framwork/对现有解决方案的忽视昨天我面试了一位Researcher,我们做了一个模拟的whiteboarding练习,我们希望她用很短的时间对我们提出的主题进行一次有结构性的访谈,这样的练习帮我们了解她作为用户研究者对于上下文的吸收能力。我们的主题是Standup(站会),她问到:现在的站会都有什么问题?我说:大家会迟到。她接着问:为什么会迟到呢?我说:站会都在早上,大家不能准时到达。她记录下来,就开始进入下一个问题的讨论了。其实我更期待的对话是:“你们现在是如何解决这个问题的”、“ 阅读全文
posted @ 2014-03-05 16:03 李淳 阅读(222) 评论(0) 推荐(0) 编辑
摘要: 作者:Dunne & RabyAB肯定的批判的解决问题的发现问题的设计即流程设计即方法给出答案问问题为行业中服务为社会服务说明世界是怎样的说明世界可能是怎样的科学虚构社会虚构未来并行的世界虚构的功能功能的虚构让世界变得更适合我们让我们更适合世界对产品的叙述对消费的叙述反对艺术应用艺术为了设计而研究通过设计做研究应用实现为产品而设计为权衡而设计有趣讽刺对概念做设计概念性设计消费者大众用户个人培训教育让我们购买让我们思考创新刺激工效学花言巧语 阅读全文
posted @ 2014-03-05 15:20 李淳 阅读(471) 评论(0) 推荐(0) 编辑
摘要: 在这篇文章中,要看看在使用看板方法中的另一种常见的反模式:使用了看板白板并声称“我们正在使用看板方法”,实际却将此当作烟雾弹,没有进行任何改变。在这种模式下,使用看板方法的组织实现了一个可视化板。这样做也许是种改进,因为这时增加了透明度、在制品和每个人正在做的工作项更加可视。然而,这块板只是对当前流程的可视化,再无其他变化。没有虚拟看板系统;没有递延的承诺;没有真正减轻过载;没有减轻过程可变性和破坏性的需求;对于如何计划、排期、估算或交付也没有发生任何变化。结果就是没有降低成本和管理费用,也没有改善前置时间、批量大小、可预见性和质量。除了提供了额外的可见性,看板方法再无其他作用。这就是这些主人 阅读全文
posted @ 2014-02-28 15:25 李淳 阅读(279) 评论(0) 推荐(0) 编辑
摘要: “在我们开始使用看板方法后,因为我们停止了测试工作,质量变得很糟糕!”这正是我在过去几年中听到的奇怪说法之一:据称因为使用了看板方法,从而导致终止了一些至关重要的事件或知识创造活动。我觉得这些说法很离奇,以至于我无法理解他们为何会如此看待事情。看板方法对这些人来说已经是一种方法论或者预定义的过程。通常,方法论或预定义过程囊括了角色、职责、要开展的活动等等。因此,看板方法并未谈及有关测试的话题,于是这些人开始遵循我们的范例停止测试并导致质量下降。从你现在做的开始!显然,解决这个问题的办法是告诉他们看板方法本应是什么。看板方法是改进你正做的事情的起点。使用虚拟看板系统的目的是提供以中机制,用于消除 阅读全文
posted @ 2014-02-28 13:51 李淳 阅读(398) 评论(0) 推荐(0) 编辑
摘要: 你怎样能帮助人们坚持改变?这张来自 RayImmelman 的图片非常有效。即使上看上去过度简单也无关紧要,因为里面有足够多的直观事实,这些足以说服别人。在你引入一个变化前,将这幅图给参与的每个人展示。当初始的积极性下降,人们开始产生负面的想法时,可以把这幅图再次拿出来。"OK,让我们试试!""这事情做起来比看去要困难得多。""看起来一切顺利。""我们到已经颗粒无收了。我们真的要永远做这件事情么?""嘿!我们正在开始越来越真正擅长做这件事情了!" 阅读全文
posted @ 2014-02-27 17:29 李淳 阅读(235) 评论(0) 推荐(0) 编辑
摘要: 在下列三种特性中,我们应该优先选择那个特性?FeatureEstimatedValueEstimatedProduction TimeA$100,00040 hrsB$80,00040 hrsC$60,00040 hrs特性A?这个问题没有? 傻瓜都知道,对吧?不尽然。约束理论(TOC=Theory of Constraints)告诉我们,生产线的总吞吐量受限于瓶颈。这就意味着,如果我们希望将尽可能多价值挤压穿过生产线,我们就必须将尽可能多的价值挤压通过瓶颈。所以重要的不是总时间,而是每个特性在瓶颈处所需的时间。FeatureEstimatedValueAt theBottleneckAway 阅读全文
posted @ 2014-02-27 16:49 李淳 阅读(359) 评论(0) 推荐(0) 编辑
摘要: 序财务管理中的三大杠杆分别是运营杠杆、财务杠杆和总杠杆,这些杠杆效应会对软件企业的发展有怎样的实际意义呢?本文将一一阐述。一、运营杠杆 运营杠杆是指在某个固定成本下,产品销量的变动对企业息税前利润的影响作用。经营杠杆系数(Degree of Operation Leverage,简称 DOL)是用来反应企业经营杠杆的大小和作用程度,以及评估风险大小的量化指标。DOL等于息税前利润变动率除以产品销量的变动率,也反映企业产品销量变动对息税前利润的影响。这里公式忽略~ 经营杠杆的支点是固定成本,由于经营杠杆反映企业产品销量变动对息税前利润的影响,因此杠杆两端的作用力分别是产品销量和息税前利润,而.. 阅读全文
posted @ 2014-02-27 09:26 李淳 阅读(1034) 评论(1) 推荐(1) 编辑