Skip to content

短期学习计划(一)- 放下敏捷的执着 #196

@EthanLin-TWer

Description

@EthanLin-TWer

虽然标题明白写着放下敏捷的执着,然而我真正想的是更加游刃有余地坚持它。我只是不想承认被洗脑罢了。TDD 还是 TDD,技术卓越还是技术卓越。我还是要坚持的。要放下的不是卓越和坚守,而是唯敏捷论的视角,是「不论这产品有没有价值功能上没上全反正我就要做满全套实践」的执念。实践虽好,却也要以产品的角度来看。产品是什么?是用户价值,有时可能是领导价值。实践是需要在这两者中间寻求一个平衡点的。这个平衡也可以说就是「裁剪」,然而我不这么讲,原因是「裁剪」总让人感觉良好,误以为万事具备,只欠自己来剪这么一下了。

所以说放下即非放下。希望接下来用九个月的时间,阅读、学习、体会一下敏捷原著的精神和实践,然后内化之,凭着对「价值」的感知去做事。要让敏捷变成阳光和空气一般的存在,而不是每做一个项目就得喊一下做敏捷。要带着「产品」和「价值」的帽子来思考问题了,至于具体实践的落地实施,要相信这点能力还是有的。

最好的阅读书单

  • 最好的敏捷资料是什么呢?敏捷宣言啊。
  • 阅读关于敏捷的几本著作,对敏捷尝试解决个什么问题有个认知。
    • 《能力成熟度模型(CMM)》
    • 《硝烟中的 Scrum 和 XP》 - 说看完了也没觉得有什么宝的啊?对,因为是个普及书。重点看下面一本
    • 《软件开发和创新 - ThoughtWorks 文集(上)》
    • 《持续交付 - 发布可靠软件的系统方法》
    • 《凤凰项目 - 一个 IT 运维的传奇故事》
    • 《精益思想(白金版)》
    • 《敏捷中国》
  • 阅读大熊博客中关于敏捷的论断 http://gigix.thoughtworkers.org/
    • 持续集成将死
    • 重构将死
  • P2 治理
    • 当然它是好的发心,同时是否会存在「另一种流程」的窘境?若存在,它将如何达到它要「治理」的这个目的?
    • 如果,Ron Jeffries 提出的几条敏捷核心:持续集成、持续重构,在企业里无法做到的时候,所谓「敏捷」和改善是否真正可能?
    • Ron Jeffries 又提出,相比直接跳槽离职,做好手头工作,坚持技术卓越,这种做法是否有利于解决 P2 治理原本想解决的问题?
  • 验收:产出一篇博客,讲敏捷是什么,它如何带来价值,它要解决什么问题,它如何解决这些问题,如何实践,它什么时候没用,它的未来是什么,未来有什么新的挑战,还需要敏捷么,需要怎样的敏捷形态,需要我们具备什么业务场景,需要我们具备什么能力

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions