• leslie
    2019-12-26
    最近一直在整理笔记,然后整理的过程中发现了自己的问题以及后续应当去做的努力。报了几门程序开发的课程-强化一下自己的代码功力。
         老师现在一篇文章从看完到简单梳理差不多要1小时左右。今天的课程非微软的部分案例场景在上次大会听过-填鸭似的听了2天,真心觉得比上班还累啊。大企业的转变在某些方面都有些类似的,还是对于今天的课程做点补充吧。
        1.建立面向交付的特性团队:这个循序渐进的过程,不过有个核心的前提-领导必须有强大的前瞻性和做事情的魄力,否则这件事情真实落地确实很难;
        2.自组织敏捷团队-保证团队目标的一致性和互相的配合度:需要相当严格和规范的制度与监控配合;
        3.团队转型从中型团队入手-其中包含两种形式:第一种中型企业的核心小型团队,第二大型企业的中型团队;两种方式都能去找到问题且较小的代价一步步去做一些事情。
         以上是对于今天课程的理解和总结:案例挺好挺有代表性的,幸好我今年学的课程够多,不然要开始听不懂了。谢谢今天的分享,期待后续的分享。
    展开

    作者回复: 我也补充一点,面向特性的交付团队,这个跟软件架构也有关联,很多公司不是不想按特性交付,而是软件架构决定的交付的节奏一定快不了,这也是为什么很多人在讲微服务的原因,当然拆服务不是个盲目的事情,我只想说康威定律真的是在很多地方都有印证,而逆康威定律也一样有效。

    
     3
  • 陈斯佳
    2019-12-26
    efficiency不等于effective。快,不一定对,方向很重要。有一个对方向不断矫正的反馈机制更重要。

    作者回复: 有一本书叫做《Effective DevOps》,不是一般想象中的那种DevOps书籍,而更多的把视角落在的组织和人的层面上。在公司时间久了,就会发生一家公司能不能实现DevOps,跟工具的关系是最小的,人和流程,以及思维定式才是最大的问题。就好比两个老板要约一个会议,都是跟自己手下人说,你去找那边的老板约时间,那边的老板时间不妥当,也会让他的手下同步回来。其实想想,为啥两个老板不直接聊下呢,是因为没有工具吗,微信可方便的很呀,而这就是很多问题的根源所在吧。

    
     1
  • maomaostyle
    2019-12-30
    老师可否解释下具体什么叫特性?这个概念如何定义?谢谢

    作者回复: 你好,我的理解,特性是从用户交付的视角来看待的需求。一个特性就是对用户有价值的最小功能,一般对应到用户故事级别。

    
    
我们在线,来聊聊吧