面試的時候了解到的情況：
團隊專案實際情況：
看起來問題還真不少，但是來了就不能逃避，總歸還是得解決問題啊。
現在回想起來幸好本人有敏捷思想和迭代開發護身符：）現在專案還算成功，經常被老外點讚，也已公開展出，明年開賣。下面看看怎麼解決的吧。
扭轉局面，步步為營：
惡補行業知識：
本人在加入該公司前對該公司的業務和行業知識了解基本為零，導致在交流功能和問題的時候很吃力，不知道很多術語是什麼意思。
這個不知道肯定是不行的，然後到處尋找領域知識的文件，聽到陌生的術語然後到實物上去對應，甚至還讀了一本很厚的行業（英文）書籍
給交流溝通打下了良好的基礎。
加強跟產品經理（po）溝通, 了解客戶需求和滿意度：
首先和po了解一下他對於現在專案的看法（不是很滿意，專案進度很慢，軟體基本不工作），以及對於產品的未來期望（期望很高，市場很大）。
了解了下中國這邊情況：中國這邊不大願意和po溝通，因為認為po沒有把系統明確，沒有把需求文件寫清楚。
雙方僵持不下，專案進度只能推遲。還好我有敏捷思想：）
我首先仔細閱讀了一下寫得很膚淺的需求文件，大概了解了下整個系統的需求，然後將這些膚淺的需求輸入到了tfs中，做成了feature和product backlog.
對於不明確的地方專門找po開了幾次會議，他說我寫（一般po不願意自己寫，願意說想法）初步把product backlog的描述填上了，格式當然是as a , i want so that
描述好了當然就是排優先順序咯~~ 有開了一次會議把優先順序給排好了。
有了比較好的product backlog，專案就可以脫胎換骨的重新開始執行了。和po約定好了是兩個星期為乙個sprint的迭代，第乙個sprint我們（可以不用promise那麼多，但是一定要可以交付），結果是我們成功的交付了：）po也很開心
這樣給後面兩年的持續交付，打下了良好的基礎。
這裡要記住敏捷的另乙個超級 超級 超級重要的點，每個sprint要有可執行的軟體和潛在可交付的產品。
每次互動我都讓團隊成員演示自己開發的部分，讓他們有成就感。每次review都會記錄會議的comments，結束之後我會發給po和團隊所有的人。我還鼓勵團隊成員積極和po用郵件和面對面交流，開始他們都比較shy，我就帶著他們
降低耦合功能分塊，充分調動能用的資源：
首先我發了幾天時間看了下系統功能和**，不懂的就問問（h）和（n），問問現在系統是什麼樣個狀況，是不是有些不合理的地方。
然後召開了乙個會議大致了解了一下，系統架構。很快我就發現其實系統是分為客戶端，伺服器端的，他們之間是通過資料庫作為互動，當時我就反覆確認了這個架構。
架構確認了之後，竊喜：）當場做決定，客戶端以後油（n）複雜，服務端和資料庫由（h）負責。（h）發現沒有人動到他資料庫，他也是放心了。
就這樣（n）的資源被有效的調動起來了，而且ui上wpf大家都是新手，他上手也很快，最後做出來的ui非常漂亮，po也很是滿意。
看來當初這個決定做對了：）
功能點各個擊破，迭代開發，持續交付：
還記得我剛進公司的時候（h）說系統功能都好了可以beta測試了對吧。其實（h）就是拿著國外的老系統，照著很膚淺的需求文件，東改一點，西改一點，然後以為就好了：）
事實證明根本沒有乙個功能是能用的~~ 當然他是不會承認的，寫軟體的都不會承認自己做得不對，做得不好。我只能繞著彎說，po對於系統有了新的需求，我都記錄在tfs上了。
那我們這個重新找個機會把所有的功能都理一遍吧，理一遍他當然答應了。
這樣我就按著tfs上product backlog的優先順序開始「理」系統功能了，在最開始的兩個星期迭代中（h）對於這種各個擊破的思路很是不能接受，在開發a功能還老是想著b功能，總是說你這樣只考慮a不考慮b是不行的，
系統以後會有問題的。
我只能不願其煩的解釋，不能東打一槍，西打一槍，一定要focus，focus，focus，記住了敏捷中經常提到的專注力就是這個意思。
乙個有著所有功能但不能工作的系統是沒有用的，還不如乙個系統只有幾個功能，但是這些功能都好用~~ 說了幾次之後（h）總算是答應了~~
在集中開發某一兩個功能的兩個星期後，系統總算有部分功能可以無大問題的工作了，po也很開心，提出了一些改進建議，我們再改善，再迭代~~ 如此反覆也就成了現在的模式。
引入衝突，發現系統薄弱點：
國人很害羞，有想法不敢說藏心裡。國人以和為貴，即便有不同的意見也不說，藏心裡。國人公事私事揉成一團，公事吵架了怕傷了和氣影響同事之間私下的感情，有想法不敢說藏心裡。
但是在多年丹麥文化和敏捷思想薰陶下的我，毅然決定了引入衝突，我堅信真理只有在衝突和討論中才能浮現。
當然敏捷給了我們乙個很好的工具，daily standup meeting（每日站立會議）。再完成了 每日會議儀式性的3個問題之後，就進入了我們的fighting時候。
有個現象告訴大家，人在吵架的時候都會喪失理智，所以你說什麼即便是對的，有人也會據理力駁，即便是歪理~~
但是好的結果是，過幾天當大家冷靜下來思考時，真理就慢慢浮現出來的。
剛開始大半年我們基本是9:30開會，吵到11:30 吃飯，定時開吵。也成了公司的一到靚麗的風景線~~ 當架構慢慢穩定了，我們的爭吵現在也少了，其他部門都不適應了。總覺得少了點什麼：）
大半年每天開吵，當時（h）多次提出，天天這樣吵半天我們還要不要做事？我每次的回答都是：與其天天做正確的事（低頭寫**），不如把事情做正確了（正確設計架構，發現解決潛在風險和問題）。
事實證明開發進度並沒減慢，po也很滿意我們的產出，po也希望拿到的是穩定的系統。
改變思想，引導重構：
很多人沒有經過系統的培訓或大公司薰陶的人，**功能能完成，但是**風格是五花八門，像個垃圾堆，我稱之為「野路子」。
開始我定義了一些coding standards， 但是大部分人是文件看看就扔，還是我行我素。 這個要改變真的很難，特別是在專案壓力下，花時間把「野路子」變成「正規軍」。
我也只能一點點的促使改變，比方**對齊，負責**注釋，大功能切分，減少copy & paste，還有命名注意規範，這些都是最基礎的。
剛進來的時候還想有時間要使**面向介面，測試驅動開發。不過現在還沒實現，在團隊物件導向都不怎麼了解的情況下這個暫時很難實施，所以有些東西還是要面對現實的。
現在能做的是在專案比較空閒期的時候，督促他們刪掉無用**，整合功能，提取可復用**進行封裝。
時不時發一下best practice，或者挑戰下他們明顯的**問題。
重構之路還很長，壓力還是很大~~重構，重構，重構很重要！xp裡面也有提到吧~~
對了，還有很多人比方（n）一上來就想重構架構，說現在架構這裡有問題，那裡有問題，重構一下幾天就能搞定。
我只是想說，越是年輕的程式設計師越是樂觀。重構架構聽起來很美，實施起來不容易，特別是在專案進度壓力之下，慎重考慮。
我是準備第二版有時間的時候再重構架構了，而且架構這個說實話這個詞真的說出來簡單，動起來超級複雜（除非你第一版設計就留足了靈活性，要知道這個專案我是半路殺入還是帶了一幫oo思想不熟悉的人）。
如果你真的理解了架構這個詞的話，模擬的感覺應該是相當於把房子推了重建~~
其他：
和許多其它團隊一樣，我也經歷了原來的軟體主管回歸和團隊成員的離職。
現在情況是原來的軟體主管歸到了我的旗下，我們合作得還很不錯。
由於專案比較緊，離職的團隊成員我們採取了類似外部的性質，做到專案結束。
我給他定功能交付時間，他定期來公司了解需求和討論。
新的挑戰：
日本作為第三方加入，提出系統改進需求：
日本人來了！！！
日本人作為大股東開始插手專案了，時不時的找我提出一些系統需求，怎麼辦？
敏捷思想再次用到，單一po！！！
我總是會把他們的需求記下來（表示友好，重視），然後告訴他們這個需求你需要和我們原來的po商量是否加入，以及由po來排優先順序，找我沒用。
我只能了解你的需求，要不要做我不做決定！
整個專案做下來，發現敏捷思想真的可以解決很多難題，一切都是那麼的順暢和自然。
希望大家改變瀑布思想，擁抱敏捷，擁抱變化，迭代開發，每個迭代都有可交付產品。
po希望玩真正的東西，而不是一堆設計文件和不能交付的藉口。
好吧說兩句對日本人的看法：
哈哈哈哈~~ 2015 最後一天，暫時就寫這麼多了 ：） 希望你們喜歡我碼的字~~
VS 2015專案打包
之前專案需要打包，在網上找了教程，都很完善，補充一些步驟如下 一 僅在加入專案檔案步驟下作如下補充 兩種情況 1 在專案不包含資料夾及問價夾裡面的內容 直接新增所有檔案即可 若有額為需要註冊的dll新增檔案，新增檔案，並設定為主輸出即可 2 專案生成資料夾下有資料夾的 需要在新增專案檔案的目錄下，選...
S1專案 敏捷實施
s1專案採用敏捷實施方法，分三個迭代完成。之所以棄用瀑布式，原因有三。一是管理原因，業務前期無法參與，先平遷，再根據業務需求，迭代優化 二是公有雲saas，產品適合迭代實施 三是傳統it學習網際網路，向敏捷靠攏，以此專案作試點。計畫迭代1和迭代2，將oa系統相關功能遷移，迭代3上線新模組，同時對遷移...
第11周專案6 回文，素數
問題及 檔名稱 test.cpp 作 者 陳文青 完成日期 2014年11月11日 版 本 號 v1.0 問題描述 編制乙個函式reverse，返回給定資料的 反序數 例如輸入1234，輸出4321。請編制reverse函式，在下面 的基礎上補充相關的部分，實現要求的功能。程式輸入 乙個整數，m 程...