@daysv 你的境界有点高。

@Vitumoc 听起来很有趣。很想知道怎么来的经验。。。

@cybort 你们公司没有测试和产品吗？

赞。

---
1 、原来的代码暂时不动，通过简单修改包路径防止互相交叉，新写的代码完全按新逻辑开发，要充分考虑兼容老代码逻辑，保证按时完成；
2 、陆续按模块迁移老逻辑的代码到新模块中，这个过程的进度完全根据自己可支配时间决定，然后陆续删除老逻辑；
3 、工作汇报、周报中尽量避免用 “代码逻辑优化、重构”这种模糊字眼，要不然就算你做了再多别人也会认为你在摸鱼。
4 、评估排期时，实际所需时间和评估时间，要尽量控制在 2:3 以内，这样你剩余的时间可以充分进行想要去做的优化工作；
5 、设计数据库字段、表结构、接口协议时要充分思考，因为这些地方设计的不好，上线后再改可就麻烦了。

@xueling 真是实践者的建议，有实践有理论。这样的好内容不多，v2 很多时候都是虚无主义的天下。

@charlie21 不错，分得挺细致的。把团队，软件复杂性，项目三角形分开来看。一般而言，事情能分得下去，也得整合的上来才行。

他们三个事情分开后，整合的就是他们的关联，前两者是内部的，是属于方法和操作层面的；而项目三角形则有很强的外部性，三角形的任何一个变化都会影响到开发团队之外。内部的存在是为了外部的服务。

@yjxjn 你经历了什么？交出你的故事。

@jones2000 如果问题出在开源代码上，当然可以这样做。

@darkengine

不能。

但是我猜你还有问题，就是既然不能，那么搞一个新团队的意义何在？

这就是项目三角形的功能范围的变更了。如果功能范围不包括难啃的，那么能做的还是可以交付的。

把碗里的吃掉，也顶饱啊。不能因为锅里没有，碗里的也不吃。

接下来，那要看你是什么角色了，如果是开发经理，这个做不出来就和你无关了，板子打不到你的屁股上。对你而言，这就是利好。

如果是技术经理，就要想办法找外援了。

如果是老板，就需要知道这个钱可能不该你拿，当然一般老板不会这么想，于是就 PUA 开始。

d2Vha2ZyZWU=

@kingbill 你拳法乱了。

但是我乐于痛打落水狗，不仅仅是因为落水好打，也尤其因为这个狗乱咬人。

因为我有一个雄心，就是清理网上的垃圾，让正常人可以有立足之地。


就你做的这点马卡龙大小的事情，你敢言必称体系，

就你一个小小的 sm ，你来恩赐大家说话，

就你看过一本书就指导大家如何读书，

就你一个遇到不懂的，就鼓舌如簧的掉书本从而避开正面问题你来说什么敏捷。

就你舔着 ac 之间的大脸想要求我认可你帮助了我。

你连直面问题的勇气都没有，你连承认自己没有做过的诚实都没有。你敏捷啥呀。是你往自己脸上贴金，还是你往敏捷脸上涂 si 。


“腰有十文钱必振衣作响”说得就是你这类。

敏捷的基础是勇气是诚实。你的敏捷没有这些，所以是无源之水 无本之木。

你以为你用了敏捷你就真的敏捷了。一个名词一个形容词没有关系好吗？一个 Java 一个 Javascript 好啊吗。你这个我给你提一个词叫做油腻敏捷。请你不要再羞辱敏捷这个好词。

之前几年有一个叫太极敏捷的，算你的前辈，更加油腻，比你油腻百倍，幸好有识之士把他骂的满地找牙，现在它不出现哦，真的为民除害。大家稍微有点山脚的地，不至于一脚下去慢脚狗屎。他也叫敏捷，他真的就敏捷啦？

你没他那么油腻，但你也污染视听。把你从网路上清理，把你分类放到垃圾桶，甚至变废为宝，从狗屎到肥料，那也是为民除害。


曾经有一个我的手下，技术不错，却不在网上分享。我鼓励他做，他说，网上喷子太多怕被喷。

这样的人不少，他们爱惜羽毛，不愿意和喷子打交道。于是喷子越来越多（这个你有一个贡献，但是也只是一分而已，因为你虽然是油腻但是不是特别臭）好人越来越少（这个我的兄弟有一份贡献）

我看着很多曾经我敬佩的我的前辈，因为不学无术而变的油腻，然后我看到年轻一代也有混吃等死，我知道油腻也可以年轻。

我警告自己，要么老而优雅要么老而油腻。现在我看到你，我知道我的知识经验显然不足，就是年轻而优雅很难年轻而油腻可以很容易。

@kingbill 先回答你最后一句。你的内容对我没有帮助。

因为你的环境太 easy 。你的实践覆盖不了我的场景。

但是我会回复你，因为你太多槽点。

你的项目三角形，包括范围，成本，时间这三个维度都没有看到任何外部压力。所以你的实践方法对你都是系统内力，缺乏外部影响。系统内力不会产生外部运动。

直接说，与其说你选择了 Scrum ，不如说 Scrum 选择了你。

你的场景下，用 Scrum 可以，用瀑布可以，啥不用一把梭也可以。因为你的方法没有服务的目标。

没有目标，无所谓方法。

所以你的场景估计故事点可以，估计时间也可以。

