agile/scrum 若是一切都從解放前開始

　　一個很是珍貴的機會，彙集了公司不少牛人，進行了一場發人深省的討論。有一個話題我想拿出來和他家分享一下個人見解。

愈來愈不舒服的站會

　　站會是天天都在固定的時間、地點，大概持續15分鐘左右（咱們的小組都比較小，Scrum精神的一部分吧）的站着開的會。參加人員通常有全部的Developer， Project Manager（簡稱PM）等其餘人。

站會的目的是爲了讓組內每一個人的工做更加透明，若是能發現問題互相幫助更好。因此，站會每一個人說話的內容有三要素：昨天干了啥，今天準備幹啥，遇到什麼困難。昨天干了啥，你們通常都會從這幾點開始說：作了什麼，怎麼作的，進展怎麼樣。開始你們還都集中精力適應Scrum，因此也不多有什麼不舒服的感受。

可是隨着Scrum的進展，咱們發現了一些很差的地方。下面是三個小故事

1. 若是我前天說有一個問題我在Debug，昨天說我在繼續Debug，今天我該說點什麼呢，仍然在Debug？其餘人，尤爲PM，會懷疑個人能力，到底在不在幹活兒？
2. 通常Debug的過程都很曲折，若是前天我說，多是A緣由；昨天說，A可能不是最終的緣由，發現B多是；今天說，上午我在解決B問題，發現C纔是根本緣由。結果你們「哄」笑了，背後的意思是「你肯定不會發現D纔是根本緣由」？
3. 咱們的Project很是大，纔會致使了上面那個問題，這裏面還有一個其餘問題。當我發現B問題的時候，可能我以爲它比較淺，較深層次的緣由可能在別的組的一些組件裏，我須要請教其餘組的人，我須要掌握他們的邏輯，我須要看看他們的代碼。這些至少都須要時間，那麼也就是說若是直接Fix那個淺淺的問題，我不要學習其餘的東西，時間很短，1天就好。可是，當我想深層次的Fix這個問題，由於那纔是根本，這樣我才能成長、擴大我對Project的理解、成長爲專家。可是，當我說我須要5天時，我以爲臉上火辣辣的：別人可能都以爲我只須要1天就行了，說這麼多天，別人會怎麼想我呢？我須要向他們解釋嗎？

　　這種狀況下，公司老人都有這樣的擔心，那麼對新人，尤爲還不瞭解公司文化的狀況下，實際上是更加很差的：「由於我須要證實我是能幹活的，只須要不多的時間」。可是，其實公司但願他慢點Fix，去找到根本緣由，去學習，半年後成爲專家，而不是兩年後仍是停留在問題的表面。

須要被完善的Agile/Scrum

　　 在讀了《agile software development》 和《程序員的思惟修煉-開發認知潛能的九堂課》以後我意識到公司培訓了咱們Agile/Scrum，可是並無培訓咱們如何去思考，如何去完善Agile/Scrum。

　　不只沒有如何完善，更有甚者，其實咱們是在往一個你們對Agile/Scrum理解的交集上靠攏着。就像這樣：

 

而咱們期待的是：

 

我思故我在

　　Agile/Scrum不是一套寫死了的，你這麼幹就Agile/Scrum了，它也不是一種流程，規範；它更加不是老闆怎麼說，咱們就怎麼辦！它是一種精神（從這一刻起，我以爲，那些書名叫敏捷方法的，均可以斃掉了）：全員，敏捷。

　　在《程序員的思惟修煉》裏提到，Andy的思考：不論遇到什麼問題，感受不對了，就思考，就要想辦法改變，而且時時刻刻地在發生。

　　公司培訓了咱們Agile/Scrum，可是，沒有告訴咱們這不是一個固定的、徹底適合咱們的方法，咱們須要每一個人都參與其中，去適應，去按照咱們具體狀況地完善它。

　　在《agile software development》裏提到了代碼表現出來的幾個問題，其中一個是Viscosity，粘性/粘度。從一個方面理解它就是說：當你想作一件正確的事情時，好比抽取一個函數出來，遇到了很大的難度，這個難度就是一種粘性。

