※ 引述《kuosos520 (kkk)》之铭言：
: 小弟就业大概十来年
: 虽然刚入职场时
: 敏捷开发就已经是很红的议题
: 但至少我前几份专案都还是很传统的瀑布
: 个人感觉是近年越来越明显
: 所有的专案管理方式都越来越朝敏捷的概念走
: 我自己体感
: 比以前痛苦指数提高了很多
痛苦就不是敏捷
: 例如说
: 以前谈好一整个版本的spec
: 要谈时程就是基于一整个版本再谈
: 中间有什么改动很正常
: 基于是整个版本谈时程
: 大多数还有arrange的空间
: 时程变动就是整体移，不会在一条一条对
: 通常不太会很细节的追进度
: 顶多每周或每天需要跟自己直属报一下
这还比较敏捷
: 最近几年很明显
: 所有的专案管理方式都往敏捷的精神走
: 工作订出来就是丢给工程师问时程
: 没有一个很固定的版本空间
: 就是请你一直做，做到一个程度再确定版本
敏捷跟不确定不相关，这是误解。这种情况其实就是陨石
: 但是需求一直改本来就很正常
: 所以明面上是工程师自己压
: 但其实需求根本不固定
: 所以细项时程根本没参考性
: 每天为了其实很不重要的东西被时间追着跑
压时间就不是敏捷了。
: 早期都是谈1-2个月的版本开发时间
: 需要的话平日加班周末加班赶进度
: 进度状态比较好也可以适度休息一下
: 只要在讲好的时间拿出来，大家都好说话
: 现在偏向每一天都被进度追着跑
: 一个礼拜要报好几次进度
: 时程没对到就说工程师自己定的
再重申一次，定时间是完全违反敏捷的精神。敏捷是预估(forecast)不是设定(promise)
: 以前传统瀑布式自己可以抓放工作
: 有些小东西先放一下以后再处理
: 或是卡关太久需要交代进度
: 就抓个小东西出来作
: 交代完进度再来专心面对魔王关
: 现在敏捷其实
: 不会给你自己安排的空间
: 东西丢出来就要定时程
: 每次都跟你逐条讨论
: 你根本无法自己安排每天要做什么
: 甚至上下午可能都被定死
流星雨，不是敏捷
: 先不讨论哪一个开发模式对专案品质比较好
: 我也没有那个视野可以讨论这种事情
: 单就痛苦指数来说
: 从工程师角色看，绝对是指数级上升
: 我就很不解
: 为啥很多工程师很热衷于讨论敏捷开发
: 甚至是去学习敏捷开发课程
: 从我的逻辑看
: 相当于工程师用管理者的视角
: 去思考如何压榨自己
: 然后还去实践
因为你被假敏捷压榨。Scrum常常会变成这样，Scrum是压榨员工的好工具，如果滥用的话。

敏捷是快速取得回馈并持续改善 废物公司只想快速结案死不改善

你这样讲我勉强认同，唯一一个点，Rd主导开发，但需求还应该给专业的处理吧，我想，jira真的超雷的，slack还比较有用处

推, 真的大部分的scrum都是雷缺

给原PO:你应该是误解了 "主导" 可参考"安灯系统"

可用的软件 重于 详尽的文件 那可用是谁说的算？

这样是不用结案的概念。

你说的是理论 他说的是现实

Linux Kernel就是很好的敏捷案例。APTON大的"安灯系统"比我刚才想打的一串的好，精简清楚。

说得很好.下次可以直接用贴的.但没有解决实务问题

Linux kernel project 是agile? 给一下出处好吧。

员工痛苦股东才会爽

@Apton, @原Po, 两位的'主导'定义好像跟一般不太一样?能否详细说明一下，这里的主导是只有出问题时停下来吗?还是包括专案的成果评估，方向，业务目标在内?

大家都说不是敏捷，那那间公司跑的是真敏捷？

按上方的定义：不用结案的公司。

国外公司都受不了被压榨的工作模式，早就已经放弃敏捷开发就台湾人自己越来越盛行www

咦...这个说法，给个出处好吧。

@atst2 如果以"做产品"的角度 当然是都要包含不然最后遇到状况，开发还是会回头去问同样的问题但是大部分的公司都是分工不合作 各团队的距离很远

台湾老板眼中的敏捷=你各位员工员工做快一点

怕加班的我把敏捷点满了...还是继续加班

痛苦就不是敏捷？所以敏捷式宣言包含不能痛苦是不是

@APTON, 这个"都要包含"的意思，是指第一线开发者还要兼职

