Các thuật ngữ trong Scrum chính xác là như thế nào ?
Bài đăng này đã không được cập nhật trong 4 năm
Bạn có biết một trong những khuyết điểm chính của mô hình Thác nước (Water Fall) truyền thống là - ngay khi giai đoạn đầu tiên của dự án hoàn thành, ứng dụng không chuyển sang giai đoạn khác. Và nếu có một số thay đổi trong giai đoạn sau, thì việc thực hiện những thay đổi đó trở nên rất khó khăn, vì nó sẽ liên quan đến việc phải xem lại các giai đoạn trước đó và phải làm lại các yêu cầu. Scrum đã khắc phục điều đó.
Một số đặc điểm chính của SCRUM
Team tự tổ chức và tập trung lại làm với nhau. Không có tài liệu yêu cầu lớn, thay vào đó có một bộ tài liệu rất chính xác. Các nhóm chức năng chéo làm việc cùng nhau như một đơn vị duy nhất. Liên lạc chặt chẽ với đại diện người dùng để hiểu các tính năng. Có một mốc thời gian xác định tối đa một tháng.
Thay vì thực hiện toàn bộ điều trên một lúc, Scrum thực hiện một chút mọi thứ trong một khoảng thời gian nhất định. Khả năng nguồn lực và tính sẵn sàng của team được xem xét kỹ lưỡng trước khi cam kết với khách hàng bất cứ điều gì.
Để hiểu rõ về phương pháp này, điều quan trọng là phải hiểu các thuật ngữ chính trong SCRUM.
1) Scrum Team
Scrum Team là một nhóm gồm 7 người + hoặc - hai thành viên. Các thành viên này là một tổ hợp năng lực bao gồm các nhà phát triển, người thử nghiệm, người phụ trách cơ sở dữ liệu, người hỗ trợ, vv cùng với chủ sở hữu sản phẩm và chủ scrum. Tất cả các thành viên này làm việc cùng nhau trong sự hợp tác chặt chẽ trong một khoảng thời gian đệ quy và xác định, để phát triển và thực hiện các tính năng đã nói.
Sắp xếp vị trí ngồi của đội SCRUM đóng một vai trò rất quan trọng trong sự tương tác của họ, họ không bao giờ ngồi riêng rẽ, mà sẽ là chung một cái bàn lớn.
2) Sprint
Sprint là khoảng thời gian hoặc khung thời gian được xác định trước trong đó công việc phải được hoàn thành và team phải làm cho nó sẵn sàng để xem xét hoặc sẵn sàng để triển khai sản xuất. Lượng thời gian này thường nằm trong khoảng từ 2 tuần đến 1 tháng. Khi team nói team đang theo chu kỳ Sprint 1 tháng, điều đó chỉ có nghĩa là team sẽ làm việc trong một tháng cho các nhiệm vụ đã được giao và sẽ phải làm cho ứng dụng trở nên sẵn sàng để demo vào cuối tháng đó.
3) Product Owner
Chủ sở hữu sản phẩm là bên liên quan chính hoặc người dùng chính của ứng dụng sẽ được phát triển. Chủ sở hữu sản phẩm là người đại diện cho phía khách hàng. Anh ấy / cô ấy có thẩm quyền cuối cùng và luôn luôn sẵn sàng giải đáp mọi thắc mắc cho team dự án. Anh ấy / cô ấy nên sẵn sàng khi bất kỳ ai trong team dự án đang có điều gì cần làm rõ. Điều quan trọng là chủ sở hữu sản phẩm phải hiểu và không chỉ định bất kỳ yêu cầu mới nào ở giữa giai đoạn nước rút hoặc khi nước rút đã bắt đầu.
4) Scrum Master
Scrum Master là người hỗ trợ của nhóm scrum. Anh ấy / cô ấy đảm bảo rằng nhóm scrum có năng suất và tiến bộ. Trong trường hợp có bất kỳ trở ngại, chủ scrum theo dõi và giải quyết chúng cho nhóm. SCRUM Master là người trung gian giữa PO và nhóm. Anh ấy / cô ấy giữ PO thông báo về tiến trình của Sprint. Nếu có bất kỳ rào cản hoặc mối quan tâm nào cho nhóm, hãy thảo luận với PO và giải quyết chúng. Giống như Standup (họp đầu giờ sáng) hàng ngày của nhóm, một standup của SCRUM Master với PO sẽ phải cùng có mặt với team mỗi ngày.
5) Business Analyst (BA)
Một người phân tích nghiệp vụ đóng một vai trò rất quan trọng trong SCRUM. Người này chịu trách nhiệm nhận được yêu cầu được hoàn thiện và soạn thảo lại cho vào trong các tài liệu yêu cầu (dựa trên những yêu cầu người dùng đã mong muốn). Nếu có bất kỳ sự mơ hồ nào trong tiêu chí yêu cầu khách hàng / Chấp nhận của Người dùng, anh ấy / cô ấy là người được nhóm kỹ thuật (SCRUM) tiếp cận và sau đó anh ấy sẽ đưa nó lên PO hoặc nếu không thì có thể tự mình giải quyết. Trong các dự án quy mô lớn, có thể sẽ có nhiều hơn 1 BA nhưng trong các dự án quy mô nhỏ, SCRUM Master cũng có thể đóng vai trò là BA. Luôn luôn là một thực hành tốt để có một BA từ trong giai đoạn khởi động dự án.
6) User Story
Story của người dùng không có gì ngoài những yêu cầu hoặc tính năng phải được thực hiện. Trong scrum, chúng tôi không có các tài liệu yêu cầu lớn đó, thay vào đó, các yêu cầu được xác định trong một đoạn văn bản ngắn gọn súc tích, thường có định dạng là: Là <Người dùng / loại người dùng> Tôi muốn <Một số mục tiêu / mục tiêu có thể đạt được> đạt được <một số kết quả hoặc lý do để thực hiện việc này> Ví dụ: Là Quản trị viên, tôi muốn khóa mật khẩu trong trường hợp người dùng nhập mật khẩu không chính xác trong 3 lần liên tiếp để hạn chế truy cập trái phép.
Có một số điều cần lưu tâm trong yêu cầu từ người dùng cần được tôn trọng. Các yêu cầu của người dùng nên ngắn gọn, thực tế, có thể được ước tính, đầy đủ, có thể thương lượng và kiểm tra được. Yêu cầu của người dùng không bao giờ bị thay đổi hoặc thay đổi ở giữa Sprint. Trách nhiệm của SCRUM Master và BA (nếu có thể) là đảm bảo rằng PO đã phác thảo chính xác Story của người dùng với một bộ Tiêu chí chấp nhận phù hợp. Nếu bất kỳ thay đổi nào sẽ ảnh hưởng đến việc phát hành demo cuối mỗi sprint, xử lý nước rút sẽ được thực hiện, thì những yêu cầu như vậy sẽ bị loại bỏ khỏi giai đoạn cuối sprint hoặc chúng sẽ được thực hiện theo kế hoạch có sẵn.
Mỗi yêu cầu của người dùng đều có một tiêu chí chấp nhận cần được nhóm dự án xác định và phải hiểu + nắm rõ.
Tiêu chí chấp nhận cũng do người dùng cung cấp hỗ trợ. Nó giúp tiếp tục tinh chỉnh story người dùng cụ thể hơn. Bất cứ ai trong nhóm cũng có thể viết ra các tiêu chí chấp nhận. Nhóm thử nghiệm sẽ đưa ra các trường hợp / điều kiện thử nghiệm của họ dựa trên các tiêu chí chấp nhận này.
7) Epics
Epics là những câu chuyện người dùng không rõ ràng hoặc chúng ta có thể nói rằng đây là những câu chuyện người dùng không được xác định và được lưu giữ cho những sprint trong tương lai.
Một Epic cũng giống như việc bạn sẽ cần phải lên kế hoạch cho kỳ nghỉ hè năm tới, nơi bạn chỉ biết rằng bạn có thể sẽ muốn đi, nhưng ở đâu, khi nào, với ai, tất cả những chi tiết này bạn đều không biết tại thời điểm hiện tại.
Theo cách tương tự, một tính năng bắt đầu với một Epic và sau đó được chia thành các câu chuyện có thể được thực hiện.
8) Backlog
Backlog sản phẩm là một nơi lưu giữ tất cả các yêu cầu của người dùng. Tài liệu được nắm giữ bởi Product Owner. Việc tồn đọng sản phẩm được tưởng tượng như một danh sách mong muốn của chủ sở hữu sản phẩm nhưng ưu tiên thấp, nó được đưa ra dựa theo nhu cầu kinh doanh.
9) Sprint Backlog
Dựa trên mức độ ưu tiên, các yêu cầu của người dùng được lấy từ Product Backlog mỗi lần. Nhóm Scrum sẽ cần xác định tính khả thi và quyết định các yêu cầu đó có được chọn để làm việc trong sprint nào cụ thể không. Danh sách tất cả các yêu cầu này của người dùng mà được nhóm scrum hoạt động trên 1 sprint tổng hợp thì sẽ được gọi là Sprint backlog.
10) Story Points
Là một dấu hiệu định lượng về sự phức tạp của một tập những yêu cầu từ người dùng. Dựa trên mỗi point, ước tính và nỗ lực cho một yêu cầu sẽ được xác định. Để đảm bảo rằng ước tính và nỗ lực của chúng tôi là chính xác, điều quan trọng là phải kiểm tra xem các yêu cầu của người dùng không quá lớn. Yêu cầu của người dùng càng chính xác và nhỏ hơn, thì ước tính sẽ càng chính xác.
11) Burn down chart
Biểu đồ ghi xuống là biểu đồ cho thấy khả năng thực tế so với khả năng ước tính ban đầu của team dự án
Đây là một cơ chế theo dõi sprint chạy cụ thể, các nhiệm vụ hàng ngày được theo dõi để kiểm tra xem các yêu cầu có đang tiến tới việc hoàn thành các điểm story đã cam kết hay không.
12) Velocity
Tổng số điểm story mà một nhóm scrum lưu lại được trong một lần chạy sprint thì được gọi là Vận tốc. Nhóm Scrum được đánh giá hoặc tham chiếu bởi vận tốc của nó. Nên nhớ rằng mục tiêu tham chiếu ở đây KHÔNG phải là đạt được điểm story tối đa, mà là để có một chất lượng có thể giao được tới khách hàng, thì phải tôn trọng sự thoải mái làm việc cho nhóm Scrum.
Một Sprint được đánh dấu là Done khi tất cả các story được hoàn thành, tất cả các nhiệm vụ dev, nghiên cứu, QA đều được đánh dấu 'Done', tất cả các bug được close, đánh giá code và Unit Test đã hoàn thành, số giờ ước tính đã đáp ứng số giờ thực tế đưa ra trong các nhiệm vụ và quan trọng nhất là bản demo thành công đã được giao tới cho PO và các bên liên quan.
All rights reserved
