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

0
115
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 linh hoạt”, 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 nhóm nhanh nhẹn sử dụng để lập kế hoạch công việc hiệu quả và trình bày công việc cần làm. Tiếp tục với loạt công cụ và kỹ thuật này, chúng ta sẽ tìm hiểu công cụ thứ hai không kém phần quan trọng, đó là điểm cốt truyện.

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

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 nhân viên có kinh nghiệm có thể hoàn thành user story với ước tính 3 điểm (3 point) trong một buổi sáng, nhưng một nhân viên mới có thể mất cả ngày để hoàn thành. vì vậy mục đích của 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ốt truyệ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 một câu chuyện của người dùng nhất định, là thước đo trừu tượng về nỗ lực cần thiết để làm cho nó xảy ra. Nói một cách dễ hiểu, điểm câu chuyện là một con số, một đơn vị đo lường thông báo cho toàn đội về độ khó của câu chuyện, độ khó có thể liên quan đến khối lượng công việc phải hoàn thành, mức độ phức tạp của công việc, rủi ro hoặc sự không chắc chắn. . làm việc để thực hiện đầy đủ một hạng mục công việc tồn đọng (backlog item) hoặc bất kỳ phần công việc nào khác.

Ước tính điểm cốt truyện, một loại ướ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 tôi nên sử dụng điểm câu chuyện?

Khi lập kế hoạch cho một dự án linh hoạt, nhóm thường không thể dự đoán thời gian cần thiết để tính năng sản phẩm/phần mềm 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ẽ chỉ định một giá trị điểm cho mỗi câu chuyện dựa trên kích thước của nó. đó 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 mức độ phức tạp của các tính năng thay vì thời gian chính xác để phát triển chúng, nhóm tham gia vào quá trình lập kế hoạch chung và đưa ra dự đoán về 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 tế về quản lý dự án linh hoạt)

làm cách nào để ước tính điểm câu chuyện trong Agile?

Các điểm của câu chuyện rất đơn giản: nhóm chỉ cần chọn một số điểm thể hiện quy mô, độ khó, độ phức tạp và khối lượng công việc cần thiết cho mỗi câu chuyện và chỉ định số đó cho từng câu chuyện của người dùng trong hồ sơ tồn đọng . Thay vì cố gắng dự đoán chính xác sẽ mất bao lâu để tạo một tính năng, nhóm chỉ định giá trị điểm số cho mỗi câu chuyện 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 đã được tạo trước đó. Ban đầu, các ước tính sẽ khác nhau rất nhiều giữa các câu chuyện, nhưng sau một thời gian, nhóm đã quen với quy mô mà họ sử dụng để ước tính, việc tính toán kích thước của mỗi câu chuyện sẽ trở nên dễ dàng hơn.

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

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

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

– có đủ thông tin để hoàn thành những vấn đề này không?

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

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

