当《开心农场》这样一款SNS游戏风靡网络的时候,“今天你偷菜了吗?”成为网络的流行语,而我们部门基于此编排的小品在集团的联欢会上一炮打响。而今天,在现代的软件开发领域中,敏捷开发运动开展的如火如荼,在软件工程领域又掀起了一场革命。在这场革命中,我们能不能及时有效的实施敏捷开发,能不能关注软件开发中最核心的部分,化繁为简,我们是不是需要时刻问我们自己:“我们今天敏捷了吗?”。
看完了《高效程序员的45个习惯—敏捷开发修炼之道》,对敏捷开发有了更深刻的认识。以前在学习Grails这个框架的时候,曾经体会到Grails带给我们的敏捷(《Grails初体验》)。但这只是软件技术在敏捷开发上的一种实践,它里面蕴含的思想和实现,颠覆了我们以往传统的软件开发模型,在我的思想里引起了巨大的震撼。而读完这本书,让我对敏捷认知的层面也越来越宽广。那什么是敏捷呢?
敏捷开发就是在一个高度协作的环境中,不断的使用反馈进行自我调整和完善。
敏捷开发是一种把以人为本、团队合作、快速响应变化和可工作的软件作为宗旨的开发方法。
敏捷方法可以快速的相应变化,它强调团队合作,人们专注于具体可行的目标(实现真正可以工作的软件),这就是敏捷的精神。它打破了那种基于计划的瀑布式软件开发方法,将软件开发的重点转移到一种更加自然和可持续的开发方式上。
那敏捷的精神是什么呢?我理解为以下几点
· 个体和交互胜过过程和工具
· 可以工作的软件胜过面面俱到的文档
· 客户合作胜过合同谈判
· 响应变化胜过遵循计划
而在我们的团队和所做的项目中,我们因为没有实施敏捷的开发方法而导致的一系列的问题,我总结如下:
· 没有及时的重构和迭代,导致项目越大,系统维护难度越大,成本越高。最后导致代码不敢修改,改一处而动全身,明知症结所在,却无从下手,留下大量的死代码,脏代码。在集团网、网上药店和KOA项目中,这些都有体现。项目的发布不是终点,功能的完成不是结束,不断的反省自己,不断的学习并加以改进,是老代码和新代码之间没有过大的差距,保持与时同步的先进性。
· 太重视结果而忽视了过程。一个新的项目,开始就制定计划,确定开发完成的时间。而往往由于时间的紧促,导致在项目实施的过程中,不能正确的设计、架构,不能不断的寻找优化的方案,不能不断的迭代重构以保证代码的先进性。这是因为我们太看重软件开发周期的前半部分,而忽视了后期的维护、扩 展,以及需求的不断变更。
· 产品发布的周期过长。我们总是期望能一次性的拿出一个好的产品,能在上线时尽善尽美,从而导致了,我们不能及时的让用户看到或者使用系统,不能及时的获取反馈,从而不能持续不断的改进。延长项目的周期,缩短项目的发布周期,重视软件生命周期的没一个过程,不断的迭代,循环,保证时时刻刻都 能发布可用的系统,这样的系统才有活力。
· 把需求的变更要么看成用户的刁难,或者责备自己开发的系统不容易扩展。其实不是,需求的变化是时时刻刻都在发生的,我们无法预知太远的将来,我们只要专注于眼前,然后不断的回顾、更新,保证需求的不断的满足。我们不要才开始就想调研好所有的需求而后期拒绝需求变化,我们也不要过分的设计可 扩展的系统,以保证能适应未来的变化。需求和架构都是在项目的过程中不断演化而来的,我们只要保持持续不断的更新、发布、保证代码的鲜活,这就够了。
· 既然需求的变更时无时无刻不在发生的,那就不断的和用户保持沟通,不断的发布可用的系统,不断的与用户协作,共同的完成系统。这一点我们做的很不好,我们花去了很长的前期调研时间,而在开发的过程中,却没有和用户保持持久的、频繁的沟通,导致项目最后变化很大,开发者和用户相互的抱怨。药 品不良事件上报系统就遇到过该情况,导致第一个版本完全和用户的想法不一致而重新开发。
· 太重视文档,而轻视了代码。我们往往花费了很长时间写了一大堆的文档来描述项目,而往往我们会将它们束之高阁。我们在项目的过程中,代码就是我们的文档,一切的变化和改进都是围绕着代码来进行。而我们不断的审查文档,却没有及时的审查我们的代码。谁敢保证项目中的代码风格的一致性,谁能保证项目中代码的质量都是很优秀的。质量差的代码经过时间的累积,就像隐藏在火炉边的炸 弹,随时都有可能被引爆。质量怎么保证,需要团队协作,需要集体完成功能,而不是一个人的战争。所以需要重构,需要迭代,更需要团队内部的交流和共同开发,同时需要时间作为保证。
那么我们应该怎样建立一个敏捷团队?我们有该怎样实施敏捷开发方法?那我们就深入到该书的每一章,去领悟敏捷,去深刻体会高效程序员的45个习惯吧。
原文出处:http://www.po-soft.com/blog/yongtree/1123.html
提供该文档的机构为 百洋软件研究实验室,更多的博客文章可以到 百洋软件研究实验室博客查看。该文档附件欢迎各位转载,但是在没有获得文章作者许可之前,不得对文章内容或者版权信息进行更改,版权归百洋软件研究实验室所有,仅此声明。
您可能会对以下文章感兴趣:
相关推荐
4. **站立会议**(Daily Scrum):敏捷团队每天的短暂会议,讨论昨天做了什么,今天计划做什么,以及遇到的障碍。这有助于保持团队同步,及时解决问题。 5. **Sprint**:在Scrum框架中,每个迭代被称为一个Sprint,...
每日站会中,团队成员分享昨天完成的工作、今天计划完成的任务以及遇到的问题,以保持团队间的同步。评审会议则是向利益相关者展示已实现的功能,获取反馈,并可能调整后续迭代的计划。回顾会议则用于团队内部总结...
2. 每日站会:这个会议一般比较短,一般不超过 15 分钟,这个会议只讲 3 件事情“昨天做了什么、今天计划做什么、遇到了什么问题”。 敏捷中还有许多其他的概念和技术,如燃尽图、看板、DOD 原则等,这些都是敏捷...
- **每日站会**:每天召开站会,每位成员回答“昨天做了什么”、“今天计划做什么”、“遇到了什么问题”,以此提高团队透明度,促进成员之间的协作。 - **代码审查**:完成代码编写后,项目经理或其他成员进行代码...
敏捷开发的流行得益于其适应性和高效性,尤其在需求频繁变更、市场竞争激烈和技术快速演进的今天。 敏捷软件开发原则、模式和实践涉及的几个关键方面如下: 1. 敏捷宣言的核心价值: 敏捷宣言是由一群软件开发...
《用户故事与敏捷方法》是敏捷开发领域的重要著作,作者Mike Cohn是敏捷开发的先驱之一,他在书中深入探讨了如何在敏捷项目管理中有效地使用用户故事来驱动开发过程。用户故事是敏捷方法中一个核心的概念,它代表了...
有时候,站会上的内容非常单调,如“我昨天解bug,今天继续解bug”。这种情况下,站会很难达到预期的效果。 **应对策略**:主持人需要引导团队成员分享更多有价值的信息,比如他们是如何解决问题的、遇到了哪些挑战...
在激烈竞争和充满无限可能的今天,响应变化的能力已成为组织的核心生存能力。因此,敏捷对于软件开发组织是一个必然的选择,而非一个可有可无选项。但如何正确实施敏捷,从而构建灵活响应的组织,却绝非易事,需要在...
3. **每日站会(Daily Scrum)**:也称为每日_scrum会议,团队成员每天进行短暂的同步交流,讨论前一天的工作进展、今天计划完成的工作以及任何阻碍。 4. **冲刺待办列表(Sprint Backlog)**:团队从产品积压工作...
今天我准备做哪些任务?我遇到了什么困难? * 演示会议:产品功能演示,面向对象为需求提出者(如PM)。参与者为所有产品开发人员,在演示的过程中,把需要改进的问题记录下来,加入以后迭代的任务列表。 * 回顾会议...
每天团队成员会进行15分钟的站立会议,分享昨天完成了什么,今天打算做什么,以及遇到了哪些障碍。这有助于保持团队同步,及时解决问题。 3. **评审会议(Sprint Review)**: Sprint结束时,团队会展示他们在...
- **每日Scrum(站立会议)**:团队成员分享过去一天的工作进展,计划今天的工作,以及面临的问题。 - **Sprint评审会议**:Sprint结束时,团队展示已完成的工作,邀请利益相关者提供反馈。 - **Sprint回顾会议**...
9. 每日站会:敏捷团队每天进行短暂的站立会议,讨论昨天做了什么,今天打算做什么,以及存在哪些障碍,以便团队成员之间保持同步,及时解决问题。 10.回顾会议:每次Sprint结束后,团队会进行回顾会议,评估过去的...
本书主要包含4部分内容,这些内容对于今天的软件工程师都非常的重要,它们是: ●Agile方法:主要讲述了如何去使用 Agile 方法,其中有很大一部分内容是告诉你为什么要这样做。 ●面向对象设计原则:本书包含...
”、“今天计划做什么?”、“有没有遇到阻碍?” #### 六、Scrum框架的第二阶段 - **Sprint评审会议**: 产品负责人确认已完成的工作,并演示给相关干系人。 - **Sprint回顾会议**: 反思和总结整个Sprint的过程,...
3. **站立会议**(Daily Scrum):每日团队同步会议,每个成员回答昨天做了什么、今天打算做什么以及遇到了什么问题,保持团队同步和透明。 4. **结对编程**:两个程序员共享一个工作站,一起编写代码,提高代码质量...
- **每日晨会**:团队每天进行15-30分钟的站立会议,回顾昨天的工作,讨论今天计划,并解决遇到的问题。腾讯尝试通过各种方式提高晨会效率,如轮流主持、在线工具等,以适应分布式团队协作。 - **结对编程**:在...