Sơ lược về Scrum framework

Đăng bởi - Vào

SƠ LƯỢC VỀ SCRUM FRAMEWORK

ĐỊNH NGHĨA KHUNG LÀM VIỆC SCRUM - WHAT IS THE SCRUM FRAMEWORK?

- Là khung làm việc (framework) dựa trên mô hình Agile do đó nó có đầy đủ tính chất của Agile; mong muốn áp dụng những gì tốt nhất cho khách hàng;

- Ra đời năm 1955

- Có 3 tính chất:

+ Nhẹ (lightweight): không có quá nhiều rule cần phải tuân theo

+ Đơn giản (Simple): nói lí thuyết trong 1-2 giờ chúng ta hoàn toàn có thể hiểu được Srum là gì và luồng làm việc của nó như thế nào nhưng rất khó để thành thạo (tính chất thứ 3)

+ Khó để thành thạo

3 TRỤ CỘT CỦA SCRUM - 3 PILLARS OF SCRUM

- Tính minh bạch (transparency): tại mỗi thời điểm, tất cả mọi người trong team đều biết trạng thái công việc, tiến độ, thời gian,... 

- Có thể kiểm tra được (inspection): kiểm tra về timeline, sprint goals

- Tính thích nghi (adaption): thích nghi với sự thay đổi về yêu cầu của khách hàng

3 VAI TRÒ TRONG SCRUM TEAM - 3 ROLES

- Product owner (PO)

+ Quản lí Product Backlog

+ Là 1 cá nhân, không phải 1 tổ chức

- Scrum master (SM)

+ Đảm bảo scrum được thực hiện 1 cách bài bản nhất (VD: đảm bảo các các events được tổ chức đúng lịch và tất cả các thành viên scrum team đều tham gia)

+ Đưa ra rules và yêu cầu mọi người tuân theo

+ Bảo vệ team khỏi các tác động bên ngoài => chăm lo đời sống vật chất, tinh thần anh em development team

- Development team (Developer, Tester, BA, Designer)

+ Biến US của PO thành sản phẩm có thể chuyển giao cho khách hàng

+ Có 2 đặc điểm cực kì quan trọng khi xây dựng 1 Development team:

  • Một là, tính tự quản (self-organizing) => không có leader, không có chức danh cụ thể cho từng thành viên, mọi thành viên ngang hang nhau; trách nhiệm là của chung, khi xảy ra bất kì sai xót nào thì không được đổ lỗi cho bất kì ai mà đó là lỗi của cả team vì đã vi phạm tính minh bạch trong scrum
  • Hai là, tính đa năng (cross-functional): không cần sự hỗ trợ từ các chuyên gia bên ngoài vẫn có thể hoàn thành công việc => Các thành viên trong team ngoài hiểu rõ công việc của mình cần hiểu luôn công việc của các thành viên khác. VD: ông dev hoàn toàn có thể sang hỗ trợ tester nếu tester nghỉ phép hoặc tester không kịp

+ Kích thước team: 3-9 thành viên

CÁC VẬT PHẨM TRONG SCRUM - SCRUM ARTIFACTS

- Product Backlog

+ Danh sách tất cả mọi thứ chúng ta cần làm => PO quản lí và sắp xếp độ ưu tiên

+ Product backlog bao gồm các user stories => Các US liên quan với nhau được gom lại thành Epic

+ User story có thể được tách thành nhiều task/subtask => dễ quản lí, estimate hơn

+ Product Backlog items cần có các thông tin: Description, order (thứ tự), estimate, value

+ Development team có nhiệm vụ estimates cho từng US (không phải nhiệm vụ của PO)

+ Product Backlog luôn luôn được phát triển theo dự án, không bao giờ hoàn thiện, chỉ kết thúc việc thay đổi khi dự án kết thúc

- Definition of Done - Định nghĩ về sự hoàn thành

+ Giống như một hợp đồng, liệt kê rõ ràng tất cả các tiêu chuẩn cần đạt được mới công nhận công việc là hoàn thành

+ Đảm bảo tính minh bạch của scrum => mọi thành viên trong team đều nhận định được công việc cần làm – tránh Dev hiểu 1 kiểu, Tester hiểu 1 kiểu

- Scrum events

Lưu ý: tất cả sự kiện trong scrum đều là time-boxed => sẽ kết thúc khi hết TG mà không cần quan tâm kết quả nó như thế nào, có hoàn thành hay chưa

