Viện Quản lý dự án ATOHA (Học Online, Offline, In-house)

Viện Quản lý dự án ATOHA (Học Online, Offline, In-house)

Như đã chia sẻ trong bài viết “Câu chuyện của người dùng – Công cụ lập kế hoạch nhanh nhẹn” , chúng tôi đã đề cập đến Câu chuyện của người dùng – một trong những công cụ. Các công cụ mà nhóm nhanh nhẹn sử dụng để lập kế hoạch hiệu quả và những việc cần làm ngay bây giờ. Tiếp tục loạt công cụ và kỹ thuật này, chúng ta sẽ tìm hiểu một công cụ thứ hai, quan trọng không kém, Điểm câu chuyện .

Đương nhiên, chúng tôi khó đưa ra ước tính tuyệt đối chính xác, nhưng việc lập ước tính bằng cách so sánh với một yếu tố khác (ước tính) sẽ dễ dàng và thoải mái hơn. lượng tương đối). Điều này cũng đúng đối với các nhóm nhanh nhẹn, những người coi trọng các ước tính tương đối. Hầu hết các ước tính của họ không tính bằng giờ / ngày / tuần mà là một đơn vị tương đối được gọi là “ điểm câu chuyện “.

Bạn Đang Xem: Viện Quản lý dự án ATOHA (Học Online, Offline, In-house)

Một lý do khác để sử dụng công cụ ước tính tương đối là mỗi thành viên trong nhóm làm việc với tốc độ khác nhau. Ví dụ, một câu chuyện của người dùng với số điểm ước tính là 3 (3 điểm) có thể được hoàn thành trong một buổi sáng bởi một nhân viên có kinh nghiệm, nhưng có thể mất cả ngày để một nhân viên mới hoàn thành. Vì vậy, các điểm câu chuyện chỉ tập trung vào việc ước tính quy mô và độ phức tạp của câu chuyện.

Điểm câu chuyện?

Điểm câu chuyện là một thuật ngữ được sử dụng trong quản lý và phát triển dự án để ước tính quy mô, độ khó và độ phức tạp của việc triển khai câu chuyện của người dùng nhất định, là một thước đo trừu tượng về nỗ lực cần thiết để thực hiện nó. Tóm lại, điểm câu chuyện là một con số, một đơn vị đo lường mức độ khó khăn để kể một câu chuyện cho cả nhóm. hoặc không chắc chắn. Nỗ lực thực hiện đầy đủ một mục trong Product Backlog (danh sách việc cần làm) hoặc bất kỳ công việc nào khác.

Ước tính điểm câu chuyện, một ước tính tương đối, thường được thực hiện trong các cuộc thảo luận về sản phẩm tồn đọng.

Viện Quản lý dự án ATOHA (Học Online, Offline, In-house)

Tại sao lại sử dụng điểm câu chuyện?

Khi lập kế hoạch cho các dự án nhanh, các nhóm thường không thể dự đoán các tính năng của sản phẩm / phần mềm sẽ mất bao lâu hoặc ngày hoàn thành chính xác của chúng. Khi ước tính theo giờ / ngày / tuần, bạn phải cam kết thời gian chính xác. Thay vào đó, khi sử dụng điểm câu chuyện, nhóm sẽ gán cho mỗi câu chuyện một giá trị điểm dựa trên quy mô của nó. Đây là lý do tại sao hầu hết các nhóm scrum sử dụng các điểm câu chuyện để lập kế hoạch cho các dự án của họ, cho phép họ so sánh các câu chuyện. Bằng cách tập trung vào độ phức tạp của các tính năng hơn là thời gian chính xác chúng được phát triển, các nhóm có thể tham gia lập kế hoạch cùng nhau và dự đoán những tính năng gia tăng nào có thể được thêm vào phần mềm / sản phẩm sau mỗi chu kỳ.

(Xem thêm: Khóa đào tạo thực hành về quản lý dự án Agile)

Làm thế nào để ước tính điểm câu chuyện trong nhanh?

Điểm câu chuyện rất đơn giản: nhóm chỉ cần chọn một số điểm đại diện cho quy mô, độ khó, độ phức tạp và nỗ lực cần thiết cho mỗi câu chuyện và chỉ định số điểm đó cho mỗi câu chuyện của người dùng trong tồn đọng. Thay vì cố gắng dự đoán chính xác thời gian để xây dựng một tính năng, nhóm đã chỉ định cho mỗi câu chuyện một số điểm dựa trên độ phức tạp của nó sau khi so sánh nó với các tính năng khác mà nhóm đã biết. Ban đầu, ước tính cho mỗi câu chuyện sẽ rất khác nhau, nhưng sau một thời gian, khi nhóm đã quen với kích thước mà nhóm sử dụng để ước tính, việc tính toán kích thước của mỗi câu chuyện trở nên dễ dàng hơn.

Khi chúng tôi sử dụng điểm câu chuyện để ước tính, chúng tôi chỉ định mỗi mục một giá trị điểm. Giá trị ban đầu được sử dụng bởi nhóm không quan trọng. Điều quan trọng là các giá trị này là tương đối. Ví dụ: Điểm phân công câu chuyện là 2 phải gấp đôi Điểm phân công câu chuyện là 1. Nó cũng phải là 2/3 câu chuyện, ước tính là 3 điểm câu chuyện. Ngoài việc chỉ định 1, 2 và 3, các nhóm có thể chỉ định 100, 200 và 300. Hoặc 1 triệu, 2 triệu và 3 triệu. Điều quan trọng là tần suất chứ không phải con số thực tế (giờ / ngày / tuần).

Trong sơ đồ, để lập kế hoạch sprint hiệu quả hơn, chủ sở hữu sản phẩm và nhóm phát triển sẽ đưa ra một ước tính sơ bộ và kiểm tra trước khi lập kế hoạch sprint khi tinh chỉnh sản phẩm tồn đọng:

– Sẵn sàng thực hiện kế hoạch chạy nước rút một cách hiệu quả?

– Có đủ thông tin để hoàn thành những câu hỏi này không?

– Các câu chuyện của người dùng có được phân chia chính xác không?

Có nhiều cách để ước tính điểm câu chuyện trong nhanh và mỗi nhóm sẽ thống nhất về cách tính toán. Trong hầu hết các trường hợp, các điểm câu chuyện được tính theo một trong các thang đo sau:

