近，在Agile Leaders郵件列表中，Dan Mezick發(fā)起了一場(chǎng)關(guān)于敏捷教練是否該有職業(yè)道德規(guī)范的討論。Dan寫道：

 

　　當(dāng)潛在的客戶致電談?wù)撚嘘P(guān)敏捷教練的事情時(shí)，他們通常只有很少敏捷方面的經(jīng)驗(yàn)，對(duì)敏捷的理解程度也比較低。甚至幾乎不了解敏捷，要尋求高度專業(yè)的指導(dǎo)。

 

　　同時(shí)，敏捷教練又必須創(chuàng)造效益來謀生，這樣他們可能有意或無意地造成客戶對(duì)教練的依賴。這樣極有可能產(chǎn)生機(jī)能障礙(dysfunction)??他們會(huì)很快陷入嚴(yán)重的互相依賴的機(jī)能障礙中？蛻魧で髮＜襾砀嬖V他們“應(yīng)該”做什么，可實(shí)際上卻把招募的教練置于更高權(quán)威的角色和地位上去。而教練在一些重要事項(xiàng)上會(huì)左右為難。

 

　　對(duì)此James Schiel回復(fù)說：

 

　　我傾向于相信因果報(bào)應(yīng)。換句話說，別惹你的客戶，因?yàn)椴还苣阗嵙硕嗌馘X，終都會(huì)失去他們的信任。

　　James O. Coplien并不贊同此觀點(diǎn)：

 

　　我覺得制定職業(yè)道德規(guī)范??比如像美國銀行業(yè)協(xié)會(huì)(ABA)所做的??基本沒有效果。我認(rèn)為良好的職業(yè)道德規(guī)范終將會(huì)成為大家常識(shí)中的基本要求，如消除障礙并轉(zhuǎn)向透明的態(tài)度，以及可以進(jìn)行開放、富有成效的對(duì)話的環(huán)境。即，如果你已經(jīng)在實(shí)踐敏捷的價(jià)值觀，那么在某方面，人以及人們彼此之間的互動(dòng)應(yīng)該是占據(jù)主導(dǎo)地位的，卻會(huì)發(fā)現(xiàn)有一套道德體系處在流程和工具中。它也會(huì)加入一些不變的東西，導(dǎo)致在某些方面，本應(yīng)該是敏捷教練能靈活處理的事，卻變得非常僵硬和不靈活。

　　Dan Mezic對(duì)敏捷教練和設(shè)立了從業(yè)道德標(biāo)準(zhǔn)的其他形式的教練作了比較：

　　對(duì)通常所說的教練，已經(jīng)建立了從業(yè)道德標(biāo)準(zhǔn)，而且形成了穩(wěn)定的基礎(chǔ)。它們來自于國際教練聯(lián)盟(ICF，International Coach Federation)，而且被其他組織所使用，比如美國教練培訓(xùn)學(xué)院(CTI，Coaches Training Institute)。我們可以把“ICGCodeOfEthics”(譯者注：指The Institute of Career Guidance Code of Ethical Principles，職業(yè)道德規(guī)范準(zhǔn)則指導(dǎo)學(xué)院)當(dāng)作基類來繼承，用來給我們創(chuàng)造出新的精細(xì)詳盡的道德規(guī)范類……我們可以調(diào)用使用了國際教練聯(lián)盟(ICF)標(biāo)準(zhǔn)的“AgileCoachingEthics(敏捷教練職業(yè)道德規(guī)范)”類作為基類。在ICF標(biāo)準(zhǔn)中沒有說明：采用權(quán)威的立場(chǎng)(或者不是)并沒有考慮到“客戶想要的”是什么。


　　客戶經(jīng)常對(duì)真正的需求毫無頭緒，他們通常尋求的只是“止痛藥”。我們的工作是要千方百計(jì)地為他們服務(wù)。

　　James指出，結(jié)構(gòu)化的道德體系可能違背敏捷的原因：


　　記住，職業(yè)道德規(guī)范目的在于：當(dāng)情況太過復(fù)雜或你被攪亂頭緒時(shí)，用它來幫助你采取行動(dòng)，以做出“正確的”(無論那意味著什么)決定。它完全未顧及敏捷本身的特性，因?yàn)槊艚菟械囊磺卸际顷P(guān)于透明地支持開放性對(duì)話的，而不是依照從業(yè)道德體系采取專斷的行為。

　　我并不是說它沒有意義，只是……基本沒有通用的道德，更別說通用的道德規(guī)范了。我認(rèn)為你完成發(fā)布敏捷教練職業(yè)道德規(guī)范列表的方法是使用命令，而那是違背敏捷原則的。


　　所以我認(rèn)為費(fèi)勁做這件事很可能是自欺其人，這樣說并不是因?yàn)槲胰狈σ庠富蛐枨螅怯捎谒倪@種結(jié)構(gòu)化的方式。

　　Peter Stevens補(bǔ)充說：

　　敏捷聯(lián)盟有職業(yè)道德規(guī)范。我認(rèn)為應(yīng)該要求敏捷認(rèn)證教練CSC簽署這份規(guī)范，不過我也不確定(而且我更不確定Scrum認(rèn)證教練CST的情況)。

　　Dan總結(jié)說：

