与敏捷的初次接触 敏捷开发XP项目管理软件测试编程
程序员文章站
2024-02-06 08:16:10
...
与敏捷的初次接触
在中国，大部分的软件开发都是采用瀑布模型，这种开发方式是从传统制造行业引生过来，大量的需求，尽可能详细的需求文档，这个过程要花费大量的时间，因为所有参与项目的人员都想把需求做得足够好，开发起来足够顺畅，事实上，这在软件开发行业经常都是不可能实现的，因为我们的客户总有新想法出来，因为我们的老板总是想开发一个尽善尽美的产品。
瀑布模型的逻辑是按照人的常规思维来走的，一步一步下来，我们在项目开发过程中，设计、制作、编码、测试的参与人员都在想做好自己的那部分工作，都在尽可能想完成自己的那部分工作，早点交差，所以，后期拒绝变化，当客户新的需求来了以后，开发人员总是在埋怨设计人员的设计，设计人员总是在埋怨做需求的人，这样一个恶性循环，导致大量的返工，大量的资源浪费，这都是大部分传统软件开发或者说叫采用瀑布模型开发的团队经常遇到的问题。
我们公司也是这样一个过程，由于是给公司自己开发的产品，所以老板就是我们的客户，项目进行到现在，感觉项目已经远远的脱离了最初的核心目标，老板不断的需求，不断的变化，设计不断的改动，开发人员不断的重新编码，导致项目上线时间一再延后，同事项目开发人员的情绪不断的变化，早已经没有当初的那股激情，包括我自己也是，被不断的新的需求压倒，不断的新的任务压倒，任务一大推，老大，经常再问，你这个做得怎么样了，那个出来了吗，搞得根本没有良好的状态来工作了，最近我一直在思考，问题出在哪儿了，因为怎样改变，因为老板的需求没有错，老板是客户，客户就是上帝。
在逛书店的时候，偶然见看到一本关于敏捷开发的书籍，虽然以前也经常听说敏捷，可是一直没有去关注，看了前几页，就买了这本书，一口气读完，感觉心情赫然开朗，感觉自己团队目前所遇到的问题，敏捷都可以解决，实在是有一种跟敏捷相见恨晚的感觉。
敏捷开发方式跟传统的瀑布模型有很大的不同，瀑布模型讲究严格的层级关系，同时拒绝后期的变化，敏捷则是拥抱变化后。
敏捷开发具体的方式有很多，这里着重介绍三种，即xp、rup和scrum，xp就是极限编程，着重讲的是具体的开发方式，rup则侧重项目开发周期的具体执行方式，内容比较复杂，先不减少了，这里我们主要讲 scrum，scrum是一种具体讲的一种项目任务的管理方式。
在scrum里，追求的价值观就是做有价值的能够使用的产品出来，所以，一般一个项目会根据时间的长短确定几个开发周期，即sprint，每个sprint完成都会出来一个可以运行的成品，这里也是跟瀑布模型有很大的区别，瀑布模型一般都是最后才出来成品，严格的层级关系，而在scrum，设计、编码、测试是同步进行的，这样大大的节省了资源，不会在设计的时候，编码人员和和测试等着，编码的时候，测试人员等着，会为整个产品节省大量的成本。
在scrum里，一个项目下来以后，会有一个product backlog，里面会写一些比较简短的story
，这些story大概描述的项目初略需求以及核心，这里不会很详细，不会像瀑布模型哪像一大堆文档，因为谁也预料不到需求的变化，当确定好sprint的周期之后，再会确定第一个sprint的backlog，再根据sprint里面的story去划分具体的task，给这些task确定时间，优先级，这里是相当重要的，每个task都会有状态跟着，当前是否在进行，当前是否呗阻塞，当前是否已经完成，而且这些task会让团队人员自己去挑选，这样就不会出现一个擅长后台的人去捣鼓前台，一个擅长前台的人员去捣鼓后台，浪费大量的时间了，同时，这些任务都是自己挑选的，对开发人员来讲，做起事来也是很顺心，很开心。
在scrum里面，还有一个最主要的事情，那就是每日的scrum会议，这个会议不会太长，一般都会回答三个问题，“昨天做了什么？”，“今天准备做什么”，“遇到了什么困哪？”，这样就会让每个开发人员每天都会很有成就感，同时，每天团队所有人都会知道整个团队的进展情况，相互之间的问题也可以得到及时的解决。
Scrum主要强调团队的沟通能力，最快的沟通，最好的沟通，最好是面对面的沟通，强调团队的自我管理能力，把开发的责任变成义务，让大家每天在任务的task状态的驱动下，都有成就感。
Scrum拥抱变化，当老板的需求来了以后，可以给这些新的story划定优先级进行管理，不会再出现以前那样的老是做着偏离核心的东西，开发出一大堆无用的功能，有人说，scrum不讲究文档，其实这是不正确的，scrum也会有文档，一般一两张纸就足够了，不需要像以前那样费时费力的整一大堆文档出来，结果没人看几眼，敏捷讲究的是效率，讲究的是质量，讲究的是尽快做出能让客户看到的有价值的东西，这样在尽可能早的时间内，给出反馈，做出修改，避免后期的大改动。
Scrum需要设计、开发、测试、客户一起参与，这样才能完成一个完美的产品。
其实在实施敏捷的过程当中，不仅仅是scrum，敏捷讲究的是高效，有效，所以一切有利于开发的方法方式都可以加进来，比如，xp里面的很多东西，都是对开发非常有帮助的，如：结对编程、重构、持续集成等等，这些都是实施一个敏捷团队必须的。
以上就是对敏捷的一点点认识，更多东西还有待慢慢学习。
Task状态图
注：
Scrum:一种敏捷实施方式
Xp：敏捷实施方式
Backlog：记录开发任务
Story：一个一个的需求
Task:任务
Sprint:scrum中的一个开发周期。一般为两周至两个月不等，具体根据项目确定
在中国，大部分的软件开发都是采用瀑布模型，这种开发方式是从传统制造行业引生过来，大量的需求，尽可能详细的需求文档，这个过程要花费大量的时间，因为所有参与项目的人员都想把需求做得足够好，开发起来足够顺畅，事实上，这在软件开发行业经常都是不可能实现的，因为我们的客户总有新想法出来，因为我们的老板总是想开发一个尽善尽美的产品。
瀑布模型的逻辑是按照人的常规思维来走的，一步一步下来，我们在项目开发过程中，设计、制作、编码、测试的参与人员都在想做好自己的那部分工作，都在尽可能想完成自己的那部分工作，早点交差，所以，后期拒绝变化，当客户新的需求来了以后，开发人员总是在埋怨设计人员的设计，设计人员总是在埋怨做需求的人，这样一个恶性循环，导致大量的返工，大量的资源浪费，这都是大部分传统软件开发或者说叫采用瀑布模型开发的团队经常遇到的问题。
我们公司也是这样一个过程，由于是给公司自己开发的产品，所以老板就是我们的客户，项目进行到现在，感觉项目已经远远的脱离了最初的核心目标，老板不断的需求，不断的变化，设计不断的改动，开发人员不断的重新编码，导致项目上线时间一再延后，同事项目开发人员的情绪不断的变化，早已经没有当初的那股激情，包括我自己也是，被不断的新的需求压倒，不断的新的任务压倒，任务一大推，老大，经常再问，你这个做得怎么样了，那个出来了吗，搞得根本没有良好的状态来工作了，最近我一直在思考，问题出在哪儿了，因为怎样改变，因为老板的需求没有错，老板是客户，客户就是上帝。
在逛书店的时候，偶然见看到一本关于敏捷开发的书籍，虽然以前也经常听说敏捷，可是一直没有去关注，看了前几页，就买了这本书，一口气读完，感觉心情赫然开朗，感觉自己团队目前所遇到的问题，敏捷都可以解决，实在是有一种跟敏捷相见恨晚的感觉。
敏捷开发方式跟传统的瀑布模型有很大的不同，瀑布模型讲究严格的层级关系，同时拒绝后期的变化，敏捷则是拥抱变化后。
敏捷开发具体的方式有很多，这里着重介绍三种，即xp、rup和scrum，xp就是极限编程，着重讲的是具体的开发方式，rup则侧重项目开发周期的具体执行方式，内容比较复杂，先不减少了，这里我们主要讲 scrum，scrum是一种具体讲的一种项目任务的管理方式。
在scrum里，追求的价值观就是做有价值的能够使用的产品出来，所以，一般一个项目会根据时间的长短确定几个开发周期，即sprint，每个sprint完成都会出来一个可以运行的成品，这里也是跟瀑布模型有很大的区别，瀑布模型一般都是最后才出来成品，严格的层级关系，而在scrum，设计、编码、测试是同步进行的，这样大大的节省了资源，不会在设计的时候，编码人员和和测试等着，编码的时候，测试人员等着，会为整个产品节省大量的成本。
在scrum里，一个项目下来以后，会有一个product backlog，里面会写一些比较简短的story
，这些story大概描述的项目初略需求以及核心，这里不会很详细，不会像瀑布模型哪像一大堆文档，因为谁也预料不到需求的变化，当确定好sprint的周期之后，再会确定第一个sprint的backlog，再根据sprint里面的story去划分具体的task，给这些task确定时间，优先级，这里是相当重要的，每个task都会有状态跟着，当前是否在进行，当前是否呗阻塞，当前是否已经完成，而且这些task会让团队人员自己去挑选，这样就不会出现一个擅长后台的人去捣鼓前台，一个擅长前台的人员去捣鼓后台，浪费大量的时间了，同时，这些任务都是自己挑选的，对开发人员来讲，做起事来也是很顺心，很开心。
在scrum里面，还有一个最主要的事情，那就是每日的scrum会议，这个会议不会太长，一般都会回答三个问题，“昨天做了什么？”，“今天准备做什么”，“遇到了什么困哪？”，这样就会让每个开发人员每天都会很有成就感，同时，每天团队所有人都会知道整个团队的进展情况，相互之间的问题也可以得到及时的解决。
Scrum主要强调团队的沟通能力，最快的沟通，最好的沟通，最好是面对面的沟通，强调团队的自我管理能力，把开发的责任变成义务，让大家每天在任务的task状态的驱动下，都有成就感。
Scrum拥抱变化，当老板的需求来了以后，可以给这些新的story划定优先级进行管理，不会再出现以前那样的老是做着偏离核心的东西，开发出一大堆无用的功能，有人说，scrum不讲究文档，其实这是不正确的，scrum也会有文档，一般一两张纸就足够了，不需要像以前那样费时费力的整一大堆文档出来，结果没人看几眼，敏捷讲究的是效率，讲究的是质量，讲究的是尽快做出能让客户看到的有价值的东西，这样在尽可能早的时间内，给出反馈，做出修改，避免后期的大改动。
Scrum需要设计、开发、测试、客户一起参与，这样才能完成一个完美的产品。
其实在实施敏捷的过程当中，不仅仅是scrum，敏捷讲究的是高效，有效，所以一切有利于开发的方法方式都可以加进来，比如，xp里面的很多东西，都是对开发非常有帮助的，如：结对编程、重构、持续集成等等，这些都是实施一个敏捷团队必须的。
以上就是对敏捷的一点点认识，更多东西还有待慢慢学习。
| 张三 Task3 |
| 李四 Task2 |
| 王五 Task1 |
| 未开始 进行中 被阻塞 已完成 |
Task状态图
注：
Scrum:一种敏捷实施方式
Xp：敏捷实施方式
Backlog：记录开发任务
Story：一个一个的需求
Task:任务
Sprint:scrum中的一个开发周期。一般为两周至两个月不等，具体根据项目确定