agile是不是邪道不知道，但是正在有越来越多的公司使用。

但实际中很多时候客户根本不可能一开始就清楚自己需要什么, 销售和pm也不可能拿出完善的需求..

- 这正是agile解决的问题，不需要完善的需求，根据优先级先完成客户最需要的需求，然后通过评审会议检查和实际需求的不符合处，然后安排在之后的迭代中修正
再举个例子，某些敏捷实践中，会放置一台单独的持续集成机器，上面总是运行着最新的build，有什么需求需要澄清，
Product Owner立刻和团队（甚至可以包括销售和最终客户）看着能工作的软件直接讨论
这比拿着一个技术建议书/系统架构图/系统详细设计的WORD文档围着投影仪开会讨论要高效的多了

而代码人员的素质更无法保证..就算有高素质的人员...能看到需求中的不合理处..往往也无拍板权...
- 需求本来就不应该由代码人员拍板，代码人员不是业务专家。
Agile解决的另一个问题就是有时候代码人员会按照自己幻想的需求/需求的优先级去开发系统，
结果开发了很多用户根本不需要，或者目前不需要的功能。

你们要敏捷, 先拿出东西来(以速度为向导的结果最通常的结果就是无注释,可维护性差)
- 如果你关注过敏捷，你就会知道这两个问题在Agile里是通过TDD解决的，而且TDD比传统的注释方法更好
换句话说，程序员看别人写的test case，比看别人写的那么几行注释，更容易理解另一个程序员的真实想法

随时适应需求变更(需求变更往往意味着不同程度的返工)...
- 现在的市场下，不存在不需要返工的软件，因为市场和需求的变化太快了


BTW:不过有一点我很赞同，现在在国内agile用成了什么样，那就是另一个话题了。
在一些地方，的确如你所说是在现在的国内的环境更多只是老板对员工的变相剥削。
本来敏捷很大程度上建立在开发团队和PO/SM之间的一种契约精神上，
但是这种精神在国内的PM身上基本不存在，PM们总是习惯多安排一些任务，完不成没关系，但是绝对不能让团队闲着。

举个例子如果团队承诺10天干完，结果5天就干完了，
理论上需要检讨的是PM，因为对团队生产率估计出现了严重失误，在每日例会检查燃尽图时发现可以提前完成时也没有及时安排unplanned item进入当前迭代.
正确的做法是其他5天团队想干啥干啥，打游戏上网都行，因为团队已经履行了契约。直到下一次迭代，PM才有机会修正自己的错误。
而实际上中国的PM们基本上的做法都是，立刻开始下一个迭代，这等于撕毁了和团队的契约。

本帖最后由 分不清雨水泪水 于 2012-7-20 18:51 通过手机版编辑

小声说下，２００２年，ｐｏｃｋｅｔ ｐｃ已经早有好多年了。。。。ｐａｌｍ已经烂大街了

agile是不是邪道不知道，但是正在有越来越多的公司使用。

但实际中很多时候客户根本不可能一开始就清楚自己需要什么, 销售和pm也不可能拿出完善的需求..

- 这正是agile解决的问题，不需要完善的需求，根据优先级先完成客户最需要的需求，然后通过评审会议检查和实际需求的不符合处，然后安排在之后的迭代中修正
再举个例子，某些敏捷实践中，会放置一台单独的持续集成机器，上面总是运行着最新的build，有什么需求需要澄清，
Product Owner立刻和团队（甚至可以包括销售和最终客户）看着能工作的软件直接讨论
这比拿着一个技术建议书/系统架构图/系统详细设计的WORD文档围着投影仪开会讨论要高效的多了

没有大体完善的需求就不存在所谓的最需要的需求..
需求不是只为码农存在的, 提出需求本来就是梳理业务和逻辑过程..一个抽象完善的过程往往会推翻很多开始的直观感觉..
而现在很多所谓的敏捷实践指导都默认这个业务架构是从天上掉下来的..
然后看着能工作的软件讨论往好处说是可以直接指出现有表面上的不足, 但只要背后联系稍微复杂一点..很多人都没有那个能力一次过指出来..这里暗含多余的返工工时很容易就被表面上的每天都有进展掩盖了..

而代码人员的素质更无法保证..就算有高素质的人员...能看到需求中的不合理处..往往也无拍板权...
- 需求本来就不应该由代码人员拍板，代码人员不是业务专家。
Agile解决的另一个问题就是有时候代码人员会按照自己幻想的需求/需求的优先级去开发系统，
结果开发了很多用户根本不需要，或者目前不需要的功能

这里我的着眼点和你不同..我眼中的代码人员包括我自己..都不会主动去开发不再列表上的需求..因为那意味着工作量..而且那的确不是代码人员的工作
我说的不合理处..指的是只有高素质人员看得出的业务上的缺陷..pm和客户往往只关心表面..但编码是讲究逻辑的..而这些逻辑往往和业务的深层逻辑切合..
这就回到上一条:敏捷 往往让客户和pm都忽略了对业务的抽象..总是幻想着只要有个能动的界面就能一步步完善...
从大方向上的确是一步步完善..但里面因为开始时的错误而导致的返工究竟浪费了多少时间..无法统计..