　　以前，公司裏的architect問我，是什麼樣的狀況，致使一個Cpp文件能有10000多行的Code呢？當時，我就想起來了Viscosity，代碼庫工具的Viscosity。咱們使用了公司內部開發的一種代碼庫管理工具，它有一個地方不太好用，在一個Project裏添加文件，很麻煩，先是概念上的複雜，新人不容易掌握，由於用的很少，老人們用的時候，也須要回憶一下；再是，UI上操做完成了，不必定能百分之百的成功，須要去文件裏確認一下，操做是成功的；最後是，命令行操做，不多人熟悉。

　　這是一種典型的Viscosity，Environment Viscosity。咱們在站會這件事情上遇到的問題，也是Viscosity，一種不能讓人踏實地、按照本身的節奏幹活兒的Viscosity。

　　這裏有幾個問題：首先，你們沒有識別出這種Viscosity，由於尚未要去識別它的意識；第二，即便識別了，也只能私下裏討論一下，不可能立刻傳播到其餘組裏，由於沒有公司層面的支持，公司層面從文化，到流程，到條例等各個方面的支持。

　　爲何沒有意識，一，已經說過了，公司沒有培訓；二，咱們沒有讀到過這本書，太忙了，一天到晚的Debug，幹不完的活兒，哪有時間；三，讀到了，忘記了，爲何忘記了，沒有《知道作到》。

　　回到，Andy的思考，以及全員，敏捷。這是要動員全民去思考，去完善這個流程。咱們的一個領導曾經提過一句：大家應該多思考，去改變本身（方式，方法）。可是這一點從沒有被High Light過，慢慢的，就成了一句不顯眼的提醒了。可是，我以爲這句話比起，其餘任何具體細節應該被強調，由於它更加劇要。

　　如今的Scrum的流程，已是Scrum大牛們實踐了多年後的、幾年前的版本。咱們讀到的書，開始實踐Scrum都是人家幾年前的「剩兒」了。如今咱們Run的Scrum已經和大牛們的最新版本差了不少，若是咱們不能思考，並去完善它，那麼咱們的Scrum會愈來愈與之脫節。搞很差，咱們最後會得出一個結論，咱們部署過Scrum，它並不適合咱們。

　　我靠！咱們從沒有一天真正的Agile/Scrum過，好很差！！

　　鼓勵你們去思考，深刻的思考，從多個角度的思考，從人性，腦力，工程師文化等各個角度去思考，去創新。鼓勵你們，有想法，就始終如一的堅持思考下去。哪怕最終發現是錯了，也是收穫，由於你知道哪裏錯了，爲何錯了。

　　思考問題，提出問題，和別人去討論，去實踐，造成完整的理論體系，傳達給其餘須要的人，完成我的價值。

科學的方法-統計

　　若是作到這一點？《Code Complete》上有過關於命名的討論，擺數據證實了變量仍是要全名，全名比縮寫更容易使用：本身寫的時候，本身半年後讀的時候，別人讀的時候，新人讀的時候，所有考慮進去。我想知道一件事情，那個數字是怎麼來的。怎麼來的過程，也就是在回答「如何作到這一點的」的過程。

　　咱們平常工做中，也遇到過命名的問題，基本上是找一些參考資料，按照那個上面說的作。這裏有一個問題，各類參考資料不統一怎麼辦？這就致使了，Code Review，你們互不相讓。最後的結果莫不是：Case by Case；更甚者，由於誰也不接受誰的，而後就不了了之了。

