phabricator項目管理

本文目錄一覽：

• 1、如何打造團隊的工程師文化
• 2、如何在mac下遠程搭建git服務器
• 3、從PM的角度聊聊敏捷開發(fā)
• 4、如何在mac系統下搭建theano深度學習

如何打造團隊的工程師文化

打造團隊的工程師文化需要做好10件事：

1. 優(yōu)化迭代速度?？焖俚乃俣忍岣吡斯ぷ鞣e極性和興奮度。一些工程師在面試時對他們?yōu)槭裁匆x開公司列舉了最常見的令人沮喪的原因是基礎設施和繁冗流程阻礙他們部署代碼或者上線功能。在組織上，快速迭代意味著給工程師和設計師的靈活性和不設限自主做日常決策。我在谷歌，任何用戶可見的搜索結果改變，即使是低流量的實驗，需要瑪麗莎梅耶在 每周 UI 審查批準。雖然這允許谷歌保護它的搜索的品牌，但它明顯阻礙創(chuàng)新。優(yōu)化迭代速度也意味著，有明確定義的流程推出產品，而不會說花了大量時間投入后意外發(fā) 生。

優(yōu)化迭代速度意味著建立持續(xù)部署以快速驗證，提高測試覆蓋率，減少構建和網站當機次數，快速單元測試，并鼓勵大家來運行，快速增量編譯 和重新加載，以縮短開發(fā)時間。持續(xù)部署，提交馬上到線上特別重要。 迭代速度至少在小工程隊利大于弊（線上出錯的風險）。人們更興奮看到功能和修復 Bug 是因為很快看到實時流量變化。這要比超過一周或成批的代碼提交，要更容易推斷和精確定位錯誤源的位置。

團隊智慧，快速迭代的速度意 味著有強有力的領導者，幫助協調和推動團隊的工作。在決定關鍵點上負責人需要有效地作出決定，并承諾他們的選擇。借用比爾 · 沃爾什，一個領導 49 人隊 3 次進超級碗的一句話，強有力的領導者需要 “承諾，引爆，恢復”，這意味著承諾攻擊計劃，執(zhí)行它，然后看反應結果。優(yōu)柔寡斷團隊只會導致個人努力白費。

2. 盡量自動化。

在技術講座 “規(guī)模化 Instagram”，Instagram 的聯合創(chuàng)始人邁克 · 克里格引 “優(yōu)化最少的操作負擔” 作為一個重要的教訓，領導他的 13 人團隊用戶增長到幾千萬。 產品的增長意味每工程師的操作負擔加重，如用戶跟工程師或者特定功能跟工程師的比率。 像 Facebook 號稱每個工程師支持超過 100 萬的用戶比例指標。

自動化解決方案和腳本去重復執(zhí)行任務很重要，因為它們解放工程團隊，讓他們?yōu)閷嶋H產品工作。確保如有失敗服務自動重啟和方便快捷在流量高峰期替代是在管理大而復雜產品的明智方案。在短期內可以對應用做快速修復，而長期還是要依賴自動化測試，這需要權衡。

Etsy 的的座右銘 “衡量所有，衡量一切”。支持像開源監(jiān)控和制圖工具 graphite 和 statsd 突出自動化 – 即自動化必須由數據和監(jiān)控驅動。如果沒有監(jiān)控和日志你怎么知道什么事情錯了，為什么錯。自動化是困難的。一個后續(xù)的座右銘是 “衡量所有，衡量一切，并盡可能自動化?！?/p>

3. 建立合理的軟件抽象。

我的麻省理工學院教授和本科生研究顧問丹尼爾 · 杰克遜說的軟件抽象的重要性：

“選擇正確的方式，程序化自然而然地設計; 模塊化就是有小而簡單的界面; 新功能在不影響全局的情況下產生。要是搞錯的話，程序將是一系列的討厭的坑：接口很笨拙因為他們無法適應一些意料之外的交互，即使是最簡單的改動將是很難維護 “。

是什么在谷歌讓數千名工程師建立可擴展的系統，是因為他們有非常聰明的工程師像杰夫 · 迪恩和桑杰 · 格瑪沃特創(chuàng)建了簡單，但豐富的抽象，如 MapReduce 的，SSTable，Protocol Buffer 等。是什么讓 Facebook 工程這么支持大規(guī)模，是因為專注于核心，同樣喜歡抽象和簡單，Thrift, Scribe, Hive。是什么讓設計人員能夠有效構建產品，Webnode，Livenode 也是基于同樣的理解。

