为了年少时候的承诺

以前用了很多盗版软件,最大的原因就是太贵,买不起,而不得不承认,正因为其中的一些软件,才让我有了今天的些许成绩。虽然不是自己的个人问题,曾几何时,这是一个普遍的社会现象。如同现在我们到国外,发现东西不贵啊,而且是人家几十年一直这个价格。

不是很懂宏观经济,反正现在可以支配的货币多了,很多软件都买得起了。office 和很多常用的共享软件已经用了很多年正版了,之前一直想入手 adobe lightroom,但是几千的价格还是有点下不了决心,最近发现,原来 adobe 已经学习 microsoft 了,软件可以用和会员结合的年服务费模式,并且有专门只使用 lightroom 和 photoshop 的摄影会员可供选择。

那就不要犹豫了,这个世界是公平的,每个人的贡献,汇聚在一起,力量会很大。如果只是吃吃喝喝混日子,有什么意义呢。

谢谢 lightroom,曾经处理了成千上万张照片,虽然佳作寥寥,但也带来了很多欢乐。

lightroom

2005年那时候,做过很多免费虚拟主机的计划,记得当时的网站叫做理想空间,现在我写一点很简单的开源软件,教教小孩子 python,好像这样更加有趣和有意义。自己年少时候的承诺总是要尽量去履行的。

swift之浅尝

apple的swift推出已经有一段时间了,国内之前赶进度弄出很多速成教材,后来也没有什么下文了。

公司目前的ios应用还是用oc,不过swift总是潮流,于是稍微看了一下,也买了一些国内的书。

记得很早以前学习vb的时候,起初也是一头雾水,当时看了一本很薄的书,是老外写的,国人翻译的,那时候的翻译还是比较有良心的,信达雅。

后来学习delphi,虽然界面和vb差不多,但是语法和使用方式和之前turbo pascal差别太大,并且编程思想和vb差别更大。记得当时整个市面上一共只有两本delphi的书,都是翻译的国外的书,其中一本我一直有印象是全篇一个故事,说一个独立程序员怎么接了一个项目,然后通过学习delphi,完成项目,在整个过程中,要不断学习提高用各种技术来满足变化的需求。

自然,上面这些书使得编程入门变得很容易。初步学会之后,虽然还是会有很多弯路和提升,但要理解每一门语言的博大精深就容易一些了。

国内,写得好的swift例子还不是很多,这个不错,在视频网站也有一些讲解视频制作的不错。可惜,还是少数。大部分的书籍和教程也就是把apple的文档或者老外写得一些东西翻译了一下,在说明的时候条理不清楚,不是站在学习者的角度。急功近利,太过明显。

swift从语言角度,很新,因此很多语言的优点都有体现,apple在开发环境上的努力也是众所周知,swift值得跟进。

未来不远

特别爱看美国大片里面那类星际旅行的,特别喜欢看那些超牛的控制台,大屏幕的显示器,复杂的操作,互相之间的通讯,都是很cool的样子。

OSX升级到了10.10,于是有一部分未来的功能可以实现了,当iphone响起来的时候,我可以选择在电脑上接听电话,双手被解放了,用起来也方便,还很虚荣。

而新版本OSX和iOS的Handoff功能,使得工作连续也能够实现了,所谓一台电脑上copy另外一台电脑上paste其实已经ok了。在mac机上用浏览器查看的网页可以继续在iPhone或者iPad上查看,或许也有点矫情,但的确把设备串联了起来。

微软的windows让我们接受了图形化操作系统来控制电脑,这几年Apple的发力,让用户体验更好,革了很多传统包括传统电器和传统使用方式的命。未来一步步的就在眼前。

敏捷开发入门

之前在这里写过若干篇敏捷开发的入门心得,后来重新做了一个整理,以此pdf为准(1M多一点),感兴趣的同好分享。

下载:敏捷开发入门_v0.0.1_20140620.pdf

国内来说,作坊居多,或者就是外企那种传统瀑布式开发,敏捷这些年在一些互联网公司开展较多,但终究还是曲高和寡。

很多人对敏捷不了解,也有很多对敏捷的误解和滥用。

不是为了敏捷而敏捷,实践最为重要。

蜘蛛侠

超凡蜘蛛侠,已经第二集了。

以前的蜘蛛侠,应该是有三部曲吧。回想起来,还是在电影院看了很多电影。

第一部蜘蛛侠,历历在目啊。

今天很忙,六个会。

其实我不喜欢这种忙碌,以前也这么忙碌过,当时乐在其中,可是后来,其实也就那样。

能力越大,责任越大。

我能力一般,所以责任一般。

有时候想起11岁开始学习basic,后来的logo、dbase、foxbase、turbo pascal、foxpro、visual basic等等,有时候就想做一个安静的简单的程序员,我也知道我有能力可以写出一些小软件,解决一些人的问题。

没时间,或许只是借口。安逸了。

喧嚣可暂停

6619386554165034779

一切喧嚣终究暂停。有时候只要一口深呼吸,也就安静了,心境。

世界终究不会理会我们个人的感受,而汹涌的飞奔。

