Course Mô-đun 3 - Lecture: Quy trình trong Scrum

kế hoạch nước rút

Lập kế hoạch Sprint là giai đoạn đầu tiên trong Scrum Sprint. Nó xác định phạm vi và cách thức thực hiện công việc trong giai đoạn nước rút. Toàn bộ nhóm Scrum tham gia vào việc lập kế hoạch.

Chạy nước rút là một khoảng thời gian được xác định rõ ràng trong đó một phần công việc cụ thể phải được hoàn thành. Sprint cần lập kế hoạch trước khi bắt đầu. Trước hết, bạn cần xác định thời lượng và mục tiêu của Sprint.

Tại hội thảo lập kế hoạch, danh sách các nhiệm vụ và mục tiêu của Sprint được thống nhất. Điều quan trọng là phải truyền cho nhóm động lực làm việc đúng đắn, để mỗi thành viên đều tập trung vào thành công.

Nếu Sprint được lập kế hoạch kém, thì điều này có thể khiến nhóm thất bại. Các nhà phát triển sẽ không thể đối phó với những kỳ vọng đặt ra cho họ, bởi vì các nhiệm vụ hóa ra là không thực tế.

Các câu hỏi cần xem xét khi lập kế hoạch chạy nước rút:

Khách hàng hoặc chủ sở hữu phần mềm thông báo mục tiêu của lần chạy nước rút, đồng thời giải thích cách đạt được mục tiêu đó. Nhóm Scrum tìm ra những nhiệm vụ nào có thể được hoàn thành trong một lần chạy nước rút trong tương lai để đạt được mục tiêu này.
Các nhà phát triển phân phối một kế hoạch làm việc giữa họ, kế hoạch này đã được thống nhất với khách hàng phần mềm.
Khách hàng (chủ sở hữu) của sản phẩm luôn tham gia vào việc lập kế hoạch chạy nước rút. Anh ấy đặt mục tiêu và nhóm lập trình phải tìm hiểu xem liệu mục tiêu đó có thể đạt được trong một lần chạy nước rút hay không.
Kế hoạch nên sử dụng một sản phẩm tồn đọng, thông tin từ đó có thể được thêm vào kế hoạch.
Các thành viên trong nhóm nên kết thúc cuộc họp lập kế hoạch với sự hiểu biết rõ ràng về những gì họ cần để đạt được kết quả. Bạn có thể hiển thị thứ tự của các hành động trong tương lai trong Sprint Backlog.

Lập kế hoạch không nên vượt quá hai giờ mỗi tuần. Scrum Master phải giải thích cho mọi người rằng có giới hạn thời gian. Nếu mọi vấn đề công việc được giải quyết nhanh chóng thì cuộc họp có thể kết thúc sớm hơn bình thường. Không có thời lượng tối thiểu cho một cuộc họp như vậy.

đánh giá nhiệm vụ

Đánh giá mức độ phức tạp của công việc không cần phải làm quá. Quá trình lập kế hoạch không cần chính xác, nhưng ít nhất là đánh giá gần đúng về mức độ phức tạp của sự phát triển. Nhóm không chỉ phải hiểu mục tiêu của nước rút mà còn phải so sánh mục tiêu với khả năng của nhóm mình.

Để đánh giá độ phức tạp, bạn có thể sử dụng các cỡ quần áo thông thường cho mọi người (L, XL, XXL). Tất nhiên, điều này không đảm bảo độ chính xác, nhưng vẫn vậy.

Để việc đánh giá độ phức tạp được chính xác hơn, cần có sự hiểu biết lẫn nhau. Các thành viên trong nhóm nên cởi mở chia sẻ ý kiến của họ và không ngại đặt câu hỏi cho chủ sở hữu sản phẩm.

Những lời chỉ trích đối với nhóm sau khi hoàn thành công việc có thể dẫn đến thực tế là khi lập kế hoạch cho lần chạy nước rút tiếp theo, các dự báo sẽ kém lạc quan hơn. Điều này sẽ giúp nhóm tránh lặp lại sai lầm và bảo vệ nó khỏi bị đánh giá tiêu cực trong tương lai.

Đánh giá độ khó về điểm, điểm, giờ

Thông thường, các nhóm phát triển ước tính mức độ phức tạp của công việc của họ theo thời gian. Nhưng một số nhóm Agile chọn xếp hạng độ khó theo điểm hoặc điểm. Đây là một dấu hiệu tốt hơn về tổng chi phí cần thiết để thực hiện một hạng mục tồn đọng hoặc nhiệm vụ được giao khác.