保持核心抽象的簡單和減少自定義解 決方案，并增加團隊熟悉度和對專業(yè)知識的抽象。日益普及系統像 Memcached，Redis，MongoDB 等系統都是降低建立定制存儲和緩存系統的必要。團隊重點轉移到少數核心抽象，而不是分裂在很多臨時解決方案，讓公共庫更穩(wěn)健，監(jiān)控更智能，性能更易理解， 測試更全面。所有這一切都有助于搭建一個簡單的系統，降低操作負擔。

4. 注重代碼審查，編寫高代碼質量。

維持高品質的代碼庫增加了整個工程團隊的工作效率。清潔代碼更容易便捷發(fā)展和維護，更適應變化，不容易引入錯誤。健康的代碼審查過程使之成為可能。

建立及時代碼審查流程，不管是預提交或提交后，能有幾種方法的提高代碼質量。首先，知道有人會檢查你的代碼，提交寫得不好的代碼可能會辜負你的隊友。那些難以維護，或未經測試的代碼是一種壓力。第二，代碼審查也提供了評審和相互學習編寫更好代碼的機會。

代碼審查更容易接觸到其他工程團隊成員，評論也帶動了 a）增進一段時間內審查代碼的責任感 b）允許團隊成員 – 特別新手 – 觀摩別人的好代碼，c）加快最佳編碼實踐的傳播。

有種說法，靈活的團隊沒多少時間花費在代碼審查而忽視了技術債務，可以很容易地從寫得不好的代碼積累。 在創(chuàng)業(yè)早期就為了完成盡可能多的功能而忽略代碼審查; 其結果是，雖然最初的產品更迅速地擁有了市場，但代碼變得修改痛苦，我們花了一年多時間僅僅是改寫脆弱的代碼，以償還技術債務。

谷歌預先進 行審查所有的代碼，但規(guī)模較小的團隊并不需要那么全面和嚴格，因為不是所有的代碼需要使用相同的標準審查。 公司后來采用后提交的評論通過電子郵件通知核心處危險的變化。我們用 Phabricator 對所有的代碼審查，大多后提交，并采用了不同的標準模型，比如控制器代碼和視圖代碼; 對于敏感的代碼或新工程師的代碼，我們要么做預提交的評論或試圖在幾個小時被提交的代碼中查看它們。

5. 保持一個尊重的工作環(huán)境。

同事之間的尊重構成開放交流的基礎?？孔V的想法獲得往往通過大家辯論，這種挑戰(zhàn)也是感覺很舒服的方式。人們不爽的是重要反饋沒有及時回應。

1948 年，亞歷克斯 · 奧斯本概述了在過去的幾十年中在工作環(huán)境中流行方法，參與者走到一起，拋開批評和負面的反饋，共同凝聚在一起不用擔心被評判，頭腦風暴會議。最近的心理學 研究已經開始推翻奧斯本的做法，表明在頭腦風暴會議，鼓勵辯論實際上避免群體思維并產生更有效的思路。鑒于這一研究，一個尊重環(huán)境變得更加重要使得攻擊僅 僅是觀點而不是個人。

工程往往跨越廣泛的領域（系統，機器學習，產品等），而不是每個人都有相同的專業(yè)知識在每個領域。其實是一個強大的團 隊應該具備，在某些領域都有能干的牛人，即使他們最終會被替代。這有時很麻煩，讓一個系統工程師來評估產品工程師的能力，但在一個健康的工程師文化中尊重 這些差異很重要，并不是完全根據自己的優(yōu)勢來判斷。

6. 建立共享代碼所有權。

雖然有些人自然就成為精通代碼庫或基礎設施的各個部分，但沒有一個人應該覺得他們擁有或任何一件的唯一維護者。雖然有個人一年以上能在一些領域成為專家，在短期內有成效，這種做法最終傷害長期利益。

在組織上，共享的代碼所有權提供了三個好處。首先，保持因子 8 大于 1 可以減輕壓力和降低團隊維護者離開的風險。這也使人很難在休息時間無憂。我清楚記得，當我夏威夷火山上徒步旅行度假時候，得到報警，因為我是公司的日志處理器的唯一維護者。