看到美国队长2-寒冬战士、超凡蜘蛛侠2、还有保罗最后的一部电影暴力街区今天都放了出来。

我一边欣赏着自己送给自己的礼物,正版的game maker专业版,一边看着新一代的美剧,一级谋杀第一季、血族第一季等等。

总觉得这个武宁路桥有点像麒麟之翼中的场景,人性到了某些时刻,都可以暂停,去思考。

敏捷开发-缘起

1986年,竹内弘高和野中郁次郎最早提出一种新的整体性方法,1991年,这种方法被称为Scrum,借鉴了橄榄球中的术语。1995年,萨瑟兰和施瓦伯的论文中首次正式提出Scrum概念 。

标准的Scrum中有三种主要角色, Scrum Master,确保团队合力的运作Scrum,产品负责人确定产品的方向,定义产品发布的内容、优先级、交付时间等,开发团队则拥有交付可用软件需要的各种技能。

产品订单和冲刺订单。在标准敏捷中,每一个冲刺,就是sprint中的功能来自一个大的产品订单,也就是product backlog,每一个sprint中有一个sprint backlog。

在Scrum的Standup会议上,是需要每个团队成员回答三个问题,分别是今天你完成了哪些工作、明天你打算做什么、完成目标是否存在什么障碍。

Scrum的会议包括Sprint计划会、每日站会、评审会议和回顾会议。

Scrum是强调所有团队成员坐在一起工作,及时的进行口头交流。

在大的企业中,单独团队的敏捷是一个理想的模型,一个大项目会有很多项目组成,这时候是不是不能用敏捷了呢?如果生搬硬套是不行,大项目适当的用敏捷管理,会取得更加明显的进步。

在Capital One,大的IT项目会被拆分成多个子项目,安排给各个“敏捷团队”,这种方式在“敏捷开发”中叫“蜂巢式(swarming)”,所有过程由一名项目经理控制。

为了检验这个系统的效果,Capital One将项目拆分,从旧的“瀑布式”开发转变为“并列式”开发,形成了“敏捷开发”所倡导的精干而灵活的开发团队,并将开发阶段分成30天一个周期,进行“冲刺”。每个冲刺始于一个启动会议,到下个冲刺前结束。

在与传统的开发方式做了对比后,敏捷开发使开发时间减少了30%~40%,有时甚至接近50%,提高了交付产品的质量。但是他们也觉得大型项目或有特殊规则的需求的项目,更适宜采用传统的开发方式。

Scrum模型的一个显著特点就是响应变化,它能够尽快地响应变化。下面的图片使用传统的软件开发模型(瀑布模型、螺旋模型或迭代模型)。随着系统因素(内部和外部因素)的复杂度增加,项目成功的可能性就迅速降低。

1

2

敏捷开发之所以为敏捷开发,不是因为其方法(虽然方法也很重要),而是因为敏捷思想存在 。敏捷思想我通俗的说就是小步快跑。

小步快跑有两点,第一要先跑起来,多说无益,第二要快。因为这是一种思想和精神,是一种主人翁态度。很多时候,我们或许出发的时间太长,忘了在起点时候所设定的目标。不能只注重表面的形式,而忽略了内在的精神。

敏捷开发中Scrum、Sprint是这样的一种精神和态度,一种对产品,对项目的由内而外的热爱,乐于贡献的主人翁精神。每个个体都可以按照组织的最高利益,自我驱动的完成组织的目标。

第一要做到人找问题,而不是问题找人。尽量避免企业扩大团队人数多而带来的责任分散。

第二是流程与灵活的平衡,科学管理与情感精神的统一。当今商业环境快速变化,唯一不变的就是变化。冲在一线的“开发人员”是最了解系统架构和技术、开发工作量,某一件改动对项目影响的人。团队成员应该拥有在一定范围内的自我决策的能力,充分灵动的为产品创造最大价值。

在敏捷思想的指导下,有很多具体的方法,比如极限编程XP、测试驱动开发TDD、自适应软件开发ASD、特性驱动开发FDD、动态系统开发DSDM、精益软件开发LSD等,都有不同的应用场景和对团队的要求。

Ruby On Rails这样的敏捷对于2000时候的互联网发展起到了很重要的作用。2004年7月,大卫•海纳梅尔•韩森(David Heinemeier Hansson),公开了RoR框架,并响亮的提出了“敏捷的web开发”的口号。

其实这个敏捷和Scrum是有很大区别的,RoR是一种深度基于MVC框架并且崇尚设计原则包括“不做重复的事”(Don’t Repeat Yourself)和“惯例优于设置”(Convention Over Configuration)。

RoR从开发理念上来说和敏捷开发不谋而合,快速迭代、注重效率、简洁优雅。

3

Scrum为我们提供了一套非常好的项目开发管理框架,为我们打开了一扇窗,短短十几年,无敏捷,不开发。任何方法工具只有经历项目的锤炼才能发挥出其真正的价值!

敏捷开发之六:测试、生产测试和beta测试

