首页 > 代码库 > 敏捷开发的一点感受
敏捷开发的一点感受
用了3天，充分挤完了海绵里的时间，看了《轻松Scrum之旅：敏捷开发故事》这本书，觉得写得很好，有意思，找到了当时看大话设计模式时候的感觉。
从书的题目可以看出，这本书主要是讲敏捷开发的，我也是第一次接触，理解的不好还请读者见谅。
一、从技术角度看：传统的瀑布模型由于在前期花费了大量时间去分析需求和准备文档，导致在产品模型在时间上的每一次迭代都会很漫长。而这其中很可能会发生需求的不断变化，甚至产品完成后早已和时代脱节，失去了其本应产生的作用。造成的后果很明了：用户不满意，而且耗资很大。
而敏捷开发显得更为轻灵多变一些。首先，轻量级的文档使我们不再需要准备一些多年无人问津的复杂分析和记录；另外，对变化的充足准备使得需求的频繁变动不再成为程序员的噩梦。
二、从组织管理角度来看，1、我们传统的团队开发很可能存在以下现象。如：部门之间不协调，缺乏充分的沟通，人际交流成为一纸空谈；小组内各成员也常常是各自开发自己的部分，对项目整体或与自己相关的部分也不很了解；沟通渠道缺乏导致上传下达和团队交流出现一些不必要的问题，甚至引发矛盾。
这些问题的根源就来自于缺乏相应的机制进行组织和交流，把大家的意见和想法充分表达出来是敏捷开发中以人为本、团队合作的宗旨。
2、在项目把控上，传统的开发都是定义好的，根据计划把整体的任务都一次性定好，缺乏灵活性，难以应对内外部环境的变化。但敏捷开发中的Backlog—Story—Task任务划分机制很好的解决了这个问题，使得在项目需求有较大变化时通过先急后缓的方式充分应对。
3、在部门划分上，敏捷开发提倡按产品划分，而不是部门。把编码和测试人员绑定在一起，使整个开发的过程成为一个流畅的整体，避免了出现相互争资源；把单元测试放到每一个Sprint阶段之后进行，减轻了集成测试的压力，缓和了测试人员由于不理解需求，测试不彻底或描述不准确与程序员产生分歧。
三、从学习角度看，我们可以借鉴敏捷开发中的一些优秀经验和思想。平时兼顾整体规划和细节规划，在应对变化上要做到灵活，给自己预留足够的缓冲时间。
做好人际交流，了解集体状况、优秀的或与自己紧密相关的个人的状况，这是自我调整的强有力参考。
最后，要做好选择，找到适合自己的环境和方法。踩在如此多的“关毅”的肩膀上，我们已经有足够的知识水平和认知能力去适应这个世界的节奏了。
从书的题目可以看出，这本书主要是讲敏捷开发的，我也是第一次接触，理解的不好还请读者见谅。
一、从技术角度看：传统的瀑布模型由于在前期花费了大量时间去分析需求和准备文档，导致在产品模型在时间上的每一次迭代都会很漫长。而这其中很可能会发生需求的不断变化，甚至产品完成后早已和时代脱节，失去了其本应产生的作用。造成的后果很明了：用户不满意，而且耗资很大。
而敏捷开发显得更为轻灵多变一些。首先，轻量级的文档使我们不再需要准备一些多年无人问津的复杂分析和记录；另外，对变化的充足准备使得需求的频繁变动不再成为程序员的噩梦。
二、从组织管理角度来看，1、我们传统的团队开发很可能存在以下现象。如：部门之间不协调，缺乏充分的沟通，人际交流成为一纸空谈；小组内各成员也常常是各自开发自己的部分，对项目整体或与自己相关的部分也不很了解；沟通渠道缺乏导致上传下达和团队交流出现一些不必要的问题，甚至引发矛盾。
这些问题的根源就来自于缺乏相应的机制进行组织和交流，把大家的意见和想法充分表达出来是敏捷开发中以人为本、团队合作的宗旨。
2、在项目把控上，传统的开发都是定义好的，根据计划把整体的任务都一次性定好，缺乏灵活性，难以应对内外部环境的变化。但敏捷开发中的Backlog—Story—Task任务划分机制很好的解决了这个问题，使得在项目需求有较大变化时通过先急后缓的方式充分应对。
3、在部门划分上，敏捷开发提倡按产品划分，而不是部门。把编码和测试人员绑定在一起，使整个开发的过程成为一个流畅的整体，避免了出现相互争资源；把单元测试放到每一个Sprint阶段之后进行，减轻了集成测试的压力，缓和了测试人员由于不理解需求，测试不彻底或描述不准确与程序员产生分歧。
三、从学习角度看，我们可以借鉴敏捷开发中的一些优秀经验和思想。平时兼顾整体规划和细节规划，在应对变化上要做到灵活，给自己预留足够的缓冲时间。
做好人际交流，了解集体状况、优秀的或与自己紧密相关的个人的状况，这是自我调整的强有力参考。
最后，要做好选择，找到适合自己的环境和方法。踩在如此多的“关毅”的肩膀上，我们已经有足够的知识水平和认知能力去适应这个世界的节奏了。
敏捷开发的一点感受
声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉： 投诉/举报 工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。