其次，共享所有權讓工程師不限制在特定區(qū)域，以促進新的見解。它讓工程師們從他們被困在某些項目上離開，并鼓勵他在多樣性項目上工作，這有助于保持工作有趣性，并提升員工學習積極性。從長遠來看，它降低組織風險，一些工程師感到停滯就會決定離開。

第三，共享所有權還設置了有多個團隊成員（從敏捷開發(fā)的一種技術）一起在一個高優(yōu)先級的問題，必要時更迅速地完成戰(zhàn)略目標奠定了基礎。而孤立的所有權，負擔通常落在一兩個人。

很多工程組織犯的錯誤是為時過早將整個團隊分成子團隊。子團隊會形成責任的阻礙，并很難去打破所有權的墻，因為個人可能會被其子團隊的目標進行評估。 有很多小團隊，我很珍惜與一些其他團隊的工作機會; 他們使用敏捷開發(fā)，重心放在共享代碼所有權，使得工作幸福感和生產力更佳。 初期我喜歡的一個方面是更強調項目而不是團隊，讓我有機會合作的項目從用戶增長，機器學習，工具，推薦，分析，網站的速度，和垃圾檢測。

7. 投資自動化測試。

單元測試和集成測試覆蓋率是管理一個大的代碼庫與一大群人沒有不斷被破壞構建或產品的唯一可擴展的方式。自動化測試提供了對提高代碼質量的大規(guī)模重構的信心 和也進行有意義的保護。缺乏嚴格的自動化測試，需要手動測試無論是對工程團隊或外包測試團隊，是容易令人害怕的，很容易陷入恐懼改善代碼的文化，只是因為 它有可能破壞以前的。

在實踐中，自動化測試是對持續(xù)部署工作團隊成長的要求。代碼庫規(guī)模隨著時間的推移增長，但熟悉的代碼庫多少會隨團隊成 員新人加入而減少。測試和驗證是最容易被原代碼作者完成，因為在他們腦子里還是清晰的，而不是被稍后幾個月或幾年嘗試修改代碼的人。鼓勵單元測試是讓作者 為自己工作責任。

8. 分配 20％的時間。

Gmail 是保羅 · 布赫海特的 20％的項目，第一個版本在一天搞定。 谷歌新聞，谷歌公交，和谷歌建議也是推出的 20％的項目。我用 20％的時間，而在谷歌寫一個 Python 框架，使得它更容易建立搜索頁面演示。而谷歌的 20％的時間在創(chuàng)業(yè)初期可能降低生產力，讓工程師們花 20％的時間做某件事情而不是他們的產品規(guī)劃上，仍然是小型工程組織的創(chuàng)新搖籃。

Ooyala 公司沒有正式 20％的時間，我們花了一些時間寫了一個命令行構建工具 Flex 和 ActionScript，加快了團隊構建時間。正當 Adobe 的 Flex Builder 工具降級時候我完成了它，在工程團隊超過兩倍大小時該工具仍然在使用。 Atlassian 公司在嘗試一年后通過 20％的時間。Facebook 后來又增加了一個 20% 時間的變化是周期性的黑客比賽 – 一晚上的事件，規(guī)則是，你可以做任何東西，除了你的正常項目的工作。

自上而下的方法對產品的規(guī)劃，對公司的總體方向是重要的，不能指望從工程師中冒出很多的想法。只要工程師對他們 20％的時間和專注于什么可以有很大影響的負責，這些項目可能會導致很大的向前發(fā)展。沒有官方的 20％的時間，它仍然是可能的，對工程師和設計師可能更難去嘗試瘋狂的想法 – 基本上都找周末或假期做。

9. 建立學習和持續(xù)改進的文化。

學習和得到充分得到挑戰(zhàn)是心理學教授米哈里 · 米哈伊稱之為 “流”，一個人是如此的完全集中在他們做的事情，他們甚至忘了時間。 直接即時的反饋能夠適應更快的迭代周期。

每周技術會議給工程師分享他們的設計或者正工作的項目，創(chuàng)造了一個機會，工程師們?yōu)樗麄児ぷ鞲械阶院?，并學到更多工作以外的范疇。內部文檔記錄電子郵件服務的工作原理或如何讓排名改變搜索服務，讓工程師學習和探索新的東西，也很好地補充了 20％的時間。

