這是《落葉》文集里第?82?片落葉闹丐，希望你能喜歡阱高，不為別的赚导，只為這份堅(jiān)持。
“十宗罪”之七：缺乏測試
這個(gè)問題在不少的敏捷團(tuán)隊(duì)都有赤惊，組建的時(shí)候吼旧，為了追求所謂的快，用開發(fā)自己在做每個(gè) User Story 時(shí)做的單元測試或者集成測試替代了完整需求的測試驗(yàn)證未舟。為了達(dá)到所謂的不用固化角色圈暗，可以互相 backup，而由單一的開發(fā)人員來組建團(tuán)隊(duì)裕膀。
這種做法有點(diǎn)本末倒置了员串，敏捷開發(fā)的初衷和目標(biāo)是提升研發(fā)效率和需求實(shí)現(xiàn)的契合度，無論是真的做到了敏捷昼扛，還是半瀑布半敏捷寸齐，甚至于偽敏捷也好，都只是流程問題或者是效率問題，但最核心最基本的原則不能丟访忿，那就是產(chǎn)品的質(zhì)量瞧栗。
雖說我很認(rèn)可一個(gè)觀點(diǎn)，那就是質(zhì)量不是靠測試保證的海铆，而是要靠開發(fā)的代碼質(zhì)量保證的迹恐。但就我這些年來的工作經(jīng)歷看來，70%的開發(fā)人員的確沒有這個(gè)意識卧斟，或者說現(xiàn)在絕大多數(shù)公司的研發(fā)流程中殴边，對開發(fā)代碼質(zhì)量的考核，就從來沒有嚴(yán)格到那個(gè)程度珍语，也沒有任何研發(fā)模式會引導(dǎo)開發(fā)自主的對代碼質(zhì)量重視起來锤岸，
所以，現(xiàn)階段來說板乙，一個(gè)產(chǎn)品的質(zhì)量是偷，還是需要測試去驗(yàn)證和保證的。而在敏捷中募逞，我們更多地應(yīng)該是去思考如何讓開發(fā)和測試的配合更加敏捷蛋铆，而不是簡簡單單地只是去考慮如何能讓開發(fā)替代測試的工作，或者讓測試能夠去寫代碼放接，這些其實(shí)并不是敏捷思想真正想去達(dá)成的目的刺啦，我認(rèn)為這反而是一個(gè)相當(dāng)大的誤區(qū)。
“十宗罪”之八：忽視用戶的反饋
敏捷與瀑布比纠脾，有一個(gè)很大的優(yōu)勢玛瘸，就是它有很多個(gè)迭代構(gòu)成，每個(gè)迭代都有可工作的產(chǎn)物生成苟蹈，用戶就能看到成品糊渊，并且使用體驗(yàn)，同時(shí)提出建議和意見慧脱。然后團(tuán)隊(duì)在根據(jù)用戶的反饋在下個(gè)迭代里進(jìn)行改進(jìn)和調(diào)整再来，用戶在下個(gè)迭代結(jié)束的時(shí)候又能看到一個(gè)改進(jìn)調(diào)整后的功能，在這樣連續(xù)反復(fù)的迭代中磷瘤，產(chǎn)品經(jīng)過團(tuán)隊(duì)和用戶的反饋->改進(jìn)->反饋芒篷。。采缚。针炉，逐漸地被打磨成用戶真正想要和真正滿意的樣子。
而很多團(tuán)隊(duì)在一開始扳抽，特別抵觸篡帕，甚至于“反感”這種用戶反饋殖侵，他們總認(rèn)為用戶是在干擾他們實(shí)現(xiàn)某個(gè)需求，而不愿意停下來好好去看看镰烧，去理解用戶的反饋拢军。這是因?yàn)榇蠹覄倓傓D(zhuǎn)型，還不是特別理解敏捷很多思想的時(shí)候怔鳖，仍然固有自己在實(shí)現(xiàn)過程中茉唉，不希望被打斷。有些人這時(shí)候還會拿出 Scrum 的教科書來說结执，書上不是說每個(gè) Sprint 里不允許發(fā)生需求變更嗎度陆？
沒錯(cuò)啊，我們這里說的用戶反饋献幔，并不是打斷你當(dāng)前 Sprint 的進(jìn)行懂傀，他是在兩個(gè) Sprint 之間所產(chǎn)生的，它會影響到的只是下個(gè) Sprint Backlog 里的 User Story蜡感，并不會中斷你正在進(jìn)行中的工作蹬蚁。
而且我們之所以引入敏捷，不就是想通過短平快的路子來不斷地試錯(cuò)郑兴，獲得用戶的及時(shí)反饋缚忧，再進(jìn)行持續(xù)的改進(jìn)嗎，從而提升用戶對產(chǎn)品的滿意度嗎杈笔？如果脫離或者屏蔽了用戶反饋，那豈不是又會產(chǎn)生原有瀑布模式下的問題了嗎糕非？
所以蒙具，不管我們是否采用敏捷，都不能脫離用戶需求朽肥，不能忽略用戶的意見和建議禁筏。雖然用戶不是上帝，但用戶的確是檢驗(yàn)?zāi)惝a(chǎn)品成功與否的唯一衡招。
作者簡介：14 年測試經(jīng)驗(yàn) + 11 年項(xiàng)目管理經(jīng)驗(yàn) + 11 年團(tuán)隊(duì)管理 = 一個(gè)測試?yán)媳?br>
