Scrum過程是否最終剝離團隊成員各自的技能？

Question

我的組織一直在嘗試引入更多的「敏捷」方法。我們一直在嘗試Scrum方法，而且大部分團隊都或多或少地適應了它。我喜歡它作爲一個整體，但我擔心方法的一個潛在的嚴重影響：由於團隊一直關注功能和積壓項目，並且測試人員與整體開發過程更加整合，所以似乎技能集正在成爲模糊，人們感覺不那麼尊重他們的個人能力。

我們的一些開發人員非常擅長服務器端技術和優化重量級數據供應。其他人已經投入了大量的職業學習GUI技術，並且已經對用戶和應用程序的可用性有了基本的瞭解。這兩種技能都不如其他技能更好，但它們肯定不同。

這是Scrum過程的必然結果嗎？由於團隊中的每個成員（據我瞭解）都有助於滿足下一個功能/需求，積壓項目或手頭的測試目標，因此其基本理念似乎是「任何人都可以做到」。根據我的經驗，這是不正確的。大多數工程師（開發人員，測試人員等）都擁有他們多年來磨練出來的特定技能，而在我看來，Scrum方法傾向於貶低他們以前所尊重的能力。

這裏澄清一個例子：

如果在服務器端的數據供應發生技術的突然改變，和待辦事項列表衝刺上每一個項目就是基於這一新的變化，在GUI開發者（可能沒有時間適應新技術）可能無法爲衝刺做出貢獻。至少，他們需要投入時間來提高速度，然後他們的代碼會因爲缺乏經驗而受到懷疑。

我知道快速發展的必要性，以阻止「角色孤島」，但這並不折扣一個基本現實：人們根據需要，他們的興趣或他們的經驗發展技能。當人們認爲他們的位置是「可插拔的」位置時（例如，我們可以「插入」任何人來完成這項特定任務），人們看起來動機不大。 Scrum如何解決這個問題？如果不這樣做，有沒有人在採用Scrum方法時解決了這個問題？

Answer 1

Scrum的重點是開發者自我組織。我們在哪裏使用Scrum，並且按照某個人的重點被動地排序。我們不會故意使用圖表和列表，只會發生。我們都知道誰最擅長什麼，或者他們的主要/次要焦點是什麼。如果「主」人需要幫助，他們會獲得輔助重點人員幫助。我們確實得到了很多不一定符合我們特定焦點的任務，但是你總是知道誰應該尋求幫助。

舉個例子 - 我不知道如果你說有3個服務器人員和5個gui人員，你希望得到在該sprint中完成的所有工作（如果服務器人員+其他人還不夠）。衝刺應該運作的方式是，從優先級列表中，開發人員選擇他們認爲在30天的時間內完成的事情。如果這意味着GUI們需要2天的服務器端培訓才能獲得幫助，那就是它的意思。除非有同時發生的事情，他們可以做的事情也高。短跑任務不應該被管理層視爲假期限期。

如果您有一個Safari帳戶，那麼發明Scrum的人中就有一本非常有趣的案例研究書籍。

Answer 2

聽起來像這樣會導致更全面的開發人員，也允許那些在某些領域的專家繼續貢獻自己的專業知識。

我自己還沒有使用過很多Scrum，但是從你的描述來看，這些類型的團隊會導致一個整體上也更加全面的團隊/組織 - 而且不應該是任何球隊的目標？

Answer 3

如果您發現任何原因（「技術的突然變化」），系統在sprint上所需的工作量大於可用的工作量，那麼您的調度就會出現問題。

一個問題就是，如你所建議的那樣，你需要從其他領域的程序員那裏把它們投入混合。這樣做的效果取決於該人的技能以及問題領域的差異程度，但將程序員視爲可根據需要進行培訓的通用單元通常不是開發軟件的成功策略。

雖然這仍然是一個調度問題。

Answer 4

我不確定爲什麼技能會變得模糊。敏捷世界中存在相當多的混亂。 Scrum是一個項目管理過程，而不是一個軟件開發過程，不應該被視爲一個。工程師必須遵循他們自己的方法，如TDD或極限編程，才能將自己的部分添加到敏捷中。

Scrum中沒有任何東西可以消除。

PM仍在繼續文檔 建築師仍然在構建他們的組件。唯一的一點是他們只是將一些重大決策推遲到更負責任的時間點。 開發人員仍應遵循最佳實踐，例如SOLID principles，以便在功能更改時以一致的方式進行重構。