建設學習文化的一個辦法是注重指導和培訓，以確保每個人都掌握基本的算法，系統和產品成功所必需的技能。工程組織的成長，花在招聘（尤其是高校招聘）越多， 更多的努力需要投入到指導和培訓。一個導師每天花一個小時為一個新員工的前 4 周工作上似乎是很大負擔，但投資是總時間的新員工將在一年內花費不到 1％，并能幫助到此人是否真正成功。

10. 招最好的人。

雇傭最好的人是許多其他列出的 基礎。如果你認為自己是一個 B 級工程師很難有人尊重。如果你不信任他們開發(fā)產品能力，很難給別人自主權去開發(fā)產品。如果沒有足夠的工程經驗，很難識別正確的抽象去構建系統。這很容易陷 入構建復雜結構的陷阱，又沒有其他聰明人來挑戰(zhàn)你的想法和推動你走向簡單正確的道路。

在硅谷的史蒂夫 · 喬布斯說，“A 等人聘請 A 等隊員。 B 等人聘請 C 等人。“關注招聘和雇傭合適的人很難，但這對工程組織有效增長很關鍵。黃易山，是前 Facebook 一個工程經理和總監(jiān)，認為招聘必須是工程組織的首要任務，不只是管理者，工程師也如此。 他也正確地指出 “雇傭最好的” 和 “雇用你面試過的最佳人選” 的區(qū)別

在初期，我們在客戶工作上不堪重負，我們很想降低我們的招聘門檻，這樣我們可以聘請足夠的人來做大量工作。我很高興我們沒有，因為低質量的代碼和較弱的工程師團隊積累技術債對團隊和產品的傷害是很大的。

建立一個良好的工程文化無疑是一個大量的工作，但由此產生的工作環(huán)境是值得的。

如何在mac下遠程搭建git服務器

您好，很高興能幫助您

首先要有 ssh遠程登陸的工具，比如secureCRT等

方案一 基于SSH直接搭建

Git支持的協議主要是四種：

本地: 需要文件共享系統，權限不好控制

HTTP：速度慢

SSH：同時支持讀寫操作，不支持匿名的讀取(Git默認協議)

GIT：最快

從搭建的難易程度和特點綜合篩選，最合適的還是ssh，并且大部分服務器上基本都有ssh服務，所以省去了不少麻煩。一個最基本的思路是給每一個人一個ssh帳號，這樣大家就可以通過用戶名和口令來訪問了，但是顯然這不是一個好的選擇，這個做法有些多余，并且對于repo的權限很難管理。

在使用Github的時候，會利用rsa.pub公鑰/私鑰的方式，這樣在服務端擁有用戶的公鑰（*.pub）之后就可以，跨過繁瑣的口令，直接認證提交了，而服務端也會根據不同的用戶身份，對其權限有著更加靈活的管理。因此我們也采用這種方式。

服務端

為了使遠程庫訪問更加直觀，先在服務器上創(chuàng)建一個名為git的賬戶，這樣以后clone的時候就如下面的格式了：

git clone git@server:some.git

創(chuàng)建新的用戶，創(chuàng)建repo等目錄

$sudo adduser git

$su git

$cd ~

$mkdir repos

在HOME下的.ssh目錄，如果沒有則創(chuàng)建，創(chuàng)建一個authorized_keys文件，這個文件就是用來管理所有git用戶的公鑰的，也就是這里面的用戶對于項目有著R+W的權限。

客戶端

對于每一個客戶端，我們需要生成一對密鑰和公鑰，如果是Github用戶，那么.ssh目錄下，一定有id_rsa.pub和id_rsa兩個文件，其中第一個是系統生成的公鑰，另一個是自己要保存好的密鑰。如果沒有的話，可以在終端執(zhí)行：ssh-keygen來生成，完成后，將自己的公鑰提交給管理員，這就是一個注冊的行為。

完成

最后一步，管理員將團隊成員的公鑰添加到authorized_keys中，比如將同學susie加入：

$ cat susie.pub authorized_keys

至此，大家可以通過git@server:repos/some.git來訪問公共的版本庫了。

問題

安全問題，成員可以登錄git用戶的shell,細節(jié)權限如分支等不好控制

管理麻煩，新建repo,或者增加成員比較麻煩，尤其是修改的時候

方案二 使用Gitolite服務

Gitolite 也是基于SSH協議構建的方便管理git repo的應用，可以通過其源碼安裝.

