|
锁定老帖子 主题：正确认识scrum和xp
该帖已经被评为新手帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-09-01
有感于最近和很多人讨论scrum。总结下来，无外乎这样几个观点：
1. 敏捷开发必须要有单元测试，结对编程，tdd这些东西。 2. scrum太简单了，是在忽悠人。 不想再在原来的帖子回复，大家可以自己去看。http://www.iteye.com/topic/748985 在这里，我想让大家自己问下自己，什么是真正的敏捷？你对敏捷开发是否真的了解？ 让我们来看下敏捷宣言： 引用 敏捷软件开发宣言
我们正在通过亲身实践以及帮助他人实践，提示更好的软件开发方法。 通过这项工作，我们认为： 人和交互 重于 过程和工具 可以工作的软件 重于 面面俱到的文档 客户合作 重于 合同谈判 随时应对变化 重于 遵循计划 虽然右项也有价值，但我们认为左项更加重要。 敏捷宣言遵循的原则 我们遵循以下原则： 我们最优先要做的是通过尽早地、持续地交付有价值的软件来满足客户需要。 我们欢迎需求的变化，即使到了开发后期。敏捷过程能够驾驭变化，为客户创造竟争优势。 经常交付可以工作的软件，从几个星期到几个月，时间间隔越短越好。 在整个项目开发期间，业务人员和开发人员必须朝夕工作在一起。 围绕斗志高昂的人构建项目。给他们提供所需的环境和支持，并且信任他们能够完成任务。 在团队内部，最有效率也最有效果的信息传达方式，就是面对面的交谈。 可以工作的软件是进度主要的度量标准。 敏捷过程提倡可以持续开发。出资人、开发者和用户应该总是保持稳定的开发速度。 对卓越技术和良好技术的不断追求有助于提高敏捷性。 简单--尽量减少工作量的艺术是至关重要的。 最好的构架、需求和设计都源自自我组织的团队。 每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。 看看，这里面有哪一条写过，要让大家做单元测试，做tdd？ 敏捷的方式有很多种，不要认为只有极限编程才是正宗门派，其他的都是歪门邪道。如果真的是这样，那就成了岳不群了。 javaeye作为国内高水平的技术社区，大家应该对敏捷开发有一个正确的认识。scrum 也好，极限编程也好，都是实现敏捷的不同手段和方式，二者可以互相结合。而不是只有极限编程才是敏捷开发，而其他的都不是。 还有，scrum实施起来要比极限编程简单。这也是很多人攻击scrum的原因。其实大错特错了。把事情做复杂很容易，把事情做简单很难。scrum规定的是宏观的管理框架，并没有具体规定你开发如何如何。这才是他的包容所在。就像打仗，战略制定好了，具体的战术可以有作战部队灵活掌握。如果战术都远程控制，必败无疑。 所以，对scrum有偏见的朋友们，再好好看看scrum和极限编程的相关资料。认认真真的思考下，然后我们再来一起讨论。我希望这次讨论，可以讨论具体的问题。比如如何写user story，如何估计任务时间，如何开站立会议。 声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2010-09-01
呵呵，
看看，这里面有哪一条写过，要让大家开站立会议，记backlog？ |
| 返回顶楼 | |
|
发表时间：2010-09-01
呵呵，是啊。所以有各种各样的敏捷。拿到结果就是好事情。
|
| 返回顶楼 | |
|
发表时间：2010-09-01
wwccss 写道 有感于最近和很多人讨论scrum。总结下来，无外乎这样几个观点：
1. 敏捷开发必须要有单元测试，结对编程，tdd这些东西。 2. scrum太简单了，是在忽悠人。 不想再在原来的帖子回复，大家可以自己去看。http://www.iteye.com/topic/748985 在这里，我想让大家自己问下自己，什么是真正的敏捷？你对敏捷开发是否真的了解？ 让我们来看下敏捷宣言： 引用 敏捷软件开发宣言
我们正在通过亲身实践以及帮助他人实践，提示更好的软件开发方法。 通过这项工作，我们认为： 人和交互 重于 过程和工具 可以工作的软件 重于 面面俱到的文档 客户合作 重于 合同谈判 随时应对变化 重于 遵循计划 虽然右项也有价值，但我们认为左项更加重要。 敏捷宣言遵循的原则 我们遵循以下原则： 我们最优先要做的是通过尽早地、持续地交付有价值的软件来满足客户需要。 我们欢迎需求的变化，即使到了开发后期。敏捷过程能够驾驭变化，为客户创造竟争优势。 经常交付可以工作的软件，从几个星期到几个月，时间间隔越短越好。 在整个项目开发期间，业务人员和开发人员必须朝夕工作在一起。 围绕斗志高昂的人构建项目。给他们提供所需的环境和支持，并且信任他们能够完成任务。 在团队内部，最有效率也最有效果的信息传达方式，就是面对面的交谈。 可以工作的软件是进度主要的度量标准。 敏捷过程提倡可以持续开发。出资人、开发者和用户应该总是保持稳定的开发速度。 对卓越技术和良好技术的不断追求有助于提高敏捷性。 简单--尽量减少工作量的艺术是至关重要的。 最好的构架、需求和设计都源自自我组织的团队。 每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。 看看，这里面有哪一条写过，要让大家做单元测试，做tdd？ 敏捷的方式有很多种，不要认为只有极限编程才是正宗门派，其他的都是歪门邪道。如果真的是这样，那就成了岳不群了。 javaeye作为国内高水平的技术社区，大家应该对敏捷开发有一个正确的认识。scrum 也好，极限编程也好，都是实现敏捷的不同手段和方式，二者可以互相结合。而不是只有极限编程才是敏捷开发，而其他的都不是。 还有，scrum实施起来要比极限编程简单。这也是很多人攻击scrum的原因。其实大错特错了。把事情做复杂很容易，把事情做简单很难。scrum规定的是宏观的管理框架，并没有具体规定你开发如何如何。这才是他的包容所在。就像打仗，战略制定好了，具体的战术可以有作战部队灵活掌握。如果战术都远程控制，必败无疑。 所以，对scrum有偏见的朋友们，再好好看看scrum和极限编程的相关资料。认认真真的思考下，然后我们再来一起讨论。我希望这次讨论，可以讨论具体的问题。比如如何写user story，如何估计任务时间，如何开站立会议。 该说的上个帖子都说过了，这里就说下我对（我所经历的）SCRUM/XP/敏捷的一个比喻吧，可能不是完全贴切： 敏捷就是经典 XP就是四大名著 （我所经历的）SCRUM就是起点 起点说:"经典不等于四大名著。你去看看wiki，所谓经典就是'最能表现本行业的精髓的，最具代表性的'。 我起点这么大，无论玄幻、穿越、网游还是后宫，最具代表性的都在我这儿，你能说我不是经典吗？ 经典是各式各样的，无论什么人，只要能写出‘最能表现本行业的精髓的，最具代表性的’小说，那就是经典。再说了，我也没说不让你吴承恩和曹雪芹在我这儿上封推啊！我们是相互合作，互补的关系，你们这些读者总说经典就是四大名著，把起点和经典对立起来，有意思吗？” 他说错了吗？没错吧。 |
| 返回顶楼 | |
|
发表时间：2010-09-01
"可以工作的软件 重于 面面俱到的文档 "
跟UNIX哲学一样"能用就行". 这样子不严谨. |
| 返回顶楼 | |
|
发表时间：2010-09-01
最后修改：2010-09-01
引用 该说的上个帖子都说过了，这里就说下我对（我所经历的）SCRUM/XP/敏捷的一个比喻吧，可能不是完全贴切：
敏捷就是经典 XP就是四大名著 （我所经历的）SCRUM就是起点 起点说:"经典不等于四大名著。你去看看wiki，所谓经典就是'最能表现本行业的精髓的，最具代表性的'。 我起点这么大，无论玄幻、穿越、网游还是后宫，最具代表性的都在我这儿，你能说我不是经典吗？ 经典是各式各样的，无论什么人，只要能写出‘最能表现本行业的精髓的，最具代表性的’小说，那就是经典。再说了，我也没说不让你吴承恩和曹雪芹在我这儿上封推啊！我们是相互合作，互补的关系，你们这些读者总说经典就是四大名著，把起点和经典对立起来，有意思吗？” 他说错了吗？没错吧。 看不太懂，呵呵。要么是我的理解有问题，要么是你的表述有问题。hoho。技术讨论，言简意赅为上策。 其实敏捷的有几大名著，xp是一部，还有其他很多部。scrum也是其中的一部。 
|
| 返回顶楼 | |
|
发表时间：2010-09-01
最后修改：2010-09-01
引用 "可以工作的软件 重于 面面俱到的文档 "
跟UNIX哲学一样"能用就行". 这样子不严谨. 敏捷宣言是整个敏捷开发的基础，这个你都不认同，就没有办法讨论了。 至于unix设计哲学，你所说的应该是这个。 引用 简单原则”——尽量用简单的方法解决问题——是“Unix哲学”的根本原则
人家可不是可用就行。最简单的解决方法，往往是最可靠而且为容易实现的方法。 |
| 返回顶楼 | |
|
发表时间：2010-09-01
SCRUM简单，明了，操作性强。
不明白为什么说简单的东西就是忽悠人。 |
| 返回顶楼 | |
|
发表时间：2010-09-01
当你迷茫时，静下心来想想问题的本质。。可能思路就打开了，自己到底需要什么应该怎么做，就会变得清晰。。
|
| 返回顶楼 | |
|
发表时间：2010-09-02
上周末下了硝烟中的scrum和xp看了一下，在不少场合下，还是很有存在价值的。其实很多方法，我们平常的项目管理中也一直在用,只不过不是完全一样而已。记得去年面试某公司的项目经理职位，被该公司boss问到每日站立会议，我当时持反对意见，至少是不赞成。后来被pass掉。哈哈。
|
| 返回顶楼 | |
