`
taowen
  • 浏览: 193562 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

为什么我的敏捷项目有如此多的问题?

阅读更多

OK,敏捷哈。不争论什么是敏捷。我们来看一些现象,然后你来告诉我,你有没有遇到过这些问题。

没人提真正的Feedback

每个迭代结束之后,我都会做Showcase。但是从Showcase上收集到最多的,就是UI的问题,字体太小之类的。每个Release发布之后,项目都会部署一个试用版本。但就是不见真正的用户来“试用”,就更别提Feedback了。敏捷不是强调Feedback吗?客户(Customer)时间不够,同时他们也不是最终用户,提不出足够有深度的Feedback。而最终用户呢,压根就没兴趣。

架构咋弄啊

每个迭代都要被催着出东西,哪里有时间弄架构哦。一开始就一个劲的加功能。前几个迭代大家都很Happy,功能出来的特别快。后来就越来越慢了,团队情绪也很差。

客户说没有不是Must Have的

事情实在太多了,做不完呀。那让客户来排优先级吧,把哪些是Must Have的找出来。但是客户说了,这些都很重要,没有这个Feature,或者那个Feature系统就压根没有用处。

路漫漫其修远兮,我到底在往哪走

团队的成员越来越多地在抱怨,天天做Story。但是这些Story都是干什么用的呢?这做一点,那做一点,根本就整合不到一个Vision里去。客户说,我给了你Vision啊,你看这个Feature那个Feature,这些要做的东西就是我们的Vision啊(心里还在犯嘀咕呢,你们干活的吵什么吵)。

 

这些问题都有一个相同的最终根源。我们先来看最明显的Feedback问题。为什么客户和最终用户都不提Feedback?因为不关他们的事!做Showcase不过就是在眼前晃两下,有深度的Feedback不是那么容易及时地想到的。而Release又有多少是真正部署到产品环境的?最终用户一方面还用这旧的系统,天天忙着四脚朝天的,哪里有时间来试用我们的新系统呢?无论你是设置了一个测试机在他的桌子旁边,还是一天三次的发Email提醒。只要你的系统不是完成他工作必须的一部分,他就不会理你。

为什么Release出来的系统不能部署到Production环境呢?这不是很奇怪吗。是的,确实很奇怪。但是,假如你是客户,你被你的组织委任了一个替换现有系统的差事。现有的系统有100个功能,完全开发完这些功能可能需要两年。但是,每三个月都有一次绩效考核。你会不会希望每三个月,就让领导看到你都弄出了点了啥?于是你找到了一个号称可以做敏捷开发的外包公司,要求他们每三个月给你出一个版本。但是这个版本能真正上Production么?不能!现有系统有100个功能,那么多用户在用呢。你三个月弄出来的系统怎么替换这么大一个系统啊?一个“成熟的企业”,对于一个这样系统的GO OR NOT GO MEETING都要开三个月呢。

也许你要说,我们是真正的Green Field开发,彻底重头写的。那么有你开发的系统之前,这家企业是怎么运作的?至少有一个Paper Process吧。没有电子系统,人们就用纸笔,各种单据来工作呗。IT系统不过是Paper Process的自动化而已。再说了,这年头还真没几个请得起我们,而且现在还没有一个IT系统的,需要从Paper Process开始的?

除非你做的是非常有创新性的企业开发。通过创新性的IT系统,开发新的业务。比如通过新的交易应用来辅助新的Margin Loan产品的市场投放。大部分时间来说,我们都是被引入进来“替换”现有的Paper Process,或者现有的遗留应用的。

 

假设我们要替换的就是一个有100个功能的遗留应用,我们是怎么来“玩”敏捷的呢?基本上来说,我们假设了一个温室的环境。在这个环境里,你可以假设你做的是Green Field的开发。把100个功能,分成多个Release,每个Release又分成多个Iteration。在每个Release之后都会发布一个Pilot版本给测试用户试用。这样就可以迭代式地添加Feature,直到最后能够替换原有的系统。从我的经验看来,正是这种做法,部分导致了以上问题(甚至有些情况下是根源)。前面已经提到了,这样会导致缺少来自最终用户的,真正的Feedback。其次,由于少了一个Feature都无法替换旧的系统,客户很难做出优先级的正确选择。以替换旧的系统为目的,所有的Feature都是Must Have。同时这样会导致每个Release缺乏明确的,唯一的Goal。经常是这个Feature做一些,那个Feature做一些,Team会觉得没有明确的目标。

 

如果我们不以替换旧的系统为目标?那么应该以什么为目标?这个时候你可以去看看Eric Evan的Strategic Design。他说,你应该想想What drives you to spend million dollars on this project in the first place(你为什么在最开始要在这个项目上决定花上一百万美元)。这个背后一定是原因的。基于对这个原因的理解,我们可以选定一定的Feature来实现。然后就开始实现,然后把实现部署了让所有的用户去用。用这种策略,而不是前面那种策略,这样就逼着我们去做很多事情。而我相信这些事情,很有可能就有助于解决前面四个问题。特别是,其中的架构问题。为什么呢?架构是什么?架构就是对问题的一种分解方式。怎么样才能迫使我们去思考架构问题呢?在现有的系统上打个洞,然后挖掉一块,围一道墙,里面再把新的Feature做出来。没有对系统整体的了解,没有对模块的分解,没有对模块之间耦合依赖关系的分析,是不可能做到这些的。这样就迫使我们做出一个低耦合高内聚的架构!

 

把这种策略做到极致就是之前我说过的持续部署才是王道。不但每个Release都和旧的系统集成起来,然后真正的部署。甚至,我们可以做到每个迭代都部署。在Fred George描述的团队里,甚至都没有迭代。一个Feature开发出来就立马被部署了。

0
2
分享到:
评论
5 楼 toafu 2011-04-17  
我的理解是,持续集成和交付也解决不了人的问题。
4 楼 kong_desheng 2010-03-15  
写得比较实在,中国软件企业中很多项目,都是像这个项目一样,从一开始就注定要失败的。
我个人认为,这样的典型项目,其失败的主要原因有:
1) 需求分析不到位。客户具体需要什么,研发团队没有深刻而完全理解清楚。而依赖客户把需求都说清楚,根本不切实际。
2)没有优秀的软件架构师来设计、控制整个系统的架构。以为敏捷了,就不用架构了。
3)需求失控。什么都想做,各种功能特性被不断加入到开发计划中,每个特性都实现得一团糟,代码质量无法控制,项目一再延期,团队士气低迷。
4)敏捷:敏捷是一种软件开发过程,而软件开发能够成功,根据上讲,取决于项目团队成员的技能,包括需求分析技能、需求管理的技能、系统架构的技能、软件编码的技能、测试的技能等等。在中国搞敏捷开发,需要在对软件研发管理有深刻理解和丰富实战经验的人的领导下进行,方有成功的希望。


3 楼 andyhu1007 2010-03-10  
深切理解你的这些感受。说白了,谁都不会太关心跟那些远在天边而不是跟当前利益相关的事情。
2 楼 agiledo 2010-03-10  
我的一些意见:
架构-需要有高水平的架构师角色,架构不是3个臭皮匠就会赛过诸葛亮。
Feedback:客户只会做利益相关的事情。所以同意你的说法,部署。不是“potentially shippable", 而是“shippable”。只有在线使用,用户才会反馈最痛的问题
Must have:我也遇到同样问题,我的做法是拆分故事,直到我们团队可以保证质量在一个sprint内完成。拆分任务是SM和PO很重要的事情

希望和你多交流。
另外,我们团队实践敏捷开发(Scrum),有一些做法和教训,希望和你分享:
公司背景:通讯公司,团队最初不了解Scrum,开发团队有最初的几个人发展到几十个人。由一个Scrum团队发展到多个Scrum团队,有专门的PO团队。。。

目前文档完成的内容包括:
团队建设、评估会议、Sprint 计划会议1、Sprint 计划会议2、每日例会、Sprint 评审会议、Sprint 回顾会议、质量保证、经验总结、Product Backlog、过程监控、部署、SM的角色、PO的角色、沟通、教训总结、典型问题、32人的Scrum团队
完整内容共81页,28M;完整版可以在www.agiledo.cn中下载。

如果您对细节有兴趣,让我们讨论、不断改进。

我的联系方式:(Andy Yuan 袁斌)
邮件:andy@agiledo.cn;yuan_bin01@163.com;
MSN:agiledo@hotmail.com;
手机:13501397696;
QQ:908235532
1 楼 orcl_zhang 2010-03-10  
引用

而最终用户呢,压根就没兴趣。
这些问题都有一个相同的最终根源。我们先来看最明显的Feedback问题。为什么客户和最终用户都不提Feedback?因为不关他们的事!做Showcase不过就是在眼前晃两下,有深度的Feedback不是那么容易及时地想到的。

我很关心你们的需求是如何做的?我在想,既然客户对新系统不关心,那他搞新系统干吗?
我觉得对于敏捷开发,最重要的是先对需求有一个大体的正确的理解。
当某个模块或者功能需求确认80%以上,或者可以满足开发条件的情况下,以简单的方式把需求实现。
然后在以小版本release,用户反馈的方式来挖掘更深层的需求。
引用
也许你要说,我们是真正的Green Field开发,彻底重头写的。那么有你开发的系统之前,这家企业是怎么运作的?至少有一个Paper Process吧。没有电子系统,人们就用纸笔,各种单据来工作呗。IT系统不过是Paper Process的自动化而已。再说了,这年头还真没几个请得起我们,而且现在还没有一个IT系统的,需要从Paper Process开始的?

这个感觉是个梦想。。
我们现在做的这个项目,客户比较关心。但是由于公司年轻,刚成立,项目组也年轻,刚组成,组员经验也不多,都是刚从java,c++转来的,而且没有敏捷开发的经验,也没有和客户挖掘需求的经验,所以请了外援来。存在的问题主要是经验和团队配合,不过经过这个项目大家都成长很多。客户这边比较配合,我们也是针对某些问题发布某个release,然后客户feedback。这些都比较顺利。比较严重的就是项目的每个release都比较延期一些。

相关推荐

    敏捷开发基本概念

    3. 客户协作优于合同谈判:在敏捷项目中,与客户的紧密合作是至关重要的,以确保产品符合实际需求。 4. 适应变化优于遵循计划:敏捷开发鼓励在开发过程中接受变化,以保持项目的竞争力。 敏捷宣言还包含十二个原则...

    为什么开放、透明的环境对于大数据团队是如此重要?.docx

    当员工意识到他们有权利和责任提出问题,他们会对工作投入更多热情,主动寻求改进。例如,对于工具不完善的抱怨,员工可能会积极参与到工具优化的过程中,从而提高整个团队的工作效率。 为实现开放透明的环境,企业...

    敏捷开发之通俗理解

    敏捷开发并不是一个严格意义上的完整开发模型,而更多地体现为一种思维方式或哲学。它并不像传统的瀑布模型那样,有着固定且详细的阶段划分及流程规范。相反,敏捷开发更加注重灵活性和适应性,强调快速响应变化而非...

    敏捷方法在测试计划中的应用

    在瀑布或者敏捷项目中您觉得测试计划有什么问题?这些问题相似或者不同吗?  InfoQ:在瀑布或者敏捷项目中您觉得测试计划有什么问题?这些问题相似或者不同吗?  EddyBruin:我记得我对我编写的第一个主测试计划非常...

    敏捷软件测试

    - **响应变化**:敏捷的核心是适应变化,测试策略也应如此。 - **自我组织**:鼓励团队成员自我管理和自我激励。 - **关注人**:以人为本,重视团队成员的发展和个人成长。 - **享受乐趣**:积极乐观的态度有助于...

    敏捷模型详解-流程与关键节点

    - **解决问题**:识别并讨论任何阻碍项目进展的问题。 - **增强协作**:鼓励团队成员之间的相互支持和协作精神。 通过上述内容的介绍,我们可以看出敏捷开发不仅是一种软件开发的方法论,也是一种思维方式。它强调...

    建筑施工的常见问题及策略.doc

    5. **过程监控与改进**:文档中提到的施工管理问题,比如缺乏全面动态监管,提示我们在IT项目管理中,应实施严格的项目跟踪和控制,使用敏捷方法或DevOps工具来实时监控项目进度,及时发现问题并进行调整。...

    软件项目管理工具表

    例如,Jira是一个流行的选择,它用于敏捷项目管理,支持Scrum和Kanban方法;Trello则提供了一个看板视图,便于团队成员可视化任务状态;而Confluence则用于知识管理和团队协作。这些工具可以帮助项目经理跟踪任务,...

    梦断代码英文PDF版

    本书的核心问题是:“为什么好的软件如此难以创造?”这一问题贯穿全书,试图揭示软件开发过程中存在的根本性难题。尽管计算机科学已经发展了半个世纪之久,但至今仍未找到一个完美的答案来解决这一问题。本书通过一...

    软件工程的软件工程项目管理.pptx

    #### 为什么软件工程项目管理如此重要? - **确保项目进度与质量**:通过持续监控项目的进度与质量,确保项目能够按照既定的时间表完成,并达到预期的质量标准。 - **提高开发效率**:通过有效的管理和协作机制,...

    IT项目管理那些事儿.pdf

    这些方法论为项目团队提供了不同的工作方式与流程指导,有助于提高项目执行效率与质量。 #### 3. 风险管理 风险管理是IT项目管理中的一个重要环节,涉及识别潜在风险、评估风险可能性及影响、制定应对策略等步骤。...

    石油工程留学常见问题与解答.doc

    在整个面试过程中,表现出对行业的热情、持续学习的态度以及处理复杂问题的能力,将有助于你在众多竞争者中脱颖而出。 对于有意申请石油工程留学的学生来说,除了学术成绩外,积累实践经验、提升沟通技巧和团队合作...

    敏捷思维-架构设计中的方法学(1-15).doc

    复杂度是导致项目失败的主要原因之一,因此,保持设计简洁有助于减少错误和维护成本。 6、迭代设计 敏捷开发倡导迭代和增量式开发,每次迭代都应有可工作的软件交付。架构设计也应如此,逐步构建,每次迭代完善一...

    1软件开发项目管理概述.pptx

    软件项目尤其如此,它们通常涉及开发独一无二的软件解决方案,满足特定用户的需求。项目有明确的目标、整体性、一次性、资源消耗性和不确定性等特征。与此相反,日常运作是重复性的、目标导向的,并且通过职能式线性...

    Yocto 项目概述和概念手册.pdf

    ##### 2.1 什么是 Yocto 项目? Yocto 项目是Linux基金会旗下的一个项目,旨在提供一套完整的工具和框架,帮助开发者构建定制化的嵌入式 Linux 系统。它不仅仅是一个构建工具,还是一套涵盖了从开发到部署整个生命...

    敏捷思维-架构设计中的方法学.doc

    总之,方法学是软件开发不可或缺的一部分,尤其在敏捷开发环境中更是如此。通过理解和应用方法学中的核心要素,可以有效提高项目的成功率。同时,注重沟通与反馈机制的建设,能够进一步增强团队的协作能力,确保项目...

    97 Things Every Project Manager Should Know

    即当项目中出现一个新问题时,解决这个问题的过程中又会暴露出新的问题,如此循环往复。作者建议通过更好的需求管理和变更控制流程来避免这种现象的发生。 - **实际应用:** 实施敏捷开发方法论可以帮助团队更好地...

Global site tag (gtag.js) - Google Analytics