　　咱們都是在科學這面大旗下成長大的，可是關鍵時刻都忘記了屬於科學的方法：統計。咱們能不能這樣，互不相讓者，從發現問題就開始着手研究，各自的影響到底是什麼：全名好，怎麼好，從人的閱讀，到意思的表達等多個角度，舉例說明！縮寫好，好在哪裏？能不能創建起來一個網頁，讓你們開始給出本身的反饋，從本身到其餘人，從老人到新人，從剛寫完Code到半年後回顧，每一種形式都做一個Survey，每一年做一次，每當有任何新進展的時候做一次。不出三年，對咱們本身很是合適的數據就出來了。50.000001%的人，認爲全名好，Ok，那麼咱們就全名吧；或者更具體的Survey是，那種狀況下全名好，哪一種狀況下，縮寫好。這就是科學的Case by Case，不是耍流氓的那個。

　　有了科學的方法，必定也能出科學的結果，那麼咱們多年後就能夠讀本身寫的書了，而不是多年後咱們仍是在讀別人的書。在這個過程當中，咱們缺失了的是思考，方法論，和公司文化層次上的支持。

　　公司從文化層次上的支持過重要了，沒有這個，都被壓榨的去改Bug去了，哪裏還有時間思考。咱們有Innovation小組，也能夠把這個「科研」內容放到這個小組裏面啊。這不也就是官方的支持了嗎？

　　都說軟件開發過程多年來，始終沒有突破一個怪圈，就是沒法大幅度提升生產效率。我深深的以爲這是和人息息相關的。咱們的意識，咱們尚未意識到應該如何不扯皮就能成長，還能用數聽說服全部人。有人又說了，若是咱們得出的數據與《Code Complete》不一致怎麼辦？第一爲何要一致；第二，深挖「不同」的來源。總之，咱們要科學的成長，要積累。

　　軟件開發和我的息息相關，同一本書，每一個人的理解不同，有的人理解的深，有的理解的淺，有人理解的東，有人理解的西。總之，你們不能很好的統一。這樣，那些書上血淚史就不能被不多的傳承。不讀書的就不說了，搞很差讀過書的，由於沒有傳承意識，一切都從解放前開始，從新摸索一遍，一直到天黑請閉眼，而後，就沒有而後了。後來者，依然要從解放前從新開始。

　　Agile/Scrum那些牛人，努力了十多年，積累了必定的經驗，又有足夠好的「天時，地利，人和」，纔有了今天的Visibility（可是，依然不夠啊，不然，爲何你們沒有像喜歡電視劇男/女主角同樣喜歡他們呢？）。若是在公司文化層次上有這樣的支持，咱們就能夠很快積累一樣的經驗，並比他們作的好，一方面找到了更好的軟件開發的路，二方面，引領了潮流，吸引更多牛人的加入。

總結

   　　咱們學會了基本的Agile/Scrum的規則，就認爲這就使一切。這個感受有點兒和「咱們什麼都準備好了，就差幾個Developer來實現了」的商業宣言同樣，其實咱們距離Agile/Scrum還很遠，咱們還須要思考，須要科學的方法，須要按照咱們的方式去完善它。

後記

 　　 據說公司最近有些制定了一些新的規則，隱約以爲有些不妥。本着此次討論的，哪一個詞彙會讓人感受更加舒服些，好比：Review->audit->discovery，這樣的精神。與其 Check（performance）不如help（to setup a plan to increase the settle down speed）。由於Check帶來的壓力只能阻礙認知。

 

　　再說個規則的故事吧：

　　多年前，美國憲法制定者們，美國的國父們，曾經就總統選舉問題進行過不少輪的爭論。要普選仍是間接選舉，是其中問題之一。解決這個問題就是一句話，大意是：咱們要普選，雖這樣麻煩些，可是更加容易實現公平、公正。由於間接選舉的話，普通老百姓可能會被一些政客忽悠，從而失去選舉的意義。最重要的是，這套規則，簡單明瞭。即便多年後，任何參與人，均可以按照其本意來操做，不會被歪解，扭曲。

　　咱們每一個制定的規則，是否是考慮了，今天你明白也知道如何操做。可是，明天新人來了，他能明白嗎，知道如何具體操做嗎？或者，一個瞎眼老百姓，你告訴他，他就能正確操做嗎？若是不能，請慎重！或者去Help?

　　請思考！