00.在人类行为领域，很难发现非常一致的事情，因此，一旦一个团队被认为是功能有效的，人么便归功于它对目标有明确的了解。
01.构想的两个关键方面是明确的和令人振奋的目标，这个目标使项目大不相同并给项目增加了紧迫感。没有明确的构想，敏捷项目的探索本质就会导致该项目陷入无休止的试验当中，明确的构想必须明确探索的界限。
02.建立明确、引人注目的构想是非常困难的事情，需要做大量的工作并拥有高效的领导。
03.
04.敏捷项目成功基础被定义为：
*价值目标——创建可交付的产品
*质量目标——创建交付可靠的、适应型强的产品
*约束目标——在可接受的约束内，实现价值和质量目标
05.把重点放在战略的可交付能力的问题上，而不是只关注详尽的功能清单，可以给整个项目团队提供合适的动力，从而适应不断变化的环境。
06.可发布的产品和可用到的产品构想框和项目数据表中的信息可以定义为：
*可交付的产品：产品构想框；项目数据表——项目目标声明、企业目标、性能、性能价值
*可靠的、适应性强的产品：项目数据表——质量目标
*在可接受的约束内：项目数据表——均衡矩阵（范围、进度和成本）
07.在敏捷项目管理的构想和推测阶段，尤其重要的是要记住：
*团队成员应该经常自问：“我们需要的刚好足够的流程和文档是什么？”
*与团队交付“方式”有关的所有做法都需要随着项目的进行，不断做出裁减和调整，以提高业绩
*项目社团将会不断演变其团队做法
*产品构想:产品构想框和电梯测试说明书；产品体系结构和指导原则
*项目目标和约束：项目数据表
*项目社区：找到合适的人选；确定参与者；客户团队——开发团队界面
*方法：流程和做法的裁取
08.不管对于什么开发方法，这句话都是真的。迭代开发的优势在于如果没有构想，它能够比传统方法更早地暴露出来，在人们发觉事情的真相之前，传统方法制造了一个假象，即构想早已存在几个月了。
09.产品体系结构的目标是描述项目内部沟通渠道，是一种促进探索和知道正在进行的产品开发的设计。一个早期的“骨架”产品体系结构不仅能知道技术工作，也能指导执行技术工作人员的组织工作。它旨在把较大的项目背景传达给开发团队，而不是局限于一个设计。
10.敏捷开发中，体系结果是引导，而不是紧箍咒。
11.体系结构指南的第二部分是一套指导原则（Guiding Principles,GP）,用来协助开发团队塑造产品，满足客户需求。
12.一些指导原则除了可以在项目构想阶段就制定外，通常要早起的开发迭代时才出现。每个原则应该用一两个句子描述，而且在任何情况下，一个项目的全部原则描述不得超过十个句子。
13.项目数据表是用一页概括主要商业和质量目标、产品功能和项目管理信息。这是一个简单却又重要影响力的文档。它简洁的格式，对整个项目社区呼吁并且不断提醒他们那些是项目的战略方面。
14.
15.项目数据表
16.当项目启动的时候，项目计划保持在价值、质量和约束三者之间的健康平衡非常重要。当这个平衡被打破的时候，权衡矩阵就开始发挥作用。
17.阐明项目的探索系数有助于管理客户和主管的期望值。
18.如果没有认识到不同的问题领域，整齐划一的项目流程和做法也许还有理由；而一旦有了这样的认识，按具体的问题量身定制合适的流程和做法将会使项目团队取得成功。
19.最合适的人，并不意味着要找到最具天赋的、经验最丰富的人，而是说要做这个工作最适合的人选
a.具备适当的技术能力
b.表现出适当的自律行为
20.
21.
22.组织内部IT项目失败或者表现不佳的其中一个关键原因是：错误地理解了项目经理和产品经理这两个角色的本质。产品经理必须来自IT部门外部.
23.团队在某个具体项目选择和裁减做法
*哪些做法是必需的？
*还需要哪些辅助性做法？
*需要对选择的做法哪些修改？
*做法的编档、批准和更改需要什么手续和形式？
24.不是文档的问题，而是理解的问题.
25.在构想阶段后，构想并没有停止。在每次迭代的开头，团队在一起思考下一次迭代时，团队成员需要重新审视该构想。重新审视的目的是为了修改这个构想，或者在紧张的日常工作之余，提醒团队他们努力的目的地在哪里。
1060
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