Sprint: là trái tim của scrum; kéo dài 1-4 tuần (đẹp là 2 tuần), kéo dài như nhau trong xuyên suốt dự án; không có thời gian nghỉ giữa 2 sprint (sprint sau bắt đầu ngay khi sprint trước kết thúc)

+ Sprint Planning

  • Time-boxed: 8hours để planning cho sprint 4 tuần (4h/2 tuần, 2/1 tuần,...)
  • Lên danh sách công việc sẽ làm trong sprint tới => Sprint backblog (do development team quản lí)
  • Deliver cái gì cho khách hàng sau khi kết thúc sprint => Sprint goals
  • Các trở ngại và cần những gì hỗ trợ để các kế hoạch đó hoàn thành

+ Daily scrum

  • Time-boxed: 15 phút, tố chức cùng địa điểm, cùng thời gian => giảm thiểu sự phức tạp
  • Stand up during the meeting - đứng cho mỏi chân họp cho lẹ lẹ, không có ngồi nhé
  • Mục đích: đồng bộ hóa hoạt động của các members
    • Trong 24 giờ qua => What did I do yesterday?
    • Trong 24 giờ tới => What will I to today?
    • Các khó khăn => có khó khăn gì không?
  • Scrum master đảm bảo daily meeting được diễn ra đúng kế hoạch và tất cả mọi người đều phải tham gia
  • Điểm lợi của daily scrum: 
    • Cải thiện kĩ năng giao tiếp của team
    • Giảm thiểu những buổi họp adhoc để giải quyết vấn đề hoặc họp hàng tuần, hàng quí để tổng kết
    • Nhận định ra những rào cản, bất lợi sớm
    • Đưa ra những quyết định nhanh (cản trở này ai sẽ là người giúp để giải quyết vấn đề mà team đang gặp phải)

+ Sprint review

  • Time-boxed: 4 hours cho sprint 4 tuần
  • Demo cho tất cả Stack-holder xem chúng ta đã làm được những gì, có đúng yêu cầu không?
  • Sau mỗi buổi sprint review, Product Backlog được cập nhật lại đễ sẵn sàng cho sprint tiếp theo

    => Review Sản phẩm

+ Sprint Restropective

  • Time-boxed: 3hours cho sprint 4 tuần
  • Xem lại quy trình làm việc của team: những gì cần phát huy, cần cải thiện

=> Review qui trình làm việc


- Sprint Monitoring

+ Burn-down chart

  • Khối lượng công việc còn lại của sprint đến thời điểm hiện tại
  • Dạng biểu đồ đường, nếu trên đường lí tưởng là chậm hơn tiến độ, dưới đường lí tưởng là nhanh hơn tiến độ

+ Burn-up chart: Khối lượng công việc đã hoàn thành strong sprint tính tới thời điểm hiện tại

STORY POINT & ESTIMATION

- Story point

+ Cho biết khối lượng công việc, độ phức tạp, rủi ro khi thực hiện công việc => vd: công sức bỏ ra để lắp ráp 1 chiếc xe đạp sẽ ít tốn công hơn, đơn giản hơn, ít rủi ro về kĩ thuật hơn lắp ráp 1 chiếc xe máy

+ Như vậy, Story point sẽ cho biết độ khó của User Story => User Story càng khó thì số point càng cao và ngược lại

+ Story point so sánh sự phức tạp tương đối giữa các User story với nhau, không phụ thuộc vào năng lực của con người hay của team

+ Số story point thuộc dãy Fibonaccy: 1, 2, 3, 5, 8 (không nên vượt quá 8, nếu vượt quá 8 thì break US thành một US mới cho dễ quản lí). Tại sao point là fibonacci? => không tăng quá chậm như dãy số tự nhiên, không quá nhanh như hàm mũ

- Estimation

+ Development team mới có quyền thực hiện estimate cho task

+ Số point sẽ không phụ thuộc vào kinh nghiệm, kĩ năng của người estimate mà phụ thuộc vào US chuẩn do team đề ra

+ Estimate bằng point thì mỗi sprint sẽ khác đi, nếu bằng hours thì mỗi tuần luôn luôn 40hours sao mà tính Velocity


VELOCITY

- Số lượng Story Point của User Story hoàn thành trong 1 sprint


LUỒNG LÀM VIỆC - WORK-FLOW

<<updating...>>

Nhận xét

Đăng nhận xét

Bài đăng phổ biến từ blog này

[DATABASE] Tìm mọi khóa của lược đồ quan hệ