很多时候工程师的立场跟客户就是相对的，这样要怎么玩下去？很多工程师以删客户需求作为自己的kpi. 这样可以良好互动？

PM, Market，客服，主管等任务吗? 还是你有别的意思呢?还望更进一步提供说明.

我看过太多太尊重工程团队的公司，搞到最后就是没有人可以叫他们做事PM, 客服, 主管, 客户通通都不行，最后动用到创办人下来盯场，但是在看不见的地方还是偷鸡摸狗，客户干到翻天，这样会比较好？理想当然是工程师能够自律，能够以帮助客户解决问题为目标，现实就是自律的人太少了..给予工程师过大的自由跟权限就是什么事都做不成

推

(顾客，pm，主管）决定功能，工程师决定时间与作法。不过梦想很丰满，现实很骨感。当压力来的时候，加班，压时间，各种非敏捷的作法通通上来，能够彻底执行敏捷的团队还是少。而且敏捷最重要的是所有人都须认同也配合，这也是不容易的。没有良好的团队，或者强力沟通能力的主管，敏捷不容易执行也不容易成功。这有点像社会主义，理念良好，但常常沦落到独裁者模式。敏捷是需要上面的人全力支持，加上所有人的配合才行。国外我看到成功的案例比较多，台湾可能我也是见识少，看到的比较少。敏捷真的就是人的互动才是重点，但人的互动真的是最困难的课题。要愿意信任也是个困难。

@oopFoo，如果一个方法论，需要依赖人的素质，才会有用, 这个方法论能称得上是方法论吗?反过来问，有没有案例是，有良好的团队但不走敏捷，所以失败，改用敏捷后就成功了?还是只要有良好的团队，不论走不走敏捷，其实都无所谓呢?

应该说敏捷是成功率比较高的方法，所有方法都有成功的机会但敏捷迭代，多许多机会成功。当初xp的团队，是良好的团队，但最后他们的案子是被取消的

关于方法论是否影响产出，NDark网友有提出 #1MWgps7K那您这边提到'成功率'比较高，是否也有研究可以参考呢?

因为Chrysler被Daimler-Benz买走，新东家有不同想法。

在您继续回复，我先提一下个人对Agile/Scrum/Lean的想法，

老实说，没有研究。这都是我们观察跟想当然尔的

个人觉得敏捷以及相类似的方法论，其实是有一定道理的。但个人一直觉得，这些方法论，很多还只是理论, 而非定理.从理论到落实一直有很大的落差，而这些落差，目前看不到相关推广的人，有想去填补的努力在，而一直是不断强调理论有多美好.也许有团队/研究已经在努力了，但个人见识有限，无法知晓.在这种情况下，去指称某些公司跑的是'假敏捷'，敏捷"不是"什么，是没有意义的。因为对于想要进入"敏捷"，享用到好处的团体而言，他们想要知道的是，弥平理论到实作间的落差的手段。

敏捷好棒棒，每间都说在跑敏捷，需求完成率很高

如果没有这个手段，而只能依赖团队人员素质的话，老实说,与其引入敏捷，不如去增进HR团队的能力还比较实际一点。

我做上百个大大小小(钱)的案子，人员倒是没有哪些一百几十的案子。但三五七个倒有。就是没有方法论。但全部准时收钱。数学解题，就是从基本的去解就是好的方法。哪些什么特解，遇到某类题目有专门快速的解法，就是烂解法。

只能说牵扯到人的理论在实际上就是会有落差

台湾文化融合的敏捷等于快速结案

很多人都认为，用了某某方法，我也可以做出一样的系统.正如看着菜谱，人人都是大厨的概念。

推atst2

Ron 让我学到很多，感谢分享*Ron的文章

extreme programming系列的书，是一个好入门的书，它提倡test first，短时间的迭代，standup meeting，pairprogramming和如何计画，都有很好的解释跟缘由。现在的人使用敏捷大部分都不了解背后的缘由。toytota way，也是一个很好的管理想法，虽然跟软件有点远。好的团队是需要时间去互相磨合，也不是hr找对人就可以的。所以敏捷第一条就是"个人与互动"。这真的是最难的课题。

Jira只是工具 雷在哪错的是用的方式吧

最后我想强调的是，敏捷强调的是心态。但理工人喜欢方法，想找SOP，想找工具来解决问题。敏捷宣言就是想告诉你那是次要的。正确的心态才是比较重要的。

我看得少.如果 Debug 和带新人不算的话.pair programming 我没看过馁两位程式设计师，写一份码不吵架，可能吗？（当然，平常就是用嘴巴写程式那种不讨论）

我懂了，敏捷就是宗教。站立会议就是早晚课，检讨会议就是发露忏悔。每次迭代都是一个轮回。好好照着做就可以成佛。不成的话，就是心态不正，信仰不足。持续做下去就对了。

pair programming很少见，大部分人不愿意试，主要就是困难问题一起pair，或带新人大家比较愿意做。站立会议，检讨会议现在都太形式化了。开会是要了解跟检讨程式问题。其实两三个人一组，不要超过五六个人参与，简短结束。当变成形式的时候，就是要换个方法做。可惜，现代管

国外立意良好的东西进到台湾后都会歪斜

pair要好好分组训练 因为这种新制度在学校职场都没教新制度的引入就跟新机器一样要有教学

敏捷很容易压榨啊 那个宣言都是强者 敏捷就是很多强者一起合作 不会掉棒不欣赏工具这段还是怪怪的 抓战犯用excel管也能抓

信奉敏捷式的人都没有拿研究或数据佐证 只会说你成效不彰就是没有敏捷/不够敏捷 论述充满不可证伪性

excel的好处是，pm花时间填资料就没那么多时间骚扰工程师

jira是工具，不会扭曲流程，如果流程有问题，不能怪jirajira也可以不压时间啊，是用法问题

某种敏捷有一条规则是"成员都是专家" 而且都假设是全端的

须符合真空状态下，且专家是球体的时候才有效

预估根本不准，不然就不会不做不知道一做吓一跳了，待过某家公司，就是把预估当成是设定，一个spint一定要完成，拖延到的话PM还会很不爽。

我还遇过直接把planning 的点数当成kpi的呢

嗯...果然根本没有打算讨论，只是想趁机偷酸，还好没浪费时间回复

真的，还遇到一个连规格都不会开的在那一般说要导入敏捷xD

觉得问题点在于1. 团队了解敏捷开发是什么？ 2. 团队要知道怎么执行？ 3. 上头有权力者要相信 了解 决心推动敏捷开发不懂 执行的不是敏捷 没有权力只能推半套 都会爆炸想想人也是很重要的 只有工具也是不可行 再好的工具遇到错的人 不去用或是用错也是白搭

AGILE的专家们，请问AGILE 在最开始前，要先写一些底层的东西吗? 要架环境吗? 要的话，要算进sprint?会人人都有工作? 还是只有某几位负责?再来，何时on production? 按国外大神的说法，没提到呢若成员的程度差异，导致他的工作无法如期完成，会不会大家都完工了，还要等他? code review 会算进sprint?review 后的modification 要算下一个sprint?

1)看团队自己决定，2)人人有工作，3)随时都是production，4)每个人拿自己适合的工作，有问题在standup meeting就要提出，如果还是不能解决，转给可解决的人。如果无人可解，看是要花时间研究，或放弃选另一条路走。code review完才算完成，但有的team不用code review。进度其实是检视，而不是要追求的目标。做不到，做不快，就