安裝

安裝按照官方給定的文檔就可以輕易的實現：

$ git clone git://github.com/sitaramc/gitolite

$ mkdir -p $HOME/bin

$ gitolite/install -to $HOME/bin

$ gitolite setup -pk YourName.pub

如果執(zhí)行最后一條命令的時候，gitolite不識別，則可以通過下面兩種方式解決：

將gitolite添加到PATH里面

通過$HOME/bin/gitolite setup -pk YourName.pub 執(zhí)行

至此，gitolite在服務端，搭建完畢，會發(fā)現此時HOME目錄下增加了一個文件projects.list和一個目錄repositories,后者就是我們的版本倉庫了，每當新建repo的時候，就會在其中創(chuàng)建。

使用

是時候說一下gitolite的管理模式了，他會創(chuàng)建一個gitolite-admin的repo，管理員就是通過像這個repo提交配置文件而實現對git服務器的控制的。

首先，將這個repo導入到我們的workspace：在此之前，需要配置本地的ssh,gitolite要求管理員的本地密鑰和其注冊公鑰的名字一致，比如我們安裝的時候指定 -pk后面為 admin.pub 則管理員本地需要由admin對應的私鑰。我們可以通過~/.ssh/config來進行配置（注：有些系統可以用conf，Mac OSX 下無效，只能用config).

host gitolite

user git

hostname yourhostname.com

port 22

identityfile ~/.ssh/admin

這樣，當我們訪問gitolite的時候就會自動根據配置文件執(zhí)行，配置完成后可以根據下面的命令，將gitolite-admin轉移到本地。

git clone gitolite:gitolite-admin.git

克隆完成后，可以發(fā)現，gitolite-admin下面有兩個目錄，其中conf保存配置文件，我們可以通過編輯里面的gitolite.conf文件，管理git服務器，keydir目錄保存用戶的公鑰pub文件。

當我們講修改后的repo 提交的時候，gitolite就會自動的應用這些配置，管理過程就方便了很多。

配置規(guī)則

打開gitolite.conf文件可以看到其中的示例：

To add new users alice, bob, and carol, obtain their public keys and add them to 'keydir' as alice.pub, bob.pub, and carol.pub respectively.

To add a new repo 'foo' and give different levels of access to these users, edit the file 'conf/gitolite.conf' and add lines like this:

repo foo

RW+ = alice

RW = bob

R = carol

上面的配置文件就是新建了一個repo foo，并且添加了三位項目成員，每一個人的權限不同。提交push后，管理便生效了。

可視化

我們可能會需要一個web界面來管理這些項目，我目前知道的有三種方式：

git源碼中自帶的組件，cgi腳本實現，使用gitolite服務

gitlab開源框架，基于ROR，新版本不再使用gitolite服務

FB開源PHP框架 phabricator，功能高端上檔次

你的采納是我前進的動力，

記得好評和采納，答題不易，互相幫助，

從PM的角度聊聊敏捷開發(fā)

從去年年底開始負責APP的社區(qū)功能，技術實現上用可H5的形式，從APP團隊中獨立出來。以小團隊嘗試敏捷開發(fā)模式的探索，而我作為產品經理，自然也是這個敏捷項目的Scrum Master。

我們團隊的構成為：

這應該算是敏捷開發(fā)中最mini的團隊，而且大部分人還不是完整的一人力投入到社區(qū)工作中，包括我自己。但好在其他人額外的工作也由我這邊管理，從需求排期上我可以靈活支配大家的工作排期，不影響到社區(qū)項目整體節(jié)奏。經過這快一年的磨合，我們的迭代速度從2周變?yōu)?周，也把敏捷開發(fā)流程修改踐行到最適合我們團隊的模式。

有一些我作為產品經理對于敏捷開發(fā)的思考，將其記錄下來。

所有講Scrum敏捷開發(fā)的文章里都很重視團隊每日的站會，“今天做了什么，將要做什么，有什么障礙”的站會三個主題是為了團隊每個人快讀溝通當前的進度與困難，促使團隊更好的協同開發(fā)，認為站會是敏捷開發(fā)中必不可少的環(huán)節(jié)。但是在施行中，站會的效率很難保證，經常變成昨日熱門話題的集中閑聊會，當然也是我這個PM組織的爛。而且因為是彈性工作制，加上北京早上糟糕的交通，召集會議也花很多時間。

