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概念和原則的貫徹執行。