Theo Cỡ áo phông:

  • Nhóm scrum có thể dựa trên ý tưởng chia nhỏ theo kích cỡ áo thun để xác định kích thước và độ phức tạp của câu chuyện và gán giá trị điểm cho mỗi kích cỡ. T-Shirt Size là công cụ ước tính nâng cao được sử dụng để ước tính ban đầu về tính năng sản phẩm và câu chuyện của người dùng trong giai đoạn đầu của dự án (khi không có nhiều chi tiết).
  • Để phản ánh sự không chắc chắn liên quan đến những ước tính này, ước tính của chúng tôi sẽ là kích thước áo phông, từ cực nhỏ đến cực lớn (xxl). .
  • Chúng tôi không cố gắng ước tính kích thước tuyệt đối của từng danh mục hoặc thậm chí là kích thước so với các kích thước khác. Tất cả những gì chúng ta biết sẽ là siêu nhỏ ít hơn nhỏ, ít hơn trung bình, v.v.
  • Ví dụ: một nhóm có thể quyết định sử dụng tính năng rất nhỏ 1 điểm, tính năng nhỏ (nhỏ) 2 điểm, tính năng trung bình 3 điểm và phép tính 4 điểm. Yamato 5 điểm là rất lớn.
  • Siêu nhỏ

    Nhỏ

    Trung bình

    lớn

    Quá khổ

    1 điểm

    2 điểm

    3 điểm

    4 điểm

    5 điểm

    • Quyền hạn của 2: Ngoài ra, nhiều nhóm cũng sử dụng dãy số 1, 2, 4, 8, 16 được tạo bởi lũy thừa của 2 để ước tính số điểm của câu chuyện.
    • Chuỗi Fibonacci của các điểm câu chuyện: Khi nhóm đã quyết định về kế hoạch mở rộng quy mô, nhóm cần thống nhất và quyết định áp dụng phương pháp tính điểm nào. Một số nhóm sử dụng chuỗi Fibonacci hoặc một số biến thể của chuỗi (1, 2, 3, 5, 8, 13, 21 …) làm điểm cốt truyện vì họ tin rằng chuỗi Fibonacci cung cấp chế độ xem Câu chuyện thực tế hơn, quy mô của một câu chuyện tương đối với một câu chuyện khác. Miễn là nhóm của bạn sử dụng thang đo một cách nhất quán, thì việc sử dụng nó sẽ không thành vấn đề đối với nhóm của bạn.
    • Viện Quản lý dự án ATOHA (Học Online, Offline, In-house)

      Bất cứ điều gì chưa hoàn thành trong một nước rút sẽ được chuyển từ nước rút này sang nước rút tiếp theo. Và tổng số điểm câu chuyện đã hoàn thành trong mỗi nước rút được theo dõi dưới dạng vận tốc của dự án (vận tốc – chúng ta sẽ tìm hiểu thêm về khái niệm này trong một bài đăng trong tương lai). Nếu một nhóm hoàn thành 15 câu chuyện trong một chặng nước rút với tổng số điểm là 55 câu chuyện, họ sẽ coi 55 điểm câu chuyện đó là vận tốc nước rút, điều này cung cấp cho nhóm một ý tưởng chung về tốc độ chung của cả nhóm, dự đoán tổng số điểm câu chuyện mà họ có Có thể thành công trong nước rút tiếp theo.

      Xem Thêm : All about supply chain…

      Theo thời gian, các nhóm trở nên tốt hơn trong việc chỉ định điểm câu chuyện và họ trở nên nhất quán hơn về số điểm câu chuyện mà họ hoàn thành trong mỗi sprint. Bằng cách này, các nhóm có thể xem họ có thể làm được bao nhiêu trong một chặng nước rút và cùng kiểm soát kế hoạch.

      Quy trình ước tính điểm câu chuyện

      • Bước 1: Xác định câu chuyện cơ sở
      • Để tìm câu chuyện cơ sở, chúng tôi cần tìm câu chuyện cơ sở của người dùng đáp ứng các tiêu chí được xác định rõ ràng để xác định dod và gán cho câu chuyện đó một điểm cốt truyện. Câu chuyện cơ sở được dùng làm cơ sở khi so sánh các câu chuyện khác.

        • Bước 2: Tạo ma trận để ước tính
        • Nhóm sẽ ước tính điểm câu chuyện (mục 3) như mô tả ở trên. Tiếp theo, nhóm sẽ tạo một ma trận với mỗi hàng cho mỗi điểm câu chuyện (ví dụ bên dưới sử dụng số Fibonacci) và các câu chuyện liên quan của nó. Sau đó, nhóm sẽ thu thập tất cả các câu chuyện và bắt đầu phân loại chúng thành các hàng, so sánh các câu chuyện với nhau và với các câu chuyện đã hoàn thành hoặc câu chuyện cơ sở khác. Lưu ý rằng câu chuyện cơ sở đã có trong ma trận này, ở hàng đầu tiên và giá trị là một điểm câu chuyện.

          Cốt truyện

          Câu chuyện

          1

          Với tư cách là khách truy cập trang web, tôi muốn truy cập trang Giới thiệu để tìm hiểu thêm về dịch vụ.

          2

          3

          5

          Xem Thêm : Cách phân biệt Toyota Vios G và Vios Limo

          8

          Để chỉ định điểm câu chuyện cho mỗi câu chuyện, nhóm tổ chức một cuộc họp, trong đó tất cả các thành viên của nhóm phát triển sẽ sử dụng poker lập kế hoạch để xác định điểm câu chuyện cho một câu chuyện.

          Plan Poker là một kỹ thuật ước tính dựa trên sự đồng thuận để ước tính lượng sản phẩm tồn đọng. Nó có thể được sử dụng với nhiều công cụ ước tính khác nhau, nhưng ở đây chúng tôi đang lập kế hoạch chơi poker với các điểm cốt truyện.

          Bước 3: Lập kế hoạch Quy trình Ước tính Poker

          • Mỗi thành viên nhận được một bộ thẻ.
          • Tất cả các thành viên chọn các thông tin tồn đọng để ước tính, thảo luận về các tính năng và đặt câu hỏi.
          • Sau khi thảo luận kỹ lưỡng về một tính năng, mọi người sẽ đưa ra ước tính của riêng mình – giữ bí mật và chọn một thẻ để đại diện cho ước tính của họ.
          • Sau khi mọi người có ước tính riêng của họ về câu chuyện, họ sẽ ngay lập tức hiển thị thẻ của mình. Nếu tất cả các ước tính đều khớp, nhóm sẽ chọn một mục tồn đọng khác và lặp lại quy trình tương tự. Khi các ước tính chênh lệch quá nhiều, vấn đề sẽ được thảo luận để đạt được sự đồng thuận.
          • Khi kết thúc trò chơi poker theo kế hoạch, nhóm sẽ điền vào ma trận với tất cả các kết quả thu được. Các câu chuyện người dùng của nhóm được chia thành các dòng dựa trên các điểm câu chuyện tương ứng được yêu cầu để thực hiện chúng. Một dòng có thể có nhiều câu chuyện.

            Cốt truyện

            Câu chuyện

            1

            Với tư cách là khách truy cập trang web, tôi muốn truy cập trang Giới thiệu để tìm hiểu thêm về dịch vụ.

            Là một khách truy cập vào trang web, tôi muốn có thể đặt lại mật khẩu của mình nếu tôi quên.

            2

            Với tư cách là người dùng đã đăng nhập, tôi muốn có thể xem lịch sử thanh toán của mình trên trang cài đặt.

            Với tư cách là khách truy cập trang web, tôi muốn có thể sử dụng biểu mẫu liên hệ để gửi phản hồi hoặc báo cáo sự cố.

            3

            Với tư cách là khách truy cập trang web, tôi muốn đăng nhập / đăng ký bằng email / mật khẩu của mình.

            Với tư cách là người dùng đã đăng nhập, tôi muốn thêm nhận xét vào nội dung trên trang web.

            5

            Với tư cách là khách truy cập vào trang web của tôi, tôi muốn sử dụng biểu mẫu tìm kiếm với các bộ lọc để tìm kiếm nội dung cụ thể.

            Là một khách truy cập vào trang web, tôi muốn xem thông tin chi tiết về nội dung.

            Xem Thêm : Cách phân biệt Toyota Vios G và Vios Limo

            8

            Với tư cách là người dùng đã đăng nhập, tôi muốn có thể thêm nội dung vào tiêu đề trang web, mô tả, nội dung phương tiện (hình ảnh, video, âm thanh), vị trí địa lý.

            p>

            Với tư cách là người dùng đã đăng nhập, tôi muốn có thể giao tiếp với những người dùng khác qua tin nhắn.

            • Bước 4: Lập kế hoạch Sprint
            • Tại thời điểm này, nhóm có ước tính độ lớn dựa trên các điểm câu chuyện, câu hỏi đặt ra là làm cách nào nhóm chuyển các điểm câu chuyện này thành ước tính thời gian thực tế (giờ / ngày / tuần). Thật không may, nhóm không thể làm điều này cho đến khi nước rút đầu tiên hoàn thành. Khi chạy nước rút đầu tiên, nhóm có thể theo dõi vận tốc của nhóm. Khi nước rút kết thúc, nó biết được nhóm có thể hoàn thành bao nhiêu điểm câu chuyện trong mỗi lần chạy nước rút. Các đội sử dụng những con số này để dự đoán xem họ sẽ thể hiện như thế nào trong nước rút tiếp theo.

              Khi ước tính tất cả công việc tồn đọng dựa trên các điểm của câu chuyện, scrum có thể xem nhóm sẽ cần bao nhiêu nước rút để hoàn thành dự án. Cuối cùng, nhóm có thể biến các đơn vị trừu tượng này thành dữ liệu thời gian thực.

              Các lỗi thường gặp khi sử dụng cốt truyện

              • Chuyển đổi Điểm câu chuyện thành Giờ: Bằng cách chuyển đổi Điểm câu chuyện thành Giờ / Ngày / Tuần, nhóm sẽ bắt đầu làm việc và phải mạo hiểm thực hiện các cam kết về thời gian phù hợp để hoàn thành. Giả sử khung thời gian để ước tính điểm câu chuyện là 10 – 20 giờ, nhưng khi ước tính theo giờ, nhóm phải đưa ra một con số chính xác, chẳng hạn như 15 giờ, điều này có thể dẫn đến sai lệch và khiến bạn khó đạt được cam kết hơn khi ‘ đang làm việc vào một thời gian chính xác.
              • Đưa ra điểm câu chuyện trung bình: Khi lập kế hoạch chơi poker, một nửa số thành viên trong nhóm ước tính một mặt hàng tồn đọng của sản phẩm là 3 điểm câu chuyện và nửa còn lại ước tính nó là 5 điểm câu chuyện. Nhóm nghiên cứu đã giải quyết vấn đề này bằng cách đặt 4 điểm câu chuyện làm ước tính. Các đội không nên làm điều này vì các đội sẽ thỏa hiệp bằng cách cung cấp độ chính xác sai. Tốt hơn hết bạn nên để cả nhóm thảo luận để hiểu rõ hơn là lấy điểm trung bình.
              • Điều chỉnh ước tính điểm câu chuyện cho câu chuyện của người dùng trong thời gian chạy nước rút: Khi nhóm bắt đầu giải quyết vấn đề, các nhóm không nên điều chỉnh ước tính điểm câu chuyện, ngay cả khi ước tính của họ không. Đúng. Việc ước tính bị sai theo thời gian là điều bình thường, vì vậy thay vì điều chỉnh, các đội nên lưu lại thông tin này để làm cơ sở xác định chính xác hơn các điểm câu chuyện trong tương lai.
              • Đánh giá lại các điểm câu chuyện cho các vấn đề còn mở: Không cần đánh giá lại khi chuyển một mục Product Backlog đang mở sang sprint tiếp theo. Các ước tính có thể không chính xác, nhưng đó không phải là vấn đề. Nhờ lập kế hoạch chạy nước rút, nhóm sẽ biết tất cả các nhiệm vụ cần thiết để hoàn thành câu chuyện của người dùng. Ước tính cho các nhiệm vụ này là hàng giờ. Do đó, trong nước rút tiếp theo, nhóm sẽ biết mình sẽ mất bao nhiêu thời gian để hoàn thành việc tồn đọng sản phẩm này.
              • Điều chỉnh ước tính điểm câu chuyện dựa trên toán tử: Câu chuyện của người dùng có thể là 3 điểm câu chuyện cho thành viên có kinh nghiệm và 8 điểm câu chuyện cho thành viên mới. Đây là phương pháp sai. Chúng ta không nên điều chỉnh các điểm câu chuyện vì những người cụ thể sẽ thực hiện công việc. Bởi vì điểm câu chuyện chỉ dựa trên quy mô, độ phức tạp và độ khó của câu chuyện người dùng.
              • Thực hiện theo lời khuyên của các chuyên gia trong nhóm: Khi lập kế hoạch chơi poker, nhóm có thể làm theo lời khuyên của các chuyên gia thay vì kết hợp các bên. mỗi thành viên. Các nhóm thường giải quyết công việc bằng cách nhờ các chuyên gia trình bày các chi tiết của công việc. Sau đó, yêu cầu những người còn lại trong nhóm ước tính mà không cần chuyên gia. Chúng ta cần nhớ rằng ước tính điểm câu chuyện là nỗ lực của cả nhóm, không chỉ của bất kỳ thành viên nào.
              • Điểm không chính xác trong ước tính điểm câu chuyện không được xem xét lại trong phần hồi cứu nước rút: Đôi khi các nhóm nhận thấy vấn đề rõ ràng khi ước tính điểm câu chuyện hoàn toàn sai. Điều quan trọng là phải thảo luận về những vấn đề này và cố gắng học hỏi và cải thiện để các ước tính trong tương lai sẽ chính xác hơn.
              • Tóm tắt

                Khái niệm về điểm cốt truyện rất đơn giản, nhưng khó áp dụng. Hầu hết mọi nhóm scrum đều sử dụng chúng, nhưng chúng không phải là một phần của các công cụ scrum cốt lõi. Vì vậy, mọi người có ý kiến ​​khác nhau về cách sử dụng chúng. Việc sử dụng các điểm câu chuyện ngay từ đầu có thể dẫn đến các ước tính sai lệch của nhóm, nhưng theo thời gian, việc hiểu và kiểm soát kế hoạch cùng nhau và số điểm được giao trong mỗi nước rút nhất quán hơn sẽ giúp nhóm trưởng thành hơn và làm cho các ước tính hoạt động dễ dàng hơn và dễ dàng hơn.

                Kiến thức chung của giảng viên nguyễn hải hà (pmp®, giảng viên pmi-atp)

                Tài liệu tham khảo: luyện thi pmi-acp, đầu óc nhanh nhẹn, mô hình trực quan, moutaigoatsoftware, medium, ruby.garage

                Product Backlog là gì? Nó liên quan gì đến wbs

                Tuyên ngôn Agile – Lịch sử của Agile

                12 nguyên tắc của Agile

                Việc ước tính có thực sự cần thiết trong một dự án nhanh không?

                Sử dụng scrum để quản lý dự án

                những câu nói lảm nhảm

                Câu chuyện của người dùng – Công cụ lập kế hoạch nhanh nhẹn

                Điểm câu chuyện – Công cụ ước tính nhanh nhẹn

                Vận tốc là gì – Một nhóm nhanh nhẹn hoàn thành công việc nhanh như thế nào

                Bản đồ câu chuyện – Lập kế hoạch nhanh nhẹn

                Agile Retrospective – Đánh giá và Cải thiện Hiệu suất Dự án

                Kanban – một cách giúp cải thiện quy trình làm việc của dự án

                pdca – Chu kỳ cải tiến liên tục

                Vai trò – một công cụ để xây dựng sự hiện diện của khách hàng một cách linh hoạt

                Lean – Các quy trình được sắp xếp hợp lý một cách hiệu quả

                Hướng dẫn Scrum 2020 – Hướng dẫn Scrum 2020

                Bóng đá có 3-5-2, scrum có 3-5-3

                Chúng ta bắt đầu scrum từ đâu?

                Một số cách để thực hiện một cách hiệu quả một công việc hàng ngày

Nguồn: https://anhvufood.vn
Danh mục: Kinh Nghiệm

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *