MyException - 我的异常网
当前位置:我的异常网» 研发管理 » 小弟我们的项目敏捷失败了

小弟我们的项目敏捷失败了

www.MyException.Cn  网友分享于:2013-12-24  浏览:8次
我们的项目敏捷失败了

首先告诉大家一个好消息,我们的项目采用敏捷Scrum进行X项目开发宣告失败,中途不得不转向传统过程。
为什么是好消息?我认为:失败是成功之母。没有失败就发现不到所隐含的实际问题,将实际问题解决才是成功的必经之路。如果第一次成功反而不正常,所以这次的失败是个好消息。
下面我将结合敏捷Scrum在该项目中应用失败的经验与大家分享。

引出实际的问题(也是现象)

  1. 整个团队没有掌握敏捷Scrum。
  2. 团队成员不知如何更好地划分User Stories。
  3. 在需求分析阶段我们更多的是在争吵需求。
  4. 我们对现有的持续集成工具了解甚少。
  5. 我们没有用(自动)测试来驱动开发(TDD)的动力。
  6. 开发过程中其他团队的人需要我们的帮助。
  7. 领导们仍然在等待团队的开发进展汇报。
  8. 缺乏有实践经验的Scrum Master的指导。

整个团队没有掌握敏捷Scrum

整个团队对敏捷思想还没有基本的了解,甚至还有很多人认为敏捷就是“裸奔”。有些误认为仅有状态墙就是敏捷了。
在X项目敏捷过程中,A同事问我Sprint是什么,Backlog又是什么,等等。
当然这是因为当时缺少敏捷培训所致。
我个人理解:敏捷就是在合理的时间内高质量迭代式地完成客户所需软件的开发过程,去掉多余的无实际意义的工件。而Scrum是敏捷过程的其中之一,它有一定的过程规范要求。

团队成员不知如何更好地划分User Stories

X项目团队成员缺乏搜寻User Story的能力。
由于接触敏捷时间不长,加上Scrum的Story又是项目中的重中之重。而如何搜寻User Story?一时也不知所措。
Story Point更加是雾里看花,越看越花。X项目V1R2版本的Story Point基本上是拍脑袋拍出来的,对Scrum的Story Point理解不深没有掌握,所以拍出来的都缺乏实际意义。具有讽刺意味的是状态墙上的燃尽图走的是楼梯形。
推荐大家看《User Stories Applied》,目前只有英文版。

在需求分析阶段我们更多的是在争吵需求

在讨论需求时,我们开发人员一直都是在没有客户在场的情况下进行需求分析和争吵的。
A、B、C都是开发者。A认为x需求应该加入该版本,B认为y需求也应该加入该版本。C发言了,他提出z需求,而且他还情不自禁地说出了z需求如何实现的。C又认为A的x需求不合理,B认为C的z需求不合理。争吵中……
需求分析时,不是只听某个人的也不是只听领导的(领导有时也犯错),而应该是更多地听取客户(或者客户代表、产品代表)的声音。之所以敏捷Scrum中也把客户纳到软件开发团队中来的目的。

我们对现有的持续集成工具了解甚少

在X项目敏捷时误以为暂时没有持续集成工具我们也可以做到敏捷,然而结果就是失败。
持续集成就是每天晚上(充分利用工作以外的时间)自动编译连接和测试运行所有的模块,尽早地暴露出问题。
在X项目敏捷中都是手动地测试,每次要一起测试时都要重新搭建环境。测试验证效率低。
我了解到现有的CC.NET为免费的,但听说配置比较复杂。
不管工具怎样不方便,我们仍需要加快熟悉持续集成工具。

我们没有用(自动)测试来驱动开发(TDD)的动力

X项目敏捷时的误区:我们编写代码都是先编写好后再来手动地进行测试,没有真正用上TDD。
最大的原因就是大家都不知如何开始TDD,心存疑虑。
在X项目敏捷失败后,我初试一下TDD开发X项目命令行联想模块。现正在开发当中就已经感觉到TDD的好处。其中TDD步骤如下:
1、写一个测试程序。考虑一下你希望实现的操作(功能)要如何使用代码来体现。
2、尽快地让测试程序可运行。如果明显存在一个整洁、简单的解决方案(例如伪实现),那么就将其键入。如果这个方案需要耗费一分钟的时间,再仔细想想怎样才能几秒钟内就能运行通过。
3、编写合格的代码。将第2步的简单方案优化,消除先前引入的重复设计,使测试尽快通过。

开发过程中其他团队的人需要我们的帮助