鑒于此，我們不再開晨會，而是直接坐在一起。每天需要同步大家進度的時候，直接轉個椅子快速溝通就結束了，而且遇到問題也及時讓同事提出來，大家一個轉身就去看具體問題了。

另外這種從技術、產品、設計的獨立團隊中剖離出來的獨立感，坐在一起能讓團隊成員有項目團隊的歸屬感。除工作以外，大家也更熟悉生活中的彼此，能更好分擔協助彼此完成項目的工作。

在公司開發(fā)流程中最常用的項目協作工具是Readmine。我個人是對傳統的這類軟件開發(fā)時代用的協作工具Readmine、Bugzilla……抱有無限的敵意，因為這類工具經過這么多年的更新，實在是太完善了，太大太全太復雜。并且傳統項目管理工具的受眾是專職的項目經理，產品經理用這類軟件做項目管理太耗費時間，太容易掉到瑣碎的項目管理細節(jié)中。

所以，在我們項目中采用Tower做項目管理工具。類似的看板類項目管理工具如Trello、Teambition、Phabricator、Tower……大多大同小異，找一個自己順手習慣的就好。看板類的項目管理工具最方便的就是拖拽任務，可以在一頁上看清該版本各個任務的進度。另外這類項目管理工具有更好的擴展性，有豐富的插件可以去選擇性集成以提高開發(fā)效率。

在敏捷開發(fā)的流程中，產品經理需要做好項目管理的工作。而項目管理工具是必不可少的，至于如何選擇每個人使用習慣差異很大，可以根據自己團隊現實情況去選擇。總之不要用傳統的項目管理軟件，因為傳統項目管理工具的受眾是項目經理，而不是產品經理。

我們公司沒有UE，產品經理除了出需求，還需要給出交互。如果按照正規(guī)的文檔流程規(guī)范，一個版本的文檔寫完，留給開發(fā)的時間也就不多了。至少在我們項目中，我不寫文檔只出交互，重要的點直接在圖中文字標注。但產品的邏輯細節(jié)，我會在畫交互稿的同時記錄在個人的印象筆記里。好記性不如爛筆頭，盡管不輸出正式的文檔，但產品的邏輯必須明確。畢竟后續(xù)的需求修改、測試用例都基于原始的產品邏輯，產品經理忘記自己設計的東西，無論如何都是說不過去的。

輸出交互稿之后，我會單獨拉上開發(fā)、測試和視覺去開一個會，具體講一下這個需求的設計，傳達本來需要我用文字寫在文檔中的意思。當然不寫文檔，不代表需求模糊，經不起其他人在會上的挑戰(zhàn)。

會上說需求設計的最大的好處是，我能明確的用口語傳達出對需求細節(jié)的感情色彩，哪兒是重點，哪兒細節(jié)體驗要保證，哪兒做成什么樣都行……很多是無法拆分的需求細節(jié)，但是通過言語說出來就很容易被拆分掉，更好地讓開發(fā)容易理解需求重點，加快開發(fā)速度。

一般項目的需求評審一般是產品拉著各個老大來做需求評審，各個老大接了需求后會上評估下工期，會下再把相關的需求分給下面的人做。具體做事的人，往往是接到需求后再啃文檔，自己理解后再去開發(fā)?？偨Y復盤的郵件更是只在產品組內部和leader的郵箱里呆著，根本不會給到每個開發(fā)成員

而敏捷開發(fā)從需求評審階段就必須拉上所有團隊成員，產品經理要把需求場景、優(yōu)先等級、用戶調研……講給所有人聽。然后要在團隊中達成一致，讓團隊所有的小伙伴都認可你的需求，并且愿意主動把這個需求做下去。版本上線后的效果也需要同步給團隊的小伙伴，讓大家都輸出的結果都有反饋，然后也可以聽聽團隊每個人的建議與感覺，再綜合考慮及時調整產品。這些能極大強化團隊的凝聚力，讓每個人并非只是做自己手頭的工作，更有產品的主人翁意識。

這點經驗與我們項目類型有關，因為我們做的是社區(qū)類產品，很多測試的case流程必須要帳號間的互動，久而久之我們團隊在測試階段每個人都演變成了測試。