你们要敏捷, 先拿出东西来(以速度为向导的结果最通常的结果就是无注释,可维护性差)
- 如果你关注过敏捷，你就会知道这两个问题在Agile里是通过TDD解决的，而且TDD比传统的注释方法更好
换句话说，程序员看别人写的test case，比看别人写的那么几行注释，更容易理解另一个程序员的真实想法

我当然知道TDD..但实际上..TDD完全解决不了这个问题..甚至..很多时候更糟..
只要你不是直接重写..你要依据test case去修正一段代码..你最终还是得理解那段代码..
test case往往也是代码(因为敏捷一般要求代码人员自测试)..从test case中理解逻辑...不比从注释里理解代码逻辑容易..
而且在test case是代码的情况下..原本只要推敲的逻辑从1份(代码), 变成了2份(test case, 代码)..
其实最终还是人员素质的问题...好的注释..甚至是好的代码(自注释型代码)..好得test case..逻辑一般是明晰的易懂的..但人员的要求也是高的..
在test case 也是代码人员负责的情况下, 你不能指望一个注释不明, 代码条理不清的代码人员能有一份条理清晰的test case..
在test case 由别的人员负责的情况下..那么接手的人可能就要面对两份不同思维模式的代码...但他喵的太阳炉还没研发出来阿...

随时适应需求变更(需求变更往往意味着不同程度的返工)...
- 现在的市场下，不存在不需要返工的软件，因为市场和需求的变化太快了

不存在不需要返工的软件..这个我和你看法一样..我不看好敏捷..是因为我觉得比起传统的瀑布式开发..敏捷因为给pm和客户的期望过高而导致的需求不明确造成不可统计的隐性返工随着工程的变大风险实在太大了..

其实总结来说..我不是完全排斥敏捷..对于个人或几个人组成的小团体开发的小型软件,又或者架构已经确定,只是业务需要拼装的终端型软件...我觉得敏捷很有优势..因为这些情况初期pm和需求的弱化可以让软件快速进入良性的迭代..
但对于没有确定架构的中至大型软件..敏捷还是算了..

别谷歌，别翻书，说说你所理解的agile

一句话。如果你做的东西简单让用户拖拖就ok。那你的价值在哪。

我错了，不好意思才看到你前面已经码了好多字了。
不过我不想码太多字来说我对敏捷的认识，我在公司开发实践了好多年搞笑用的敏捷方法了。
绝大多数人嘴上挂着敏捷实际p都不懂。
屁股不同决定思维不同。至少我实践过的敏捷都被上头去其精华取其糟粕了。

你说我的脑补我认为是贬义词，但我没看出我哪里脑补了。
如果你认为那段 +1 是针对你说的话，我只能说你脑补了。

[本帖最后由 lvcha 于 2012-7-20 21:07 编辑]

LZ的主管坚持自己的梦想很让人佩服 但不知变通有点迂....

另外能码字的人 我也很佩服

SAP、ORACLE、国产金蝶等笑而不语，楼主进错公司了

微薄上让人哭笑不得的敏捷实践看了很多了，完全能理解国内某些敏捷实践的搞笑之处。
比如半小时以上的带笔记本的坐在会议室开着投影仪的 stand up meeting，
stand up meeting之所以要stand up ，就是为了快速沟通进度和解决blocking issue，完全口头交流，一般5分钟解决，15分钟已经是极限了。
国内有些公司把stand up meeting开成技术问题辩论赛了。。。。。。

没有办法，也许很多团队最初的敏捷实践是非常好的，
但是如果不是公司整体向敏捷转型，再加上敏捷团队不能保证对团队建设自身的迭代改进，
很容易被“企业重力”拉回来到传统开发模式的。

随手打了个脑补，的确用词和口气不妥，致歉。

另外我的理解主要来自于我所在团队最近1年的敏捷实践，再看点书。
如果临时翻书上网的话估计就是把宣言4条和12准则贴来贴去了，不至于这么能码字

[本帖最后由 分不清雨水泪水 于 2012-7-20 21:51 编辑]

没办法。。。。上30了，码不动代码了。。。。准备以后靠码字吹嘘敏捷糊口的