kích thước theo cỡ áo:

  • Các nhóm Scrum có thể dựa vào ý tưởng phân chia theo kích cỡ áo đấu để xác định kích cỡ và độ phức tạp của một câu chuyện và gán giá trị tính điểm cho từng kích cỡ. Định cỡ áo phông là một công cụ ước tính cấp cao, được sử dụng để đưa ra ước tính ban đầu về các tính năng của 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 thông tin chi tiết.
  • Để phản ánh sự không chắc chắn liên quan đến các ước tính đó, ước tính của chúng tôi sẽ là kích thước của áo sơ mi, từ cực nhỏ (es) đến cực lớn (xxl). .
  • Chúng tôi sẽ 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í kích thước đó lớn hơn hay nhỏ hơn bao nhiêu so với các kích thước khác. tất cả những gì chúng ta biết sẽ cực nhỏ nhỏ hơn nhỏ hơn nhỏ, nhỏ hơn trung bình, v.v.
  • Ví dụ, nhóm có thể quyết định sử dụng 1 điểm cho đặc tính rất nhỏ, 2 điểm cho đặc tính nhỏ (nhỏ), 3 điểm cho đặc tính trung bình, 4 điểm cho đặc tính lớn và 5 điểm cho đặc tính cực lớn.
  • rất nhỏ

    nhỏ

    trung bình

    lớn

    rất lớn

    1 điểm

    2 điểm

    3 điểm

    4 điểm

    5 điểm

    • lũy thừa 2: ngoài ra, nhiều nhóm còn sử dụng dãy số 1, 2, 4, 8, 16 được tạo bởi lũy thừa 2 để ước lượng số điểm câu chuyện .
    • chuỗi fibonacci cho điểm câu chuyện: khi nhóm đã quyết định kế hoạch chia tỷ lệ, nhóm phải 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 dãy fibonacci hoặc một số biến thể của dãy này (1, 2, 3, 5, 8, 13, 21…) kích thước của một câu chuyện, kích thước của một câu chuyện liên quan đến 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ì đó không phải là vấn đề đối với nhóm.
    • Viện Quản lý dự án ATOHA (Học Online, Offline, In-house)

      Mọi thứ chưa được hoàn thành trong lần chạy nước rút sẽ được chuyển từ lần chạy nước rút này sang lần chạy nước rút tiếp theo. và tổng số điểm câu chuyện đã hoàn thành trong mỗi lần chạy nước rút được ghi lại dưới dạng vận tốc (tốc độ; chúng ta sẽ tìm hiểu thêm về khái niệm này trong các bài đăng sau) của dự án. nếu một nhóm hoàn thành 15 câu chuyện với tổng số 55 điểm câu chuyện trong một lần chạy nước rút, nó sẽ coi 55 điểm câu chuyện này là tốc độ chạy nước rút và điều này giúp nhóm có cái nhìn tổng quan về tốc độ làm việc chung của nhóm, dự đoán tổng số điểm câu chuyện mà họ có thể đạt được thực hiện trong lần chạy nước rút tiếp theo.

      Theo thời gian, nhóm đã phân bổ điểm câu chuyện tốt hơn và ngày càng trở nên nhất quán về số điểm câu chuyện mà họ hoàn thành trong mỗi lần chạy nước rút. theo cách đó, nhóm có ý tưởng về mức độ họ có thể làm trong giai đoạn nước rút và họ cùng nhau 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 ta cần tìm một câu chuyện cơ bản của người dùng đáp ứng tiêu chuẩn định nghĩa dod rõ ràng và chỉ định một điểm câu chuyện cho câu chuyện đó. tin gốc được dùng làm cơ sở khi so sánh các tin khác.

        • bước 2: tạo ma trận để ước lượng
        • nhóm sẽ ước tính số điểm của câu chuyện như mô tả ở trên (mục 3). Sau đó, 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 chúng. Sau đó, nhóm tập hợp tất cả các câu chuyện và bắt đầu sắp xếp 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ơ bản khác. lưu ý rằng cốt truyện cơ sở đã có trong mảng này, ở hàng đầu tiên với giá trị là một điểm cốt truyện.

          điểm nhấn của câu chuyện

          lịch sử

          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ề các dịch vụ.

          2

          3

          5

          8

          để chỉ định điểm câu chuyện cho mỗi câu chuyện, nhóm 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 bài xì phé lập kế hoạch để đưa ra số điểm câu chuyện cho một câu chuyện.

          xì phé lập kế hoạch là một kỹ thuật ước tính dựa trên sự đồng thuận được sử dụng để ước tính danh mục sản phẩm. 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 bài xì phé với các điểm câu chuyện.

          bước 3: lập kế hoạch cho quá trình ước lượng bài xì phé

          • mỗi thành viên nhận được một bộ thẻ.
          • tất cả thành viên chọn các mục đang chờ xử lý để ước tính, thảo luận về các tính năng và đặt câu hỏi.
          • khi một tính năng đã được thảo luận đầy đủ, mỗi người trình bày ước tính của riêng mình, đảm bảo tính bảo mật và chọn một thẻ để thể hiện ước tính của họ.
          • Khi mọi người đã ước tính được câu chuyện, họ ngay lập tức tiết lộ thẻ của mình. nếu tất cả các ước tính phù hợp, nhóm sẽ chọn một mục đang chờ xử lý khác và lặp lại quy trình tương tự. khi ước tính chênh lệch quá nhiều, mọi người sẽ thảo luận vấn đề để đi đến thống nhất.
          • khi kết thúc việc lập kế hoạch poker, đội sẽ điền tất cả các kết quả thu được vào ma trận. Các câu chuyện của người dùng nhóm được chia thành các hàng dựa trên các điểm câu chuyện tương ứng cần thiết để chạy chúng. có thể có nhiều câu chuyện liên tiếp.

            điểm nhấn của câu chuyện

            lịch sử

            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ề các dịch vụ.

            với tư cách là 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

            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ể gửi phản hồi hoặc báo cáo sự cố bằng cách sử dụng biểu mẫu liên hệ.

            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.

            Là người dùng đã đăng ký, tôi muốn thêm nhận xét vào nội dung của trang web.

            5

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

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

            8

            với tư cách là người dùng đã đăng ký, tôi muốn có thể thêm nội dung vào tiêu đề trang web, mô tả, nội dung đa 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 ký, tôi muốn có thể giao tiếp qua tin nhắn với những người dùng khác.

            • bước 4: lập kế hoạch chạy nước rút
            • Tại thời điểm này, nhóm đã có ước tính về mức độ 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 có thể chuyển đổi các điểm câu chuyện này thành các ước tính thời gian thực (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 được hoàn thành. Trong khi chạy nước rút đầu tiên đang diễn ra, nhóm có thể theo dõi tốc độ của nhóm. ngay sau khi Sprint kết thúc, bạn sẽ biết có bao nhiêu điểm câu chuyện mà nhóm có thể hoàn thành trong mỗi Sprint. nhóm sử dụng những con số này để dự đoán hiệu suất của nó cho lần chạy nước rút tiếp theo.

              Bằng cách ước tính tất cả công việc tồn đọng dựa trên các điểm câu chuyện, scrum có thể biết nhóm sẽ cần bao nhiêu lần chạy nước rút để hoàn thành dự án. và 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 điểm câu chuyệ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 đưa ra cam kết về thời gian hoàn thành để biến nó thành chính xác. Giả sử ước lượng story point có khoảng thời gian từ 10 đến 20 tiếng, nhưng khi ước lượng theo giờ thì team phải đưa ra con số chính xác như 15 tiếng, sẽ dẫn đến sai lệch, khó đạt được cam kết cao hơn khi làm việc vào những giờ chính xác.
              • cung cấp điểm câu chuyện trung bình:trong lập kế hoạch poker, một nửa số thành viên trong nhóm ước tính rằng một hạng mục danh mục sản phẩm có 3 điểm câu chuyện và nửa còn lại ước tính 5 điểm câu chuyện. nhóm đã giải quyết nó bằng cách ước tính 4 điểm câu chuyện. nhóm không nên làm điều này vì nhóm đang thỏa hiệp với việc cung cấp sai độ chính xác. tốt hơn là cả nhóm nên thảo luận để hiểu rõ hơn thay vì lấy giá trị trung bình.
              • điều chỉnh ước tính điểm câu chuyện của người dùng trong giai đoạn nước rút: khi nhóm bắt đầu giải quyết vấn đề, 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 bạn không chính xác. Việc ước tính đôi khi bị sai là điều bình thường, vì vậy nhóm không nên điều chỉnh mà hãy lưu lại thông tin này, làm cơ sở để xác định điểm cốt truyện trong tương lai chính xác hơn.
              • đánh giá lại các điểm câu chuyện cho các vấn đề chưa hoàn thành: khi di chuyển một hạng mục tồn đọng chưa hoàn thành sang lần chạy nước rút tiếp theo, không cần phải ước tính lại. 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à mỗi giờ. do đó, đến lần chạy nước rút tiếp theo, nhóm sẽ biết sẽ mất bao lâu để hoàn thành mục tồn đọng này.
              • điều chỉnh ước tính điểm câu chuyện dựa trên nhà điều hành: câu chuyện của người dùng có thể là 3 điểm câu chuyện đối với thành viên có kinh nghiệm nhưng là 8 điểm câu chuyện đối với thành viên mới. đây là cách sai để làm điều đó. chúng ta không nên điều chỉnh điểm của câu chuyện bởi vì một người cụ thể sẽ thực hiện công việc. bởi vì điểm của câu chuyện chỉ dựa trên quy mô, độ phức tạp và độ khó của câu chuyện của người dùng.
              • tuân theo ý kiến ​​của các chuyên gia trong nhóm:khi lập kế hoạch chơi poker, có rủi ro là nhóm sẽ tuân theo ý kiến ​​của các chuyên gia chứ không phải là sự kết hợp các bộ phận của từng thành viên. các nhóm thường giải quyết công việc bằng cách để các chuyên gia trình bày chi tiết công việc. sau đó để 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 phải nhớ rằng ước tính điểm câu chuyện là nỗ lực của cả nhóm chứ không phải của một thành viên nào.
              • không thảo luận lại sự không chính xác của ước tính điểm câu chuyện trong cải tiến nước rút: đôi khi, nhóm xác định các vấn đề hiển nhiên khi ước tính điểm câu chuyện hoàn toàn sai . điều quan trọng là 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 chính xác hơn.
              • tóm tắt

                Khái niệm điểm câu chuyện đơn giản nhưng khó áp dụng. hầu như tất cả các 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ì điều này, mọi người có ý kiến ​​​​khác nhau về cách bạn nên sử dụng chúng. Việc sử dụng các điểm câu chuyện ngay từ đầu có thể khiến nhóm ước tính sai, nhưng sau một thời gian, việc cùng nhau hiểu và kiểm soát kế hoạch, nhất quán hơn về số điểm họ đạt được trong mỗi lần chạy nước rút sẽ giúp nhóm trưởng thành hơn và thực hiện công việc ước tính nhiều hơn nhẹ hơn. và dễ dàng hơn.

                kiến thức chung của huấn luyện 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, nhanh nhẹn đầu tiên, mô hình trực quan, moutaingoatsoftware, trung bình, ruby.garage

                tồn đọng sản phẩm là gì? nó liên quan như thế nào đến wbs?

                bản tuyên ngôn linh hoạt – lịch sử linh hoạt

                12 nguyên tắc nhanh nhẹn

                trong các dự án linh hoạt, công việc ước tính có thực sự cần thiết không?

                quản lý dự án với scrum

                đám mây

                câu chuyện của người dùng: công cụ lập kế hoạch linh hoạt

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

                tốc độ là gì: tốc độ hoàn thành công việc của nhóm nhanh nhẹn

                bản đồ câu chuyện: lập kế hoạch linh hoạt

                hồi tưởng linh hoạt: nhìn lại và cải thiện hiệu suất dự án

                kanban: phương pháp 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

                personas – công cụ xây dựng hình ảnh khách hàng một cách linh hoạt

                tinh gọn: hợp lý hóa các quy trình một cách hiệu quả

                hướng dẫn scrum 2020 – hướng dẫn scrum 2020

                bóng đá là 3-5-2, scrum là 3-5-3

                chúng ta bắt đầu với scrum từ đâu?

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

LEAVE A REPLY

Please enter your comment!
Please enter your name here