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

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

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

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

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

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

我怎么看敏捷

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

如何建设全功能团队

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

重复造轮子有何尝不可?

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

大型网站技术架构的演进

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

工作记忆 vs. 长期记忆

长期一来一直有个说法:“鱼的记忆只有七秒,7秒之后它就不会记得曾经的事情了,所有的一切又都会变成崭新的开始。所以,在那一方小小的鱼缸里面,它永远不会觉得无聊。” 当然这个美丽的谣言已经被一些死硬理派得人非常煞风景的辟谣了。

职业女性确实处于劣势吗?

我会把收到的巨款用来置装,美容,健身。然后穿的花枝招展,抹的五彩绚烂,露出两条人鱼线。站在女程序员们旁边,给她们端茶倒水擦汗。并且忘掉我也可以是一个独立的个体,也可以通过某种其他的方式体现自我价值。成为一名雄性鼓励师,从此人生走上巅峰。

实战:持续交付中的业务分析

在需要频繁交付、不断收集用户反馈、拥抱变化、追求业务敏捷的项目中,软件的开发和交付是迭代式进行的。在这样的项目团队中,BA(业务分析师)通常需要在一个开发迭代开始之前完成该迭代开发任务的分析。但在特殊情况下,从收集客户需求到将功能细节传达给开发团队的周期会缩短到一至两天。BA可以用于思考和分析的时间远远少于可以预先做出所有设计的瀑布式项目。

软件系统的稳定性

软件系统的稳定性,主要决定于整体的系统架构设计,然而也不可忽略编程的细节,正所谓“千里之堤,溃于蚁穴”,一旦考虑不周,看似无关紧要的代码片段可能会带来整体软件系统的崩溃。这正是我阅读Release It!的直接感受。究其原因,一方面是程序员对代码质量的追求不够,在项目进度的压力下,只考虑了功能实现,而不用过多的追求质量属性;第二则是对编程语言的正确编码方式不够了解,不知如何有效而正确的编码;第三则是知识量的不足,在编程时没有意识到实现会对哪些因素造成影响。