測試同事寫完測試用例，等提測之后，我們所有人都匯聚在一個小會議室里。每個人分工其中的一些流程測試，快速協助測試走完case，然后快速將bug記在白板上發(fā)到群里備份，一部分需要專業(yè)手段的測試還需要測試同事專業(yè)的方法，大家協助測試的部分主要還是流程測試。快速過完之后，開發(fā)回去解bug，測試同事整理測試報告。遇到重大的bug block版本，大家就直接在會議室里討論預案。

這種快速的團隊測試能極大的提升測試效率，往往測試同事花一天才能跑完的用例，我們四個人在會議室一小時就搞定了，而且因為開發(fā)也參與了測試流程，連問題描述、復現步驟都不用寫就可以直接定位問題。

這點其實是所有開發(fā)排期的都需要注意的問題，只是敏捷開發(fā)更容易暴露這個問題。這里的重要功能，并不是產品優(yōu)先級上的重要，而是開發(fā)難度上的定義。因為敏捷開發(fā)的周期很短，每個重要功能上線后往往需要一定時間進行穩(wěn)定。如果在排期上每個Sprint都有重要的功能，穩(wěn)定上個版本與開發(fā)下個版本交叉，基本上會造成下個版本的delay。

所以在需求排期中，臨近的Sprint要注意功能上的間隔。有的功能干脆就在需求排期中強制拆開，留足穩(wěn)定的buffer。另外，有時候版本發(fā)不出去就不要發(fā)，不要為了敏捷而發(fā)版，那樣就本末倒置啦！我們團隊還有一個約定俗成的事，如果大家齊力克服困難將一個眼看需要delay的版本弄上線了，上線后必須tb大吃一頓作為獎勵刺激，23333~

我們項目經過大半年的敏捷開發(fā)，無論是團隊氣氛還是產品數據都取得了比較好的結果。 與其說敏捷開發(fā)是一種項目管理的方法，不如說是一種切換大家工作角色的方式。讓大家拋開原來的螺絲釘角色，全方位的參與到整個項目的流程中，強化主人翁意識。 讓團隊的每個人切實地認識到自己就是這個產品的主人，主動為產品考慮，主動協助上下游更好地完成目標。

如何在mac系統下搭建theano深度學習

方案一 基于SSH直接搭建 Git支持的協議主要是四種： 本地: 需要文件共享系統，權限不好控制 HTTP：速度慢 SSH：同時支持讀寫操作，不支持匿名的讀取(Git默認協議) GIT：最快 從搭建的難易程度和特點綜合篩選，最合適的還是ssh，并且大部分服務器上基本都有ssh服務，所以省去了不少麻煩。一個最基本的思路是給每一個人一個ssh帳號，這樣大家就可以通過用戶名和口令來訪問了，但是顯然這不是一個好的選擇，這個做法有些多余，并且對于repo的權限很難管理。 在使用Github的時候，會利用rsa/sitaramc/gitolite $ mkdir -p $HOME/bin $ gitolite/install -to $HOME/bin $ gitolite setup -pk YourName port 22 identityfile ~/.ssh/admin這樣，當訪問gitolite的時候就會自動根據配置文件執(zhí)行，配置完成后可以根據下面的命令，將gitolite-admin轉移到本地。git clone gitolite:gitolite-admin.git克隆完成后，可以發(fā)現，gitolite-admin下面有兩個目錄，其中conf保存配置文件，可以通過編輯里面的gitolite.conf文件，管理git服務器，keydir目錄保存用戶的公鑰pub文件。 當講修改后的repo 提交的時候，gitolite就會自動的應用這些配置，管理過程就方便了很多。 配置規(guī)則 打開gitolite.conf文件可以看到其中的示例： To add new users alice, bob, and carol, obtain their public keys and add them to 'keydir' as alice.pub, bob.pub, and carol.pub respectively. To add a new repo 'foo' and give different levels of access to these users, edit the file 'conf/gitolite.conf' and add lines like this:repo foo RW+ = alice RW = bob R = carol上面的配置文件就是新建了一個repo foo，并且添加了三位項目成員，每一個人的權限不同。提交push后，管理便生效了。 可視化 可能會需要一個web界面來管理這些項目，目前知道的有三種方式： git源碼中自帶的組件，cgi腳本實現，使用gitolite服務 gitlab開源框架，基于ROR，新版本不再使用gitolite服務 FB開源PHP框架 phabricator，功能高端上檔次