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

 

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

 

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

 

　　對此James Schiel回復說：

 

　　我傾向于相信因果報應(yīng)。換句話說，別惹你的客戶，因為不管你賺了多少錢，終都會失去他們的信任。

　　James O. Coplien并不贊同此觀點：

 

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

　　Dan Mezic對敏捷教練和設(shè)立了從業(yè)道德標準的其他形式的教練作了比較：

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


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

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


　　記住，職業(yè)道德規(guī)范目的在于：當情況太過復雜或你被攪亂頭緒時，用它來幫助你采取行動，以做出“正確的”(無論那意味著什么)決定。它完全未顧及敏捷本身的特性，因為敏捷所有的一切都是關(guān)于透明地支持開放性對話的，而不是依照從業(yè)道德體系采取專斷的行為。

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


　　所以我認為費勁做這件事很可能是自欺其人，這樣說并不是因為我缺乏意愿或需求，而是由于它的這種結(jié)構(gòu)化的方式。

　　Peter Stevens補充說：

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

　　Dan總結(jié)說：

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

　　Gene進一步闡述了該討論：


　　我覺得詳細討論這個話題非常重要。因為敏捷教練這個角色相對來說仍然還很年輕(起碼它不會比敏捷/Scrum本身存在的時間還長，對吧?)我們得承認它仍然有需要改進的地方，而職業(yè)道德規(guī)范可能正是這些改進點中很好的一個方面。


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

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

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

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

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

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

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

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

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

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

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


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


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


　　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溝通)