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车维持团队成员我的的灵活性的同时，最大化这个核心时间。

 

4.我看了这段文字

  新加入团队成员

      在项目进行过程当中，已成立的团队有时须要增长新成员。无论是什么缘由，好比人员流动、公司重组、交付期限提早、工做量增长或者其余什么，考虑周全后再加新成员并使其尽快融入团队是相当重要的。即便在最理想的状况下，因为团队须要适应新人加入以及新人须要熟悉状况，团队都会暂时放慢速度。当加入-位不合适的成员或者在毫无准备的状况下加入一一个正确的成员，这种减速可能会持续延长。这正好验证了布鲁克斯定律，即“在一个进度滞后的项目中增长人力会使之变得更加滞后。”

那么问题来了：让新成员彻底融入已建好的团队，第一步是选对人。当你为团队增长成员的时候，首先要看他的我的价值观体系。这我的乐于接受变化吗?灵活吗?谦虚吗?善于团队合做吗?好学吗?

对于这些问题，若是答案是确定的，那么再看看他的技能。这我的具备完成工做所需的技能吗?价值观确定比技能重要，由于技能是很容易教的。在这一章的故事里，团队由于Dennis的我的价值观和能力而选择了他。他们知道他能够很好地融入团队文化。

 

5.我看了这段文字

我但愿前面已经很清楚地表达不要组合角色。但我知道你极可能仍是想尝试。若是要这样作，我建议只能组合团队成员与ScrumMaster角色。为何?这是一种危害最小的组合。让ScrumMaster与团队一块儿工做，可能最容易说服管理层，特别是当他们觉得这个角色是额外负担而说“大家不能作Scrum”的时候。这样作的时候要当心，确保全部人一开始就达成共识。想要知道为何要有一个全职的ScrumMaster？

首先要知道什么是ScrumMaster？

 

 

 Scrum Master有点相似产品经理，可是又不太同样。 2.Scrum是一种敏捷开发模式，SM是Scrum敏捷团队的领导者和服务者。 3.主要负责同外部沟通、解决敏捷团队开发中遇到的问题、监督scrum概念和原则的贯彻执行。