Điểm được trao dựa trên mức độ phức tạp và khối lượng công việc. Ngoài ra, những rủi ro có thể xảy ra cũng được tính đến. Tính điểm bằng phương pháp này giúp chia nhỏ công việc thành các bước nhỏ một cách hiệu quả.

Bằng cách thường xuyên sử dụng phương pháp tính điểm (điểm) khi lập kế hoạch, các nhóm hiểu rõ hơn và chính xác hơn về thời gian họ sẽ cần để hoàn thành công việc. Ngoài ra, còn có những ưu điểm khác nữa.

Ước tính thời gian không tính đến công việc không liên quan trực tiếp đến dự án, mặc dù nó chắc chắn sẽ xuất hiện. Thảo luận về các vấn đề công việc thông qua một trình nhắn tin, tổ chức các cuộc họp - tất cả những điều này cũng làm mất thời gian của các thành viên trong nhóm.
Cảm xúc có thể ảnh hưởng đến việc lựa chọn ngày. Cho điểm khi đánh giá công việc loại bỏ yếu tố này.
Việc đánh giá mức độ phức tạp của công việc và theo đó, tốc độ hoàn thành nhiệm vụ có thể khác nhau đối với mỗi nhóm. Công việc với các điểm được thực hiện không thể được coi là bất kỳ chỉ số nào về tốc độ. Tức là không gây áp lực tâm lý cho đội.
Bằng cách phân phối chính xác chi phí lao động và mức độ phức tạp, bạn có thể nhanh chóng và không có xung đột phân chia điểm cho công việc được thực hiện giữa những người tham gia.
Số điểm nhận được khi hoàn thành một nhiệm vụ phụ thuộc vào độ phức tạp của nhiệm vụ chứ không phụ thuộc vào thời gian bỏ ra. Do đó, các lập trình viên sẽ nghĩ về việc cải thiện hiệu quả của họ chứ không phải về việc sẽ mất bao lâu.

Nhược điểm của ước lượng độ phức tạp là nó thường bị lạm dụng. Ví dụ, phương pháp này không thể được sử dụng để đánh giá nhân viên.

Các nhóm nên sử dụng hệ thống tính điểm để hiểu rõ hơn về khối lượng công việc được giao cho họ và sắp xếp thứ tự ưu tiên một cách chính xác.

Cuộc họp Scrum hàng ngày

Hội thảo rất quan trọng: tại đó, các thành viên trong nhóm chia sẻ ý kiến của họ, giao tiếp và thống nhất về các hành động tiếp theo. Các cuộc họp scrum hàng ngày cũng cần thiết để nâng cao tinh thần đồng đội và thông báo tin tức hiện tại.

Stand-up là một cuộc họp ngắn của những người tham gia dự án chính: chủ sở hữu phần mềm, lập trình viên và giám đốc scrum. Cấu trúc của phần đứng lên bao gồm ba câu hỏi.

Những gì chúng ta đã có thể làm ngày hôm qua?
Hôm nay chúng ta đang làm gì?
Điều gì ngăn cản chúng ta đạt được kết quả?

Đặt những câu hỏi này kích thích sự phát triển và giúp xác định các vấn đề trong nhóm. Khi mỗi người tham gia truyền đạt cách họ giúp đạt được mục tiêu chung, điều này sẽ cải thiện sự hiểu biết lẫn nhau trong nhóm.

Điều quan trọng cần nhớ là không có một khuôn mẫu duy nhất nào về cách tiến hành đứng lên. Mỗi đội tổ chức họp theo mô hình riêng, dựa trên đặc điểm của đội.

Và bây giờ chúng ta hãy thảo luận về những gì cần thiết cho một tư thế đứng hoàn hảo và làm quen với các ví dụ về các động tác đứng hiệu quả.

Đầu tiên bạn cần chọn thời điểm phù hợp với mọi người. Thông thường, các cuộc đứng lên cho các đội từ cùng một văn phòng được tổ chức vào đầu ngày làm việc - từ 9 đến 10 giờ sáng. Điều này cho bạn thời gian để lên kế hoạch tốt hơn cho lịch trình của bạn trong ngày. Nếu các thành viên trong nhóm làm việc ở các khu vực khác nhau, thì thời gian sẽ được chọn phù hợp với tất cả mọi người. Ví dụ: nếu một số thành viên trong nhóm sống ở California và Sydney, thì thời gian chờ bắt đầu lúc 15:30 giờ California. Tất nhiên, việc đứng dậy sau bữa tối không thuận tiện cho tất cả mọi người, nhưng nó giúp bạn có thể giữ liên lạc với các đồng nghiệp ở bên kia bờ đại dương.

