成為乙個小團隊的teamleader半年多了，有成功的喜悅，也有失敗的苦悶，無論如何，是該總結一下了。
*關於計畫
作為乙個小團隊的leader，專案的計畫分成兩個部分，專案計畫和進度控制，事實上在我經歷過的或者我觀察過的（我的或者他人的）多個專案當中，往往最常犯的毛病就是有計畫沒控制，甚至是沒計畫更沒控制。事實上兩部分相互相成，乙個糟糕的專案計畫必然導致糟糕的進度控制，但有好的計畫而糟糕的進度控制則會導致一切努力化為泡影，領導不滿意，團隊成員多怨言，上下不討好裡外不是人。自己曾經也多次地經歷過這種鬱悶，甚至一度想放棄，最終還是堅持了過來。
1)專案特點總結：一般目前處理的都是一些短時間迭代的任務（周迭代），每個迭代相對比較簡單
2)時間評估：良好的開端是成功的一半， 在專案的開始時，首先仔細地進行時間評估，盡量地細化任務以獲得更好的時間控制。此階段非常地重要，評估的失誤往往導致進度過緊，而人在疲倦的時候更是往往錯誤不斷，最終導致整個計畫失去控制。我的經驗是，在一切任務開始之前，一定要跟相關人員將業務溝通地非常清晰，此階段的乙個小錯誤，將導致後面的全面被動，在溝通完畢之後，由開發人員評估時間，之後根據經驗得到乙個正常的評估結果。這個過程中最容易犯的錯誤就是,一是開發人員對時間評估往往非常地樂觀，因為他只看到了開發的這個過程，關於這個問題，我把評估時間段分為：溝通時間、設計和開發時間（包括自測）、聯調時間（跨團隊甚至是跨公司）、發布beta測試時間，跟開發人員強調每個過程可能會發生的時間，在這些時間的基礎上，再乘乙個緩衝基數，得到最終的評估時間，儘管如此，在不少情況下，還是出現了需要加班才能夠完成的情況，這個確實是需要繼續總結思考的地方；二是對一些任務，往往領導規定了時間，這種情況下都是非常地被動，只能根據時間來定計畫，往往這種情況下更需要保持清醒地頭腦，更細緻地進行計畫，而一旦發現偏差太大，則必須強烈拒絕，否則最終的結果也不會是領導期望看到的，在這個問題上可以說是犯了非常多地錯誤，對困難估計不足，過於樂觀，屈服於領導的意願，看來這方面還是得繼續加強。
3)與第三方合作：多次與第三方進行了合作，也總結出了下面的經驗；在開始階段雙方定義好業務流程圖，並指定每一步驟由哪方完成，並形成文件; 在開始階段根據業務流程圖定義好所有的介面，包括介面引數和返回結果，並形成文件; 在定義完業務流程圖之後，出原型（包括介面原型、郵件原型等）; 定義好雙方各個時間點，包括stub測試程式發布時間、介面文件提交時間、某業務點發布、出原型時間、 聯調時間等等; 控制變更。其實在與第三方合作最困難的一點就在於，對方看不到如上這些控制的好處，思維不在一塊，往往會導致在後期還在不斷地調整，一整個就搞地非常地鬱悶。
4)過程控制：控制整個過程，我的經驗是從控制各個時間點，必須把各個重要的時間點和產物定義地非常地清晰。目前主要定義的時間點和產物包括：需求確認完成階段--最終確認無誤的需求文件（包括原型和相關的模板之類的），提交測試用例--評審後的測試用例，設計時間點--設計溝通（比較簡單）或設計文件（比較複雜），開發、自測時間點--**、自測的結果excel列表（根據專案的特點而定）、版本和變更說明，beta測試--測試報告，發布。此外，目前的做法是每天花二十分鐘了解一下專案的進展情況，並一再跟專案團隊成員強調，一旦發現進度偏離，必須馬上反映。
5)變更控制：無止境的需求變更往往就是專案進度控制的掘墓人，剛開始最容易范的毛病就是，往往不加以評估就隨意地答應業務人員的需求變更。現在的做法就是，發生需求變更時，進行仔細評估，是否會影響專案的進度，往往對一些無傷大雅的需求變更則大方答應，樂地做好人，但一旦發現對進度會產生影響，一般的做法就是，向業務人員建議，要麼下個迭代處理，要麼砍去目前已有的功能。經過這些溝通，往往業務人員之後對業務的變更會更謹慎。
6)持續迭代：對於有些任務，會使用短週期、多次迭代的方式進行，在這種專案中，我碰到的最常見的問題就是，往往到下乙個迭代開始之後，才開始下個迭代的準備工作（需求了解、設計及相關工作），而往往每個迭代週期的時間又非常地短暫，導致開發和測試時間不足而引發其他的問題。最近總結的結果就是，對這種短週期多次迭代的專案，開發測試和下個迭代的準備工作同步進行，確保在每個迭代開始之後，相關的工作已經就緒，當然，這是比較理想的情況，在迭代準備工作需要涉及外部配合的情況下，會有一定的障礙，不過，盡快地推動開始，相當於拉長了每個迭代的開發和測試週期，能最終為計畫騰出更多的緩衝的時間，同時也能更好地保證開發質量。
*關於質量
專案最終產物的質量將決定了整個專案的成敗的結果，因此，如果在專案的過程當中去保證質量致關重要，我的經驗總結是，
1)流程中的質量控制：控制各個點的質量，以保證最終的質量：一是需求質量--我一般都會跟相關參與溝通的人員一再地強調，謀定而後動，必須想清楚想明白點滴確認好，不要匆匆忙忙地動手，現在一般都會非常仔細地去了解需求，對不明確地需求要求業務人員確認，通過此輪準備，重要的失誤不會在最後才被發現；二是測試用例--要求所有的相關人員參與測試用例的評審；三是設計--設計完成之後必須進行溝通，不允許在沒有經過相關人員地確認就匆忙開始；四是開發和自測--盡量地提交測試excel報告、teamleader對**進行codereview；五是beta測試--提交測試報告。
2)人為因素的質量控制：首先，質量控制是基於準確的時間評估，因此必須在開始階段保證了時間評估的準確性，過緊的開發進度容易導致人的疲勞，人的疲勞又常常導致過多的錯誤，導致質量失控；其次，在團隊成員上，不斷灌輸質量的理念，讓他們了解到質量的重要性，並積極參與質量保障措施（譬如測試excel報告）；最後，灌輸分清主次的觀念，要求他們在時間緊迫地情況下，保障重要功能重要問題的質量。
事實上說的這個過程會過於理想，在實際操作中往往有非常多的意外情況發生，這也是需要不斷地去提高這方面的技巧。
*團隊建設
如上的說明更多地是在規範和流程上去控制好整個團隊的工作，事實上，人的因素非常地重要，個人的主觀積極性和能力，往往能夠能大大提交團隊地開發效率，目前在團隊的建設上，我主要採用如下的措施：
1)培訓：工欲善其事,必先利其器，只有整個專案團隊成員能力的提高，最終才能推動整個團隊的素質的提高，因此在培訓上的投入可以說是非常地重要，在後續中，也必須繼續加強這方面的安排。
2)構建團隊和諧地氣氛：這一點感覺做地還是非常地不錯，整個團隊的氣氛比較輕鬆和活躍，基本上每個成員之間都能夠彼此相互幫助，並感受到在這個團隊中的快樂，積極做事，快樂工作。當然，該放鬆時放鬆，但該嚴肅時必須嚴肅，特別是在專案進度上，是絕對不能討價還價，實在不行就得加班，當然，在兄弟們加班時，一般都會與大家一起奮戰到最後。
3)鼓勵：每週例會，現在一般強調地最多的就是兩點，一是總結，要求團隊成員總結本週工作情況、提出個人想法，其實一般這種並非是需要了解他們的工作，而是鍛鍊總結能力和口頭表達能力；二是自由發言，鼓勵他們提出自己的想法。目前這個方面做地還是遠遠不夠的，看來還得繼續加強啊。
關於團隊建設方面，現在能做的還是太少，看來接下來得多花點時間多思考這方面事情。
半年的時間是非常短暫，總結出來的東西還是很淺薄，路還很長，希望之後能夠更多地學好這方面的知識，以期做地更好
半年簡單總結
一轉眼到這裡也半年多了。得 跟隨乙個固執的老大實踐了一些軟體工程的過程。老大比較固執也是乙個好事情，比較堅持原則。學會了怎樣使用狀態機來幫助實現處理複雜事務。這裡的管理還是比較嚴格的，所有的過程都有標準需要遵循，因此在編碼方面也養成了好的習慣，至少從編碼風格和標準上是這樣的。學會了簡單使用clear...
半年知識總結
mysql匯出 mysqldump t cyou cms uroot p community image user info c user.sql 資料庫授權 grant all on database to root identified by password with grant option...
工作半年總結
在不知不覺也工作了半年了,剛出去找工作的時候,別提心裡有多不安了,現在對於找工作是已經不畏懼了,不管工資怎麼樣,工作是肯定找得到的.所以下面總結一下半年來我有哪些地方是我自己覺得進步了 進步的地方 1.編碼水平在不斷的穩步 可以達到中級程式設計師的標準.我的工作其實還是挺輕鬆的,但是我也是那種對co...