A同事在进行X项目开发的同时又要支持M产品。B同事更加是忙不开,因为他比较热心,其他团队的人有问题就找他。
我们正在开每日15分钟例会,其他团队的某同事要求A帮忙定位一个问题。
正在开发中,一个电话过来需要参加一个会议。
同样正在开发中,一个使用X项目的用户打电话过来说,strstr函数是如何用的。-_-!
像这种被很多事情干扰的例子数不胜数,开发效率必受到影响,敏捷也许就是空谈。

领导们仍然在等待团队的开发进展汇报

我记得在X项目 V1R2的第1个Sprint中,同事A坚持认为要向领导们每周汇报开发进展。
他打心里上说不汇报,领导们不知道我们在做什么,做到什么程度了。当时我也当心领导们不知道如何看我们的状态墙而没有反对。
同事A在汇集进展时要向每个人问一问,而且还征求团队每个人的同意。这一搞下来1个小时时间整理不到10行的进展汇报。
建议领导们也应该参加敏捷培训。

缺乏有实践经验的Scrum Master的指导

在X项目敏捷过程中缺少这个角色。
假设对敏捷Scrum有着基本的认识和了解,也必须要有经验的Scrum Master来引导。因为他可以:
引导实践过程出现问题时如何解决。
引导我们什么时候该计划Sprint和如何计划。
引导我们什么时候该回顾Sprint和如何回顾。
引导我们如何找到真正的Story。
引导我们如何玩转敏捷Scrum。
引导我们不会走老路。

 

文章评论

旅行,写作,编程
旅行,写作,编程
一个程序员的时间管理
一个程序员的时间管理
要嫁就嫁程序猿—钱多话少死的早
要嫁就嫁程序猿—钱多话少死的早
什么才是优秀的用户界面设计
什么才是优秀的用户界面设计
我是如何打败拖延症的
我是如何打败拖延症的
编程语言是女人
编程语言是女人
做程序猿的老婆应该注意的一些事情
做程序猿的老婆应该注意的一些事情
漫画:程序员的工作
漫画:程序员的工作
为什么程序员都是夜猫子
为什么程序员都是夜猫子
总结2014中国互联网十大段子
总结2014中国互联网十大段子
Web开发人员为什么越来越懒了?
Web开发人员为什么越来越懒了?
团队中“技术大拿”并非越多越好
团队中“技术大拿”并非越多越好
不懂技术不要对懂技术的人说这很容易实现
不懂技术不要对懂技术的人说这很容易实现
程序员都该阅读的书
程序员都该阅读的书
那些争议最大的编程观点
那些争议最大的编程观点
 程序员的样子
程序员的样子
中美印日四国程序员比较
中美印日四国程序员比较
我跳槽是因为他们的显示器更大
我跳槽是因为他们的显示器更大
程序员的鄙视链
程序员的鄙视链
每天工作4小时的程序员
每天工作4小时的程序员
程序员和编码员之间的区别
程序员和编码员之间的区别
写给自己也写给你 自己到底该何去何从
写给自己也写给你 自己到底该何去何从
聊聊HTTPS和SSL/TLS协议
聊聊HTTPS和SSL/TLS协议
程序猿的崛起——Growth Hacker
程序猿的崛起——Growth Hacker
老美怎么看待阿里赴美上市
老美怎么看待阿里赴美上市
程序员眼里IE浏览器是什么样的
程序员眼里IE浏览器是什么样的
亲爱的项目经理,我恨你
亲爱的项目经理,我恨你
为啥Android手机总会越用越慢?
为啥Android手机总会越用越慢?
Java 与 .NET 的平台发展之争
Java 与 .NET 的平台发展之争
科技史上最臭名昭著的13大罪犯
科技史上最臭名昭著的13大罪犯
Java程序员必看电影
Java程序员必看电影
看13位CEO、创始人和高管如何提高工作效率
看13位CEO、创始人和高管如何提高工作效率
鲜为人知的编程真相
鲜为人知的编程真相
初级 vs 高级开发者 哪个性价比更高?
初级 vs 高级开发者 哪个性价比更高?
代码女神横空出世
代码女神横空出世
程序员周末都喜欢做什么?
程序员周末都喜欢做什么?
Web开发者需具备的8个好习惯
Web开发者需具备的8个好习惯
“懒”出效率是程序员的美德
“懒”出效率是程序员的美德
程序员应该关注的一些事儿
程序员应该关注的一些事儿
如何区分一个程序员是“老手“还是“新手“?
如何区分一个程序员是“老手“还是“新手“?
程序员最害怕的5件事 你中招了吗?
程序员最害怕的5件事 你中招了吗?
10个帮程序员减压放松的网站
10个帮程序员减压放松的网站
如何成为一名黑客
如何成为一名黑客
当下全球最炙手可热的八位少年创业者
当下全球最炙手可热的八位少年创业者
10个调试和排错的小建议
10个调试和排错的小建议
软件开发程序错误异常ExceptionCopyright © 2009-2015 MyException 版权所有