Đăng bởi - Vào
Hình ảnh
  Cách thực hiện: Gọi K là tập khóa cần tìm B1. Tìm tập nguồn N và Tính N + F Nếu N + F  = Q +  thì suy ra lược đồ quan hệ chỉ có một khóa duy nhất là N và kết thúc thuật toán Ngược lại, qua bước 2 B2. Tìm tập trung gian TG Nếu TG =   thì lược đồ quan hệ có 1 khóa là tập nguồn N và kết thúc thuật toán Ngược lại, nếu TG ≠   thì tìm tất cả tập con khác rỗng X i  của tập TG Lấy từng X i  hợp với N => N ∪ X i  TH1 : Nếu (N ∪ X i ) + F  = Q +  thì (N ∪ X i ) là khóa, loại tính toán đối với các tập con khác của TG có chứa X i  ; thêm khóa vào tập K TH2 : Nếu (N ∪ X i ) + F  ≠ Q +  thì  (N ∪ X i ) không là khóa B3. Kết luận:  Khóa của lược đồ quan hệ là tập K ------------ Giải thích: N là tập thuộc tính nguồn (chứa những thuộc tính chỉ xuất hiện ở vế trái của các phụ thuộc hàm; các thuộc tính không xuất hiện ở cả vế trái và vế phải của phụ thuộc hàm) TG là tập thuộc t...
Xem chi tiết »

[DATABASE] Phủ tối thiểu của tập phụ thuộc hàm

Đăng bởi - Vào
Hình ảnh
Cách thực hiện: B1. Phân rã PTH sao cho VP chỉ còn 01 thuộc tính B2. Loại các thuộc tính dư thừa ở VT (không xét PTH mà VT có 01 thuộc tính) Bỏ thuộc tính ở VT khi và chỉ khi bao đóng của các thuộc tính còn lại chứa thuộc tính ở VP B3. Loại bỏ các PTH dư thừa ( không xét PTH mà thuộc tính ở VP chỉ xuất hiện một lần) B3.1: Tìm bao đóng của VT B3.2: Nếu bao đóng của VT chứa thuộc tính ở VP thì nó là PTH dư thừa, ngược lại nó không là PTH dư thừa ------------ Ví dụ : Cho lược đồ quan hệ Q=(A, B, C, D) và PTH F={AB → CD, B → C, C → D}  Tìm phủ tối thiểu?  B1. Phân rã PTH sao cho vế phải chỉ còn một thuộc tính F={AB → C, AB → D, B → C, C → D}  B2. Bỏ các thuộc tính dư thừa ở vế trái B → C, C → D : không xét vì vế trái chỉ có một thuộc tính Xét AB → C A + F-{AB → C}    = A, không chứa C nên B không thừa B + F-{AB  → C}   = BCD, chứa C nên A thừa Loại thuộc tín...
Xem chi tiết »

[DATABASE] Dạng chuẩn cao nhất của lược đồ quan hệ

Đăng bởi - Vào
Cách thực hiện: B1: Tìm mọi khóa của lược đồ quan hệ B2: Kiểm tra dạng chuẩn từ cao xuống thấp (BCNF - 3NF - 2NF - 1NF) BCNF (Boyce-Codd Normal Form)  Tất cả VT của phụ thuộc hàm là khóa (VT là siêu khóa) 3NF (Third Normal Form) Phân rã VP của phụ thuộc hàm sao cho VP chỉ chứa một thuộc tính Thỏa 1 trong 2 điều kiện: VT của phụ thuộc hàm là khóa hoặc VP là tập con của khóa 2NF (Second Normal Form) B1: Xác định các thuộc tính không là khóa B2: Tất cả thuộc tính không là khóa phải phụ thuộc đầy đủ vào khóa Trường hợp khác #1 : Cách để kiểm tra có đạt 2NF không trong trường hợp không biết cách xác định tính phụ thuộc đầy đủ: Với mỗi khóa K, tìm bao đóng của tất cả  tập con thực sự  Xi của K Nếu tồn tại bao đóng  X i +  chứa thuộc tính không khóa thì không đạt dạng chuẩn 2, ngược lại đạt dạng chuẩn 2 #2 : Nếu lược đồ chỉ có 01 khóa và khóa đó chỉ có duy nhất 01 thuộc tính thì chắc chắn đạt dạng chuẩn 2 1NF (First Normal Form)  Nếu lược đồ quan hệ không đạ chuẩn...
Xem chi tiết »