作者回复: 赞一个
作者回复: 这是个好问题,关于人员培养的问题是个永恒的话题。这里面涉及2个方面,一个是态度转变,一个是能力提升。态度转变的话我们其实有很多方法可以让员工有参与感,参与到转型过程中,如后面05会有一些方法,让员工进到我们的转型过程,有参与感,同时也要意识到自己的能力需要提升,这样很多员工都有提升的动力;第二个问题,能力提升的问题方法也非常多,可以组织拆书会等等快速地了解一个领域的知识,也可以互相之间分享,老带新,反讲,建立辅导机制,能力高的辅导能力低的等等,非常多的方法,只要人发动起来,方法总能找得到。最后记住一点是,人毕生都是在发展的,减少对人的刻板印象,鼓励发动他动起来学起来跟上来,这个很重要。
作者回复: 第一个问题,我们在04里有一些关于组织的说明,特性团队拆分在敏捷里如上面朋友所说,确实没有固定的死的标准,但有些原则可供你参考。一个是团队大小,是5-9个人,大了要进行拆分;第二个是全功能团队。
第二个问题,文档的留与否,需要根据实际情况来做剪裁,在剪裁前,评估文档为产品开发带来的价值大小和实际工作量,一般而言不建议省略接口文档,接口文档是开发中的重要文档,但如果团队找到了更好的工作方法替代这个文档除外。
作者回复: 思维方式转变确实是比较难的,仅靠口头说服是远远不够的,所以除了宣讲以外,我采取的方式有很多:带他们参观已经转型的团队,有一些感性认识;必要的时候带他们打个胜仗,团队在不同阶段需要的辅助也是不同的,还有我们在05团队试点里的一些方法等等重要的是要让他们觉得是他们需要改变而不是“我”作为咨询师或者敏捷推动者让他们改变。
作者回复: 现实中没有完美的敏捷模式,虽然这是我们一直追求的目标,但大家都走在路上,推进敏捷的方式有激进式的“貌似一步到位”,但其实后面也有很多工作,另一种渐进式的则是解决一个旧问题出现一个新问题,其实一直在做持续改进,有的企业先做了“形式”上的敏捷,后面发现痛点之后继续改进一步一步地推进了更多的技术实践来助力研发
作者回复: 首先是组织设计问题,其次是人员培养问题和带团队的问题,我们后面有涉及,细看一下咱们专栏的实战篇
作者回复: 所谓船小好调头,每个小团队的协作效率更高一些,而且当我们把需求拆下以后,对应这样的小特性团队会让整个开发过程更加的灵活。
04有讲具体怎么做。
作者回复: 1. 可以的,只要能够跟开发兄弟沟通,能够听懂他们的语言。
2.虽然团队已经引入了敏捷,但是一般而言,引入以后一般不能一步到位,团队还需要慢慢带领和培养,可以在后面的工作中慢慢体会和参与引导,从引导团队对话中慢慢地体会敏捷。
作者回复: 这涉及一个客户期望管理的问题。始终要对客户灌输价值理念,让他自己挑选价值最大的需求,以及向其可视化你们的工作,让他理解到在有限的时间内,有限的资源不能完成所有的事情,但我们能保证的是在给定的资源和时间内给他最好的。
作者回复: 这一块内容我们在02有讲到,继续往后看哈:-)