×

Loading...

Topic

This topic has been archived. It cannot be replied.
  • 工作学习 / 事业工作 / 谁给用 3 句半解释下 Agile?谢谢。
    • 一句话就可以:开会。 +4
    • 简单地说就是,管他的,干了再说,有啥事明天再研究。 +5
      • 人定胜天指导思想的产物?
        • 不是“摸着石头过河”?
          • 我这不刚开始了解么,还不知道是摸石头还是摸地雷过河。
            • 摸到石头就过,摸到雷了嘛…… 炸了就炸了,明天又是一条好汉。
              • 反正是客户的钱,,,
                • 反正客户心里也没谱,闲着也是闲着。
                  • 这是 who 闲着没事整出来个硕大个名头?
                    • 多少人靠这个混饭吃呀。
    • 上来就干,大家一块儿干,你没干完,我就干,不停的干,一边干,一边上,不停出错,不停改。劳民伤财。 +4
      • 盲 code?图啥呢?钱不赶紧烧烧不上了就?
        • 首期出来的块,都是毛病。
          • 就是先套钱?然后让客户骑虎难下,接着往坑里扔钱?忒阴咧。
            • 还是老板有商业意识,经济头脑,我们就知道闷头干,想到哪干到哪。
            • 就是这样,先出来东西好圈钱。
    • 我们现在有二十多人,七八个人干活,其他的人都靠说,和在墙上贴纸片。 +8
      • BA舒服了,码工累趴下了
        • BA 瞎勒勒,让码工给 TA 们擦 PG?
          • 反正我不喜欢这个模式
            • 我觉的这个模式的最大优点是把各部门的人聚在一起,减少了扯皮现象。
              • 是推迟了扯皮而已。
        • 您这是自己给自己贴了个Agile的标签。没经验的公司都这样。真正的Agile里面没有BA。 +1
      • 我是干活的之一,也要花一半时间陪他说。 +1
    • 早期软件开发叫瀑布式有个长远规划+设计最后开始动工,一般会发现几年开发完成后需求早变了 --- 于是开始尝试 agile,简言之走一步看一步,摸着石头过河,不存隔夜粮,需求变我也变...相较更适合小团队尤其 startup... +2
      • 是个好主意但是实施起来有一定的难度,能不好会不停得出废品。
    • 就是17个极度自恋的人凑一起整的一个往自己脸上贴金的故事。 +4
      • 没有青史,创作青史,也要留名。
    • 早会晚会天天会,快干盲干白白干。一人码砖三人看,两周冲刺四周改。 +5
    • 特别适合喜欢瞎jb咧咧的老白, 和迎合拍马的老印,老中开会不太出声,开完会闷头干活,身后一堆老白、烙印围着挑毛病 +7
      • 我们这儿也这样。其他人工作都轻松了,就码工累,改来改去,活干的更多了。
      • 您这个就是自己给自己贴了个Agile标签。Daily Scrum meeting只有干活的可以参加,吆喝的不让。
    • 软件开发🀄️的Agile🈶️很多种,比如SCRUM, XP, Kanban。但是大部分平民百姓说的Agile就是SCRUM。SCRUM有很多规定,其中SCRUM team的size最好是3-8人。多了少了都不好。ProductOwner, SCRUM Master不属于SCRUM team。SCRUM的精髓:信任,合作,快但不省。 +1
      • 理论上的玩意。。。。实际中都在扯皮,开会,贴纸头,看进度曲线,因为改动太多出现git merging hell.... +2
        • 可能的,如果SCRUM team的技术及思维功力还不够的话。Backlog review / grooming需要有大牛,及非常有智慧和战略眼光的ProductOwner。要问非常tough的商业流程问题滴 +2
          • 如果有这样的掌舵人,Wallfall 还是 Agile,已经是形式主义了。 +2
            • True.
              说实话,agile 对组员/项目要求更高 - 需要组员有主人翁意识-- 所以更适合 startup,而不是很多滥竽充数的人的大企业。项目也最好是短平快 --- 否则组员负责短期冲刺但 PO 还是需要有超过 6-12个月的 vision -- 这也是为什么很多企业没有 strong PO,agile 成了盲人骑瞎马 。

              这也是我为什么认为要想做好 agile,负责人需要全面理解 waterfall ---- 根据 *这个* 项目具体情况砍掉不需要的繁文缛节从而 agile 起来 ---- 但如果一个项目 / 产品周期很长,没有人有长远规划或有能力做长远规划 ---- agile 往往出问题。
              更何况那样的大企业往往有很多滥竽充数的组员。

              另外好奇您怎么想起问这个 -- 这个东西就算适用也只是软件业 --- 盖个房子,架个桥什么的 --- 千万别。
              • 这个不同意。前提:很多滥竽充数的人的大企业,用什么都不会成功。
                本文发表在 rolia.net 枫下论坛说实话,agile 对组员/项目要求更高 - 需要组员有主人翁意识--
                用waterfall 能降低对组员/项目要求?估计不一样的产出。

                所以更适合 startup,而不是很多滥竽充数的人的大企业。项目也最好是短平快
                --- 否则组员负责短期冲刺但 PO 还是需要有超过 6-12个月的 vision --
                这也是为什么很多企业没有 strong PO,agile 成了盲人骑瞎马 。
                Vision的问题应该由上层来决定,一个很多滥竽充数的人的大企业,有Vision的人还是很多的。
                在软件行业,超过 6-12个月的 vision是很了不起的事情。假如这个vision错了呢?3年的项目怎么掉头?例如,公司选了Angular 1,三年后傻眼了。Agile出了问题,重来就是。


                这也是我为什么认为要想做好 agile,负责人需要全面理解 waterfall
                ---- 根据 *这个* 项目具体情况砍掉不需要的繁文缛节从而 agile 起来 ----
                但如果一个项目 / 产品周期很长,没有人有长远规划或有能力做长远规划 ---- agile 往往出问题。
                ----这个waterfall的问题更大,两害相权取其轻,还是Agile好。
                更何况那样的大企业往往有很多滥竽充数的组员。

                另外好奇您怎么想起问这个 -- 这个东西就算适用也只是软件业 --- 盖个房子,架个桥什么的 --- 千万别。

                如何在大项目中做的更好,象1000人年以上的。
                这种项目的难点是什么?难点是领导想800人年就应该干出来了,就给下面的人300人年的工期,结果900人年才干出来,你觉得项目超资太厉害了,其实。。。更多精彩文章及讨论,请光临枫下论坛 rolia.net
                • 相对会稍微好一些 -- 比如早期软件行业外包定义好输入输出,外包人员只要填代码 --- *相对* 要求低。但前期工作巨大,这也就是瀑布式主要矛盾。
                  • Agile也是外包人员只要填代码。 白天讨论好需求和架构,晚上外包人员只要填代码, 需求架构改了,代码重填(*相对* 要求更低)。测试24小时不停。
                    • Agile + offshore = a recipe for disaster... 说多了都是泪... lol...
                      • 泪的都是onshore的, 老板可不这么认为。 +1
                • 大企业滥竽充数的人更多,从你的例子里可以看到你选了angular1然后三年之后悲剧了:这是一个典型的短视行为:选好某个方向就没有退出方案,尤其在混乱的ui技术时代,说明公司没有人有远见,有远见的会让这个发生吗?有很多种办法退出或切换某个技术
                  • 公司没有人有远见, 那不可以改变,在这个前提下,你用什么方法论?反过来说,公司的人有远见,你又用什么方法论? 根据是什么。 还是Agile好啊。
                    • 这个就好比大师随手一把拉就搞个杰作出来,底下一堆人不解:说好的,你咋不用agile呢?
                      • 也好比当年赵括在讲武堂把一堆老将军憋屈得,结果长平一战。。。
                      • 滥竽充数的大企业,随手就出一个大师? 当年还有一个人写的操作系统呢。
                        • 你的原话:有vision的人很多
                          • 这样讨论也没意思,举个例子吧!
                            那天听CBC说安省政府还有很多的系统是COBOL,计划用25亿来改造一下,换成更现代的系统,你说用什么方法论来干吧? 我们自己的钱。如果是我的话,会把项目包给塔塔。要求他用Agile和offshoe。你怎么选?
                            • 你懂赵括怎么失败的吗?一个项目的成功取决于很多因素,缺一不可,如果你只知道agile和offshore,那就离失败很近了,赵括在理论上是完美的,但实际战役有很多因素影响成功与否,比如他知道如何鼓舞士气吗?他知道如何慑服那些不听话的将军吗?
                              • 这里当然假设其他因素一样,
                                就是纯方法论的比较,不然无法讨论。你说纸上谈兵,我不知道你是否因为经历了失败的项目而得出这个结论,但历史是前进的,就象当年我也认为git比svn强不了多少,但现在已经是标配了。政府,银行的项目基本上是成本和工期的问题,还没见过干不出来的,质量很差的见过,延期是一定的。所以降低成本是王道,反正一年半载后还是要重写或升级。
                                • 我就具体一点吧,我公司自从用了agile之后效率大幅度降低,原因很简单,用agile的人夸大了其作用,引得周围的人抵制:感觉功劳全是你的,系统设计,BA,开发都没有功劳?
                                  • 这说明你们公司管理水平低啊,还抵制,还抵制成功了?
                                    • 那就说说你们公司高水平的管理,让大家学学
                                  • 这就等于说现在我公司用cobol用的好好的,换成java后效率大大降低,所以我们换回Cobol,以后在也不用java了。
                                    • 我已经说过很多次了,头脑简单的人总是一叶障目,把成功只归咎于一个两个点
                                • 也顺便说一下,很多东西别人不说不代表别人不懂: 我以前写了一些程序觉得很有意思,后来他们给它起了个名字叫ajax,我以前用了一些项目管理的方法很有意思,在极短的时间里搞定了复杂的需求,后来他们给它起了个名字叫agile
                                • 如果你没有见识过项目失败,那说明你见识还是偏少偏小
                                  • 见识过又有什么了,就是项目管理失败了。
                            • 理论上,我会尽量将业务需求 / 技术实现 / 项目实施方法论 这三个元素分离,但
                              现实中这三个会有很强的相关性,但是这正是拼经验拼 vision 的地方了。

                              比如 angularjs -> ng 2,如果模块化设计得好的话,至少不需要从 0 开始。

                              至于 legacy system 现代化问题,网上有很多 best practices。基本上根据业务需求(驱动)决定是否(哪些部分)保留原有架构或(哪些部分)移植至现代架构等等等等 ---- 我觉得根据分析结果来决定每个具体项目合适的方法论 --- 很有可能有些适合瀑布式,有些适合敏捷。
    • 4个字: 改来改去
    • 昨天干了什么,今天要干什么,明天会干什么。然后下班。 +2
      • LOL