歡迎來到 常識詞典網 ， 一個專業的常識知識學習網站！
[ Ctrl + D 鍵 ]收藏本站
答案 1：
1.敏捷中文檔輕量化，但是并不代表不保證質量。敏捷是減少不必要的文檔，減少重復文檔，敏捷中不會出現傳統開發中分的那么細的各個階段文檔，你可以看下scrum中的backlog，這個文檔可以從需求貫徹到測試整個過程。對用戶故事，計劃估算，實現方法，如何測試等內容都有描述。2.是提供用戶故事，但是用戶故事粒度比你說的會細化很多。敏捷過程中同樣不允許出現需求蔓延情況。一個用戶故事是能夠帶來用戶價值的最小需求單位。用戶估算不管如何實現，但是一定是會把需求說清楚。3.迭代只是敏捷的一個特征，而不是全部。敏捷更加重要的特征是通過短周期迭代而帶來的團隊不斷自適應和調整。敏捷方法中需求人員在迭代1當然沒有必要想好后續所有迭代的產品細節，但是一定要想好整個產品的功能規劃，即對產品的高端規劃和設計還是要有。答案 2：
1.文檔的量我覺得可以少些，過多的文檔是不符合敏捷開發的理念的，但是文檔的質量必須得到保證，測試用例的覆蓋一定要夠，像你說的那個成功案例，雖然只有一張紙，恐怕上面也有著大量的測試用例吧2.我覺得雖然敏捷開發可以邊開發邊設計細節，但是明確的需求肯定是必須的，任何一個設計在確定時最好先想想這個設計是否能讓迭代順利。3.我覺得敏捷開發就是迭代式的開發，確實有可能出現邊實現邊設計的情況，這也是很難避免的，因為需求時刻都有可能發生變化。所以，測試人員應該及時跟上開發和需求人員的腳步，及時地更新測試用例，并提醒大家需求的變更是不是超過了限度，該控制控制了。答案 3：
1. 敏捷開發過程中, 相關的系統分析文檔, 設計文檔. 對應的測試分析文檔, 測試用例, 是否需要按質量完成.這些文檔視情況而寫，對于框架平臺的，設計文檔可能會要求嚴一點；業務開發，可能會只需要畫幾個類圖而已。但是不管如何，測試用例我們是要求寫的。對于測試用例質量的要求與傳統敏捷開發一樣2. 關于需求, 敏捷開發過程中, 是否需求方只需要提供一個用戶故事,而具體的詳細設計在開發過程中邊設計邊討論.用戶故事往往在實際開發中不夠，因為價值的東西都是相對高層的東西，實現的時候還需要細化，可以使用用例、業務規則等形式細化，檢驗的標準就是開發人員能夠理解需要做什么，知道有哪些流程。詳細設計肯定是在開發過程中去做的，但是在估時時會進行簡單的設計，這個準確度是隨著團隊經驗以及能力提高而提高的。3. 敏捷開發過程, 是否可以等價于迭代式開發迭-發并不是敏捷開發，它只是敏捷開發的一個方面。就但說迭代，有沒有固定周期、有沒有價值目標就是敏捷開發中的一些要素。答案 4：
1，文檔要全，而且要保證質量，不過測試用例例外，看情況而來。敏捷團隊有建議的人數規模，測試人員應該著眼于關鍵點，一個全面的測試用例也常常被證明40%以上的用例是徒勞的。測試人員應該具備出色的test sense，根據經驗能夠判斷出哪里是潛在bug、缺陷和主要數據流關鍵點，針對這些地方寫測試用例，方便管理也能夠判斷數據流階段性的正確。還有就是TDD在開發過程中的保證，前期的需求討論，測試人員參與程度應比開發人員更高，而系統架構確定、軟件架構確定，都是由開發和測試共同決定，并在開發過程中出現需求變動，也保持軟件架構的相對穩定，因為軟件架構的改動對于測試人員來講不單單是改動，很可能是重新來過。2，這個不管是不是敏捷的，前期都盡量挖掘客戶的需求，不留下任何潛在的需求。開發過程中的需求變動，根據經驗來說，還沒有遇上過需求不變的。這個其實是很無奈的，這是由客戶方不夠專業引起的，這也確實沒有辦法，只能是期望變動不是翻天覆地的。3，開發過程差不多，或者說一樣也可以，但敏捷方法對人員上的控制有一些建議，來使人員工作效率更高，交流成本更低。在這方面來講，敏捷對于人的性格也有要求，不是每個人都適合參加敏捷開發，在搞人這方面上，敏捷只是提出了一些建議，最佳實踐還是得根據公司人員和公司-結構的實際情況來定了。答案 5：
職責沒有變化，但是意識要有很大的變化。意識需要從發現Bug轉變為預防Bug出現，從越多發現Bug轉變為越早發現Bug答案 6：
敏捷中根本沒職責的概念，沒有測試、開發的分工，兩種角色可以互換。但是這種要求對現在我們的團隊來說，有點困難 。文檔，敏捷其實不等于無文檔，只是要產出必要的文檔，在一個小團隊里，如果人員足夠自主的話，充分的溝通是可以代替文檔傳遞項目內容的。但是這個我們也嘗試失敗了，主要原因還在于人員問題。人員，我曾經問一個培訓老師，敏捷是不是對人員要求不顯著，可以通過團隊來彌補一個新人的技術能力問題？雖然回答是肯定的，但是我們嘗試過，其實敏捷對人還是有一定要求的，最少的要求是主動性強。敏捷和瀑布哪個好？其實一個開發模式沒有自己的好壞，要看適合與否。瀑布模式會流程感強一點，而且留下的文檔對于產品的長期維護還是有幫助的。敏捷中產出的文檔太少，項目后期若不補充文檔，產品長期發展是不利的。如果一個團隊人員自主性不強，主動性也不好，能力普遍不強，其實這樣子情況瀑布模式反而會讓人覺得過程可控（感覺上的）。并且這種情況下，個人感覺瀑布和敏捷差別不大。答案 7：
我認為敏捷測試是為了讓測試團隊回歸測試的本質，即驗證功能性能，預防與發現Bug，測試不是為了出文檔而進行的，測試的質量不是由文檔來決定的，關鍵是測試的人員。敏捷測試正是強調參與人員的重要性。對于比較簡單的場景，減化必要文檔能提高測試的效率，但對于比較復雜的場景，添加必要文檔也許可以提高效率。答案 8：
我覺得,不管是不是敏捷開發。對于測試團隊的職責和產出是沒有影響的。職責始終應該是根據需求來檢驗產品質量，保證最后遞交的產品符合出口準則。產出應該就是各類測試報告。答案 9：
主要職責沒有變化，仍然是以發現BUG為前提的測試，但是要多一種更積極的溝通意識，很多不是BUG的問題也要盡早發現盡早反饋。答案 10：
個人覺得在敏捷團隊中，測試的難度和挑戰比瀑布模式大的多。不斷變更的需求，技術重構，從story到迭代版本的基本驗證，測試...因此測試的主要職責可以包括以下的幾點：1.需求的把握。測試要對不斷變化的需求都能把握住，以PO（product ower）的標準來要求自己，敏捷的要旨是小步快跑，保證每一步都是對的，這樣在團隊中就需要有人來保證我們做出來的東西是沒有偏離需求的，這個角色只有測試勝任；2.團隊節奏的控制。不知道大家有沒有做過敏捷項目，迭代不斷的出現延遲，問題單越來越多，大家疲于根據計劃加班。這個時候我們可不可以把下個迭代要做的事情暫時先停下來，留一個迭代或者半個迭代來解決問題，重新讀下代碼，找出那些異味的代碼（-elly code）重寫一下。找找我們流程中的問題并改進。這個事情也是由測試人員來提出比較合適；3.質量控制。這當然是測試的傳統的工作，找出問題，讓開發人員來解決。對于一個tester來說，質量控制Quality Control比質量保證Quality Assurence更重要。在敏捷階段，不是說發現的所有問題都需要馬上讓開發人員去改，因為或許這個bug對應的需求還不明確，或許下輪的重構就能自動解決問題，或許當前這個迭代使用的技術解決這個問題代價太大... 總之，這里是比較靈活的，也是比較考驗測試人員的經驗的，什么問題應該馬上解決，什么問題可以討論。另外，關于質量控制比較重要的一點是分清楚測試階段，這點在國內的公司很明顯，單元測試，集成測試覆蓋率低，或者干脆不做，或者做了沒啥作用，每當大家回去做問題回塑，會發現很多問題應該在ut或者st階段發現。那么這里的測試人員要不要去做這些測試，如果要做怎么做，這個對于不同形態的產品或許答案完全不一樣。自己參與過的大型產品中測試人員都是做集成測試的，只是這個過程對測試來說比較痛苦，需要了解代碼，有一定的編碼能力。另外，測試的產出這個有點不好界定，產出這個東東感覺是和流程比較強相關的，我在流程的哪個階段必須產出什么東西。文檔，測試分析，問題單，測試需求分析等等。。。 這個也是和產品的形態有關，如果是輕量級的產品完全不需要做很多事情，或者很多事情可以合并來做，產出一份文檔或者結果就可以。答案 11：
敏捷過程中，測試的主要職責應該是對每次迭代的產出物做驗證，確保產出物滿足產品設計需求，質量合格。答案 12：
1.關于輕文檔的說法之前也看了些關于敏捷模型和方法的介紹性文章，對其中“輕文檔”的概念是深信不以，自己誤將“輕文檔”理解為“無文檔”了 ，這下出亂子了，在一段時間里需求和設計都是采用口口相傳的方式，完全靠個人的理解和記憶力，使所有成員都處在混沌狀態（畢竟這種方式對人的要求太高了，按照當前中國企業人員現狀，大家都懂的...），最后連產品經理自己都不記得當時是怎么設計的了，后來改成了設計討論優先，技術同學可以開始開發，此時交互設計師同步撰寫設計文檔，在產品開發過程中再不斷完善這個文檔。但是文檔本身也必須講究輕量級，將主要的邏輯和需求明確清楚，對于異常問題可以隨著后續的開發進程進行補充。對于測試的一張紙的問題，我覺得一張兩張或者三張的這種形式并不重要，重要的是測試用例是一定要有的，另外測試人員也需要對每個迭代所要達到的目標爛熟于心，這點個人覺得很重要。2. 關于需求的這個觀點，其實我個人只能贊同一半了，贊同的是需求可以通過user story card進行傳達，但是設計不是要等到開發時才出，而是要將本迭代需要開發實現的需求要同步討論和給出設計來3. 這點贊同人月神話的回答，我再補充一點，“比如, 將某個產品分成幾個部分, 先完成某個部分, 再完成其他部分, 或者先做出一個基本原型. 此原型能夠實現基本功能, 再次基礎上繼續完善其他功能“的這個說法，我個人不是很贊同，敏捷的迭代應該是盡量將產品所要傳達給用戶的最有價值的功能先行實現，而不是簡單的說是先實現幾個部分再實現幾個部分答案 13：
我越來越覺得 是中國的產品經理能力不夠 對細節無法把握 也做不出原型 所以我很同意上面的觀點 在反復中完善細節 其實如果原型交互做的好 真的可以減少文檔 但中國會用工具的人太少了下一篇:高智商的男人情商一般比較低嗎？？ 下一篇 【方向鍵 ( → )下一篇】
上一篇:-的-辦事處都負責哪些業務？ 上一篇 【方向鍵 ( ← )上一篇】
快搜
