去年11月，在導師的建議下，自己基於對網際網路產品/專案過程的理解和實驗室參與專案的經歷，以圖標的方式簡單完成了針對實驗室團隊情況的專案過程，命名之為「自郵之翼」專案過程。（自郵之翼原本是實驗室內部專案的名稱，後來亦漸漸成為團隊的代號了）。
首先，從實驗室團隊的特色出發，我們需要乙個過程去提高專案的可控可管性，同時讓我們適應網際網路的步驟。團隊成員，除了老師便是學生，基本在實驗室工作1.5-2.5年（保研的多大四那一年），人員變更快；先前沒規範過程的時候，專案的管控過分依賴於人，而由於人員變更快，管控的質量是很不穩定的，都是各人實驗性地嘗試，也沒留下什麼積累。同時，我所在的團隊更多去做網際網路相關的專案，在這方面經驗少，亦需要乙個過程幫助我們去理解網際網路專案的過程，如迎合快速迭代，快速原型等特點。所以，希望能有總結出乙個過程，幫助我們團隊理解網際網路過程，彌補成員變更快速等團隊特點帶來的影響，同時綜合兩方面特點提高專案的效率和速度。
其次，從學生自身的培養看，對專案過程有乙個清晰全面的理解和把握有利於個人綜合素質的提高。從專案中鍛鍊技術能力固然重要，但這個主要是靠自己的；除此之外或者說專案經歷給我們更寶貴的財富應該是對專案過程的理解和把握。如果參與了不少專案，但還不知道專案從開始到交付甚至運維/迭代是如何乙個完整的過程，可以說，從專案經歷而來的收穫是會大打折扣的。而且，在學生團隊中，我們真的有機會去負責乙個專案過程的管控工作，同時有機會犯錯！我們提出乙個過程，不是基於空想，亦不會提出後停留在理論階段不進行實踐，我們是真真正正去以之實踐，過程會基於實踐有反饋，會更新，會積累，會傳承的
再次，還有許多小好處，比如帶新人容易了，更方便交接專案了，等等。
「自郵之翼」專案過程，是針對5-15人團隊規模和偏向網際網路應用/產品的，重視快速原型和迭代反饋的敏捷過程。（注：團隊規模講是的現實中我們的專案組團隊規模，但從過程圖看，並未體現團隊規模）
概要圖（只描述階段和階段的重要事件）和總圖（細化，體現角色的職責和協作，等）如下：
（注：版本1.1，更新於2012.2.15）
一、快速原型
其詳細過程如下圖描述（借用2月做團隊專案介紹會中自己的ppt，偷個懶。。）。從資訊結構圖到低保真原型到高保真原型，及其階段所使用的工具和成果，都有描述。
在最新的一次原型中，我們並沒直接使用axure，而直接通過我們新完成的前端頁面框架，完成簡單原型，節省了從axure原型到工程靜態頁面的轉化時間。
（關於使用axure的思考：由於我們難以積累乙個內部的axure元件庫，也沒法定向培養使axure做原型的產品人員，而且我們一般都得身兼多職，完成原型也得做最終的頁面設計，所以用axure做的拋棄型原型還是有一定的成本的，而隨著有我們內部的前端頁面框架後，亦可以直接做靜態頁面了，而且做出的原型較axure原型來說，更可謂高保真。 同時，我覺得axure更適合不懂真正的ui**但還得做出美觀的demo的人，但要做出美觀的原型，成本也不小，在沒有積累內部元件庫的情況下）
二、開發迭代中的todo
先前我們使用todo list，以0.5-1天為粒度去劃分工作內容。引用老師的一句話：在過去的專案過程管理中，我們發現，如果乙個工作的任務劃分以月為粒度，那它的延遲粒度也是以月為粒度，如果是以週為粒度，則最終進度的拖延亦以週為粒度。所以，在開發todo中，要求以0.5-1天為粒度去劃分任務（其實說的是個人todo，專案todo表一般還是按3-5天，而分到個人todo中會將任務再細分）。
先前我們一時沒找著合適的工具去進行todo的跟蹤反饋，一直是使用wiki去記錄；初期還好，但到後期就覺得混了。後來，覺得還是得找專門的專案管理工具，現在發現redmine不錯。
注：todo，更適合任務較明確的時候，在需求、規劃階段並不是那麼好使。
三、使用wiki去記錄公共文件
先前使用svn去管理公共文件，如配置文件，設計文件，等。但實在地說，svn不應該管理像pdf,doc這類文件，而且找起來也費勁。最後引進wiki後，管理配置文件的確是不錯，做一些簡單的設計說明，以及一些需協作的文件。關於更複雜的文件內容，比如visio什麼的，雖說wiki能傳圖，但覺得還是不太好。後期自郵之翼（freewings）2期有free分享，雖說不太完善，但亦解決這類的文件的存放問題。
四、開發迭代
從free分享的實踐來說，一般一周一次迭代，完成乙個次版本功能，和數個三次版本修訂，1-1.5月完成整個過程的release迭代（也可以說是主版本公升級）。
當然，一般來說，下次release迭代亦得看過程總結而定，一般不會直接想到下乙個release需求。
後期上線後，隨著使用者使用和反饋，以及前期規劃的功能修訂，工作量是不少的，所以一般release上線後進入這個階段了。
……其餘略過
再借用以下這張圖說一下反思——過程模型還待持續地探索和發展。
除了下述的問題之外，還有許多問題沒說明。比如，就乙個網際網路應用而言，運營推廣是很重要的。但實話說，這是學生團隊難以做好的，畢竟更偏向於專案實踐中技術探索和學術研究，不可能花時間做運營推廣工作；即使做，個人覺得也是不值的。除此之外，從個人經歷來說，我覺得乙個應用在上線之後的運維更新階段是很有必要突出的，在過程模型中沒體現，雖說可以簡單理解在下乙個release迭代過程中。
除了這些之外，上述許多內容，亦很可能是不完備的，需要在實踐中不斷思考總結更新的。比如之前說的快速原型，在最新乙個專案中，我就提前了直接使用前端框架完成，沒必要再走axure，這次探索似乎較為成功，相比之前原型-->靜態頁面設計階段的效率上看。但以後是否都如此，還待達成共識，畢竟最近這次這樣做也考慮到專案較為緊急。
而且，我認為，過程都是無法細化到專案成員的所有工作的，以及專案可能遇到的所有情況的。過程模型只是幫助我們理解乙個專案的過程，和對我們後期進行各階段工作有乙個最初的方向的指導，一切還是得以實際情況為準。所以是參考過程模型但不限於參考模型去實踐，而實踐最終會反饋於過程模型以提高模型的可適應性和合理性。
拖了很久終於抽時間寫完了。完成這個過程模型，去年對外對流過一次，今年給團隊新人進行專案介紹會時也專門完整講了一次，自己覺得還是挺驕傲的。同時，了解到軟體過程這個坑其實挺深的。以前學軟體工程裡的cmm，增量模型，有一定理論意義，但實踐起來覺得挺難實施的，或者不夠完備。而工業界較火的敏捷過程，如scrum，之前簡單了解了一下，並沒有具體去學習，因為自己更傾向把它們理解成思想，而非具體的方**。而有些方**，比如「5分鐘站立會議」，試驗過，但最後中咔嚓掉了，覺得不適合我們自身的例會；後來想想，如果只是3-4人小組，現在我們椅子一轉，談些工作，也就5分鐘的事，我想也許5分鐘站立會議是針對這種細粒度的會議會話吧……
完成這個過程，最大的感觸是，還是得有實踐經驗後，才能總結出來的。比如，學管理的人，沒參與過管理是無法理解管理學的。 如果沒經歷過軟體過程，學習軟體工程也是難以體會的，更不用說理解了。
Mvc專案架構分享之專案擴充套件
mvc專案架構分享之專案擴充套件 contents 系列一 架構概覽 0.專案簡介 1.專案解決方案分層方案 2.所用到的技術 3.專案引用關係 系列二 架構搭建初步 4.專案架構各部分解析 5.專案建立 系列三 infrastructure搭建 6.專案架構搭建之core搭建 7.專案架構搭建之m...
SEO專案計畫過程經驗分享
seo計畫過程是seo專案中定義工作範圍，制定seo工作計畫 排定專案進度等過程組成。這個過程在seo專案中可以簡稱為seo計畫，這個過程開始後，將在專案監控過程中進行。當發現新的資訊或出現新的情況，需要在專案週期內進行變更時，就要變更計畫甚至重新製作計畫，有時還會觸發乙個或另外多個計畫過程，甚至有...
開源專案 如何在貢獻開源專案的過程中提公升自己
我今年不知是機緣巧合，還是所謂的注定，有多次機會和大家講 開發者與開源社群的關係 的演講。那麼開源的生產方式，是高效的 高質量的，那麼這些是怎麼來的呢？其中，人是最主要的，那麼我談到的開發者是廣義的開發者，包括專案生產過程中全部的過程參與者。那麼從小白該如何晉級為高手？不妨按照文中作者的指引去做做。...