怎么在公司里推广敏捷开发的各种实践的
wj
用这些开发实践的公司都是比较新的，是不是老公司就注定走不上这条路。
希望大家都来谈谈自己的看法。
Jeff Xiong
--
Jeff Xiong
Software Journeyman - http://gigix.thoughtworkers.org
Open Source Contributor - http://rubyworks.rubyforge.org
Technical Evangelist - http://www.infoq.com/cn/
wj
On 8月23日, 下午5时24分, "Jeff Xiong" <gigix1...@gmail.com> wrote:
> 还是那句老话，你要证明做这些事创造了什么价值。
>
Jeff Xiong
li xiao
至少我以前就这样做过，周围没有一个人做敏捷相关的实践，我就只是尝试TDD，效果是
非常好的，即使没有人跟着你走敏捷的路，其他人其实也是非常认同你的能力的。多数时
候去靠说服是很难的，即使你作出成绩也很可能因为对方更习惯自己的方式做事而不采用
你的方法，毕竟人家有好几年那样的开发经验，而且是成功的（即使不是那么的成功，至少
是赚钱的），那么就很难说让人家推翻自己的过去去学习全新的东西，然后又重新从中总
结经验，因为那样的话，他基本上就又从头开始学了，并不是所有人都很有动力去重新开
始学习的，所以要包容，特别是你这样得公司，有既有的开发方式，但是也要相信只要是
好的东西，被证明是好的实践，那么总是会有更多得人乐于采用和学习的。
从另一个角度来说，完全推翻过去重新按照现在人们总结的敏捷实践来开发不见得就真的
好，毕竟人是不同的，要考虑的是在团队中发挥所有人的能力。
之前有个帖子有人谈到把敏捷的实践结合到CMM4的实践当中，发现敏捷实践自然而然让
CMM的文档充实起来，不再是完全地应付了事，就是很好的实践，可以借鉴：）
wj
On 8月24日, 上午9时01分, "li xiao" <swing1...@gmail.com> wrote:
> 从自己做起吧，最容易，最有成效的应该是TDD，或者就是补一些测试也是非常有价值的，
> 至少我以前就这样做过，周围没有一个人做敏捷相关的实践，我就只是尝试TDD，效果是
> 非常好的，即使没有人跟着你走敏捷的路，其他人其实也是非常认同你的能力的。多数时
> 候去靠说服是很难的，即使你作出成绩也很可能因为对方更习惯自己的方式做事而不采用
> 你的方法，毕竟人家有好几年那样的开发经验，而且是成功的（即使不是那么的成功，至少
> 是赚钱的），那么就很难说让人家推翻自己的过去去学习全新的东西，然后又重新从中总
> 结经验，因为那样的话，他基本上就又从头开始学了，并不是所有人都很有动力去重新开
> 始学习的，所以要包容，特别是你这样得公司，有既有的开发方式，但是也要相信只要是
> 好的东西，被证明是好的实践，那么总是会有更多得人乐于采用和学习的。
> 从另一个角度来说，完全推翻过去重新按照现在人们总结的敏捷实践来开发不见得就真的
> 好，毕竟人是不同的，要考虑的是在团队中发挥所有人的能力。
>
> 之前有个帖子有人谈到把敏捷的实践结合到CMM4的实践当中，发现敏捷实践自然而然让
> CMM的文档充实起来，不再是完全地应付了事，就是很好的实践，可以借鉴：）
>
> 在07-8-23，Jeff Xiong <gigix1...@gmail.com> 写道：
>
>
>
>
>
> > 那就不要说，做起来再说
>
> > On 8/23/07, wj <sillyempe...@gmail.com> wrote:
> > > 没有试验的机会如何证明呢，光靠论述恐怕很难
>
> > > On 8月23日, 下午5时24分, "Jeff Xiong" <gigix1...@gmail.com> wrote:
> > > > 还是那句老话，你要证明做这些事创造了什么价值。
>
> > > > On 8/23/07, wj <sillyempe...@gmail.com> wrote:
>
> > > > > 我想在公司的新项目里引入TDD和pair
> > programming，但是项目经理和部门领导都觉得这些东西不实用，费时费力，给否决了。我知道很多使
> > > > > 用这些开发实践的公司都是比较新的，是不是老公司就注定走不上这条路。
> > > > > 希望大家都来谈谈自己的看法。
>
> > > > --
> > > > Jeff Xiong
> > > > Software Journeyman -http://gigix.thoughtworkers.org
> > > > Open Source Contributor -http://rubyworks.rubyforge.org
> > > > Technical Evangelist -http://www.infoq.com/cn/
>
> > --
> > Jeff Xiong
> > Software Journeyman -http://gigix.thoughtworkers.org
> > Open Source Contributor -http://rubyworks.rubyforge.org
> > Technical Evangelist -http://www.infoq.com/cn/
>
> --
> Calen cdoe taht wkors
Jeff Xiong
Lucifer
能不能接受敏捷要看管理者的意识，我们公司做了很多年的项目管理方法的该井，一直不很理想，最明显的是工作效率低，变更无法控制，加班多，很难调动项目
组成员的积极性，大量的文档没有促进项目的进度反而成了累赘和摆设，在这样的情况下，敏捷的基本思想就显得很诱人，象是一个理想的社会里存在的东西，这
时候管理层唯一担心的是这个理想是否能够实现，那就要看有没有切实可行的过渡办法了，一个已经成型的公司一下就跳到敏捷，无疑是一种自杀行为，要有计划
的一步一步的实施。我们老总已经被开发工程师忽悠的心里痒痒，很想试试敏捷，唯一担心的就是这个东西是不是一定能达到目标，还为这个事情到
ThoughtWorks咨询了一次，可能下来会选一个小一点的项目做一些尝试，找一个适合公司转变到这个路线上的可行方法。
所以我认为没有办法直接说服管理者去接受敏捷，而是要让他自己认识到当前的关键矛盾是什么和敏捷所能带来什么，最关键的是要有一个确实可行的过渡和执行
方法，当整个过程都比较稳妥，而且有完整的风险分析和应对措施了，管理者也不是不能够接受的。
wj
coding/debug方式工作。我也不得不承认他们这样确实能完成工作，但是随着项目扩大，这种方法就经常会让人发疯。也有个别刚进公司的学生在尝
试TDD和重构，但是效果还不显著，不过我还是很高兴，有人能与我一起学习。
Codeguy
你是玩魔兽吧,我也很喜欢Lucifer....
江湖人士
某项目经理说 最近这帮人不写文档了，我要给用户提交产品手册，帮助和操作手册咋办？技术经理告诉我 敏捷不写这些。。。
于是质量管理部要定义敏捷项目应该走的过程，做事情。纳入下半年改进目标。
On 8月25日, 下午1时40分, Lucifer <yuntao...@gmail.com> wrote:
> > 希望大家都来谈谈自己的看法。- 隐藏被引用文字 -
>
> - 显示引用的文字 -