架構組織管理的五大原則：構想、節奏、預見、協作和簡化
架構組織的三在概念：準則、模式和反模式
準則：為了把原則運用到實踐中，需要實施細節。準則把廣泛的原則翻譯成是否和如何執行原則的細節。
模式：描述了開發或者使用軟體架構時可能遇到的常見問題的解決方案。
反模式：反模式描述了組織在實踐中可能遇到的陷阱，描述了不該做的事情，或者用在錯誤背景下的解決方案。
一、構想
說明了如何向架構的受益人描述一幅一致的、有約束力和靈活的未來圖景。構想需要維持一致性和協調性（靈活性）。
【其實就是和客戶及開發團隊保持一致，同時考慮擴充套件，為了更好的保證一致性可以使用rup的「4+1構架檢視」（邏輯檢視【使用者】、實現檢視【軟體開發工程師】、用例檢視【系統分析人員】、程序檢視【軟體整合工程師】、部署檢視【軟體工程師】）】
【理解客戶迫切價值；將客戶價值對映成能解決問題的解決方案；將以上問題轉成一組特定的約束條件】
驗證構想準則：
1、架構師的構想與發起人、使用者、最終客戶期望實現的目標是否保持一致。
反模式：風險後置 【先分析問題將可能存在的問題先找出確定可行性，應該主動向上層提供乙個選擇】
模式：前後一致 【架構是多使用者使用，有特定的使用者需要特定的功能但可能會破壞架構質量和穩定性，應該將上級拉入架構構想中讓他們知道風險】
2、實施人員信任並使用架構。
反模式：牆頭草【確定了構架以後要對架構作任何加入都應該開休討論會對新加入功能進行審核，避免開發人員的對開發人員對架構的不信任應該及時兌現承兌】
模式：三人臭皮匠【架構的思想並非只來自己架構師，高階提供構想，架構平台留給架構師，實現細節留給開發人員】
3、關於架構和構件的潛藏知識對其使用者是可見的
反模式：一葉障目【知識共享（培訓、專題討論、啟用知識管理平台）】
模式：輪流工作
【總結：構想是架構搭建的關鍵也是思想上大家統一確定如何實現目標的架構，此步驟的關鍵在於將上級和下級的發動，上級確定目標，下級確定細節，保證需求一致正確。最後就是知識的共享，這樣增加團隊凝聚力。建立乙個學習型應用合併的團隊，有必要時應該工作輪轉（解決學習和管理）】
二、節奏
節奏原則：刻畫了一種在整個組織範圍內的協調程度，即定期地根據可**的速度、內容和質量對製品生產進行檢查與規劃。
【節奏是乙個架構團體內部及它與客戶和**者之間反覆出現的、可**的工件交換活動，其實就是控制架構開發的進度及解決出現的問題和客戶和開發團隊】
準則：1、定期地再評估、同步和調整架構。【定期討論會議，及時討論問題解決問題】
反模式：一步成功 【乙個架構的發布不是只針對現在或特定功能，它應該是乙個完整性的、系統性的架構。如果存在市場機遇的時候可以先發布乙個圍繞特定功能，利用此主題抓住市場。再發布系統版】
模式：發布委員會
2、架構使用者對架構發布的進度和內容具有高度的信心。
反模式：超敏捷【高層管理的行動更直接地改變組織行為時組織行為不能得到嚴格的遵守】
模式：舍兵保帥【當乙個架構發布不能按預期階段發布時，應該主動與客戶溝通，將不太重要的特性移到後面發布週期】
3、通過節奏協調明確的活動
反模式：銷售未檢驗的產品【問題不能積累，定期建立應該的成功】
模式：同步發布【與合作夥伴一起確定交付架構特性的先後順序】
【總結：節奏它強調的是乙個按計畫進行。不能讓問題積累，出現問題應該立刻解決。當時間有衝突時應該舍兵保帥，制定制度嚴格執行（架構定期評估、避免高層改動）架構應該是乙個長期的系統的穩定的】
三、**
要在**未來與檢查並適應現狀之間做出平衡
準則：1、預見風險、預見客戶、預見客戶的需求、預見市場驅動標準和演變技術、預見戰略業務方向的改變
反模式：遺漏細節【其實就是需求的不全面，讓業務專業參與，調研覆蓋面很重要】
模式：示範區【大面積推廣前先進行實驗】
2、通過快速複審和開發周期，評估技術和業務上的風險與機會
3、當認識到關鍵的估計或假設有錯時，及時調整功能特性、預算
四、協作
1、架構師不斷地了解誰是最關鍵的受益人，他們如何貢獻價值，以及他們需要什麼
反模式：光說不做
模式：了解你的受益人
2、受益人之間達成明確和強制性的契約。
反模式：不記錄討論結果
模式：互惠互利
3、通過社會行為制度和非正式規範強化合作。
反模式：非正式時間做正式工作
模式：和hr密切和作
【總結：協作其實就是管理以及和客戶打交道，了解他們需求，將達成的契約強化（記錄）另外就是和下級開發人員的協作及各種旁類資源的協作】
五、簡化
簡化是指將所作用組織與環境都進行巧妙地理解與最小化，組織形成架構並且思考架構。
準則：1、開發人員長期使用架構，減少總成本和複雜性
反模式：簡單複製並修改
模式：由慢而快
2、架構小組明確理解關鍵最小需求，並且將其構造成多應用共享的核心元素
反模式：缺乏有效抽象【每次加入時避免出現榕樹、根部肥大】
模式：遷移途徑
3、通過長期的預算和行動確保當相關元素沒有被共享、增加了不心要的複雜性時或者是因為有明確的業務理由時，把相關元素從核心移走。
反模式：編碼大於架構【把首席架構師的埋單合理分配給實現新特性和調整架構兩個任務，讓最能幹的工程式師來領導實現新特性】
模式：統計構件變更
【總結：簡化其實關注的就是**的簡化，可使用設計模式進行抽象等】
艾偉也談專案管理，如何管理「人」
我們常說工作中應該 對事不對人 但事都是人做的，不同的人做相同的事效果可能相去甚遠，再好的業務如果用錯了人也會全盤皆輸。正所謂 事在人為 嘛，識人 用人 聚人是乙個團隊管理者獲得成功的基礎。先說怎麼認識人 人格矩陣法。即所謂的topk技術，topk就是由 tiger owl peacock 與 ko...
艾偉也談專案管理，微型專案實踐感悟
微型專案是指絕大部分工作由乙個人員負責的專案，這個核心成員負責專案的系統分析 構架 及絕大部分的編碼工作。專案的持續時間一般不會超過乙個月。專案的參與人員除了核心的程式設計師外還可能一部分輔助人員，包括第二程式設計師 負責一部分編碼工作 美工 負責介面設計 等。微型專案的規模一般很小，業務邏輯也比較...
艾偉也談專案管理，大專案的思考
引言 進入現在這個我們內部號稱 豪門 的專案已經兩個多月了。現在回想起進入專案前一位前輩的話 大專案有大專案的問題，但大專案也有很多東西可學 自己此時深表贊同。兩個月的時間，自己從剛來前兩周的觀察學習，到現在的基本融入，在這個過程中自己有了很多的想法和思考。為什麼測試這麼難寫？tdd的開發實踐保證了...