新書推薦：
《
海外中国研究·朝贡·海禁·互市：近世东亚的贸易与秩序（一部刷新明清外交与通商认知的典范之作。挑战朝贡
》
售價：HK$
107.8
《
财报防坑指南：20分钟看透企业真实现金流与盈利陷阱
》
售價：HK$
76.8
《
土民嗷嗷：1441年的社会史（以新闻纪实般的笔触重现室町动荡之年，展现权力崩塌与民声沸腾的历史现场）
》
售價：HK$
72.6
《
安逸哲学：锦绣天府人生智慧“安逸四川”三部曲第一部 安逸是中华文明为世界贡献的人生智慧
》
售價：HK$
96.8
《
风月狩（全二册）
》
售價：HK$
71.5
《
大学问·改过自新：清代以来自首制度的表达与实践（以丰富案例生动还原清代以来自首制度在基层的运行图景，
》
售價：HK$
74.8
《
DK照亮未知的灯塔
》
售價：HK$
74.8
《
超越高绩效团队教练：实战篇（第3版）
》
售價：HK$
153.9
|
| 內容簡介： |
|
本书总结了作者15年、参与近百个敏捷项目的经验，以及从项目管理经验中获得的\以管理视角看敏捷”的见解，共144个提示。每个提示都是作者亲身实践的宝贵经验，涵盖了从项目管理到团队协作、品质保障等多个方面。本书深入剖析敏捷管理方法论，旨在帮助读者纠正对敏捷的误解，并提供实践指导。从敏捷的基本概念、团队沟通与角色分工，到产出物构建与敏捷管理实施方法，本书全面系统地展示了敏捷实践的框架。
|
| 關於作者： |
|
渡会 健（WATARAI TAKESHI），株式会社MSOL Digital事业部总监；PMI日本支部敏捷管理研究会前任负责人；曾在Mitsubishi Space Software Co.， Ltd.和IT Innovation， Inc.任职，从事瀑布式开发项目管理工作将近20年。2008年开始接触敏捷开发，并在中型系统集成商Advanced Soft Co.， Ltd.工作期间积累了近10年的敏捷开发实践经验，之后转型成为敏捷教练，并入职Mamezou Co.， Ltd.，最后来到株式会社MSOL Digital任职。在近15年的敏捷工作经历中，拥有60多个敏捷项目的实践经验。高桥辰生（TAKAHASHI TATSUO）毕业于日本关西大学，工学硕士，资深项目管理专家，拥有PMP认证。早期就职于日本五大智库之一的日本综合研究所，在大阪、东京、纽约等地长期负责金融项目相关的管理工作。 2018年加入MSOL集团后，组织创建国内首家第三方PMO咨询团队――麦嵩隆管理咨询(上海)有限公司（任公司总裁），同时负责大中华地区的PMO事业拓展和公司运营事项，也是《PMO不败法则：100个完美收工技巧》一书的译者。
|
| 目錄：
|
10分钟速读敏捷的概述 ………………………………………………… 001
敏捷背后的思考方式――敏捷宣言 …………………………………… 013
专栏 敏捷不仅仅是Scrum …………………………………………… 022
第１章 你真的了解敏捷吗… …………………………………… 02
提示001 你真的需要“敏捷”吗 …………………………………………028
提示002 当“敏捷”成为最大的目标时，敏捷就会失败 ………………028
提示003 在欧美，“敏捷是主流”并不是事实 ……………………………029
提示004 “敏捷开发方法源于欧美，不适合亚洲文化”是错误
的说法 ……………………………………………………………030
提示005 不要害怕敏捷开发方法，已有许多成功案例可供参考 ………031
提示006 敏捷开发方法不是万能的（“换一种管理方法就能成功” 是不切实际的） …………………………………………………032
提示007 灵活应变≠敏捷开发方法 ………………………………………033
提示008 开始使用敏捷开发方法时，需要的不是标准而是指南 ………034
提示009 接受变更≠工作量无限增加，这是需要达成共识的事情 ……035
提示010 以瀑布式方法引入敏捷的悲剧 …………………………………038
提示011 不要随意混合瀑布式和敏捷，混合管理很困难，原因何在 …038
提示012 让自己从“一旦决定就很难改变”的束缚中解脱出来 ………040
提示013 在大多数情况下，必须接受从第一个迭代开始成果无法按
计划达成的事实，否则很容易一开始就失败 …………………041
提示014 在敏捷管理中，“允许失败”是有很多“学问”的 ……………042
提示015 完全交由乙方的敏捷，注定会失败 ……………………………043
提示016 被动参与的敏捷和被迫参与的敏捷 ……………………………043
提示017 不了解敏捷宣言的后果有哪些 …………………………………044
提示018 对于敏捷，你也许会认为即使没有开发经验也可以成功，这很奇怪 …………………………………………………………045
提示019 对于不熟悉敏捷的人来说，和有经验的人一起工作是最快的捷径 …046
提示020 将敏捷应用于确定性高的项目而导致的失败 …………………047
第２章 团队沟通和角色分工… ………………………………… 049
2-1 如何使团队沟通更为顺畅 ………………………………………… 050
提示021 沟通是语言的接力，而不是理论的碰撞 ………………………050
提示022 当团队内部的沟通停滞时，从“我觉得你说得对”这样的 认同开始 …………………………………………………………051
提示023 有意识地创造闲聊时间 …………………………………………052
提示024 “有意识地查看”与“无意识地输入”信息共享的巨大差异 …053
提示025 在真正意义上，将看不见的“信息”替换为可见的“东西” …055
提示026 会议主持人不应固定由Scrum Master担任 ……………………055
提示027 团队规则（工作协议）的细化和遵守 …………………………056
提示028 让第三方公司打成一片 …………………………………………057
提示029 对客户保持信息公开，没有任何隐瞒 …………………………058
提示030 导入课题管理系统 ………………………………………………059
提示031 开发团队内不创建次级团队的真正原因 ………………………059
提示032 促进可持续性开发，并不意味着不允许加班 …………………060
提示033 学会活用会议的节奏 ……………………………………………060
提示034 如何在远程办公中也能实现“在一起工作” …………………061
2-2 敏捷团队中各自的角色 …………………………………………… 062
2-2-1 产品负责人 ………………………………………………… 062
提示035 产品负责人真的只能有一个吗？团队制也是一个选择 ………062
提示036 产品负责人不是“客户”，而是一起工作的同伴 ……………064
2-2-2 开发团队 …………………………………………………… 065
提示037 起用代理产品负责人，关键是要让他能完全代入产品负责人的角色来进行决策 ………………………………………065
提示038 敏捷开发团队有很多事情要做 …………………………………066
提示039 开发团队不必一开始就是多面手，他们会随着团队的成熟而逐渐成长 ………………………………………………………067
提示040 开发团队人数限制的陷阱 ………………………………………068
2-2-3 Scrum Master …………………………………………… 069
提示041 Scrum Master不应该是敏捷团队的主角 ………………………070
提示042 Scrum Master的真正职责是塑造一个即便没有他也能持续成长的团队 ………………………………………………………072
提示043 为什么让Scrum Master同时兼任产品负责人是不好的 ………072
提示044 Scrum Master应该由产品负责人公司还是开发团队公司的人来担任 …………………………………………………………073
提示045 以现有的角色直接代入敏捷团队是不可取的 …………………074
2-2-4 传统开发中项目经理的角色应该由谁来扮演 …………… 074
提示046 为什么要在敏捷方法中将项目经理的角色进行分割 …………075
第３章 敏捷团队的成果… ……………………………………… 077
3-1 创建项目核心的用户故事清单 …………………………………… 078
提示047 需求定义书与用户故事清单的决定性差别 ……………………078
提示048 不是优先级，而是优先顺序 ……………………………………080
提示049 调整用户故事颗粒度的精髓 ……………………………………081
提示050 用户故事中必须写的和不能写的内容 …………………………082
提示051 用户故事和INVEST的陷阱 ……………………………………084
提示052 从MECE（相互独立，完全穷尽）的束缚中摆脱出来 ………085
提示053 怎样对用户故事进行拆分 ………………………………………086
提示054 用横向切分的思维得出每个迭代的可交付成果 ………………088
提示055 如果在迭代中没能按计划完成用户故事应该怎么办 …………089
3-2 待办事项清单要以迭代为单位进行创建和废弃 ………………… 090
提示056 待办事项清单与WBS的区别 ……………………………………090
提示057 怎么让产品负责人参与待办事项清单的创建 …………………091
提示058 待办事项清单中需要写哪些任务 ………………………………094
提示059 进度管理和适当的任务颗粒度 …………………………………095
提示060 怎么处理突发任务 ………………………………………………097
3-3 可交付成果与其质量 ……………………………………………… 098
提示061 始终保持只有一个最新的“可交付成果” ……………………098
提示062 确保产品质量 ……………………………………………………099
提示063 在敏捷中如何实现“共通化” …………………………………099
提示064 只要出现Bug就立刻将其修复是否真的有价值 ………………102
提示065 传统开发和敏捷开发是如何确保质量的 ………………………102
提示066 如何缩小理想化的测试驱动开发与团队能力之间的差距 ……103
3-4 让估算成为计划的参照 …………………………………………… 104
提示067 估算在敏捷开发方法中的作用 …………………………………104
提示068 由谁进行估算，这很重要 ………………………………………105
提示069 估算需要开发团队全员一起来做的理由 ………………………107
提示070 估算的基准是“过去的我们” …………………………………109
提示071 在敏捷中为什么广泛使用计划扑克 ……………………………110
第４章 敏捷的实施方法… ……………………………………… 112
4-1 通过沟通和时间管理来促进团队运作 …………………………… 113
提示072 为什么越是生产效率高的团队，越会花时间进行沟通 ………113
提示073 如何确定最适合自己团队的迭代周期 …………………………115
提示074 并不是说因为是敏捷所以不按时完成也没关系。如果不进行反省和改进，那就只是单纯的拖延 ………………………118
提示075 迭代计划与日历之间的关联 ……………………………………119
4-2 迭代开始前需要做的事情 ………………………………………… 121
提示076 不做“迭代0”的敏捷在起步时就会遭遇困难 …………………121
提示077 项目启动蓝图不是成果，而是让团队成员之间达成共识的工具 ………………………………………………………………123
提示078 项目启动蓝图类似于项目计划书，但并不完全相等，并不是越详尽越好 ………………………………………………………124
提示079 项目启动蓝图不能做完后就搁置不管 …………………………126
4-3 对于敏捷来说，计划也很重要 …………………………………… 127
提示080 迭代计划会议的规划 ……………………………………………127
提示081 做迭代计划，等于在做群体设计 ………………………………129
提示082 要记住在敏捷中，设计的时机和实施与传统方法有着根本的不同 … 130
提示083 不要把迭代计划会议分段执行 …………………………………131
提示084 为什么与其他团队比较Velocity数字是没有意义的 ……………132
提示085 价值实现效率大于开发效率 ……………………………………133
提示086 迭代计划并不是敏捷中唯一的计划，全体计划也很重要 ……134
提示08
|
|
購物車/收銀台(0) | 在線留言板
| 付款方式
| 運費計算
| 聯絡我們
| 幫助中心 |
加入書簽
HOME
新書上架
