5个问题
1.我看了这一段文字
*每一个项目都需要一定数量的文档。在![]()
salon.com上有篇1998年的文章，标题是“编程的弱智化”(The Dumbing Down of Programming),作者乌尔曼(ElenUllman指出一个大的计算机系统如何“代表人类总结的知识”LULLMAN .就系统文档面论，我们需要意识到我们不是在为自己建立或者编写，我们在为将来编写。我认为鸟尔曼在同一.篇文章中的这个片段总结得最好:
随着时间的流逝，唯一能够代表原有知识的只有代码本身，我们可以运行但并不能完全理解的东西。这已经成为一个流程，成为我们可以操作但不再会重新深入思考的东西。即使源代码就放在你的面前，人类阅读者能够从成千上万行主要为功能而不是为传达意图而设计的文本中获得的仍然有限。当知识传递到代码，它的状态就变了;就好像水变成了冰，它变成了一个有了新属性的新物体。我们使用它，但在人类认知中，我们已经无法理解了。
为什么鸟尔曼的这个“代码是形态发生改变的流程”很重要?这是因为我们需要明白，在人类认知中，我们不仅使用系统，我们也了解系统。这就是我们要做文档的原因。
随着时间的流逝，唯一能够代表原有知识的只有代码本身，我们可以运行但并不能完全理解的东西。这已经成为一个流程，成为我们可以操作但不再会重新深入思考的东西。即使源代码就放在你的面前，人类阅读者能够从成千上万行主要为功能而不是为传达意图而设计的文本中获得的仍然有限。当知识传递到代码，它的状态就变了;就好像水变成了冰，它变成了一个有了新属性的新物体。我们使用它，但在人类认知中，我们已经无法理解了。
为什么鸟尔曼的这个“代码是形态发生改变的流程”很重要?这是因为我们需要明白，在人类认知中，我们不仅使用系统，我们也了解系统。这就是我们要做文档的原因。
有一个标题是这么问的；为什么我们要做文档？
那么，什么对文档而言必不可少?什么是无用的工作?这大部分取决于你在构建什么类型的系统以及你工作的方式。相比跨洲跨时区的团队，驻扎在同一个地点的团队需要的文档少一些。 相比做销网站的团队，构建需要满足更多监管需求的银行系统的团队需要更多文档。关键在于，只做需要的文档，不多做。
2.我看了这一段文字
很少有人知道Ziv 定律，即软件开发是不可预测的。全球范围内大量项目的失败在很大程度上就是因为缺乏对这个问题以及正确处理这个问题的方法的理解。Mitch描述了对持续的变化进行检查与调整的需要。这本书中的策略可以帮助你避免很多陷阱，消除Scrum实施过程中的很多障碍
很少人知道Ziv定律，那么问题来了Ziv定律是什么？
虽然查了百度，也还是不懂。
3.我看了这一段文字
Scrum团队尽量安排在一起工作，而且最理想的是在同个办公空间里。 这样有利于有效沟通、协作以及代码的集体所有。但如果一些团队成员喜欢在早上7点来上班，而另外一些人则喜欢早上点才来， 我们应该怎么办? 同样，对于午餐时间以及每天下班时间这样的场景，我们又应该怎么办呢?
对于很多团队，这些事情看似可能都很琐碎，但其实不然。事实上，一 个像核心时间这样看似无害的小障碍可以使整个团队功亏一篑。 这种情况在下面的故事中差点儿发生:资深的开发人员认为一个年轻的开发人员缺乏对公司与团队的奉献，并因此产生了心结，差点儿使团队处于分崩离析的边缘。
对于很多团队，这些事情看似可能都很琐碎，但其实不然。事实上，一 个像核心时间这样看似无害的小障碍可以使整个团队功亏一篑。 这种情况在下面的故事中差点儿发生:资深的开发人员认为一个年轻的开发人员缺乏对公司与团队的奉献，并因此产生了心结，差点儿使团队处于分崩离析的边缘。
我觉得可以应该这样：首先，确保团队理解核心时间的重要性，并且团队就喜欢的工作时间和工作习惯达成集体协议。不管团队是在一一起工作还是分布式的， 每天在一起工作有助于保持对事情的跟踪检查和持续的沟通交流。 在一起工作的人有能力学习其他人的行为、技能和模式。随着彼此之间在生活上和工作上的了解逐步深入，他们开始凝聚成为一个团队。在一起工作也给人们提供了更多认识项目的机会，因为他们会花更多的时间在自己平常接触不到的一-些系统组件。
其次，在每个项目开始的时候以及定期在整个项目过程中根据需要建立核心时间。如果Jacob事先了解Russ的工作模式，就不会感到沮丧:尽管Russ来得比较晚，但他离开得也晚。这些模式在项目过程中可能会改变，比如上学、工作、天气和假期都可能影响每个人是否能到场，所以当团队成员的工作时间发生巨大变化的时候，他们必须及时交流，这是十分重要的。如果团队成员是分布式的或者是兼职的，而且核心时间在每个Sprint 都会发生巨大变化，那么在每个Sprint 开始的时候，都要做这种活动来确定当前Sprint 的核心时间。
最后，鼓励团队成员保持开放并愿意做出让步。也许不是每个人都能完全按照自己喜欢的时间安排来工作。提醒他们，一起 工作的好处远远高于-一个人的个人习惯。
确立核心时间虽然是一件小事情，但可能对团队绩效造成重大影响。计算大家在
奴t车维持团队成员个人的灵活性的同时，最大化这个核心时间。
其次，在每个项目开始的时候以及定期在整个项目过程中根据需要建立核心时间。如果Jacob事先了解Russ的工作模式，就不会感到沮丧:尽管Russ来得比较晚，但他离开得也晚。这些模式在项目过程中可能会改变，比如上学、工作、天气和假期都可能影响每个人是否能到场，所以当团队成员的工作时间发生巨大变化的时候，他们必须及时交流，这是十分重要的。如果团队成员是分布式的或者是兼职的，而且核心时间在每个Sprint 都会发生巨大变化，那么在每个Sprint 开始的时候，都要做这种活动来确定当前Sprint 的核心时间。
最后，鼓励团队成员保持开放并愿意做出让步。也许不是每个人都能完全按照自己喜欢的时间安排来工作。提醒他们，一起 工作的好处远远高于-一个人的个人习惯。
确立核心时间虽然是一件小事情，但可能对团队绩效造成重大影响。计算大家在
奴t车维持团队成员个人的灵活性的同时，最大化这个核心时间。
4.我看了这段文字
新加入团队成员
在项目进行过程中，已成立的团队有时需要增加新成员。不管是什么原因，比如人员流动、公司重组、交付期限提前、工作量增加或者其他什么，考虑周全后再加新成员并使其尽快融入团队是至关重要的。即使在最理想的情况下，由于团队需要适应新人加入以及新人需要熟悉情况，团队都会暂时放慢速度。当加入-位不合适的成员或者在毫无准备的情况下加入一一个正确的成员，这种减速可能会持续延长。这正好验证了布鲁克斯定律，即“在一个进度滞后的项目中增加人力会使之变得更加滞后。”
那么问题来了：让新成员完全融入已建好的团队，第一步是选对人。当你为团队增加成员的时候，首先要看他的个人价值观体系。这个人乐于接受变化吗?灵活吗?谦虚吗?善于团队合作吗?好学吗?
对于这些问题，如果答案是肯定的，那么再看看他的技能。这个人具有完成工作所需的技能吗?价值观肯定比技能重要，因为技能是很容易教的。在这一章的故事里，团队因为Dennis的个人价值观和能力而选择了他。他们知道他可以很好地融入团队文化。
5.我看了这段文字
我希望前面已经很清楚地表达不要组合角色。但我知道你很可能还是想尝试。如果要这样做，我建议只能组合团队成员与ScrumMaster角色。为什么?这是一种危害最小的组合。让ScrumMaster与团队一起工作，可能最容易说服管理层，特别是当他们以为这个角色是额外负担而说“你们不能做Scrum”的时候。这样做的时候要小心，确保所有人一开始就达成共识。想要知道为什么要有一个全职的ScrumMaster？
首先要知道什么是ScrumMaster？
Scrum Master有点类似产品经理，但是又不太一样。
2.Scrum是一种敏捷开发模式，SM是Scrum敏捷团队的领导者和服务者。
3.主要负责同外部沟通、解决敏捷团队开发中遇到的问题、监督scrum概念和原则的贯彻执行。
2.Scrum是一种敏捷开发模式，SM是Scrum敏捷团队的领导者和服务者。
3.主要负责同外部沟通、解决敏捷团队开发中遇到的问题、监督scrum概念和原则的贯彻执行。