　　我相信關(guān)于敏捷教練是否該有專門的職業(yè)道德規(guī)范的討論很有用。敏捷教練是獨(dú)特的行業(yè)，他們至少有可能極大地幫助或者傷害客戶組織。還有一些關(guān)于敏捷是如何被視為整體的推論，說是因?yàn)槊艚萁叹?理論上)參與建立了敏捷的道德和原則。

　　Gene進(jìn)一步闡述了該討論：


　　我覺得詳細(xì)討論這個(gè)話題非常重要。因?yàn)槊艚萁叹氝@個(gè)角色相對(duì)來說仍然還很年輕(起碼它不會(huì)比敏捷/Scrum本身存在的時(shí)間還長，對(duì)吧?)我們得承認(rèn)它仍然有需要改進(jìn)的地方，而職業(yè)道德規(guī)范可能正是這些改進(jìn)點(diǎn)中很好的一個(gè)方面。


　　顯然，作為教練，我們被給予了改變行業(yè)狀況的巨大力量，重建組織、影響人際關(guān)系，而且有可能引起業(yè)市場(chǎng)的變化。我們必須確保，當(dāng)我們給客戶提出建議和提供指導(dǎo)時(shí)，我們能時(shí)刻牢記他們的基本利益，并且不會(huì)操縱他們來為我們、教練或是我們所代表的人服務(wù)，而是更多地關(guān)注客戶的利益。

　　關(guān)于這個(gè)話題，Dan Mezick在他的博客里寫了更深層的想法。你可以在獨(dú)立的敏捷和敏捷教練職業(yè)道德規(guī)范的用戶故事查看他的文章。

　　你的看法呢?敏捷教練應(yīng)該有職業(yè)道德規(guī)范嗎?

　　1 敏捷過程中測(cè)試人員如何參與?具體如何配合

　　敏捷中的sprint backlog詳細(xì)標(biāo)注了每個(gè)迭代過程中的任務(wù)和目標(biāo)，開發(fā)人員負(fù)責(zé)代碼編寫，測(cè)試人員準(zhǔn)備測(cè)試用例。迭代中，開發(fā)人員不斷集成以進(jìn)行開發(fā)測(cè)試。在sprint結(jié)束時(shí)開發(fā)人員為測(cè)試人員集成一個(gè)完成了所有sprint目標(biāo)的可測(cè)試版本。

　　2 敏捷過程中的質(zhì)量如何衡量，一個(gè)story開發(fā)完成后，或者說一個(gè)迭代完成后，如何知道這個(gè)story(迭代)的質(zhì)量是好的?統(tǒng)計(jì)用例的通過率?ut的覆蓋率?還有沒有其他的衡量標(biāo)準(zhǔn)?

　　同上，story的質(zhì)量是有測(cè)試人員進(jìn)行保證的，用例通過是每個(gè)sprint的基本目標(biāo)。ut是用來保證代碼質(zhì)量，ut覆蓋率高不代表沒有問題，覆蓋率低也不一定有問題，同樣的100行代碼其邏輯復(fù)雜度有很大差距，需區(qū)別對(duì)待，不可一棒打死。需要指出的是測(cè)試人員在迭代過程中只需驗(yàn)證sprint的目標(biāo)達(dá)到即可，至于store對(duì)系統(tǒng)可能產(chǎn)生的連帶影響可以在User acceptance test中驗(yàn)證。

　　在我們團(tuán)隊(duì)的實(shí)踐里，代碼質(zhì)量主要還是開發(fā)人員自己負(fù)責(zé)，測(cè)試人員主要工作是編寫自動(dòng)化的功能測(cè)試和進(jìn)行一些無法自動(dòng)化的手工測(cè)試，還可以做做可用性測(cè)試，再閑得慌還可以做做沒有測(cè)試用例腳本的隨機(jī)測(cè)試， 有些項(xiàng)目還需要每個(gè)迭代持續(xù)的進(jìn)行性能測(cè)試與穩(wěn)定性測(cè)試。嗯，還有發(fā)布/安裝測(cè)試。

　　無論什么樣的過程，對(duì)質(zhì)量的標(biāo)準(zhǔn)應(yīng)該是沒有區(qū)別的吧，所謂的質(zhì)量無非當(dāng)前實(shí)現(xiàn)的正確性與日后的可擴(kuò)展可維護(hù)性。

　　Agile應(yīng)該沒有特別的統(tǒng)計(jì)方式吧。

　　關(guān)于如何提高項(xiàng)目的質(zhì)量，除了常見的UT+CI外，還推薦一個(gè)比較好的活動(dòng)---Definition of done(DoD)，在每一個(gè)story宣布完成后都要進(jìn)行Checklist的檢查(注意，是隨時(shí)，不要放在迭代后才執(zhí)行)， 比如：


　　1.Story Owner Approved(重要的一項(xiàng))


　　2.Code Guideline(保證通過Sonar等的自動(dòng)化檢測(cè)工具的檢查)


　　3.Code Review(保證通過了Team內(nèi)的Review)

　　4.Test Review(保證有足夠的Unit Test 與 Functional Test，并且在持續(xù)集成服務(wù)器上通過)

　　5.No Bug(保證Bugzliia中沒有相關(guān)的Bug)


　　6.Document Update(保證足夠的JavaDoc注釋， 保證用戶文檔/交付文檔需要改變的部分已與技術(shù)文檔編寫人員溝通)

　　7.Configuration Update(保證涉及系統(tǒng)配置的變更已與集成人員溝通，涉及數(shù)據(jù)的變更已與DBA溝通)