很长一段时间没有过这样在工作上产生沮丧和失去控制力的感觉了。
技术部的头头说：“我们要重点反展目前这个项目所代表的产品方向，我们要增加人力，我们要在项目完成的同时完成一个其他功能有部分重叠的产品，我们要在完成产品和项目的同时完成我们的基础平台，我们要在客户要求的期限——5月之前完成，3月就要完成。”
我惊讶的发现自己一瞬间置身于《最后期限》所描绘的一个情景之中，一场会议之后，突然发现自己的团队膨胀了一倍多。被一个人反复的强调需求文档的重要性，他却不肯花20分钟的时间来讨论一下项目的需求究竟是怎样的；听着他们给我讲J2EE架构怎样天然的促使人员的分工，而事实的划分大部分的人还是所谓“业务逻辑层”，不过要顺便作一下页面；看着主程序员与他们讨论不需要专门2个人来进行数据库设计，而这么作的解释是“我们要非常灵活，大部分界面上的字段都是可配置的”，奇怪的是我没有听过任何一个客户提过这样的要求，而我还没有写，他也未必会看的需求文档中也不会有这么一条。
尽管技术部的头头并不是像《最后期限》中的贝洛克部长那么穷凶极恶；尽管我们也都同意需要对程序的结构进行分层和面向对象的包装；尽管我们都认为项目的进行应该是迭代式的；尽管他也说3月份完成的产品不要求完全可用，而我原本的计划也要在3月发布第一个版本。然而，有更多微妙的区别存在，使我只能悲哀的看着项目的进程受到无端的打扰，只能希望这一切过去后还有足够的时间来赶上客户的进度，或者在过去之前离开这个我寄与厚望的项目。
有这么多的相同点，为什么我还是无法接受？
没有人真正来了解项目的进展情况和征求我关于项目进度的看法。就直接来“给予帮助”，并认为理所应当的应该有更快的进度。
虽然我们都在用“迭代”这个词，但是他们说的却不过是一个接一个的小瀑布而已
他们的脑子里，软件是设计出来的，开发人员能作的就是实现这样的设计，他能掌握的，不过是使设计走样的程度。
三个不同的目标由一个团队来完成，而这个团队对于单一的项目而言，太大了。更糟的是，领导随时有抽回他所投入的“帮助”人员的权力和可能性。更更糟糕的是，在一上午的讨论后，下午进行全体会议时我才惊讶的发现原来要组成的是统一的团队，而不是我一直坚持的3个相对独立的小团队，通过定期的评审和技术交流来共享技术成果。这样的基本分歧竟然留到的最终全员会议上才发现，我不清楚是交流的什么环节出现的问题。
也许工作就是这样吧，真正的敏捷就是要能够表现出相对其他方法的竞争优势。（虽然仅凭我的努力无法让整个项目敏捷）不如想想有利的方面吧：
此前的实践中我已经发现无法按照xp那样的最精简方式来进行项目，主要是因为没有现场客户。但也还没有调整出更加适合的中间产品的规范。目前这个项目中不断经受来自传统观点的置疑和约束，可以适当的调和原有实践中的偏差，并且真正检验敏捷的有效性。
由于没有有效的推行TDD，前面已经觉得没有足够的精力来保证项目的质量。现在项目进度交由其他人掌握，我可以专心考虑项目的功能设计和需求验证问题。
反复思想斗争的走人问题，至少现在作出离开的决定会容易一些。
技术部的头头说：“我们要重点反展目前这个项目所代表的产品方向，我们要增加人力，我们要在项目完成的同时完成一个其他功能有部分重叠的产品，我们要在完成产品和项目的同时完成我们的基础平台，我们要在客户要求的期限——5月之前完成，3月就要完成。”
我惊讶的发现自己一瞬间置身于《最后期限》所描绘的一个情景之中，一场会议之后，突然发现自己的团队膨胀了一倍多。被一个人反复的强调需求文档的重要性，他却不肯花20分钟的时间来讨论一下项目的需求究竟是怎样的；听着他们给我讲J2EE架构怎样天然的促使人员的分工，而事实的划分大部分的人还是所谓“业务逻辑层”，不过要顺便作一下页面；看着主程序员与他们讨论不需要专门2个人来进行数据库设计，而这么作的解释是“我们要非常灵活，大部分界面上的字段都是可配置的”，奇怪的是我没有听过任何一个客户提过这样的要求，而我还没有写，他也未必会看的需求文档中也不会有这么一条。
尽管技术部的头头并不是像《最后期限》中的贝洛克部长那么穷凶极恶；尽管我们也都同意需要对程序的结构进行分层和面向对象的包装；尽管我们都认为项目的进行应该是迭代式的；尽管他也说3月份完成的产品不要求完全可用，而我原本的计划也要在3月发布第一个版本。然而，有更多微妙的区别存在，使我只能悲哀的看着项目的进程受到无端的打扰，只能希望这一切过去后还有足够的时间来赶上客户的进度，或者在过去之前离开这个我寄与厚望的项目。
有这么多的相同点，为什么我还是无法接受？
没有人真正来了解项目的进展情况和征求我关于项目进度的看法。就直接来“给予帮助”，并认为理所应当的应该有更快的进度。
虽然我们都在用“迭代”这个词，但是他们说的却不过是一个接一个的小瀑布而已
他们的脑子里，软件是设计出来的，开发人员能作的就是实现这样的设计，他能掌握的，不过是使设计走样的程度。
三个不同的目标由一个团队来完成，而这个团队对于单一的项目而言，太大了。更糟的是，领导随时有抽回他所投入的“帮助”人员的权力和可能性。更更糟糕的是，在一上午的讨论后，下午进行全体会议时我才惊讶的发现原来要组成的是统一的团队，而不是我一直坚持的3个相对独立的小团队，通过定期的评审和技术交流来共享技术成果。这样的基本分歧竟然留到的最终全员会议上才发现，我不清楚是交流的什么环节出现的问题。
也许工作就是这样吧，真正的敏捷就是要能够表现出相对其他方法的竞争优势。（虽然仅凭我的努力无法让整个项目敏捷）不如想想有利的方面吧：
此前的实践中我已经发现无法按照xp那样的最精简方式来进行项目，主要是因为没有现场客户。但也还没有调整出更加适合的中间产品的规范。目前这个项目中不断经受来自传统观点的置疑和约束，可以适当的调和原有实践中的偏差，并且真正检验敏捷的有效性。
由于没有有效的推行TDD，前面已经觉得没有足够的精力来保证项目的质量。现在项目进度交由其他人掌握，我可以专心考虑项目的功能设计和需求验证问题。
反复思想斗争的走人问题，至少现在作出离开的决定会容易一些。