在一般项目开发中,需求方和开发的矛盾主要体现在时间和完成的功能。同样这个问题,在敏捷开发中会依然存在。

测试的重要性。为什么要有专门的测试团队以及测试的方法论这里就不多赘述了。在敏捷开发中,平行观念很重要,所以测试是可以和开发几乎一起开始的。

对于测试团队来说,一部分测试工作可以跟着Issue(User Story),当开发人员完成一个Issue开发,就可以进行功能测试。对于有些不能直接进行测试的Issue,也没关系。标准的测试案例方法还是可以使用的。在开发的初期,平行测试并不能带来很多效率提升,因为功能还没有开发好,开发好的功能一会比较零散。到了开发中后期,同步开展测试的效率就体现出来了,可以让测试的进度比开发始终只滞后一点。这在传统的瀑布开发中是做不到的。不过,这对测试人员的要求高了不少,工作强度也会增大,会产生不少反复的回归测试。我们在实际敏捷开发过程中,测试人员是一早就进入的,就是为了便于团队之间的沟通。

我们发现,测试人员提早接入还会有很多小的好处。比如,在开发过程中,开发人员需要制造一些测试数据,制造测试数据的脚本越早准备好越好,由于测试相对的提前,数据脚本的问题可以及早发现。另外,之前由于开发和测试在时间上是分成不同阶段的,而在敏捷中产品、 开发、测试几乎一直在一起,对于需求在开发过程中的具体展开有一个感性的认识。

生产测试,一般是需求方和产品经理来负责。在生产测试过程中,提出需求的部门和产品经理需要按照需求来逐个功能点进行测试。瀑布开发方式中,需求方一般要等到测试通过后才能进行测试,发现的话,需要再提交到开发,然后再经过开发-测试-生产测试的流程,这样时间当然有开销。敏捷开发模式里面,生产测试几乎和 开发、测试一起开始,发现问题的时候,通过产品经理和项目经理可以立刻就增加一个Issue或者修改功能点,以保证项目进度受到的影响最小。

公开测试,也叫beta测试,对于有用户的产品来说,让一小部分用户先开始使用,并收集意见,在下一个迭代周期中进行改进,非常符合敏捷思想。这部分其实已经不是开发的范畴了,而是产品流程的一部分。敏捷开发Scrum是按照Sprint来发布的,因此我们可以通过这样的步骤来进行一个不断迭代升级:发布一个Sprint1作为beta版本,同时继续进行Sprint2的开发测试等,同时产品经理收集beta测试中用户的反馈,进行归纳讨论后,作为Sprint3或者之后Sprint的一部分。在发布时间上,如果可以做到2-3周一个Sprint的话,那么在几个月后,用户对于产品的满意度会上升很多,并且用户会感觉他们的意见得到了重视,从而愿意更好的体验产品和提出建议。

因此,beta测试并不是给用户测试那么简单,而是在互联网、移动时代贴近用户迅速提高产品质量的一种方法。国内小米、微信等例子已经不胜枚举。说到这里,大家或许可以明白为什么Scrum方法在互联网时代突然爆发出来成为一种非常有效的方法,其在本质上就是因需而变、因用户而变。

敏捷开发之五:站会和问题解决

敏捷开发Scrum中最有趣的形式要数这个“站会”了,Stand up。原意是说站着开会效率高,估计大家都参加过很多效率不高的会,在敏捷开发中,容不得浪费时间。

按照标准的Scrum模式中,站会是每天早上进行的。对于这个定义我们在实践中做了很大的扩展。

首先,因为我们的开发时间是早上九点到晚上九点,因此我们一天开两次站会,分别是早上九点的晨站会和晚上五点的暮站会。

其次,明确站会的任务就是提出问题,只提出不解决。因为一旦要解决问题就会讨论,就可能有不同意见,然后时间就不可控。基本上我们的站会时间控制在5分钟左右。

第三,站会的流程是先检查一下之前遗留的问题是否已经解决,责任人和时间有没有问题,然后每个组、每个成员都可以提出当前碰到的问题,问题一定要描述精确,不能泛泛而谈。要有专人记录问题是否解决和提出的问题。

第四,在站会后,专人发出邮件给项目组所有成员,列出最近解决的问题、这次提出的问题和历史解决问题。每个问题都会有一个日期+序号的编号,以及问题解决人是谁,便于跟踪。这个邮件还可以抄送给不在项目组的方方面面的领导,便于了解进度和指出可能的疏漏。

最后,既然站会只是提出了问题,那么之后的时间是要解决问题的,所以除了电子邮件以外,我们还是准备了白板,一分为二,一边是要解决的问题,一边是已经解决的问题,来提醒项目组的成员。我发现这几乎是Jira的敏捷工具唯一的问题,没有提供站会的功能,我之前使用的assembla敏捷工具中是有这个功能的,那样的话就可以派发给相关人了。

从我们实践上来看,绝大多数问题都在一天内提出到解决,问题尽量不要超过一周,还是这个道理,一个sprint大约两到三周。

敏捷开发的敏捷是全方位的,包括开会和问题解决,保证每个事务的效率,才可能整体效率提高。