現在，如果有人問我要不要在專案中實施結對程式設計，我會第乙個站出來大聲地說：「堅決要實施結對」。
這個專案初次嘗試走敏捷，從一開始對敏捷的不了解，團隊成員的點滴摸索，到中間的漸入佳境，到最後的打回類cmm的原點，這種在乙個專案中「大起大落」的經歷使我倍加愛上敏捷，倍加懷念結對走過的日子。
專案啟動初期，沒有嘗試結對程式設計，還是走cmm的老路子，乙個人分配乙個任務，然後各自拿著領到的任務，開始「孤零零」地在自己的電腦前埋頭苦幹：造**、做測試、改問題，還好是專案初期，大家心情都比較輕鬆，不覺得枯燥無味，不覺得累，就這樣走過了敏捷的摸索階段。
到了第二個迭代，由於有了前期的摸索、經驗教訓，大家知道如何劃分story、task，知道乙個task必須控制在一兩天就能完成的範圍內，然後就有人提出嘗試結對程式設計的想法，就這樣揣著「先嘗試下，不行再按老路子走」的策略開始走上了結對的路子。不試不知道，一試整個團隊都愛上了這種開發模式。
和很多xp書上介紹的一樣，兩個人一台電腦，兩個人一起討論實現的細節，然後就編碼，乙個人在敲鍵盤，乙個人在旁邊「盯」著。負責「盯人」的人發現敲出的**有問題，就立即指出來並討論，然後「盯人」的操作滑鼠選中有問題的**，敲鍵盤的開始改選中的**，有時「盯人」的人直接奪過滑鼠鍵盤直接操刀寫**。敲碼人在編碼過程中，盯人的人也有時間去進一步思考細節，如邊界情況是否處理了等，當然敲碼人也經常會在敲碼過程中提出疑問。就這樣兩個人邊編碼，邊討論，一起解決問題，質量提高了，整個過程大家也很愉悅，因為不再是「孤零零」乙個了。結對也讓人更加高效，更加專注，沒有了經常間歇性的檢視郵件的功夫。
實施結對，結合合理的task週期的制定，更能提高團隊成員的戰鬥力，因為每天或每兩天就能有乙個任務、功能完成，這使得大家每天都很有成就感，大家都喜歡上了這樣的韻律與節奏。
雖然中間實施結對使團隊的效率高了很多，但由於在前期摸索過程中欠了一些「債」（一些本該在前面完成卻沒有完成的工作），感覺有點「一著錯，滿盤皆錯」的感覺，這些債一點點的拖到了後面幾個迭代中，外加對測試工作投入的不充分等等因素，專案到了後面一兩個迭代，不再實施結對，又走回了單兵作戰的路子，大家又是「孤零零」的作戰單位，我自己覺得效率低了不少，編碼過程中由於沒有人「盯」，經常出現一些低階的問題，而且也沒有了那種一兩天就能完成乙個任務，有功能出的節奏，所以現在我深深地懷念那些結對的日子。
我倡導專案中自始至終都實施結對，不管是編碼、還是解決問題，我認為都可以結對，兩個人的智慧型絕對比乙個人的大，考慮的問題絕對比乙個人全面。從我們這個專案的實施中看，結對絕對不會是效率的瓶頸，結對只會提高效率、提高質量。而且通過結對，可以提高團隊的技能，在結對的過程中，結對雙方可以互相學習、分享設計、編碼經驗。
不過，結對的過程也要注意配合方式，否則就有可能會出現「怠工」的現象，尤其是那種對系統中原有功能進行擴充套件或者改造，且結對的兩個人中有乙個人對該功能比較熟悉，而另乙個沒有接觸過該功能的情況，這時如果光顧實現的話，那麼熟悉的人就會在電腦面前猛敲**，另乙個人在旁邊只能乾瞪眼，這樣子就失去了結對的意義了。在這種情況下，實施結對的過程更應該注重「互動」，可以由熟悉該功能的人先講解下該功能的已有實現以及後面打算如何進行擴充套件、改造，雙方訂下實施方案後，由不熟悉該功能的另乙個人來編寫測試用例（ut），這樣可以增加它對該功能的了解，然後由熟悉該功能的人來實施編碼，最後由寫測試用例的人來跑測試**，通過這種方式，一來達到完成任務的目的，二來也培養了可以維護該功能的後備人員，一舉兩得。
跌跌撞撞地敏捷之路 及時記錄經驗教訓
日期 2009.03.23 今天又是乙個周一，scrum master每週一都需要做專案週報，向上及周邊相關人報告專案在上週的進展。在這個報告中有經驗教訓這一項，這裡需要在上一周中專案開展過程中團隊成員作出的經驗總結 優秀實踐 出現的問題及規避方法。scrum master早上就開始問 大家回想下，...
跌跌撞撞地敏捷之路 為什麼進度那麼慢
日期 2009.03.25 今天的站立會議花了我們不少時間，原因大家覺得如果不花點時間分析下原因，並找出對策，極有可能會影響sprint的交付。目前的狀況是 這個禮拜sprint就要結束，可實現的功能頂多只有一半。1.沒有按照story優先順序來完成story 按照昨天晚上我們的初步分析，乙個原因是...
2014 跌跌撞撞
又是一年，想起上次做總結還是在大學畢業的時候，那時候是感概萬千，給自己定了n多目標，轉眼一年半過去了，回想起當初的目標，有幾個是真真切切實現了的。這一年，過的還算充實，去年的這個時候，剛上完專業課，被boss叫來跟師兄的畢設，那是自己第一次接觸科研這個東西，以前我總覺得搞科研是乙個很神聖的事情，可是...