这两条纪律是底线。
一个优秀的项目管理者首先需要做的是让客户完全了解你的工作量估计系统是如何工作的,并不断强调你的工作量估计是合理、公平和有效的。
这代表你的客户不理解在软件开发中,“需求分析”也是工作量的一部分
这代表你的客户正在抛开自己的决策责任,尝试用最不负责任的方式逼迫你答应需求,一旦成功,这种行为就变成一个肆无忌惮的借口。
必须据理力争,请坚信,没有阻止上线的功能,只有阻止上线的、不理智的、缺乏安全的客户。
正确做法:充分做好准备工作 从业务的角度把整个要演示的功能尽可能串起来,准备好展示的步骤。 演示数据也需要准备好,展示的时候可以直接使用,只需要操作所演示功能部分,不需要临场创建准备数据。 演示环境要提前准备好,包括部署好需要演示的应用程序版本,而且要告诉团队不要破坏准备好的环境。
正确做法:开始演示前要先介绍上下文。
正确做法:以功能为单位演示。 不要一个一个用户故事的演示,而是将整个功能串起来,
正确做法:只演示最关键路径。
正确做法:只提及要演示的功能。 展示可以考虑只演示最主要的功能,那些小的反馈就不需要展示了, 也不要提及任何还未完成的功能模块,特别是对于团队正在开发的技术卡或者还不成熟的技术方案等,一定不要提及。
正确做法:人人都可以展示 尽量多参加展示会,这是一个了解系统、听取客户反馈的绝佳机会。
正确做法:展示前先充分了解系统和业务 但不建议采用给青涩新人提供展示机会的方式来帮助他们提高能力,如果要给新人锻炼机会,可以让新人在结
IKM
总结一下,PO自己搞定规划,PO和团队一起开工,团队自己搞定怎么做。IPM不占开发团队时间
展示形式:作为一个<某种类型的用户角色>,我要<达成某些目的>,只有这样我才能够获取<商业价值>
Well & Less Well
最大程度的可视化
沟通计划
团队目标不一致 团队成员不熟悉 信息发布不顺畅 行为心理学家研究认为 结语
第11章 也谈精益
第12章 团队敏捷转型的三个阶段 阶段1:建立敏捷流程,缩短交付周期
阶段2:引入技术实践,质量内建,减少返工
阶段3:提升价值交付效率和响应力
第13章 绩效考核,敏捷转型的鸿沟 敏捷转型过程中的必然挑战
绩效考核的困境
如何破局? 正如《管理3.0:培养和提升敏捷领导力》所说,所有变革最后的失败都是管理的问题。应该把绩效考核这种管理手段当成『敏捷铁三角』中一角来对待,那就是调整约束
清华大学管理学教授宁向东一针见血地批出,管理,其本质就是关于如何『破局』的智慧。所谓『局』就是管理者周围的各种资源相互联系,相互作用的一种状态。以上约束,也是软件工程表现出来的组织复杂性,也是一种局 书
第14章 一个交付故事
第15章 又一个交付故事 比如自动化测试技术干掉了传统的测试部门,数据库的自动化技术干掉了DBA,部署、运营的自动化干掉了运营,云化、安全内嵌也许将要干掉采购和安全。当这些东西,因为技术的进步而标准化后,当全面的数字化平台就绪之后,那么剩下的就仅仅是业务解决方案、技术栈与实现代码了,王老师把决策权交给开发团队是一个自然而然的选择……
第17章 如何在团队建设工程师文化?阿里资深技术专家这么做 工程师文化的特征 小团队 7-12人的团队是比较适合的团队大小。有人用毕节团队来形容一个团队大小(两张比萨可以喂饱这个团队)。脸书和谷歌经常有两三个人的团队。小团队特征 技术创新 技术决策权大 技术数据可视化 分享多会议少 测试原则 分支策略
结对编程 代码回顾
第18章 敏捷转型下的团队管理:来自一线管理者的思考 杰克 韦尔奇先生的一句名言:『在GE,我做得最棒的一件事情是创造了一台准确报时的钟』在企业中,即使是仅仅管理一个小型团队的一线管理者,管理者的目标也应该是打造一座可以自动运转并精确报时的时钟,而不是自己去报时 敏捷转型下管理者应该如何自处? 需要团队管理者首先要做到信任和放手 书