×

Loading...

管理人员通常都是技术小白,所以色厉内荏。俺们随便编个故事,就把工分翻个10倍。

Sign in and Reply Report

Replies, comments and Discussions:

  • 工作学习 / 事业工作 / 闲聊Agile -- 半夜鸡叫AI时代版 +4
    本文发表在 rolia.net 枫下论坛闲聊Agile
    来源: 托夫勒 于 2019-09-29 07:08:13 [档案] [博客] [旧帖] [给我悄悄话] 本文已被阅读: 1134 次 (2992 bytes)
    字体:调大/重置/调小 | 加入书签 | 打印 | 所有跟帖 | 加跟贴 | 当前最热讨论主题
    最早将Agile介绍给主流码农的,应该是Extreme Programming(XP)的作者。

    XP(Extreme Programming)的出现,正好也是互联网热的时候,它提出Fast Prototype,先做出一个原型系统来,正好符合这些公司的需要,这些公司为了找钱,需要给投资者展示一点东西。

    XP说,两个人要Pair Programming。因为那时候很多人转行来做软件,容易卡壳。

    这个Pair Programming,解决了外行卡壳的问题。现在的印度人,特别好这个。

    XP又说,每天要开会,这让底层经理乐得心里开花,以前追逼员工,还不好意思,有了XP,就官冕堂皇了。

    XP说最有效的纠错方法是用print,这现在看起来是很错误的。能用Debugger,还是Debugger最好。

    互联网公司倒了一批后,XP慢慢就乏人问津了。

    留下来的互联网公司,越做越大,他们把XP改头换面,变成了Scrum。



    每天的会照样开,可是,不再提pair Programming 了,科技公司现在财大气粗,可以找合格的人了,就不需要一帮一,一对红了。

    取而代之的,是给员工任务定量。这相当于中国农村以前搞过的工份制。

    以两周到四周为一个周期,周期开始前,先评估讲要完成的任务所计的工分。

    比如除草,三工分;冼碗,一工分,扫地,一工分。

    你在每个周期里都必须完成分配的工分。如果完不成,经理会利用Performance Review来羞辱你。

    “工分”的正式名字叫Story Point。

    表面上,一个任务的Story Point是全组民主评议的。实践起来的时候,经理会经常厉声地问,怎么估得这么高。所以,Story Points通常会被故意压低。

    如果正面去理解Scrum,它在做一个任务之前,大家讨论哪个任务需要先做,那个需要后坐,哪个依赖其他任务。可以避免一粒屎坏一锅粥的现象。

    Scrum收到公司的欢迎,主要是管理指标的量化。以前软件进度完全不可测,现在Story Points提供了一个方法,虽然不精确,至少有了个解决框架。为工人蓝领化提供了可能。

    提到Agile,还要提kanban,就是“看板”,来自日本,让人难看的板,把每个人的进度都贴在板上,让动作慢的人感到羞愧。更多精彩文章及讨论,请光临枫下论坛 rolia.net
    • kanban,就是“看板”,来自日本,让人难看的板,把每个人的进度都贴在板上,让动作慢的人感到羞愧。 -- 这个纯属是扯淡 。 +2
      • 一个agile,养活了多少人呀…… +2
      • 这块看板估计大家都看过哈
        +2
      • 据我所知,还有用啊窄而来管理production support的。每天例会,头的问题是: 为什么production incident queue不是零?如果不是零,你羞愧不羞愧啊?
      • 动作太快的也难看啊!人家板上都有WIP, 还头头是道讲个2分钟(limit), 你是空的,早做完了了😁 +2
    • Agile配合TDD, CI/CD,听上去还是有优点的。
    • Agile是一个低效的软件开发模式。招揽和使用10X Engineer才最高效与经济。许多著名软件的核心就是一个10X的杰作,比如Linux Kernel,Redis。如果这些软件交给一个Agile团队,那就玩完了。 +3
      • 也有道理,Agile是给客户也不清楚想要什么的情况用的!火箭发射项目肯定不适合:点火后,让我们看看要怎么走🤔 +2
      • 有几个人能写kernel,Kernel的项目也很少,一条枪干一年半载,现在做项目要什么能力,几百条枪干几年,光business rule的理解就花很长时间
    • 不是这么回事啊。也许各个公司不一样?Sprints那套其实是降低了效率,
      减少了额外的需求,来保证对工期有个比较好的估计。对于项目经理来说,还有一个指标是是否每个sprint的总分差不多一样,而且能完成。所以俺们组points一直是被PM往高了估算。有了sprint俺的活其实轻松了很多:完成两周计划的活就行了,有事找我直接推给pm;前面说了pm为了保证sprint看着好看也会帮你推活。所以只要不是太混饭吃的,sprints只好不坏
    • 自从用了agile,我的效率下降了三倍不止。每月一release, 东西打得琐碎,不连贯。又怕出现意外而超时,就高估任务。这个管理方式是方便给客户和管理层show成绩的,洋洋洒洒完成了一大堆东西,其实效率极低。 +5
    • 管理人员通常都是技术小白,所以色厉内荏。俺们随便编个故事,就把工分翻个10倍。 +3
      • 新来的项目经理让俺去改别的项目组的代码,俺跟他要权限。那老兄一瞪眼:俺已经同意了,你还要啥权限. +3
        • 谁说外行不能领导内行。等到他做了CTO,又雇了一个新的项目经理让你去改别的项目组的代码,你还会跟新人要权限,新人仍然会一瞪眼:俺已经同意了,你还要啥权限”。
          • 然后新新经理又做了指导人,雇了新新新经理。。。。