|
锁定老帖子 主题：所谓的敏捷开发，是这个样子！！
精华帖 (0) :: 良好帖 (1) :: 新手帖 (3) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-12-15
敏捷很重要，最起码可以及时发现问题。
|
| 返回顶楼 | |
|
发表时间：2011-12-15
敏捷开发在这些年都被大家津津乐道，都喊着要敏捷开发，都说自己在敏捷开发，其实没有几个是真的能达到敏捷开发的。
1、敏捷开发依靠的快速迭代周期做到产品的快速版本发布。（只对于产品，不对于工程或外包） 2、敏捷开发依靠的是人： a、强大的产品经理=强大的周期迭代性需求边界划定。 b、强大的项目经理=强大的人员把控、、进度控制、成本控制、方向性把控。 c、强大的架构师（技术总监）=强大的实时技术支持、框架优化。 d、优秀的开发人员、测试人员=快速的需求消化、快速的代码开发、高效的全面的代码测试。（不妨试试结对编程效果会更好） 3、敏捷开发依靠的是高度协同的团队，每天对此的会议是必要的： a、统一开发规则。 b、统一的测试规则。 c、统一的管理规则。 由于敏捷团队需要各方面的能力都很强大才能达到效果，所以需要注意： 1、需求边界把控不住，周期风险加大，无法按时上线、发布。 2、避免人员流失，由于敏捷开发具有高度的耦合性，人员的流失会使周期变得不可控，无法按时上线、发布。 3、项目经理的进度控制、方向性控制不足，导致周期的不可控，无法按时上线、发布。 4、敏捷开发中成本控制造成的影响也是巨大的。 5、易于扩展的架构、稳定的架构、功能齐全的架构、低耦合的架构、将在敏捷开发中有着事半功倍的效果。 6、技术总监实时的支持能让整个开发团队处于持续稳定的生产中。 7、开发人员、测试人员。我为什么要把他们放在一起的呢，因为他们才是生产中的主力军，任何一个开发测试模块如果出现问题都会对整个迭代周期造成影响。 这是鄙人在这些年在软件行业的一点感悟，欢迎大家交流想法，鄙人邮箱：mliang@neusoft.com |
| 返回顶楼 | |
|
发表时间：2011-12-15
123003473 写道 敏捷很重要，最起码可以及时发现问题。
敏捷的思想在国内用的都不好。基本上也就用了部分程序级别的。架构或者设计级别用的少之又少。 |
| 返回顶楼 | |
|
发表时间：2011-12-15
milo1984cn 写道 敏捷开发在这些年都被大家津津乐道，都喊着要敏捷开发，都说自己在敏捷开发，其实没有几个是真的能达到敏捷开发的。
1、敏捷开发依靠的快速迭代周期做到产品的快速版本发布。（只对于产品，不对于工程或外包） 2、敏捷开发依靠的是人： a、强大的产品经理=强大的周期迭代性需求边界划定。 b、强大的项目经理=强大的人员把控、、进度控制、成本控制、方向性把控。 c、强大的架构师（技术总监）=强大的实时技术支持、框架优化。 d、优秀的开发人员、测试人员=快速的需求消化、快速的代码开发、高效的全面的代码测试。（不妨试试结对编程效果会更好） 3、敏捷开发依靠的是高度协同的团队，每天对此的会议是必要的： a、统一开发规则。 b、统一的测试规则。 c、统一的管理规则。 由于敏捷团队需要各方面的能力都很强大才能达到效果，所以需要注意： 1、需求边界把控不住，周期风险加大，无法按时上线、发布。 2、避免人员流失，由于敏捷开发具有高度的耦合性，人员的流失会使周期变得不可控，无法按时上线、发布。 3、项目经理的进度控制、方向性控制不足，导致周期的不可控，无法按时上线、发布。 4、敏捷开发中成本控制造成的影响也是巨大的。 5、易于扩展的架构、稳定的架构、功能齐全的架构、低耦合的架构、将在敏捷开发中有着事半功倍的效果。 6、技术总监实时的支持能让整个开发团队处于持续稳定的生产中。 7、开发人员、测试人员。我为什么要把他们放在一起的呢，因为他们才是生产中的主力军，任何一个开发测试模块如果出现问题都会对整个迭代周期造成影响。 这是鄙人在这些年在软件行业的一点感悟，欢迎大家交流想法，鄙人邮箱：mliang@neusoft.com 上面敏捷才是真正的敏捷。当然下面也要敏捷 呵呵 |
| 返回顶楼 | |
|
发表时间：2011-12-15
最后修改：2011-12-15
引用 引用 dongdyj 写道 milo1984cn 写道 敏捷开发在这些年都被大家津津乐道，都喊着要敏捷开发，都说自己在敏捷开发，其实没有几个是真的能达到敏捷开发的。
1、敏捷开发依靠的快速迭代周期做到产品的快速版本发布。（只对于产品，不对于工程或外包） 2、敏捷开发依靠的是人： a、强大的产品经理=强大的周期迭代性需求边界划定。 b、强大的项目经理=强大的人员把控、、进度控制、成本控制、方向性把控。 c、强大的架构师（技术总监）=强大的实时技术支持、框架优化。 d、优秀的开发人员、测试人员=快速的需求消化、快速的代码开发、高效的全面的代码测试。（不妨试试结对编程效果会更好） 3、敏捷开发依靠的是高度协同的团队，每天对此的会议是必要的： a、统一开发规则。 b、统一的测试规则。 c、统一的管理规则。 由于敏捷团队需要各方面的能力都很强大才能达到效果，所以需要注意： 1、需求边界把控不住，周期风险加大，无法按时上线、发布。 2、避免人员流失，由于敏捷开发具有高度的耦合性，人员的流失会使周期变得不可控，无法按时上线、发布。 3、项目经理的进度控制、方向性控制不足，导致周期的不可控，无法按时上线、发布。 4、敏捷开发中成本控制造成的影响也是巨大的。 5、易于扩展的架构、稳定的架构、功能齐全的架构、低耦合的架构、将在敏捷开发中有着事半功倍的效果。 6、技术总监实时的支持能让整个开发团队处于持续稳定的生产中。 7、开发人员、测试人员。我为什么要把他们放在一起的呢，因为他们才是生产中的主力军，任何一个开发测试模块如果出现问题都会对整个迭代周期造成影响。 这是鄙人在这些年在软件行业的一点感悟，欢迎大家交流想法，鄙人邮箱：mliang@neusoft.com 上面敏捷才是真正的敏捷。当然下面也要敏捷 呵呵  总结的很不错，虽然有些还不是很明白根由，但也看出来了一些，对比当前项目组实行的敏捷开发，没有效果的根源显而易见。但也有些疑惑：
引用 敏捷开发依靠的快速迭代周期做到产品的快速版本发布。（只对于产品，不对于工程或外包）
不对于工程、外包，不解，实际上一多半的团队都不是做产品的，难道敏捷开发对此不适用？ 引用 a、强大的产品经理=强大的周期迭代性需求边界划定。
b、强大的项目经理=强大的人员把控、、进度控制、成本控制、方向性把控。 c、强大的架构师（技术总监）=强大的实时技术支持、框架优化。 d、优秀的开发人员、测试人员=快速的需求消化、快速的代码开发、高效的全面的代码测试。（不妨试试结对编程效果会更好） 这么强大的团队国内比较少吧？没有强大的团队，以致于敏捷实行的并不彻底吗？ |
| 返回顶楼 | |
|
发表时间：2011-12-15
最后修改：2011-12-15
caizi12 写道 引用 引用 dongdyj 写道 milo1984cn 写道 敏捷开发在这些年都被大家津津乐道，都喊着要敏捷开发，都说自己在敏捷开发，其实没有几个是真的能达到敏捷开发的。
1、敏捷开发依靠的快速迭代周期做到产品的快速版本发布。（只对于产品，不对于工程或外包） 2、敏捷开发依靠的是人： a、强大的产品经理=强大的周期迭代性需求边界划定。 b、强大的项目经理=强大的人员把控、、进度控制、成本控制、方向性把控。 c、强大的架构师（技术总监）=强大的实时技术支持、框架优化。 d、优秀的开发人员、测试人员=快速的需求消化、快速的代码开发、高效的全面的代码测试。（不妨试试结对编程效果会更好） 3、敏捷开发依靠的是高度协同的团队，每天对此的会议是必要的： a、统一开发规则。 b、统一的测试规则。 c、统一的管理规则。 由于敏捷团队需要各方面的能力都很强大才能达到效果，所以需要注意： 1、需求边界把控不住，周期风险加大，无法按时上线、发布。 2、避免人员流失，由于敏捷开发具有高度的耦合性，人员的流失会使周期变得不可控，无法按时上线、发布。 3、项目经理的进度控制、方向性控制不足，导致周期的不可控，无法按时上线、发布。 4、敏捷开发中成本控制造成的影响也是巨大的。 5、易于扩展的架构、稳定的架构、功能齐全的架构、低耦合的架构、将在敏捷开发中有着事半功倍的效果。 6、技术总监实时的支持能让整个开发团队处于持续稳定的生产中。 7、开发人员、测试人员。我为什么要把他们放在一起的呢，因为他们才是生产中的主力军，任何一个开发测试模块如果出现问题都会对整个迭代周期造成影响。 这是鄙人在这些年在软件行业的一点感悟，欢迎大家交流想法，鄙人邮箱：mliang@neusoft.com 上面敏捷才是真正的敏捷。当然下面也要敏捷 呵呵 总结的很不错，虽然有些还不是很明白根由，但也看出来了一些，对比当前项目组实行的敏捷开发，没有效果的根源显而易见。但也有些疑惑：
引用 敏捷开发依靠的快速迭代周期做到产品的快速版本发布。（只对于产品，不对于工程或外包）
不对于工程、外包，不解，实际上一多半的团队都不是做产品的，难道敏捷开发对此不适用？ 引用 a、强大的产品经理=强大的周期迭代性需求边界划定。
b、强大的项目经理=强大的人员把控、、进度控制、成本控制、方向性把控。 c、强大的架构师（技术总监）=强大的实时技术支持、框架优化。 d、优秀的开发人员、测试人员=快速的需求消化、快速的代码开发、高效的全面的代码测试。（不妨试试结对编程效果会更好） 这么强大的团队国内比较少吧？没有强大的团队，以致于敏捷实行的并不彻底吗？ 为什么所不对于工程、外包呢： 1、工程相对于来说是一次性开发，基本上很少有变动的，即需求是既定的，是在工程签订合同前就已经定死的，工程开始时间和结束时间也是相对于苛刻的，工程的结束后期的只能算是维护，而不是大量的可开发的新需求的加入。 2、项目外包是指开发其他公司制定的功能块或功能块集，这些都是根据甲方公司所定的，也是由外包合同所制约的，是根据功能来结算的，不存在快速周期内的迭代。（有人可能会问外包项目也总在变啊，但要注意那是在迭代周期内的，不是一次次的迭代周期），所以说外包还得遵循CMMI等。 3、人力外包是指把人直接借个人家去开发项目，这类基本上也不适合敏捷，人员容易产生不确定性。 大量国内软件公司都在喊敏捷，其实很多都是形式主义罢了，忽悠忽悠领导，忽悠忽悠客户。 敏捷是需要强大的团队，国内确实很少，但是会随着时间的推进、经验的积累，越来越多的。我坚信不久的将来国内会有大量有经验、优秀的敏捷开发团队。 |
| 返回顶楼 | |
|
发表时间：2011-12-15
caizi12 写道 dyllove98 写道 caizi12 写道 确实沟通比不沟通有些效果，对某些人还是有些作用，比如对今天任务不明确，不自觉这一类人员。项目组分了两个小组一个java web和etl组。人员是比较多，有忙的要死有加班的，有天天闲着没事干的，这问题一直存在。
这个应该直接和所在组的组长进行沟通,组长不行就要换. 对于不自觉的人 ,每天给他们分配的任务要具体才行. 组长经验可能也不是很丰富，整个项目非常缺少沟通。另外由于公司的原因，这个项目人员流动特别大，从去年到今年，只有差不多4个人是从开始到现在一直在项目组，其它人员都是今年，陆陆续续进来的，业务都不熟悉，项目组文档特别乱，你都找不到任何一个完整的文档，让你熟悉业务必须得不停的问。版本管理工具竟然有三套，项目文档用的是vss，代码用的是cvs，最近客户要求切换到svn上，还要把cvs上面的历史记录也要保存过来。无语了  都。。。cvs2svn，呵呵 http://cvs2svn.tigris.org/ |
| 返回顶楼 | |
|
发表时间：2011-12-16
嘿嘿 那是你没用上好工具 站立晨会我从06年就用到现在 但是很多时候作为team leader你得到的数据是进度是百分比（这是最不靠谱的）和存在的问题 但是更多的细节你不会知道（因为时间短） 然后就会被文山会海给抛到脑后
作为team member的时候 你真认为你的组员都会有责任心关注别人在做什么么？自己的那摊子事还没搞定。。。就算关注也不一定能听的懂 细节是魔鬼 对谁都一样。。。 还有很重要的：部门经理不会也不能参加 他们怎么知道你们的进度？好吧。。team leader写简报吧。。然后就回到了我之前说的，文山会海。。。 灌了那么多水。。。继续杂带私货。。。IBM RTC。。用上了就不会放过 =================================== 工具当然有用，但敏捷并不依赖工具。 毕竟敏捷工具是敏捷出现后才被开发出来的。 百分比和存在的问题是很关键的信息，从百分比，你可以估计每个成员的进度和表现，如果一个成员的估计总出错，那他就需要格外的关注（经验不足或者其他原因）。 如果某个成员有关键问题，晨会也是个时机把它提出来大家一起讨论（无论多么平庸的队伍，里面至少会有一两个技术水平比较高的人，并且喜欢把自己的观点说出来博取注意），大多时候你会找到一个合适的人帮忙把这个问题解决掉。 |
| 返回顶楼 | |
|
发表时间：2011-12-16
公司强有力的资源支持、良好的薪酬待遇、技能优秀的团队成员、严明的组织纪律、开放的沟通氛围，加上嘴皮子利落的销售代表、严谨利己的合同，再加上容易被忽悠的客户，这些条件满足的话，咱就敏捷了，可以换着花样的喷理念方法。
|
| 返回顶楼 | |
|
发表时间：2011-12-16
Fatyu 写道 听到甲方两个字。就犯恶心！
没甲方，你的薪水是谁给的呢?.... |
| 返回顶楼 | |