Theo dõi năng suất độc lập. Đừng tổ chức cuộc họp quá lâu - sự tập trung chú ý nên duy trì ở mức tốt nhất. Nếu có thể, hãy đứng lên không quá 15 phút.

Sử dụng quả bóng. Nó có thể được ném vào nhau lần lượt. Vì vậy, mọi người sẽ tham gia vào cuộc thảo luận. Trò chơi này giúp duy trì sự chú ý trong nhóm. Sử dụng nhóm hồi cứu. Stand-up được sử dụng trong nhiều phương pháp Agile, điều này không ngăn cản chúng ta thảo luận về hiệu quả của stand-up khi nhìn lại. Ai đó gặp nhau hàng ngày, các nhóm khác - một vài lần một tuần. Nếu nhóm khó đạt được lợi ích từ việc đứng lên, hãy tìm lý do cho việc này và thay đổi điều gì đó.

đánh giá nước rút

Đánh giá mùa xuân được thực hiện ở giai đoạn cuối cùng của nước rút. Nó là cần thiết để kiểm tra gia tăng sản phẩm và điều chỉnh tồn đọng. Toàn bộ nhóm scrum và tất cả các bên liên quan tham gia vào việc xem xét kết quả chạy nước rút. Cuộc họp được tổ chức theo hình thức thoải mái để cải thiện sự tương tác của những người tham gia dự án.

Đánh giá Kết quả Sprint bao gồm các yếu tố sau:

Chủ sở hữu phần mềm hiển thị những gì từ hồ sơ tồn đọng đã được hoàn thành và những gì chưa hoàn thành.
Các lập trình viên thảo luận về những gì diễn ra tốt đẹp, những khó khăn xuất hiện ở đâu và cách khắc phục chúng.
Nhóm phát triển cho thấy kết quả công việc của họ trong suốt thời gian chạy nước rút và phần gia tăng sản phẩm mà họ nhận được.
Product Owner chia sẻ suy nghĩ của mình về công việc tồn đọng hiện tại. Nó cũng đưa ra dự báo cho mục tiêu tiếp theo và thời hạn thực hiện mục tiêu đó.
Mọi người thảo luận về những gì tốt nhất nên làm tiếp theo dựa trên đánh giá thị trường và sở thích của người dùng.
Có sự trao đổi quan điểm về thời gian, ngân sách và triển vọng bổ sung vào công việc tồn đọng.

Kết quả là một công việc tồn đọng được cập nhật với các mục tiêu mới cho các lần chạy nước rút tiếp theo. Công việc tồn đọng có thể được thay đổi nếu tình hình yêu cầu.

Cải tiến nước rút

Cải tiến Sprint là một hội thảo thảo luận về cách cải thiện quy trình làm việc của bạn. Nó cũng tạo ra một kế hoạch cải tiến cho lần chạy nước rút tiếp theo. Cuộc họp thường diễn ra sau buổi đánh giá nước rút và kéo dài không quá ba giờ. Chủ trì cuộc họp là Scrum Master.

Các mục tiêu chính của Sprint Retrospective bao gồm:

Phân tích nước rút (công việc của người tham gia, kết quả và vấn đề).
Thảo luận các giải pháp khả thi để cải thiện quy trình làm việc trong các lần chạy nước rút tiếp theo.
Tạo một kế hoạch để thực hiện các cải tiến của các thành viên trong nhóm trong quá trình thực hiện dự án.

Scrum Master mời các thành viên trong nhóm đưa ra đề xuất về cách cải thiện hiệu quả phát triển. Nhóm thảo luận về các đề xuất và đề xuất một số cách thức và kỹ thuật để thực hiện chúng.

Khi kết thúc Sprint Retrospective, nhóm nên nêu bật một vài gợi ý cải tiến để thực hiện trong Sprint tiếp theo. Các đề xuất có thể được triển khai bất cứ lúc nào, nhưng Cải tiến Sprint tạo cơ hội để xem xét sâu hơn khả năng thích ứng của chúng theo quan điểm của nhóm.

Đây là nơi chúng ta kết thúc cuộc thảo luận về phương pháp Scrum. Bạn có thể tìm hiểu thêm về nó trong tài liệu chuyên đề hoặc tại nơi làm việc đầu tiên của bạn.