敏捷实践两个月

[tony]

公司有一个项目，开展了数月后，发现瀑布模型走不通，所以改为迭代模型。为加快项目的步伐，我推荐使用XP。此时，公司正在做CMMI四级的前期准备工作，希望能够通过度量数据说话。公司虽然同意使用敏捷方式，但要求符合目前公司的CMMI规范。考虑了很久，虽然觉得有些困难，但为了项目能够顺利地走下去，还是采用了敏捷方法。但是，最开始没有采用所有的最佳实践，仅采用了公司ＥＰＧ组能够接受的每日构建和ＴＤＤ，组内使用MasterStory做需求收集列表。由于公司还无法接受pair
programming，所以没有做，只是增加了走查的力度。
两个月后，感觉开发人员比较容易进入状态，但是客户不太容易进入状态。开发效率随着迭代的进展，在不断地提高，目前仍是上升趋势。
因公司项目需要，我被调入其它项目，希望这个敏捷团队能够走下去。

[zee ho]

具体谈谈"客户不容易进入状态"方面么？为什么不愿意参与整个实践？

--
When you came to this world,  there is no going  back, And , when you can't go back, you only have to worry about the best way of moving forward, The rest is up to God, including the danger　---- From <Alchemist>

[博佟]

很想具体学习一下  你们关于每日构建，tdd的具体实践。

 

不过我的感觉是  团队成员的内功是更重要的。 团队间知识的共享、userStory的定义等等 都是敏捷重要的一部分。

想真的推动敏捷不是一件容易的事情。

 

在06-11-20，tony <sagittat...@gmail.com > 写道：

[Tony Qiao]

"客户不容易进入状态"其实与我们项目的背景有关系。这个客户代表了解项目的部分业务（但本项目还有别外一部分用户群）。这个项目存在的矛盾就是开发人员可以听到来自多方面的客户声音，却没有一个能完全说了算。做为需求团队，几个客户代表本身都未能达成一致。

[Tony Qiao]

团队成员的内功当然非常重要。但是，不是每个人一上来各方面都很强。
我认为敏捷过程也是提高团队成员内功的方法和途径。比如，原来我们是不写单元测试的。在迭代开始前，我做了一个单元测试的培训，并在这个项目中要求开始写单元测试，通过走查发现单元测试中的问题，并及时纠正。开发人员感觉比原来的方式好很多，认为对自己有很大帮助。
每日构建也是一样。原来大家更多地使用debug、断点等方式来验证开发的功能，现在更多地使用单元测试。测试人员的先期介入使开发人员以测试人员提供的接受性测试用例为依据进行开发。只有通过所有测试，才能checkin代码。
我们这两个月先后采用了ＸＰ的很多实践（当然不是全部）。开始时，效率不高的确是事实（point完成的不多）。但现在效率还可以。
由于没有pair
programming，使知识共享也存在问题。但我们使用其它方式弥补。
同时，使用wiki做项目记录与知识积累。成果也还不错。

正象你所说，推动敏捷不是一件容易的事情。但如果对项目有利，我想无论上司还是下属都会支持的。
当然，必要的知识宣灌是需要的，尤其是高层领导对敏捷思想的认同和支持是至关重要的。

"博佟 写道：

[博佟]

very nice !

 

在06-11-21，Tony Qiao <sagittat...@gmail.com> 写道：

[Tony Qiao]

因工作需要，离开了原来的团队。新上任的项目经理采用了不同的管理方法，虽然表面的做法还没有变，但感觉实质已经发生了变化。个人认为，是对敏捷实践中的很多做法没有理解，只是照猫画虎，效果不理想。个人的感觉：敏捷是思想，而不是模式。没有思想，模式的意义就不大啦。

[flyingchen]

强帖!
能实践就已经是最大的进步了!