你的 PO 无可无不可，你的开发无可无不可。因为可没有利益，不可没有损失。我说的损益不单指钱。人家混弄你，你还真以为是因为你会忽悠。

你在忽悠别人，却还跟一句只要你信任他们…


然而，人心莫测世事难料。您的 po 可能换人，你的客户可能变得挑剔，你的老板可能焦虑，环境变了，本来你说什么人家并不在意，现在可能要较真了。

现在回到问题的最初。

你的故事点怎么样换算成时间？

你一直都避开这个问题。其实我可以替你回答，你想说的是，我走的是人民币，不走你的欧元。我不是非要换算不可。


你如果只做内贸，你当然可以自己玩。你想赚人家的钱，你就非要换不可。

就算你不换，你怎么知道你的开发不自己内心里面自己换？他如果换了，你的故事点是不是就变味了？



在一个问题，一个客户找过来，说侬的这个东西我 30 天内要用，侬做的出来？侬说，我的故事点…巴拉巴拉。你猜客户怎么看你？（注意，这里的侬和你，以及后面的侬和你，只是一个及物代词，不特指正在看文字的你。也不特指和我讨论问题的你。

兴致好的，说你不想做我的生意，我找别人去。性格闷的，说今天见到一个 nerd ，算我倒霉。再不好的，麻将过来，你看不起我还是看不起我的钱？

如果你有一套单独的估计时间的方法，还有一套单独的估计故事点的方法，那么为什么要搞两套？钱多烧的？

你以为这些都是假设吗？这些都是真实的场景，你一直避开不谈，只有一种可能，就是因为你根本没有处理过。你的干系人只有 PO ，你的老板看起来离你很远，

你好像接触不到客户。但是你以为你在搞敏捷，其实是敏捷再搞你。你只是一直掉书袋。你的大脑成为别人的跑马场，你还开心的说我提供了场地。

你见不到客户，但是客户会隔着若干层次穿透你。

你待在温暖的花房里，却奇怪的看着外边冰天雪地里穿棉衣的人，你们为啥不穿个小背心清清爽爽啊。

所以，我看你说你的那本书说的不少了。不如说说你的实践。你是怎么做的？你的角色是 ScrumMaster 还是团队成员还是利益相关方？没有人质疑你的观点吗？你如何回复他们的质疑？

@kingbill 关于 scrum 我看了 n 本书。反复看过。因为我作为 ScrumMaster 要实操到我带领的几个团队，这几个团队有自己的业务目标和技术特点。我遇到疑问，这些疑问需要搬开或者解决，从而赢得团队的支持。所以不得不多本对照看。并且边做边体会改进。

我看到了敏捷联盟那帮人的天才他们的创造性，也看到了得意洋洋，意气风发，看到他们逃出重围打烂过往的陈腐和破破烂烂的旧框架比如 ISO9002 ，CMMI ，IPD ，RUP 。也看到他们的局限性，他们的固执和偏执。我喜欢这些人，希望成为他们的朋友，但是也防着这些人，因为他们主要是程序员和方法论者，但是缺少并且排斥成熟管理者的经验和智慧。

你讲的内容显然不是你的看法和实践，其实就是转述书上的内容。我质疑的就是这些内容。你则再次拿这些内容回应我的质疑。这就循环论证了。

一个采用 Scrum 方法的团队，不是生活在真空里，不是自己的理论逻辑自洽就会被支持，而必须正面的对待来自利益相关人，团队成员，客户的质疑和反馈。每一个团队创造或者采用某些方法有他的独特上下文约束，独特见解也会有他的局限，这些方法应用到自己就需要去芜存菁。自根据自己的情况做价值和代价分析。


比如我看到很多人采用晨会，但是我认为这个东西的存在的形式大于实质。我因此会限定时间，很快搞完。

比如看板。贴纸条。稍微复杂一点的或者相关性很强的或者需要分解组合多层次的任务就不能这么玩。我看到很多团队的看板都是几个月前的没有更新的东西。还不如直接软件工具上做的效果更好。所以这一块一般我们用软件做。

比如说我看到故事点，好处是这样可以让开发人员压力减轻。明明直接了当的采用时间大家都懂都好交流偏偏搞一搞什么故事点。这样的压力减轻真的没意思，不如直接面对估计的压力，多做几次 WBS 多学业务和技术设计方法，累计估计的准确度来的更好。

对于结对编程和重构也是多次尝试找到一个合适的时间点和时间段。

每一个选择我都尽可能深思熟虑并做价值代价分析并尽可能和团队成员沟通合作，争取大家的意见和支持。并用真实的团队目标的达成来形成正反馈。让每一个人在每一个迭代中看到团队的目标的实现和个人的成长。而不是自说自话自鸣得意。这本身就是敏捷的一种精神。

@kingbill 所以你的故事点如何换算成时间呢？

@1000copy 所以说如果瀑布都没有做好的，敏捷就更难了我觉得

@B1acKy1in 哦，你说得是关于拥抱变化的。如果领导看到这条误解为可以随时提需求那委实麻烦。

@B1acKy1in 你说的就是瀑布模型。敏捷这种节奏要求更高，无论是对团队协作还是技术实力。领导不喜欢的话那确实难以做起来

@showB1 你这一句话捅到根本上了不管喜不喜欢，事实如此。真的就是你说的这样。大形势下不做无谓的小挣扎