关于敏捷的一点想法

　　最近，项目中开始使用敏捷的方式开发。我没有研究过敏捷，对敏捷的认识全是来自项目。项目中，敏捷的基本做法就是对项目中的任务进行拆分，开发者根据拆分中分配到自己身上的任务，进行开发。其目的是保证项目能够按照预计要求的时间，按时交付。任务的拆分和时间的规划是非常重要的，因此每次迭代前，都会开会，来对需求进行拆分。在开会的时候，非开发人员主要参与需求的确定，而需求实现的具体时间，全由开发管理者确定。项目时间确定后，就是由程序员进行开发。

　　我工作的时间不长，只有一年多，这个使用敏捷的项目是我完全参与的第二个项目。因此好几次都没有按照规定时间完成功能。我自己能力的原因占一大半，很多技术不熟悉。在开发之前，没有完整的对自己的功能的实现进行详尽的规划，很多风险没有做好规避工作。明明时间不够，但还是使用了更复杂的实现方式，导致多次未按照时间实现功能。

　　期间，出现过一个框架上面的BUG，由于架构师不在我们分部，在总部。因此短时间让他解决这个问题不太现实，但是敏捷规定的提测时间还有2天。

　　我想，上面我遇到的问题，用敏捷的或多或少都会遇到，导致交付延期。在我自己看来，使用敏捷对于领导管理项目是很方便的，因为敏捷的方式让每一个研发人员都不在是研发人员，而变成了可支配的时间。一共24个需求，每个需求需要1人2天完成，那么我投入4个人，12天就能完成.如果要求他们周六都加班，2周，就应该能够完成。如果这面出现了我上面说的导致项目延期的BUG，项目管理的做法会是加大人力。投入人力，企图弥补错误，如果投入的人很厉害，问题自然解决。如果这个人和之前的研发人员一样（比如我），并不能很好的解决问题。这样的风险问题，敏捷并没有给我们提供一个很好的解决办法。因为敏捷忽略了每一个人的不同，每一个人能力的不同。这样把人时间化，容易让人造成疲劳感。因为按照工期按时交付被视为应该的，而开发过程中出现的意外情况，造成交付延期，则都被看做是功能对应的研发人员的“错误”。研发人员都有“想要做出牛B东西”的想法（比如我，总想做的与众不同，出类拔萃），而敏捷与此是相反的，而研发工程师（比如我），在项目中往往没有意识到按时交付的重要性。

　　总结一下，在我看来，敏捷有以下的问题

　　　　1 敏捷的方法没有很好的机制来处理开发过程中遇到的问题。虽然每天都会站在一起开会，但如果站在一起的人都不能解决这个问题，敏捷的工期就会显得“很可笑”（我经常遇到这样的问题，组内成员都无法解决）。

　　　　2 研发工程师（比如我）并不能非常好的理解工期的重要性，应更加突出项目的完成时间的重要性。当然为了工期，就要牺牲代码质量，，，心在滴血(:

　　以上，是对敏捷的一点看法。我在该项目中，犯了很多错误，没有正确定位自己，没有以工期为首要。经过了这个项目，我确实也不喜欢敏捷，因为在敏捷的眼里，似乎一切都是可实现的，只要人够，这显然是狗屁。