We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
这是一篇单纯的吐槽文。
老板们(代指各种为敏捷开发站队的人)总是选择性忽略软件开发的上游:制定产品策略,收集和规划产品需求。而将所有的压力甩给负责具体执行的开发部门,还起了个好名字:敏捷开发。
很多老板认为敏捷开发就是搞搞站会就行了,当然,我个人对站会并不反感,但特别反感毫无目的的站会。如果有个固定的会议(可以不是每天),一些工作内容相关但平时不太有机会碰头(和邻座几个人站会纯粹是浪费时间,我扭个头就能说明白的事情干嘛去开会)的人,聚到一起简单的说两句,沟通有无,可能恰好就解决了困扰半天的难题。
比目的分散的站会更离谱的是,超大规模的站会,我曾经参加过一个将近 20 个人的站会,除了几个平时一起做项目的,其他人做的事情和我没有半点关系,所以这种站会除了让我知道了其他人长什么样之外,没什么意义。要是这样的站会每天开 1 个小时,我准想逃。
如果需求本身就漏洞百出自相矛盾,在此基础上做计划更像是空中楼阁。更离谱的是负责统筹计划的人还要一脸认真的询问程序员们,“这个功能需要做几天?“ 很多时候程序员连功能是什么都还没听懂,是不是又外部依赖都还不知道,就得被逼着估算工期了。这要是能估算准了算你蒙的厉害。我自己就总是在外部依赖没有就绪时(设计稿没有,api 文档都没有),估算工时。估算个屁哦!
我经历过的项目组有好后坏,但从来也没有遇到过,也没有听说过,哪个项目组原本效率低下管理困难,自从使用了敏捷开发就一骑绝尘了。软件开发领域有一句著名的公理:没有银弹。在这里也生效了。那么,为什么老板们热衷于敏捷?
敏捷开发的各种实践,站会,计划工时,首要目的都在于提供开发成员的积极性和凝聚力,的确,作为一个集体,是需要固定的时间打一打鸡血来提升战斗力的。不管具体有没有效果,老板看了一定很开心。其次,敏捷开发产生的一些数据,比如预估任务和时间(甭管真假肯定比没有强),能增加老板对手下的了解。所以从这两个方面来说,敏捷开发对老板是有利的。
当然最有吸引力的还是敏捷开发带来的掌控力提升。请看下一节。
总有傻子以为敏捷开发是程序员的福报,你他妈别傻了。敏捷开发是底层员工们去干更多活(站会,计划,估算工时),老板得到更多收获(看燃尽图)的一种制度。自古以来就从来没有这样的制度的获益人会是辛苦执行者。修金字塔不是,修长城也不是。
敏捷开发发明了一套理论,认为开发应该不停的迭代,随时修改,因为修改灵活,所以叫做敏捷 —— 老板玩弄起来比较敏捷而已。但是如果你是一个开发,你一定希望拿到需求后就不要再他妈改来改去了,可是敏捷开发就是可以光明正大的改来改去,你还不能反对。
所以敏捷开发是老板的福报,是程序员的噩梦。
敏捷开发本身是个好概念,迅速的作出原型推向市场经历真实的检验,然后根据市场反馈进行调整,这一定是比闷在办公室细心打磨最终交出一个偏离实际的作品更加有效率的做法,尤其是互联网时代机会瞬息万变,越早走向市场抓着用户流量越是有利。
但是敏捷开发并不仅仅是开发本身,因为开发是产品的下游环节,在此之前,产品调研,需求提炼,都会影响开发工作的具体进行。如果没有对产品的精准定位,对需求的科学排列,仅仅依赖搞搞形式注意就能敏捷起飞,无疑是痴人说梦了。
但很多老板并不懂这些,很多懂得也不愿意去做,因为他们的目的也许并不是快速做个好产品,可能只是想实现上面领导的技术梦罢了。所以很多公司的敏捷开发是只有其名,而无其实。
The text was updated successfully, but these errors were encountered:
No branches or pull requests
这是一篇单纯的吐槽文。
老板们(代指各种为敏捷开发站队的人)总是选择性忽略软件开发的上游:制定产品策略,收集和规划产品需求。而将所有的压力甩给负责具体执行的开发部门,还起了个好名字:敏捷开发。
你负责敏捷就行了
站会
很多老板认为敏捷开发就是搞搞站会就行了,当然,我个人对站会并不反感,但特别反感毫无目的的站会。如果有个固定的会议(可以不是每天),一些工作内容相关但平时不太有机会碰头(和邻座几个人站会纯粹是浪费时间,我扭个头就能说明白的事情干嘛去开会)的人,聚到一起简单的说两句,沟通有无,可能恰好就解决了困扰半天的难题。
比目的分散的站会更离谱的是,超大规模的站会,我曾经参加过一个将近 20 个人的站会,除了几个平时一起做项目的,其他人做的事情和我没有半点关系,所以这种站会除了让我知道了其他人长什么样之外,没什么意义。要是这样的站会每天开 1 个小时,我准想逃。
计划和估计工时
如果需求本身就漏洞百出自相矛盾,在此基础上做计划更像是空中楼阁。更离谱的是负责统筹计划的人还要一脸认真的询问程序员们,“这个功能需要做几天?“ 很多时候程序员连功能是什么都还没听懂,是不是又外部依赖都还不知道,就得被逼着估算工期了。这要是能估算准了算你蒙的厉害。我自己就总是在外部依赖没有就绪时(设计稿没有,api 文档都没有),估算工时。估算个屁哦!
有什么用?
我经历过的项目组有好后坏,但从来也没有遇到过,也没有听说过,哪个项目组原本效率低下管理困难,自从使用了敏捷开发就一骑绝尘了。软件开发领域有一句著名的公理:没有银弹。在这里也生效了。那么,为什么老板们热衷于敏捷?
敏捷开发的各种实践,站会,计划工时,首要目的都在于提供开发成员的积极性和凝聚力,的确,作为一个集体,是需要固定的时间打一打鸡血来提升战斗力的。不管具体有没有效果,老板看了一定很开心。其次,敏捷开发产生的一些数据,比如预估任务和时间(甭管真假肯定比没有强),能增加老板对手下的了解。所以从这两个方面来说,敏捷开发对老板是有利的。
当然最有吸引力的还是敏捷开发带来的掌控力提升。请看下一节。
敏捷开发是谁的福报?
总有傻子以为敏捷开发是程序员的福报,你他妈别傻了。敏捷开发是底层员工们去干更多活(站会,计划,估算工时),老板得到更多收获(看燃尽图)的一种制度。自古以来就从来没有这样的制度的获益人会是辛苦执行者。修金字塔不是,修长城也不是。
敏捷开发发明了一套理论,认为开发应该不停的迭代,随时修改,因为修改灵活,所以叫做敏捷 —— 老板玩弄起来比较敏捷而已。但是如果你是一个开发,你一定希望拿到需求后就不要再他妈改来改去了,可是敏捷开发就是可以光明正大的改来改去,你还不能反对。
所以敏捷开发是老板的福报,是程序员的噩梦。
我并不排斥敏捷开发
敏捷开发本身是个好概念,迅速的作出原型推向市场经历真实的检验,然后根据市场反馈进行调整,这一定是比闷在办公室细心打磨最终交出一个偏离实际的作品更加有效率的做法,尤其是互联网时代机会瞬息万变,越早走向市场抓着用户流量越是有利。
但是敏捷开发并不仅仅是开发本身,因为开发是产品的下游环节,在此之前,产品调研,需求提炼,都会影响开发工作的具体进行。如果没有对产品的精准定位,对需求的科学排列,仅仅依赖搞搞形式注意就能敏捷起飞,无疑是痴人说梦了。
但很多老板并不懂这些,很多懂得也不愿意去做,因为他们的目的也许并不是快速做个好产品,可能只是想实现上面领导的技术梦罢了。所以很多公司的敏捷开发是只有其名,而无其实。
The text was updated successfully, but these errors were encountered: