2015年11月30日 星期一

[筆記]Scrum軟體開發速成 THE ELEMENTS OF SCRUM(二) Scrum產出物

Scrum產出物

   1. 產品待辦清單:產品待辦清單,是產品預期交付物的累積清單。包含了特性/bug 修
                                             復/文件變更及任何有意義的東西。在清單上方,大多是較小型且
                                            定義完整的項目,越往下項目越大,定義也更粗略。

            2.Sprint 清單:Sprint清單是團隊目前sprint的工作清單。它和產品待辦清單不一樣,它
         的生命週期,僅存活一個sprint的時間。sprint清單在sprint規劃會議中產
         生。一但規劃會議結束,就不可以再修改sprint清單的項目。若要變更也
         是由團隊成員發出 並於產品負責人一起修改sprint清單中的項目。

   3.燃盡圖:描述了剩餘工作隨時間變化軌跡。
正常燃圖會隨團隊不斷工作,而隨之下降。
 
有時會因為範圍變更,有所改變,上圖為需求增加,直線向上。
4.在scrum中有兩種燃盡圖:發佈燃盡圖和sprint燃盡圖。
        4.1發佈燃盡圖:此圖為產品負責人工具,以追踪工作之用。
4.1
           4.2Sprint燃盡圖:如同發佈燃盡圖,sprint燃盡圖則顯示出目前Sprint剩餘
                工作量的變化。

    5.工作看板:有下列幾種看板範例。









2015年11月27日 星期五

[筆記]Scrum軟體開發速成 THE ELEMENTS OF SCRUM(一)

Product Owner
            1.負責待辦清單
                        1.1  待辦清單來源自,另一份按優先順序排序的清單
      1.2  內容包括 新特性/錯誤修復

   2.Index Card
                        2.1 內容記錄,記錄待辦清單中的特性,一張只記錄一個特性。這些特性稱為 
        User stories。
      2.2 User stories:由團隊成員逐一討論,確認其驗收標準,與故事的完成的模
             樣,團隊成員並討論,要完成這些故事,要做那些工作,有那
             些類型,有多少工作量。若有不清楚的故事,可以排除在當次
             的sprint。

             3.Daily Scrum每日站立會議:團隊成員輪流分享資訊。前一天完成了什麼工作;今天
                                                               打算完成什麼工作;有沒有碰到什麼障礙或問題。

             4.清單整修會議:對產品待辦清單上的故事,進行再次討論並對故事內容有疑慮的地
                                           方再確認。包含故事點的計算及故事的拆解。

Scrum角色:
   1. 產品負責人:唯一有權要求團隊做事及改變待辧清單優先順序的人。
      1.1 掌握產品願景
      1.2    代表業務
      1.3 代表客戶
      1.4 持有產品待辦清單
      1.5 劃定故事優先順序
      1.6 設定故事驗收標準
      1.7 有空回答團隊成員們的問題

   2. scrum master:引領團隊達到更高級的凝聚力,自我組織和表現。團隊的交付物是產
                                        品,而scrum master的交付物是自我組織的團隊。scrum master不是團隊
                                        的老闆僅限於透過影響力所得的領導力。引導scrum會議,幫助團隊理
                                        解和使用scrum的產出物。另一個關鍵作用是替團隊掃除障礙。
      2.1 scrum專家和諌言者。
      2.2 教練
      2.3 障礙移除者
      2.4 引導者


   3.團隊成員:
                        3.1 團隊成員可以全權決定如何完成工作,也可決定要使用的工具和技術。
      3.2 負責估計實現特性需要的工作量。
      3.3 順序由產品負責人決定,完成特性或工作需要多少時間,由團隊成員決
        定。
      3.4 負責交付使用者故事。

Sprint週期
                               
            1.一個Sprint通常為兩週,通常不會超過四週。初期scrum團隊會設成一週,以精練 
     scrum技巧。      
Sprint的各種會議
   2.Sprint規劃會議:Sprint規劃會議代表著Sprint的開始,區分兩部份,第一部份目標
    是,團隊要選擇一組交付物作為目前Sprint的承諾。第二部份,團隊要羅列出交付
    使用者故事(交付物)所需完成的所有工作。
       
                         2.1 第一部份[要做什麼?]:團隊成員與產品責人討論所有的故事(交付物),
        及各故事的驗收標準。團隊成員協商解決各故事依懶性問題,並討論實現
        故事要做那些工作。

      2.2第二部份[要怎麼做?]:團隊把選定的故事(交付物)分解成,所需要執行
        的工作。討論的過程中產品負責人要全程在場,以便回答問題。
   
   3.每日站立會議:開會時間不應該超過15分鐘,快速分享前日已經完成內容,並報告
           預計完成的內容。

   4.故事時間(清單整修會議):也有人稱作[清單稱修]會議,重新檢視清單中,未完
                 成的故事,是否需要在拆解成更小的故事,或故事有
                 不清楚的要重新理解,目的在於,要保持清單中,隨
                 時都要有一小批,已被充份理解的小故事
    
    5.Sprint檢視:也稱作Sprint Demo,目的在於展示,團隊成員的工作成果,可以邀請
         Product Own,也可以邀利害關係人一同參加。會議長度依1週的sprint約
         莫1小時為基礎。Product Own及團隊成員,可以收集會議中的回饋,當作
         之後Sprint的故事。

   6.自省會議:自省會議在每個sprint的最後才召開,目的是為了幫助團隊持續地進行檢
         驗和調整,希望能升提績效幸福感。每個開發週期以1~2小時的比
         例進行安排,最多不要超過3小時。自省議程如下:
        
       6.1 準備階段:這階段重視[建主共同的目標],讓團隊了解開會的目的,
              是為了團隊提升,而不是個人的檢討。

       6.2 收集資料:在sprint中發生了什麼。可以利用開會技巧幫助團隊,以保持
              思路清晰且不偏主題。

       6.3 洞察問題:這階段重視[為什麼],找出問題發生的原因,過程中不聚
              焦在人,而是在問題本身

                            6.4 確定方案:自省會議的問題也許有很多,最好的辦法是,一次自省會議
              ,只決解一個問題。

       6.5 結束:用感謝來當作結束,讓成員說出在sprint中可以感謝的人事物,
            可以讓團隊更加團結。

Sprint 的異常終結:在正常的Sprint中,管理層不會要求,改變需求。異常終止通常發生在外部因素。在終結前若還有可交付部份,則還是可以做Sprint Demo及自省會議,由其自省會議對異常終結Sprint來說尤其重要。


































2015年6月29日 星期一

【MongoDB】Replication Introduction

Replication Introduction
Replication是一種跨伺服器同步資料的處理技術.
Purpose of Replication
Replication提供在不同database Server之間,多重複製資料時,提供資料的高用性,並保護單一server資料遺失。也允許單一server失敗時,還原資料。在某些條件下,也可以增加讀取資料的容量。client有讀取及寫入不同Server的能力。
Replication in MongoDB
replica set  mongod instance的集合與hostData set相同。 primary  mongod 負責所有"寫入"的作業,其它所有的secondary,向primary申請相同的data set
primary允許所有來自client"寫入"操作。一個replica set 只可以有一個primaryprimary record異動dats set紀錄會存放在oplog




secondaries 複製primaryoplog及申請操作secondarydata set,這樣primarydata會反應給 sesecondarydata set.如果primary的失效,replica set會從secondayr中找一個當作primary




可以新增一個mongod instance arbiterarbiter不處理資料.因為 MongoDB 的機制,是讓眾伺服器投票決定誰當 Primary,一個 RelpSet 中只有兩台機器時,常會發生問題,造成整個群組中無 Primary 機器的狀態。所以,這時要加入仲裁者(Arbiter)機器來協助排除。



非同步複製(Asynchronous Replication)
Secondary可以primary申請非同步複製.即使過程中有多個成員失敗,還是可以持續執行.
自動故障移轉(Automatic Failover
primary無法與其他成員溝通超過10移以上,replica set會嘗試選擇其它的成員為新的primary.第一順位的secondary會收到多數的投票結果,成為primary.





2015年6月17日 星期三

【MongoDB】Sharding Introduction

Sharding Introduction

Sharding是用於跨多個機器儲存時的一種技術。MongoDB使用Sharding支援部署大量資料集,及高存取流量操作。

Purpose of Sharding

應用程式在處理大資料集跟高存取量時,對單一Service上的資料庫系統,是一個很高的挑戰。
高查詢率會消耗CPU資源,大資料集所需容量,超過單一機器所能負荷。執行時的記憶體使用量,超過單一機器所能提供,進而挑戰機器的disk I/O。為了解決上述問題,資料庫系統有2個基本方法,重直擴展【 vertical scaling和【sharding.
重直擴展Vertical scaling):增加CPU及增加Storage的容量,但這些都是有極限的。高效率的系統有大量的cup及 高記憶體,比小系統的成本還高。另外雲端系統供應商也許只提供使用者,小的instance,依照這個結論,重直擴展是有它最大的極限。
碎片化(Sharding):也可稱為水平擴展,分割的資料集及分散的資料,被存在數個不同的Service上或shard上,每一個碎片(shard)都是一個獨立的資料庫跟集合體,數個shards可以組成一個邏輯資料庫(logical database



  • 碎片化(Sharding)可以減少對每一個shard的操作,以新增為例新增資料應用程式只需要,存取某個記錄的shard

  • 碎片化(Sharding)可以減少每Server所需的stroage。以1TB的資料為例,可以存在4shardshard只需用256GB,如果有40shard只需要25GB.

Sharding in MongoDB

MongoDBsharding是透過shared Clusterconfiguration來實作。


  Sharded Cluster有幾元件組成:shardsquery routers config Servers.
碎片組(Shards):用來儲存資料。提供高可用度及一致性的資料。在正式環境中,Sharded Cluster裡的每一個shard(碎片),都是一個複製資料集
Query Routers:也可稱為 mongos instances,透過client Application及直接操作去佔用一個或多個碎片(Shard)。查詢程序或操作特定shards(碎片組)進而回傳結果會client。一個shared Cluster會包含多個Query Router去分開執行一個Client所發出的Request1client可以發出多個request給1個query Router。多數的shared clusters會有多有個query router.
Config servers:存放clustermetadata。包括cluster中的資料集與shards的對照,Query Router用這些matadata去操作做特定的shards。正式的shared cluster會有3個config Server

Data Partitioning

MongoDB是以collection層級,做分散資料或碎化(shards)。利用shard key達到碎化(shard)一個collection中的資料。

Shard Keys

碎化(shard)一個collection,需要去找出shard keyShard key會是index欄位或是一個複合式index而這個複合index存在每一個documentMongoDb劃分shard key值並將值寫入數個chunk而且分在數個不同的Shards。劃分shard key值,MongoDb使用range based partitioning or hash based partitioning其中一種方式。

Range Based Sharding


Hash Based Sharding


Splitting

Splitting是一支background Service,當一個chunk成長到specified chunk size的設定值時,會自動一分為二。

Balancing

balancer這支background service會去管理chkunk的搬移。當碎化(Shard)collectioncluster分配不平均時,blanacer會從最多chunkshard搬移chunk至最少的shard,直到整個collect平均為止。

Adding and Removing Shards from the Cluster

新增1shardcluster,因為shard沒有chunk,導致shard分配不平均。MongoDB會開始馬上搬資料到新的shard,這個動作會花一些時間,直到cluster達到平均的狀態。
刪除1個shard會先將其中的所有chunk搬到其它的shard,直到全部搬完及更新metadata後,才可以移除shard