问题一：我看了第三章用团队顾问来优化团队表现内容，内容如下：
“我知道，听我说完，” Rebecca说道，“传统上，专职团队拥有取得成功所需要的所有人，从开发人员和测试人员到设计师与架构师。我没有要求这些。我所提议 的是我需要一个专职的核心团队，他们可以完成大多数日常的工作。当我们需要一个SQL专家或者架构师或者UI设计师的特殊时候，我就从专家池中找到一个还没有被分配给任何项目的人。一个内部咨询顾问池…”她在房间里打着手势，“我们都可以按需使用。对于核心团队，他们就像咨询顾问一样。从短期来看，对于核心团队还不能胜任的工作，他们可以去完成，或者帮助核心团队完成这些专业的任务。从长期来看，如果我们正确使用结对和培训，核心团队成员可以学习这些新的技能进而可以独立承担更多的任务。这样一来，我们在实现业务目标的同时，也在努力实现学习型组织的文化目标
Dave摇了摇头:“ Rebecca，我很欣赏你为解决这个问题而做的努力，但是我真的认为这是不可行的。我们有着一个非常复杂的组织结构，我们需要保持我们的组织矩阵，以便解决项目中出现的类似问题。你所说的这个“团队顾问”的角色看上去是不可行的。我怎么管理他们的时间?你又如何保证这些问题不会再次发生?”
我对这观点表示不懂，一个团队用团队顾问来参与帮忙管理项目是能填补了团队里的技术空缺能覆盖全部项目，但这样另一个项目需要帮忙又去另一个是否会有其他新的困难，而且我百度查找了顾问的优缺点，优点是提供了团队的一些技术上的空缺，但这样会根据个人业绩挂钩，压力也会变得更多，这样到底是利大还是弊大！
问题二：我看了第五章Scrum的三大角色内容，内容如下：
Scrum之所以独特，在于每个角色都尽量不重叠，而且有意与其他角色相冲突。产品负责人应该驱动团队执行业务愿景并为项目干系人与客户交付业务价值。另外方面， Scrummaster专注于保证团队的健康并能够尽可能有效且高效地执行产品负责人的愿景。团队集中精力交付工作。没有产品负责人，团队就有迷失方向的风险；没有 Scrummaster，团队就有弹尽粮绝的危险；没有可以托付的团队成员，项目本身也会有风险。
把三个角色组合在一起是个极其糟糕的主意。我把这个组合“亲切”地称为“致命组合(酒精、苯二氮和海洛因)，我想不出它有任何好处。但是我也经历过这样的阶段，我知道很多人还是想尝试。如果只是一两个人的小团队，也许可以。即使这样也不要指望这样行得通。这种功能障碍预示着可能存在更大的问题，包括一开始可能就不该承接这个项目。
我看了作者表达的观点大致是在实施Scrum管理项目时不建议一人承担多个角色就是身兼多职，但我反过来想身兼多职也有好处吧，只有个人管理得当就不影响到项目，而且如果团队实在是没这方面技术得人那另一个有就可以适当多做，我也网上查找工作身兼多职的好处，虽然大多是说缺点说什么太过劳累和有时会混乱、力不从心，但优点也是有的，只要个人管理得当这样能有效的利用每一分时间，让自己的生活更充实同时各项工作之间能适当的调节，不会产生因为工作单一乏味而厌恶工作的现象。所以Scrum真的就不能一人身兼多职吗？
问题三：我看了第十章团队核心时间内容，内容如下：
Scrum团队尽量安排在一起工作，而且最理想的是在同一个办公空间里。这样有利于有效沟通、协作以及代码的集体所有。但如果一些团队成员喜欢在早上7点来上班，而另外一些则喜欢早上11点才来，我们应该怎么办?同样，对于午餐时间以及每天下班时间这样的场景，我们又应该怎么办呢?
对于很多团队，这些事情看似可能都很琐碎，但其实不然。事实上，一个像核心
时间这样看似无害的小障碍可以使整个团队功亏一篑。这种情况在下面的故事中差点
儿发生:资深的开发人员认为一个年轻的开发人员缺乏对公司与团队的奉献，并因此
产生了心结，差点儿使团队处于分崩离析的边缘。
在我们的故事中，Jacob感觉Russ是在偷懒，所以很不高兴。如果Letitia对这个问题置之不理，团队就可能因为什么时候开始上班这个简单问题而搞得四分五裂。
我看这章内容作者说的是上班时间问题，我表示对于程序员上班时间安排疑问，我之前做暑假工在厂里面都是一天按10小时上班，到时间就下班，而程序员上班时间是如何我有点迷茫，难道工作时间不是统一安排的吗？是根据项目内容难度来安排人员的工作时间吗？就像之前所说有些人7点上班工作，有些人11点才来。
问题四：我看了第十七章富有成效的每日站会内容，内容如下：
每日 Scrum或者每日站会，似乎是个简单的概念。每天聚在一起15分钟回答三个预设的问题同步团队的状态和确保大家正按既定轨道完成 Sprint目标。但是很多情况下，每日站会会退化成每日苦差，要么是因为没完没了的拖延，要么是因为缺乏实质内容，或者更糟糕的是，因为会议变成了互相指责。
从作者所描述的样子看每日站会也存在着一些常见问题，如有人迟到、要求压缩次数、想坐着、跑题且缺乏澄清。有人觉得每日站会有必要吗？我对这每日站会有所困惑，既然有很多人觉得烦、厌恶，但这个站会却也有很大的成效，我困惑每日站会如何开好！
问题五：我看了第二十九章大型产品列表的优先级确定与估算内容，内容如下：
你刚刚与项目干系人一起开完一个很好的用户故事写作研讨会。对于即将要开发的新产品，你感到很兴奋而且迫切地想要马上开始。但是，一回到办公室，看到堆积如山的需要估算并确定优先级的用户故事时，所有的兴奋都荡然无存，因为你面临这样一个困难的事实:不知道该从何做起。
看了我觉得很是困惑，在做一个大项目时该如何正确的确定好产品列表的优先级，就如我之前所玩的一个游戏，我去逛了该游戏论坛发现好多玩家都在吐槽游戏bug多还有尽出一些没用新玩法或者功能，这些问题是否都是项目优先级没摆好的原因吗？是先难还是先易、是用什么标准来衡量优先级，在过程中如果出现bug是否看重不重要在决定先去不去解决？