我当然知道TDD..但实际上..TDD完全解决不了这个问题..甚至..很多时候更糟..
只要你不是直接重写..你要依据test case去修正一段代码..你最终还是得理解那段代码..
test case往往也是代码(因为敏捷一般要求代码人员自测试)..从test case中理解逻辑...不比从注释里理解代码逻辑容易..
而且在test case是代码的情况下..原本只要推敲的逻辑从1份(代码), 变成了2份(test case, 代码)..
其实最终还是人员素质的问题...好的注释..甚至是好的代码(自注释型代码)..好得test case..逻辑一般是明晰的易懂的..但人员的要求也是高的..
在test case 也是代码人员负责的情况下, 你不能指望一个注释不明, 代码条理不清的代码人员能有一份条理清晰的test case..
在test case 由别的人员负责的情况下..那么接手的人可能就要面对两份不同思维模式的代码...但他喵的太阳炉还没研发出来阿...


不知道你们俩谁写的。反正这段话对tdd理解有问题，最好先谷歌下，TDD是做什么的。。

等immkll认领吧。
编辑了下之前的回帖，斜体是我的回复。

另外对LZ致歉，不小心把你的楼给歪了

LZ，幸亏你们没搞出成功的大项目，你们主管这种人是可共患难不可共富贵的。
如果真的发大财了，你的下场就是被清理出门！

且不论TDD到底是非掌握了精髓。确实有testcase写的极端差劲的。
比如说。。。我现在正在维护的产品。某天我突发奇想打开了testcase的类层次图，结果看到一个10层深的继承树。
所有testcase 跑一遍需要11个小时。。。
test之间共用一份数据，可能相互干扰。
造成的结果是至今我还没新写过一个testcase。

另外这是外企写的产品，所以嘛并不是国内玩不转敏捷，国外乱搞的也是大把。

同意。我们的项目是全球开发的。
至少我们这块和米国这块所谓的tdd是很搞笑的，从上倒下都以为拿juit生成个测试类就是tdd了。
不过也正常。绝大多数开发的都是刚毕业的学生。

先向LZ的主管表示敬意
看了LZ的描述觉得，你要真还想和主管做朋友的话，他的健康才是你该担心的
以后分手了没事多约出来吃喝玩乐，外带健康劝告吧。能不能约出来看他，自己该做的做到，也算12年的缘分

有这精力开发个网游啥的早发了， 有了钱再试想梦想

楼主说的很让我感到，想起了我第一个实习的公司。那个主管和你的主管很像，对技术很有追求。可惜他不明白小公司（至少在天朝）应该以抄袭为本。最后那公司黄了。
那是我人生中第一个老大，人很不错，当时一堆年轻人就一个想法：跟他混。可惜现实很残忍。
现在虽然我去别的公司了，但经常和他联系，由于在不同城市，每年争取有一次相聚。

agile和tdd是这几年最傻逼的潮流。。。。。。

光有梦想真的是没法支撑的，你老板的技术能力，带着十几个人做点上百万千万的项目不成问题，但是上来就想朝盖茨的方向走，那就有点大炼钢铁的味道了。

有人用得sb不代表理论sb。

还有钱的话,转型网游吧.

能挨十二年啊。。。。LZ..知足啊。。。有LZ一半就好了。。日

10年制造业ERP业内飘过，lz的主管就是一死宅，这辈子会失败的很惨很惨
对于企业产品来说，性能什么的都不是用户关心的，他们关注的是如何实现业务

对于你们主管来说最好的结果是去一家大公司打工，做技术

喜欢技术的大多都会有完美主义倾向和自负，楼主的老板就是太极端了，想几个人做出来别的大公司多少年才能积累起来的东西。饭要一口一口吃，罗马也不是一天建成的，苹果也是一开始先做个破烂的苹果一代开始卖啊。这么些人居然都想不明白这个道理，还居然跟了这么长时间。
说老实话，你们做这么长时间项目，时间评估和技术实现细节评估这种基本的流程规范都没仔细研究过，能撑到现在也不容易

本帖最后由 marsghost 于 2012-7-21 10:16 通过手机版编辑

最烦的就是这样boss，言必称要超越xxx大公司。当大公司的人才是吃干饭的啊，手头就几个刚毕业的，lz还幸运的，boss还懂技术。如果遇到boss是市场什么出身的，提出的需求让人流汗，还觉得很容易实现。这种boss早炒早开心，没错，说的就是我的boss!
另外，该跳槽就跳，树挪死人挪活。
还有就是国内小型软件公司基本都不靠谱，最好是跳到外企大型公司，就算是当码农到40有点积蓄干点啥都可以，至少身体上不会过劳死。
从外企跳到民企，是我最后悔和sb的一件事情，没有之一。民企即使给我高一倍的工资，我也再也不会到民企了。身体，个人时间，家庭，这些在30岁以后的程序员才是最重要的！

同感啊，平时开会感觉就是天马行空，说界面就是苹果，说技术就是云。。。也说不出什么具体技术怎么实现，就是说要做成苹果那样。。。

mark

mark

mark

请转游戏，有了现金再说梦想

我的第一反应也是永远的毁灭公爵。目标远大不代表做法也要不切实际。

你们的老板很有想法，但心比天高，命比纸薄，说不好听点就是眼高手低，自命不凡。

顶楼上