待过4个团队，没有一个agile是跑到起来的XD

是砍功能。如何取舍，排进度，一门艺术。

#170rfWYy 这是我的旧帐，在2007年的文章.#1I7R-qV6 这是2013年，我在介绍Lean Programming相关书藉然后在2024年的今天, Agile的传道士们, 没有证据，没有研究面对我提出的问题，把一切都归结到心态上, 最后再指责有人藉讨论之名暗酸?你们是不是真的以为，所有意见不同的人，都没有跑过敏捷没有在相关领域，花费时间精力，也不知道安灯, toyota是怎么回事?面对他人的质疑，你们的回应有符合敏捷宣言的第一条吗?

不知道为什么敏捷式开发要搞得像宗教信仰

还是要讲心态很重要。上司，顾客就是陨石，流星雨的需求，不管怎么敏捷都没用。能够抵抗陨石的需求是第一个关键，沟通再沟通，没其他法子。就算所有都作对了，也不保证成功，开心做事就好了。谋事在人成败由天

推 我们team算是一个成功的敏捷范例 我认同这篇内容敏捷跑得好 应该是大家都轻松 客户也开心 但是要跑得起来需要超罩的主管+自律的工程师 人力素质PR95以上这真的非常不容易 所以失败的敏捷居多

加班过劳死的工程师转生到异世界开始研究敏捷开发

推推

能压榨员工的敏捷对老板来说就是好敏捷

推这篇

不太同意没有时程 我觉得是宣言概念 比起压时程 更注重团队自发自律