为什么你的Scrum会失败?(一)

Scrum失败的原因有很多. 很普遍的一个原因是, 忽视其众多前提而仅仅是把现在的基层开发组织按照Scrum要求的那三种角色改一下, 就算是上马了, 很快Scrum也就像它的音译那样, 变成死马了, 仅留一身马皮. 我们来看一下为什么仅仅把基层开发组织改组为Scrum团队是不工作的.

浅薄的欢腾与自欺的流量

当我们在商业社会初学了讲故事的皮毛,却不知公益更需要引人入胜的故事时,鼓吹营销获得成功的本末倒置的思维又一次在“冰桶挑战赛”上演。公益不需要过度的娱乐、浅薄的关注和喧哗的吵闹,它需要朴素的内心和严肃的思考。

在约束与机会中权衡

做自己最适合的事,就有更好的生产力:在经济学教科书里,我们称之为比较优势。前段时间和几个创业的朋友聚会,发现创业起步者,尤其是靠项目盈利者,有一个最大的误区就在于复制客户或上游链条企业的模式,不少行业级的大企业也正在步入同样的误区:比如设备商做运营商的事,运营商做电商的事,电商做社交的事——这本质上都变成了服务商涉足自己客户的领域,同时又要求客户买单。

DevOps中文名: 开发自运维

在高度不确定性的产品创新中, 对市场的响应速度越来越快, 开发自运维是一个趋势, 可以缩短交付时间和对反馈的修复时间. 这种趋势的前一波浪潮, 则是”开发自测试”/“开发自设计“, 而下一波运动则极有可能是”设计自开发”.

敏捷咨询日记——沟通问题

强调沟通和杜绝浪费是敏捷最核心的东西,这两项基本是贯穿我这次咨询活动的主线-任何细微的活动都需要用心审视两个问题:我做这件事情的前提是传递价值给团队另一个人,那么价值的传递过程中有没有沟通的阻碍?价值的传递过程有没有什么东西导致了传递损耗既是浪费?从一对一沟通谈起,逻辑是你不可能消除所有的沟通壁垒,譬如你的口齿不够清楚,那么至少发现那些你可以消除的壁垒,消除它,并告知和提醒你的听众那些你不能消除的。往往人们犯的错误是:

建设全功能团队——实践篇

在咨询的过程中,我见过太多的团队把目标放在交付上,冀希望于工具,外部力量能够快速的解决问题,往往对小步前进不够耐心,不关心团队的成员。在我们这个 90%以上成员没有.Net经验,50%是毕业生的团队中,那些微不足道的改进,一点点的提升,最终造就了这个9个月中没有一天加班,几乎没有缺陷,提前交付的项目,客户甚至愿意为他们的满意额外支付3万美金作为奖励。我把全篇总结为一句话:把项目目标放在人员能力提升,让项目成功成为能力提升的副产物。

基于微服务架构,改造企业核心系统之实践

随着公司国际化战略的推行以及本土业务的高速发展,后台支撑系统已经不堪重负。在吞吐量、稳定性以及可扩展性上都无法满足日益增长的业务需求。对于每10万元额度的合同,从销售团队准备材料、与客户签单、递交给合同部门,再到合同生效大概需要3.5人天。随着业务量的快速增长,签订合同的成本急剧增加。

我怎么看敏捷

去年11月份的时候,我进到了ThoughWorks实习,开始了我的TW生涯,从现在除去今年年初由于毕业论文断断续续的10天左右的请假,我已经到ThoughtWorks1年了,现在我想来我聊聊我眼中的敏捷和我对敏捷的看法。

如何建设全功能团队

团队的开发人员撇开需求沉浸在想象中的“完美”程序中;测试人员迷茫的点击着按钮试图搞明白这到底是个什么功能;设计师造出了没有尽头的楼梯,更糟的是,客户爱上了这个设计;团队领导四处救火,力有不逮。种种迹象表明,我们得打破分工带来的壁垒,建设全功能团队——大多数人能完成大多数种类工作的团队。

重复造轮子有何尝不可?

在软件行业,或者说在程序员这个族群中,流行着这样一句话:不要重复造轮子。相对好的意思是应该尽可能用现有的实现来解决问题,而不太好的意思就是你太笨了,有现成的还要重写,醒醒吧?然而,纵观整个开源社区,几乎每段时间总会有各种各样的轮子被重复的造出来,不管是DI容器也好,还是MVC框架也罢。虽说随着语言的发展,有些新的轮子确实比旧的轮子优秀,然而大部分轮子都很快的销声匿迹了。当作为一个旁观者看到这样一番景象时,“重复造轮子是不好的”这个概念就会在你的大脑中被慢慢的强化,于是渐渐的,你就变成一个轮子的搜寻者,而放弃了作为一个轮子的创造者的机会。

大型网站技术架构的演进

网站技术架构为什么会演进?我个人总结出来我们的技术架构演进的两种驱动力,驱动着我们为什么演进网站的技术架构:1. 内在驱动力:我们期望把当前的业务做得更好,开发更多新业务。2. 外在驱动力:用户量的上升、用户种类的多样化。