哪些團體應該參與敏捷？

Question

在我的公司，我們有程序員，前端開發人員，設計師和UX團隊都參與敏捷團隊。我不是敏捷主人，但我明白一個團隊的所有成員都應該能夠完成任何工作。有設計師，用戶體驗團隊，前端開發人員和系統管理員參與投票，以評估後端任務將花費多長時間對我來說似乎很瘋狂。我幾乎不知道！所以我的問題是我太苛刻了嗎？這可以在敏捷環境中工作嗎？

Answer 1

你已經得到基本概念錯誤......所有成員都應該能夠跨越故事工作。不是全面的交叉功能......開發者不能突然出現成爲UI設計師。

而且沒有。每個隊員的成員數限制在7-10。所以這個小組應該被相應地分割。

Answer 2

簡短的回答是肯定的。

的純開發人員甚至團隊將傾向於自我組織成專業或特定子系統的所有者（除非你會強迫他們工作的旋轉，但這是一個不同的問題，一個主題）。因此，您將會對房間內大量成員進行估算，這些成員對與故事相關的子系統工作知之甚少。

故事估計應該是瞭解如何比較複雜/工作的尺度。它比定義的基點多出兩倍，四倍，八倍（或類似的比例）。或者，是否與我們在八點評價的這個其他項目相似？至少這是目標。在衝刺級別（與總體積壓）相比，我發現團隊更喜歡用更具體的比例（即小時）進行估算。

對於人們在特定學科，你可能會或可能不希望他們被包含在評估過程。如果這些人對任務的複雜性有合理的理解，那麼估計可能和其他成員一樣好。否則，他們不應該提供估計。包括他們的估計，因爲它往往會造成比較偏遠的估計（過高或過低）的

一個好處。當我們有一個項目的估計超出了合理的信封範圍時，這是對這項工作進行簡短而深入的討論的一個觸發因素。通常，這種討論迫使小組發現了從故事描述和接受標準中不明顯的工作/複雜性。

Answer 3

敏捷團隊應該是「跨職能的」 - 即有許多專家一起工作一些重疊。

對於網絡的發展，甚至對IT基礎架構，它可以使意義有一個DBA，設計師，業務分析師，程序員（任何你需要不同的技能）和IT基礎設施的人在同一個團隊。

不是團隊的所有成員都必須工作就可以了全職 - 但任何部門或專長，可以通過不參與推遲項目或造成誤解必須用足夠的力量和技能，有人表示做那些行動。

不要忘了人民參與：

• 誰需要簽署的事情了，
• 人誰管理常見的設施，如DNS，LDAP
• 網絡管理員
• 人誰購買和維護硬件，
• 安全的人...

我一直參與軟件準備就緒的項目，但DNS或硬件不是 - 就客戶而言這是一個#fail。 你無法控制的東西是否需要幫助？團隊領導者，教練員和Scrum高手應該期待一兩次迭代來讓合適的人蔘與其中。

讓所有參與的估計和開球會議的權利人 - 包括技術銷售和業務是至關重要的。科技的銷售可能會認爲他們不能幫助，但往往他們可以回答關於客戶希望能夠幫助創建估計達成共識什麼問題。

Answer 4

敏捷是關於合作和常識。這就是說，我認爲這將基本歸結爲實際的團隊。他們能有效合作嗎？如果沒有，您可能需要修復它。你的回憶告訴你什麼？ 敏捷是一個路徑，而不是目標

今天與所有有一種產品的所有開發人員必須採取更寬的視野他們的部分如何與產品的其餘部分進行交互協同工作的混合技術。因此，讓我覺得讓一個團隊混合好，但讓團隊公開談話並且一起工作並不總是那麼容易。人們可能很難。

Answer 5

在我的公司，我們有程序員，前端開發人員，設計師和UX團隊都參與敏捷組。我不是敏捷主人，但我明白一個團隊的所有成員都應該能夠完成任何工作。

IMO，這是一種誤解。作爲一個跨職能的團隊並不意味着對球隊每個人都應該能做到每一項工作。這意味着團隊應該是具有正確技能（作爲一個整體）朝着共同目標努力的人的正確組合。換句話說，敏捷不是在尋找一個擁有所有技能的人，敏捷並不反對專業化。每個人都不可能也不會同樣擅長一切。

讓設計師，用戶體驗團隊，前端開發人員和系統管理員投票評估後端任務將花費多長時間對我來說似乎很瘋狂。我幾乎不知道！所以我的問題是我太苛刻了嗎？這可以在敏捷環境中工作嗎？

首先，當使用計劃撲克時，沒有說你需要在第一輪收斂。其實，我認爲有分歧是很好的，讓人們解釋他們爲什麼這樣投票，有他們的確定性和懷疑，然後去下一輪。無論人們的專業領域如何，我敢打賭，不會超過3輪就能達成共識。其次，經過幾次反覆，你將有足夠的歷史數據來比較（「這個故事是這樣一個」），這將有很大的幫助，獨立團隊成員的專業化。第三，正如JeremyMcGee在評論中提醒的那樣，團隊成員將會更好地理解彼此發生的事情和角色，這是另一個重大影響。所以，對我來說，是的，這可以工作，擁有不同的技能是一種力量，而不是一個弱點。