码农：自从实行敏捷开发后，反而更觉得焦头烂额，问题出在哪了？

虽然大家都是程序员，但是每个人的开发风格与开发习惯也是千差万别，有的习惯比较优秀，也有的习惯比较有害但很易被人忽略，之所以有这么大的差别，想必与每个人所处的环境因素有关，程序员的开发风格与习惯很大一部分比例都是受环境的影响，但也不排除有个别奇才不论在任何环境都能保持自我的优良风格，近期，关于敏捷开发模式，有一名程序员说了一些他们公司的情况。

据这名程序员朋友说，自从他们公司开始实行敏捷开发，日报周报，早会，立项结项，需求讨论会，产品迭代会，代码评审会等等，搞得他焦头烂额，鸡飞狗跳，他真不知道这是他个人问题还是敏捷开发这种模式的运用有问题！听了他的描述，大概能够想象到他说的场景了，没种模式的运用最初的目的肯定是奔着高效，方便的原则，目前来看应该对这种模式的运用上还不是很成熟到位，针对这种现象，让我们一起看看其他网友们都是怎么认为的吧！

网友一：你们有问题，敏捷是通过限制并行需求数量和规模快速迭代，【不是】敏捷堆需求、敏捷加班、天天上线、敏捷改bug…

上世是朵花：看上面描述的内容，什么早会，周报，日报，需求讨论，这些跟敏捷开发也没什么关系啊，这只是平时的工作流程，不知道这与之前工作上有什么实质性的变化。

网友二：大多都是表面敏捷，不过是管理层偷懒甩锅的一种手段。学东西只学表面，敏捷开发，需要团队积淀和强大的工作流工具支持。不然互相甩锅，扯皮都扯不过来

上世是朵花：这些东西都需要技术管理者进行好好的揣摩了，这些模式性东西要领会要领，千万不能生搬硬套，否则就会适得其反，得不偿失。

网友三：画虎不成反类犬，天天学老外学得像傻货

上世是朵花：有点这个意思吧，应该是说没抓住核心精髓所在！

网友四：很多公司为了敏捷而敏捷，没有企业文化的基殿，和组织结构的配合，导致目前市面上大部分所谓搞敏捷的公司都是弄的似是而非。

上世是朵花：有这种现象和可能，所有模式的应用各个公司的运用都会有差别，有的是“变种”的运用，这种“变种”指的是跟据实际情况的变动，现实情况中，有的“变种”变的更好，更优秀，而有的“变种”就是“变味”，有种画虎不成反类犬的味道。

网友五：真正的敏捷很难的，首先公司得有积淀，其次人员匹配对要高，最后得有个懂敏捷的管理者！现在大部分公司都折在了第一点，真正的敏捷对公司很有益的

上世是朵花：赞同部分观点，文末我说下我个人的理解。

网友六：敏捷就不该写日报，只要开个站会就可以了

上世是朵花：日报算是公司管理的制度，不属于敏捷开发的范畴。但是两者可以并行，并不为因写日报就打破这种模式了。

网友七：敏捷不就是一个人把开发测试都干了嘛

上世是朵花：这应该是对敏捷开发的比较粗暴而又片面的定义吧！

网友八：总之就是不让你好好写代码

上世是朵花：这是调侃式的观点，不让好好写代码并不是他们的初衷。

接下来，我个人来随心解释一下我对敏捷开发的理解，敏捷开发是针对传统开发的一种改进方式，在传统开发中，先是需求制定，然后再是进入项目的详细设计阶段，细分到各个接口设计，数据库字段的设计，各层框框架架的设计，这些都设计好了，然后再按部就班的往里面添加代码就可以了，这种方式看是比较靠谱，比较稳定，但是人们发现即便前期考虑的很好，很成熟，在不断的市场变化面前，还是会出现各种各样的改动，甚至有的改动，对之前的的设计很有颠覆的影响，在这样一个背景下，便提出了敏捷开发这种理念，这种理念抛弃了过度设计的这个阶段，而是简单把一个大项目拆分成各个子项目，每个子项目的每个阶段都处在能用的阶段，都做的足够灵活，各个子项目之间也很容易集成，并且能跟随需求的变化做到高频的迭代，这样看来，既节省了项目的设计时间，又能让项目随时拥抱变化，既灵活又高效，非常适合现代开发状况的一种开发方式，如果说感觉自己目前的开发状况比以前的开发状况还糟糕，那肯定是没有领会到敏捷开发的精髓了。

以上所有图片均来之互联网

大家好，我是“上世是朵花”。如果你有什么好的看法或者观点可以在评论区展现你的才华，互动交流，如果想进一步了解我，那就关注我吧！