Answer 5

處理突然變化是敏捷的一部分，這可能意味着有些人不得不離開並學習新的技能。當然，這比普通的敏捷哲學更具有Scrum特有的意義。可能有一些極端的例子，客戶或企業決定通過引入新的東西來改變世界，並因此必須處理那些正在增加的人的後續痛苦，但如果這是他們想要的並且開發者被否決，那麼存在只有幾個選擇：（拿你的硬塊，並嘗試處理重大變化）或（退出並離開那裏）。

儘管可能有些情況下，某個專門從事某事的人可能能夠更快地做事，但這並不意味着太多，如果這只是團隊中的一個專家並且有足夠的工作在這個區域爲整個衝刺10人。如果那些不是專家根本就不做這項工作，並讓一個人嘗試儘可能多地完成這項工作？我不這麼認爲，但對於那些仍然試圖完成他們可以完成的任務的人來說，那些並不是最好的人應該有什麼要說的。

Answer 6

關於Scrum的最好的事情就是技能確實有點模糊的事實！重點是通過在整個團隊中傳播專業知識並讓人們在舒適區之外工作一點點，不惜一切代價避免孤島。

顯然這不適合每個人。一些開發人員對自己狹窄的專業領域感到高興，這些人在Scrum過程中比資產更容易受到阻礙，而全心全意和多才多藝的人決心完成工作，通常非常適應它並且更加高效。

Scrum的關鍵優勢之一是讓整個團隊真正參與到項目中並投入到項目中，而不是處理他們自己的特殊任務，然後騎馬到地平線上。我認爲對大多數人來說，這是一個比傳送帶更有意義的工作方式 - 瀑布過程的方法。

因此，我建議大膽接受技能的混合，並讓人們聚在一起，取而代之依靠專業孤島來解決難題。有動力的人組成的團隊的結果可能會令人驚訝。

Answer 7

我認爲斯科特·安布勒在http://www.agilemodeling.com/essays/generalizingSpecialists.htm非常徹底地解決了這個問題...

他的泛化專家的觀念是完全的事情集體所有制/ Scrum團隊要求，並非常有意義給我。

它很難在現實生活中實現，雖然;-)

Answer 8

我已經工作作爲ScrumMaster的約18個月，有兩個不同的團隊工作。我最初預計會遇到您提出的潛在問題，但事實並非如此。我通常觀察到的是，隨着人們爲自己找到合適的角色，他們可以成爲專家和通才的混合體 - 他們可以享受並取得成功。這是工作中的自組織。我從未遇到過我們的專家閒置的情況。

如果確實發生了這種情況，我認爲它會在Sprint Retrospective中作爲問題提出，並且團隊將討論如何改善情況。最明顯的（和殘酷的）結論是改變團隊組成。

Answer 9

簡短的回答是一個強調否！ Scrum確實不是模糊或貶低專業化所需的技能。 Scrum不推廣泛化。

漫長的回答是，在Scrum中，最重要的是讓工作「完成」。團隊作爲一個團隊（而不是各個「明星」的集合）根據需要進行協作，以完成工作。無論如何 - 不管他們想要什麼（Scrum是關於自我管理，自我激勵的團隊，對吧？）。

這意味着一個Scrum團隊可能由幾個專家組成，他們主要做他們專門從事的工作（DBA，平面設計，甚至是技術作家）。作爲一個整體，團隊應具備滿足要求所需的所有技能。這不同於說每個團隊成員必須具備上述所有技能。

這就是說，人們經常希望 - 通常由成員自己 - 除了專家以外的其他成員至少具有不同於他們的專業的技能。另一張海報已經提到了Scott Ambler的「一般專家」。這對團隊有很大幫助，當專家缺席時，這對團隊有幫助，當他真的想在專業之外獲得經驗時，這對團隊有幫助。

鑑於團隊是自我組織的，如果由於某種原因某個專家發現自己處於衝刺中，他的專業中沒有任何工作要處理，最好的方法就是問問專家他想做什麼。讓團隊決定。專家可以決定幫助他的其他領域充足，爲下一次衝刺做POC，通過修復一些被遺忘的技術債務來「支撐」防禦，或者照亮工作的成員的鞋子工作。

是。我不知道這是否是的漫長的答案。但它絕對是a長的答案。 :-)