敏捷開發有益于個人發展">敏捷開發有益于個人發展
敏捷項目首先擁有一支支小規模但職能全面的團隊，在這樣一個普通的敏捷團隊里，擁有具備不同職能的 7 名成員，1 名 UCD(User Centered Designer)，1 名 Visual Designer，1 名測試人員（Tester）， 1 名 Information Developer 和 3 名開發人員（Developer）。因此，每一支敏捷團隊中的設計、開發、測試、美工、文檔等等工作分屬給了這個團隊里不同的，唯一的人。每個人在團隊里因而必須具有對其所涉及領域強的責任心和領導力。就測試而言，測試人員就是好比一輛跑車里的唯一的駕駛員，項目就好比這輛跑車，測試人員需要及時修正行駛方向的偏差，確保這輛車在正確的道路上穩步前行。如果，測試人員沒有具備足夠的責任心和領導力，只是人云亦云，恐怕這種測試要與不要沒什么分別，敏捷項目的質量也更讓人擔憂，而敏捷也就失去了原有的意義。因此，作為唯一的測試人員，他（她）將擁有對測試的所有權，計劃、設計并且執行所有的測試工作。而也因為擁有了更多的主人翁精神，積極的工作熱情，測試人員勇敢的面對工作中的各種挑戰，學習新的知識和努力培養自己的工作技能。敏捷無疑對個人發展產生了很大的推動作用。
敏捷團隊中的每個人，需定時和團隊的其他成員坐下來看看團隊的整體進度，計劃下一步工作，并一起探討所遭遇問題的解決方案。也需適時的尋求團隊中其他成員的幫助解決時下緊要的問題。通過頻繁的合作與溝通，個人的協作能力、溝通能力也得到了較大的提高。下面我們具體就這兩個方面進一步談談敏捷開發是如何幫助提高個人的協作能力和溝通能力的。
與傳統開發不同，敏捷開發更加側重以人為本，發揮人的積極性，以此提高團隊的工作效率。真正實現以結果為導向的職場守則。作為團隊的一份子，無論是測試、開發人員，還是設計人員，他們都將為團隊成敗擔當不可或缺的責任。團隊是高度協作的團隊，個人除了做好本職工作外，敏捷開發模式要求個人能夠了解和爭取更多的擴展性的工作，也能幫助團隊其他成員解決他們的遇到的各種獨特問題，以加快實現團隊的統一目標，即在更少的時間里生產出能夠推向市場的可靠產品。
這里再次提及高度協作，筆者認為高度的團隊協作主要表現為以下特點：
- 團隊成員積極分享經驗，知識，自我培養所需技能和自我成長；
- 團隊成員相互幫助，愿意成為他人后備隊員，隨時做好準備投入新的戰斗，因而保障了團隊的高昂士氣和強大的生命力。
- 任何決策是團隊共同的決策，工作是團隊共同的工作，團隊工作的最后成果因而也是來自團隊中每個人的辛勤培養和貢獻。而團隊的失敗更是整個團隊的失敗，絕不會是某個人的單方面的過失。這種榮辱與共，共生共息的信念將讓團隊的力量超過團隊各個力量之和。同時，項目團隊的工作效率在團隊成員技能的提升和信念的鞏固中不斷提高
我們把團隊看做一個高度協作整體的同時，不可忽視的是團隊內部仍存在的各種矛盾，對這些問題的聽之任之將破壞團隊的凝聚力、生產力。這中間反映出來的很多問題不是敏捷方式獨有，但團隊成員因為敏捷，學會了自己解決各種問題。而相應的溝通能力也隨著問題的解決得到很大幅度的提高。
在過去的項目經驗中，我們不難發現種種人與人之間矛盾的產生。而經典的矛盾論也讓我們不得不的接受，矛盾是永遠存在的，但這并沒有什么可怕。而是一旦我們發現了矛盾的存在，就要迅速找到解決辦法，這也是團隊的相當重要的工作。尤其是在團隊組建初期，團隊開始采納新開發模式時，鍛煉團隊解決如下矛盾的工作非常重要：
- 測試人員是質量的工程師，開發人員是產品的締造者，在對質量標準的認同上常有不一致（當然，傳統開發也會產生）；
- UCD 的設計實時反應用戶需要，但有時不能顧及代碼的可實現性；
- 開發人員而卻更喜歡用想當然的理解，和習慣的方式填寫代碼，甚至主觀的抵制接受新設計思想和拒絕新類型缺陷的修復，因此與團隊的整體目標、出發點產生分歧；
- 從整個項目組織結構看來，敏捷團隊之間（一個項目通常有多個敏捷團隊組成，各個團隊有自己的側重點）存在設計，開發的不一致性，這使得產品在整合階段產生額外的成本。
正如前面所論述，矛盾總是有能夠解決的途徑，敏捷項目的組織中用管理方式去干預是一種直接、快速的方式，而今天敏捷方法論者們更加推崇的是鼓勵團隊內部進行很好的交流和溝通后自行解決。也正是通過不斷加強團隊間和團隊內部的相互理解，不但矛盾得到很好的解決（解鈴還須系鈴人嘛），個人的交流和溝通技能也得到了進一步提高。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
