Please enable JavaScript.

Coggle requires JavaScript to display documents.

Waterfall, Story point, Scrum, Agile - Coggle Diagram

- - - - Nếu estimate theo giờ thì cần estimate lại vì trước đây đánh giá thấp task, thì cần thay đổi lại, task 4h thành task 6h.
      - Nhưng với story point thì không cần đánh giá lại vì story point là so sánh sự phức tạp tương đối giữa các task với nhau, không phụ thuộc vào con người trong team.
      - Nên nếu phát hiện làm dưới năng lực mong muốn thì độ phức tạp của task vẫn như vậy, nên không cần estimate lại.
- - - - Có trách nhiệm tối ưu giá trị của sp và công việc của development team đang làm
      - Là người duy nhất chịu trách nhiệm quản lý product backbock(danh sách tất cả các task, các chức năng sẽ làm trong dự án đó)
      - Là đại diện cho tổ chức đưa ra các yêu cầu, và sắp xếp các yêu cầu đó theo thứ tự ưu tiên làm sao để tối ưu được công suất của development team
    - - Là người giỏi về scrum, hiểu biết về scrum, đảm bảo hướng dẫn mọi người trong scrum team đấy thực hành scrum 1 cách chính xác nhất
        
        Có thể không có chuyên môn về development team trong dự án
        
        Nhưng là người đảm bảo thực hành scrum 1 cách đúng bàn bản nhất
      - Servant-leader
        
        Lãnh đạo: đưa ra các rule và yêu cầu mọi người tuân theo
        
        Đầy tớ: khi mọi người có gì đó bị lệch lạc thì scrum master sẽ theo dõi, nhắc nhỡ mọi người, giúp mọi người thực hành scrum tốt nhất.
      - Giúp mọi người thay đổi sự tương tác với nhau để tối ưu hóa giá trị mà scrum team đang làm.
    - - Là tập hợp nhừng người phát triển phần mềm
        
        Biến những task do PO đưa ra thành những sp có thể deliver cho client
      - Được cấu trúc và trao quyền để tự quản lý công việc của họ
        
        không có leader, không có maneger, là team tự quản
      - 2 tính chất quan trọng
        
        tính tự quản
        
        tính đa năng
        
        tất cả các thành viên dù mỗi người có 1 kỹ năng khác nhau nhưng tổng hợp tất cả các kỹ năng đó lại sẽ đủ để giải quyết mọi bài toán trong dự án đó mà không cần nhờ bất kỳ ai bên ngoài giúp đỡ. Không cần gọi chuyên gia bên ngoài vào
      - tính chất khác
        
        Không quy định title, chức danh cho mỗi người trong team. Có 1 chức danh chung gọi là developer, dù kỹ năng là tester, designer, lập trình, QA,….
        
        Không chia sub team nhỏ hơn.
        
        Mỗi người trong team có kỹ năng khác nhau, lĩnh vực khác nhau nhưng khi chịu trách nhiệm thì mọi người phải chịu trách nhiệm như 1 tập thể.
        
        Từ 3-9 người. Lớn hơn thì chia nhiều development team.
    - - Tính tự quản(self-organizing)
      - Tính đa năng(cross-functional)
    - - biến những backlog items thành những cái có thể deliver đượ
      - Scrum team có thể deliver sp đến client
        
        1 cách có thể phát triển rộng thêm, Chứ không phải làm 1 phát từ đầu đến cuối rồi mới bàn giao
        
        Không để đến xong hết mới bàn giao như yêu cầu, như vậy là tước đi quyền của client là quyền feedback lại sản phẩm sớm nhất
        
        Bàn giao theo kiểu xoắng ốc
  - - - A time-box
        
        Là 1 sự kiện mang tính time-box. Nghĩa là nó sẽ kết thúc khi thời gian hết mà không cần biết kết quả ntn.
        
        Khi vận hành 1 dự án trên framework scrum người ta chia các khung thời gian của dự án thành các khoảng gọi là sprint.
      - thời lượng nhất quán trong suốt nỗ lực phát triể
        
        Sprint tốt nhất nên có chiều dài như nhau xuyên suốt dự án
        
        kéo dài từ 1 tuần đến 1 tháng
      - 1 sprint mới sẽ start ngay sau khi sprint trước đó kết thúc
        
        Hôm nay kết thúc sprint 1 thì mai bắt đầu sprint 2, không có thời gian nghỉ giữa 2 sprint
        
        Sprint là 1 cuộc chạy nước rút, phải làm nhanh để có sp sớm đến tay client để client tối ưu tiền mà họ đạt được
    - - Trước khi bắt đầu thực hiện 1 sprint cần xác định đạt được gì trong sprint này
        
        những chức năng cần làm được
        
        cải thiện về chất lượng, quy trình, giảm số lượng bug, tất cả mọi thứ chúng ta đặt ra trước khi bắt đầu 1 sprint
      - Các sprint goal này phải được tạo ra khi làm splan cho sprint.
      - Mục tiêu của các sprint cần gắn kết với nhau, không được rời rạc
    - - Khi làm việc trong 1 sprint thì không được làm gì nguy hiểm đến mục tiêu của sprint
      - Mục tiêu về mặt chất lượng không được phép giảm trong suốt quá trình sprint.
      - Những công việc được làm trong sprint có thể sẽ được làm rõ hoặc đàm phán lại với khách hàng hay PO trong quá trình sprint thì scrum cho phép.
        
        Điều này thể hiện tính thích nghi của scrum
        
        Mặc dù sprint đang chạy nhưng chúng ta vẫn phải làm rõ lại requirement, làm rõ lại yêu cầu khách hàng hoặc PO, scrum cho phép.
    - - Lập kế hoạch những gì làm trong sprint đó
      - Là 1 time-box event, sẽ kết thúc sau khi thời gian kết thúc
      - Sprint kéo dài 1 tháng thì sprint plan kéo dài trong 8 giờ, 2 tuần là 4 giờ
      - Sau 8 giờ mà plan chưa xong thì vẫn phải kết thúc plan đó, không làm plan tiếp. Bắt tay vào việc ngay.
      - Trả lời các câu hỏi
        
        Sẽ deliver những gì tiếp theo cho client?
        
        Cần những gì để làm được việc đó?
    - - Planning sẽ lập danh sách các công việc cần làm trong sprint, danh sách đó gọi là sprint backlog
      - Sprint backlog do development team quản lý
      - Sprint backlog chỉ có development team có thể thay đổi trong suốt sprint
      - Khi có công việc mới thì sẽ được dev team thêm vào trong sprint backlog
      - Những việc cần bỏ đi thì chỉ có dev team mới được remove khỏi sprint backlog
    - - Là event time-box 15p, hết 15p mà chưa xong thì vẫn phải kết thúc, quay lại làm việc
      - Đứng lại với nhau trao đổi trong 24h qua đã làm được gì, 24h tời sẽ làm gì, có vấn đề nào gặp phải, có khó khăn gì không
      - Daily scrum được tổ chức ở cùng địa điểm cùng thời gian của mỗi ngày để giảm thiểu sự phức tạp.
      - Từng member sẽ trả lời 3 câu hỏi:
        
        Tôi đã làm gì ngày hôm qua để giúp nhóm phát triển đạt được mục tiêu của sprint?
        
        Tôi sẽ làm gì hàng ngày để giúp nhóm phát triển đạt được mục tiêu của sprint?
        
        Tôi có thấy bất kỳ trở ngại nào ngăn cản tôi hoặc nhóm phát triển đạt được mục tiêu của sprint không?
      - Scrum master
        
        đảm bảo development team phải tổ chức daily meeting này
        
        Development team có trách nhiệm tiến hành daily scrum
        
        Scrum master có trách nhiệm chỉ cho dev team cách thức để giữ thời gian của daily scrum dưới 15p
        
        Scrum master đảm bảo mọi người trong dev team phải tham gia đầu đủ trong daily scrum
      - Thuật lợi
        
        Giúp cải thiện kỹ năng giao tiếp, cải thiện mức độ hiệu quả trong giao tiếp của development team
        
        Giảm thiểu(eliminate) các cuộc họp khác.
        
        Phát hiện các rào cảng, cảng trở sớm
        
        Giúp đưa ra những quyết định nhanh.
    - - development team phải liên tục theo dõi số lượng công việc còn lại để biết được chúng ta đang nhanh hay chậm so với tiến độ đã đề ra.
      - jira, có hỗ trợ đường burndown
        
        là đường biểu diễn khối lượng công việc của sprint đến thời điểm hiện tại.
        
        Trục tung là công việc còn lại, trục hoành là thời gian
        
        Đường lý tường: là đường thẳng từ đầu đến cuối.
        
        Khi so sánh đường burndown với đường lý tưởng sẽ cho biết tiến độ nhanh hay chậm để tìm cách giải quyết
        
        đường burndown cũng là công cụ giúp thể hiện được tính có thể kiểm tra được của sprint.
    - - là tất cả những gì làm trong sprint đó mà có thể deliver được cho khách hàng
      - Phần được thêm vào để tạo vòng tròn lớn hơn được gọi là increment của sprint 4 đó.
    - - Hủy 1 sprint nên là 1 sự kiện hiếm hoi và không nên xảy ra thường xuyên
      - Khi mục tiêu của sprint không còn đúng với mục tiêu hiện tại của client nữa thì chúng ta hủy sprint.
      - Khi hủy sprint thì những item nào trong sprint đã làm xong rồi thì thôi, những cái nào chưa xong thì đưa về backlog.
      - Việc cancel này rất hiềm và không nên xảy ra nhiều.
        
        Mất tinh thần.
        
        Lãng phí công sức của mọi người trong dự án, cũng như nguồn lực của doanh nghiệp.
    - - Khi chúng ta đã làm tất cả công việc của sprint xong, hoặc chưa xong nhưng thời gian đã hết rồi, chúng ta phải ngồi lại để review. Công việc: Xem lại đã làm gì trong sprint.
      - Là 1 buổi demo cho các stakeholders của dự án, có PO, client, làm được những chức năng gì.
        
        Demo xem có đúng yêu cầu của product owner không?
      - Sprint review kéo dài 4 tiếng cho 1 sprint dài 1 tháng
        
        Cũng là time-box event
      - Sau mỗi sprint review sẽ cần thay đổi backlog
        
        Những gì làm xong thì thôi
        
        Những cái chưa xong thì có điều chỉnh hoặc không, nhưng phải đưa vào backlog để làm kế hoạch cho sprint tiếp theo
    - - là xem lại cách thức chúng ta làm sp đấy, xem lại quy trình làm việc của chúng ta
      - Xem lại sprint trước đã làm được những gì tốt thì nên phát huy.
      - Những gì cần cải thiệt để tốt hơn cho sprint sau.
      - Là time-box event kéo dài 3 tiếng cho sprint 1 tháng
      - cần đạt 3 mục tiêu
        
        Nêu ra những vấn đề đã làm tốt những gì?
        
        Những vấn đề có thể làm tốt hơn, những thứ cần cải thiện
        
        Kế hoạch cho sprint tiếp theo, làm sao để cải thiện những vấn đề này
  - - - vật phẩm làm ra trong quá trình sản xuất pm
        
        Chức năng của phần mềm
        
        Tài liệu hướng dẫn sử dụng cho client
      - Tất cả mọi thứ được tạo ra trong dự án được gọi là scrum artifacts
    - - Trong đó, tất cả công việc, chức năng, mọi việc cần làm được đặt trong 1 artifacts lớn nhất được gọi là backlog nghĩa là cái rổ đựng mọi thứ định làm trong dự án
      - PO là người phụ trách việc quản lý backlog
      - user stories
        
        Trong 1 backlog là 1 danh sách các công việc thì mỗi công việc đó được gọi là user story
      - Epic
        
        Có những user stories liên quan nhau, Thì gom chung lại tạo thành 1 cái lơn hơn được gọi là epic(bản trường ca)
        
        Epic lớn hơn story nhưng nhỏ hơn backlog, gom các stories liên quan với nhau lại thành 1 epic
      - tasks/subtasks
        
        Trong story có thể chia thành các task nhỏ hơn được gọi là subtask
        
        Dễ quản lý và estimate hơn
      - Product backlog items
        
        Các story, epic, subtask được gọi chung là backlog item, là các item trong backlog
        
        4 đặc tính sau
        
        attributes of a description
        
        Mô tả nó là cái gì
        
        Mục đích là gì?
        
        Tạo ra để làm gì?
        
        Order
        
        Thứ tự của nó trong backlog, cái nào đặt ở trên, cái nào đặt ở dưới
        
        Chính là thứ tự ưu tiên để sau này chúng ta làm, sẽ làm những cái có thứ tự ưu tiên cao trước, ưu tiên thấp sau
        
        Estimate
        
        Estimate là 1 số bao nhiêu để thể hiện độ phức tạp của item đó
        
        Story càng phức tạp, càng lớn thì số point càng cao.
        
        Development team phải tự thực hiện
        
        Value
        
        Giá trị mà backlog item mang lại
      - Product backlog không bao giờ là đầy đủ, hoàn thiện
        
        Dự án đang chạy thì product backlog sẽ luôn được thêm các item mới vào
        
        Sẽ chỉ kết thúc khi dự án kết thúc
    - - Mỗi 1 backlog item cần có 1 khái niệm định nghĩa như thế nào là xong
      - Khái niệm này phải được đặt ra trước khi chúng ta làm
      - Định nghĩa ntn là xong thể hiện tính minh bạch của scrum
      - Cần định nghĩa minh bạch từ đầu, tất cả mọi tiêu chí để xác định 1 task ntn là xong.