構建之法閱讀筆記04

這一週，老師讓咱們作了有關於數組的動態規劃問題，咱們遇到的問題就是隻能想出複雜度n*n的算法，但是題目要求確是時空複雜度爲n的算法。最後問了一下班上的大牛同窗，教會我一個動態規劃的問題。其實我以爲和遞歸有點同樣。

這周我讀了構建之法的第六章，關於敏捷的流程。那什麼事敏捷的流程呢？我也是第一次據說，書上的定義是--敏捷的流程是一系列價值觀和方法論的集合 。敏捷開發的原則包括：1.儘早並持續地交付有價值的軟件以知足顧客的需求。2.歡迎需求的變化，並利用這種變化來提升用戶的競爭優點。3.常常發佈可用的軟件，發佈間隔能夠從幾周到幾個月，能短則短。4.業務人員和開發人員在項目開發過程當中應該天天共同工做。5.以有進取心得人爲項目核心，充分支持信任他們。6.不管團隊內外，面對面的交流始終是最有效的溝通方式。7.可用的軟件是衡量項目進展的主要指標。8.敏捷流程應能保持可持續的發展。9.只有不斷關注技術和設計，才能愈來愈敏捷。10.保持簡明儘量的簡化工做量的技藝極爲重要。11.只有能自我管理的團隊才能創造優秀的構架，需求和設計。12.時時總結如何提升團隊效率，並付諸行動。這些原則讓我對敏捷開發有了本身的理解，敏捷開發是極大程度的知足市場的需求，並在知足需求的基礎上再實現自我技術上的超越。那若是咱們要用敏捷開發，我麼應該怎麼作？書中介紹了敏捷開發的步驟，第一步，找出完成產品須要作的事情--product back-log。第二步，決定當前的衝刺（sprint）須要解決的事情--sprint backlog。第三步，衝刺（sprint），外部人員不能打擾內部人員，要注意「集中精力」和「交流」的矛盾。在衝刺階段，天天要開一個每日例會，報告：我昨天作了啥?我今天要作啥？

   可是再美妙的理論在實踐中都會碰到這樣那樣的問題，好比，各個需求之間是有優先等級的，單除了優先等級以外還有相互之間的依賴關係，那怎麼在計劃中體現依賴關係呢？

把一個任務從產品層級的描述逐步細化到技術實現層面，是很須要技術能力和交流能力的。成員任務分配不均的狀況又怎麼辦？每日例會中天天遇到的問題有可能流於形式了有怎麼辦？書中說天天跟蹤三個時間值：實際剩餘時間，預估剩餘時間，實際花費時間。這樣才能在實踐中脫穎而出。一個敏捷的團隊要怎麼衡量，包括下面的條件：1.自主管理。2.自我組織。3.多功能型。可是一個團隊只有在團隊很強的基礎上才能轉變爲敏捷團隊。看了《構建之法》才瞭解到軟件開發原來有不少種思想，因此要多學習，多瞭解，才能讓本身的知識庫不斷更新不斷豐富。