Story points - Công cụ ước lượng của Agile

Story points là 1 trong thuật ngữ được dùng nhập quản lý và vận hành và cải tiến và phát triển dự án công trình nhằm ước tính sự cân đối, Mức độ cạnh tranh, chừng phức tạp mang lại việc làm xây dựng một user story chắc chắn, là 1 trong thước đo trừu tượng về nỗ lực quan trọng nhằm triển khai nó. Nói một cơ hội dễ nắm bắt, story points là 1 trong số lượng, một đơn vị chức năng tính toán cho tất cả group biết về Mức độ cạnh tranh của story, trở ngại rất có thể tương quan cho tới lượng việc làm cần thực hiện, cường độ phức tạp của việc làm, khủng hoảng hoặc sự ko chắc chắn rằng của việc làm nhằm triển khai rất đầy đủ một khuôn khổ nhập Product Backlog (backlog item) hoặc ngẫu nhiên phần việc làm này không giống.

Như đang được share nhập nội dung bài viết “User stories - Công cụ lên plan của Agile”, tất cả chúng ta đang được nói đến User stories - một trong mỗi dụng cụ được những group Agile dùng nhằm lập plan thao tác làm việc và thể hiện tại những khuôn khổ cần thiết triển khai một cơ hội hiệu suất cao. Tiếp tục với chuỗi những dụng cụ, nghệ thuật này, tất cả chúng ta tiếp tục nằm trong thám thính hiểu dụng cụ thứ hai ko xoàng phần cần thiết cơ chủ yếu là Story Points.

Bạn đang xem: Story points - Công cụ ước lượng của Agile

Theo bất ngờ thì tất cả chúng ta khó khăn rất có thể thể hiện những ước tính vô cùng một cơ hội đúng mực, tuy nhiên tiếp tục đơn giản dễ dàng và tự do thoải mái rộng lớn trong các việc thể hiện những ước tính bằng phương pháp đối chiếu với cùng một nhân tố không giống (ước lượng tương đối). Các group Agile cũng vậy, chúng ta tôn vinh việc ước tính kha khá. Họ triển khai đa số những ước tính của mình ko cần theo dõi giờ/ngày/tuần, tuy nhiên vì thế một đơn vị chức năng kha khá được gọi là "Story points".

Một nguyên nhân không giống nhằm dùng ước tính kha khá này đó là từng member nhập group thao tác làm việc ở vận tốc không giống nhau. Ví dụ một user story đem ước tính là 3 points (3 điểm) rất có thể được triển khai xong vì thế một nhân viên cấp dưới đem kinh nghiệm tay nghề nhập một buổi sáng sớm tuy nhiên một nhân viên cấp dưới mới nhất rất có thể cần mất mặt xuyên suốt một ngày mới nhất triển khai xong. Nên story point chỉ triệu tập nhập ước tính sự cân đối, chừng phức tạp của story.

Story points là gì?

Ước lượng vì thế story points, một loại ước tính kha khá, thông thường được triển khai bên trên cuộc thảo luận về Product Backlog.

Tại sao nên dùng story points?

Khi lập plan cho 1 dự án công trình Agile, thông thường thì group sẽ không còn thể Dự kiến được những công dụng của sản phẩm/phần mượt tiếp tục triển khai nhập bao lâu hoặc ngày triển khai xong đúng mực của bọn chúng. Khi dự tính theo dõi giờ/ngày/tuần, chúng ta cần thể hiện khẳng định thời hạn đúng mực. Thay nhập cơ, Lúc dùng story point, group chỉ định và hướng dẫn một độ quý hiếm điểm (point) cho từng story dựa vào sự cân đối của chính nó. Đó là nguyên nhân tại vì sao đa số group Scrum dùng story points nhằm lập plan dự án công trình của mình, được chấp nhận chúng ta đối chiếu những stories cùng nhau. bằng phẳng cơ hội triệu tập nhập chừng phức tạp của những công dụng chứ không thời hạn đúng mực nhằm cải tiến và phát triển bọn chúng, group nhập cuộc lập plan bên cạnh nhau và thể hiện Dự kiến những công dụng tăng thêm này rất có thể được thêm nữa phần mềm/sản phẩm sau từng vòng lặp.

(Xem thêm: Khoá huấn luyện thực hành thực tế Quản lý dự án công trình theo dõi quy mô Agile)

Làm thế này nhằm ước tính story point nhập Agile?

Story points rất rất đơn giản: group chỉ việc lựa chọn một số trong những điểm thể hiện tại sự cân đối, Mức độ cạnh tranh, chừng phức tạp, lượng việc làm quan trọng cho từng story và gán số cơ cho từng user story nhập backlog. Thay vì thế nỗ lực Dự kiến đúng mực tiếp tục mất mặt bao lâu nhằm kiến thiết một công dụng, group chỉ định và hướng dẫn một độ quý hiếm điểm cho từng story dựa vào chừng phức tạp của chính nó, sau khoản thời gian lấy chuồn đối chiếu với những công dụng không giống tuy nhiên group đang được kiến thiết trước cơ. Ban đầu, những ước tính tiếp tục thay cho thay đổi thật nhiều kể từ story này thanh lịch story không giống, tuy nhiên sau đó 1 thời hạn group đang được thân quen với quy tế bào tuy nhiên group dùng nhằm ước tính thì tiếp tục đơn giản dễ dàng rộng lớn nhằm thám thính đi ra sự cân đối của từng story.

Khi tất cả chúng ta ước tính vì thế story points, tất cả chúng ta tiếp tục chỉ định và hướng dẫn một độ quý hiếm điểm cho từng mục. Các độ quý hiếm thô tuy nhiên những group dùng là ko cần thiết. Điều cần thiết là những độ quý hiếm cơ cần đem mối liên hệ tương so với nhau. Ví dụ như story được gán điểm 2 nên rộng lớn gấp rất nhiều lần story được gán điểm 1. Nó cũng cần vì thế 2/3 story được ước tính là 3 story points. Thay vì thế chỉ định và hướng dẫn 1, 2 và 3, group cơ rất có thể chỉ định và hướng dẫn 100, 200 và 300. Hoặc 1 triệu, 2 triệu và 3 triệu. Điều cần thiết là tỷ trọng, ko cần là số lượng thực sự về thời hạn (giờ/ngày/tuần).

Trong Scrum, nhằm triển khai Sprint Planning hiệu suất cao rộng lớn, Product Owner và Development Team tiếp tục thể hiện một ước tính sơ cỗ Lúc triển khai Product Backlog Refinement, trước lúc ra mắt Sprint Planning và đánh giá xem:

- Đã sẵn sàng nhằm triển khai Sprint Plan một cơ hội hiệu suất cao chưa?

- Có đầy đủ vấn đề nhằm triển khai xong những yếu tố này không?

- User story đã và đang được phân loại hợp lí chưa?

Có thật nhiều phương pháp để dự tính story points nhập Agile và tùy từng từng group tiếp tục thống nhất cùng nhau về kiểu cách tính. Trong đa số những tình huống, story points dùng 1 trong các số những thang đo sau nhằm xác lập kích thước:

Định cỡ theo dõi T-shirt size (size áo):

Scrum teams rất có thể phụ thuộc ý tưởng phát minh phân chia theo dõi T-shirt sizes nhằm xác lập sự cân đối, chừng phức tạp của một story và gắn độ quý hiếm điểm mang lại từng size. T-shirt sizes là 1 trong dụng cụ ước tính ở high-level - cường độ tổng quát lác, được dùng nhằm triển khai những ước tính thuở đầu về những công dụng thành phầm và user story nhập tiến trình chính thức của một dự án công trình, Lúc tuy nhiên đang có ít vấn đề cụ thể.
Để phản ánh sự ko chắc chắn rằng tương quan cho tới những ước tính cơ, đơn vị chức năng ước tính của tất cả chúng ta được xem là T-shirt sizes, kể từ Cực nhỏ - Extra Small (ES) cho tới Cực rộng lớn - Extra Large (XXL).
Chúng tao sẽ không còn nỗ lực ước tính độ cao thấp vô cùng của từng hạng mục hoặc thậm chí là độ cao thấp to hơn hoặc nhỏ rộng lớn từng nào đối với những độ cao thấp không giống. Tất cả những gì tất cả chúng ta biết được xem là Extra Small nhỏ rộng lớn Small, nhỏ rộng lớn Medium và nối tiếp như vậy.
Ví dụ: group rất có thể đưa ra quyết định dùng một điểm mang lại công dụng rất rất nhỏ (extra small), 2 điểm mang lại công dụng nhỏ (small), 3 điểm mang lại công dụng khoảng (medium), 4 điểm mang lại công dụng rộng lớn (large) và 5 điểm mang lại công dụng rất rộng lớn (extra large).

Extra Small	Small	Medium	Large	Extra Large
1 điểm	2 điểm	3 điểm	4 điểm	5 điểm

Lũy quá của 2: Ngoài đi ra cũng rất nhiều những group cũng dùng sản phẩm số 1, 2, 4, 8, 16 được dẫn đến bằng phương pháp lũy quá của 2 nhằm ước tính story point.
Chuỗi Fibonacci mang lại Story Point: Một Lúc group đưa ra quyết định lập plan theo dõi thang điểm, group cần thiết thống nhất và đưa ra quyết định tiếp tục vận dụng theo dõi phương pháp tính điểm này. Một số group dùng chuỗi Fibonacci hoặc một số trong những thay đổi thể của chuỗi này (1, 2, 3, 5, 8, 13, 21...) mang lại story point vì thế chúng ta cho rằng chuỗi Fibonacci hỗ trợ tầm nhìn thực tiễn rộng lớn về sự cân đối của một story, sự cân đối của một story này đối với một story không giống. Miễn là group của công ty dùng thang đo một cơ hội nhất quán, thì cơ ko cần là yếu tố Lúc group dùng.

Bất cứ điều gì không được triển khai nhập Sprint sẽ tiến hành fake kể từ Sprint này thanh lịch Sprint tiếp theo sau. Và tổng số story point được triển khai xong trong những Sprint được theo dõi dõi như Velocity (vận tốc - tất cả chúng ta tiếp tục thám thính hiểu rõ ràng rộng lớn về định nghĩa này ở những bài bác tiếp theo) của dự án công trình. Nếu một group triển khai xong 15 story với tổng số 55 story points nhập một Sprint, chúng ta tiếp tục nhận định rằng 55 story points này như Sprint velocity và điều này mang lại group một chiếc nhìn toàn diện về vận tốc triển khai việc làm của tất cả group, Dự kiến về tổng số story points chúng ta rất có thể thực hiện nhập Sprint tiếp theo sau.

Theo thời hạn, group càng ngày càng đảm bảo chất lượng rộng lớn trong các việc gán story points và càng ngày càng nhất quán rộng lớn về số story points chúng ta triển khai xong trong những Sprint. bằng phẳng cơ hội cơ, group tiếp tục cảm biến được chúng ta rất có thể thực hiện được từng nào nhập Sprint và trấn áp plan bên cạnh nhau.

Quy trình ước tính story points

Bước 1: Xác ấn định Story hạ tầng - Base Story

Để tìm ra base story, tất cả chúng ta cần thiết thám thính một user story cơ bạn dạng, ứng với chi phí chuẩn chỉnh về khái niệm triển khai xong rõ rệt - DoD, và gán mang lại nó một story point. Base story được sử dụng thực hiện hạ tầng Lúc đối chiếu những story không giống.

Bước 2: Tạo yêu tinh trận nhằm ước lượng

Nhóm tiếp tục triển khai ước tính story points như đang được trình diễn phía trên (mục 3). Tiếp theo dõi, group sẽ tạo nên một yêu tinh trận với từng sản phẩm cho từng story point (ví dụ ở bên dưới dùng sản phẩm số Fibonacci) và stories tương quan của bọn chúng. Sau cơ, group tập trung toàn bộ stories và chính thức phân loại bọn chúng trở nên những sản phẩm, đối chiếu những story cùng nhau và với những story đang được triển khai xong không giống, hoặc đối với base story. Lưu ý rằng base story đang được đem nhập yêu tinh trận này, ở sản phẩm trước tiên với độ quý hiếm là 1 trong story point.

Story point	Story
1	Với tư cơ hội là khách hàng truy vấn nhập trang web, tôi ham muốn truy vấn trang trình làng nhằm hiểu thêm về những công ty.
1
2
2
3
3
5
5
8
8

Để chỉ định và hướng dẫn story point cho từng story, group mang trong mình một buổi họp, điểm toàn bộ những member của development team tiếp tục dùng Planning Poker để mang đi ra số lượng story point cho 1 story.

Planning Poker là 1 trong nghệ thuật ước tính dựa vào sự đồng thuận, dùng làm ước tính mang lại Product Backlog. Nó rất có thể được dùng với rất nhiều đơn vị chức năng ước tính không giống nhau, tuy nhiên ở trên đây tất cả chúng ta ví dụ Planning Poker với Story points.

Bước 3: Quy trình ước tính Planning Poker

Xem thêm: Để cảng Hải Phòng trở thành cảng biển hiện đại của khu vực

Mỗi member sẽ có được một cỗ thẻ bài bác.
Tất cả những member lựa chọn Backlog items nhằm ước tính, thảo luận những công dụng và bịa đặt thắc mắc.
Khi một công dụng đã và đang được thảo luận rất đầy đủ, từng người tự động thể hiện số lượng ước tính mang lại riêng biệt bản thân - đáp ứng kín đáo, và lựa chọn 1 thẻ bài bác nhằm thay mặt mang lại ước tính của tớ.
Khi toàn bộ đang được đem cho chính mình ước tính của story, chúng ta tiếp tục bật mí thẻ bài bác của mình và một khi. Nếu toàn bộ những ước tính đều khớp, cả group tiếp tục lựa chọn Backlog item không giống và tái diễn tiến độ tương tự động. Khi những ước tính không giống nhau rất nhiều, toàn bộ tiếp tục thảo luận về yếu tố này nhằm tiếp cận thống nhất.

Vào cuối Planning Poker, group tiếp tục điền toàn cỗ sản phẩm đã có được nhập yêu tinh trận. Các user story của tập thể nhóm được tạo thành những sản phẩm theo dõi story point ứng quan trọng nhằm triển khai bọn chúng. cũng có thể có rất nhiều story nhập một sản phẩm.

Story point	Story
1	Với tư cơ hội là visitor nhập trang web, tôi ham muốn truy vấn trang trình làng nhằm hiểu thêm về những công ty.
1	Với tư cơ hội là visitor nhập trang web, tôi ham muốn rất có thể bịa đặt lại password của tớ nhập tình huống tôi quên password.
2	Với tư cơ hội là người tiêu dùng đang được singin, tôi ham muốn rất có thể coi lịch sử vẻ vang giao dịch thanh toán của tớ bên trên trang setup.
2	Với tư cơ hội là visitor trang web, tôi ham muốn rất có thể gửi phản hồi hoặc report trường hợp hi hữu bằng phương pháp dùng biểu kiểu mẫu tương tác.
3	Với tư cơ hội là visitor trang web, tôi ham muốn singin / ĐK vì thế tin nhắn / password của tớ.
3	Với tư cơ hội là người tiêu dùng đang được singin, tôi ham muốn thêm thắt phán xét nhập nội dung bên trên trang web.
5	Với tư cơ hội là visitor nhập trang web, tôi ham muốn dùng biểu kiểu mẫu thám thính tìm kiếm với những cỗ thanh lọc nhằm thám thính tìm kiếm nội dung rõ ràng.
5	Với tư cơ hội là visitor nhập trang web, tôi ham muốn coi vấn đề cụ thể về nội dung.
8	Với tư cơ hội là người tiêu dùng đang được singin, tôi ham muốn rất có thể thêm thắt nội dung bên trên title trang web, tế bào miêu tả, nội dung phương tiện đi lại (hình hình họa, video clip, âm thanh), vùng địa lý.
8	Với tư cơ hội là người tiêu dùng đang được singin, tôi ham muốn rất có thể tiếp xúc qua chuyện lời nhắn với những người tiêu dùng không giống.

Bước 4: Sprint Planning

Tại thời đặc điểm đó, group đang được đem ước tính về sự cân đối dựa trên story points, thắc mắc đề ra là làm công việc thế này nhằm group rất có thể quy đổi những story points này trở nên ước tính thời hạn thực tiễn (giờ/ngày/tuần). Rất tiếc, group ko thể triển khai việc này cho tới Lúc triển khai xong Sprint trước tiên. Trong Lúc Sprint trước tiên đang được ra mắt, group rất có thể theo dõi dõi Velocity của tập thể nhóm. Ngay sau khoản thời gian Sprint kết đốc, tiếp tục biết group rất có thể triển khai xong từng nào story points cho từng Sprint. Nhóm dùng những số lượng này để tham dự báo năng lực của tớ mang lại những Sprint tiếp theo sau.

Khi ước tính được toàn bộ những việc làm nhập backlog phụ thuộc story point, Scrum rất có thể hiểu group tiếp tục cần thiết từng nào Sprint nhằm triển khai xong dự án công trình. Và sau cùng, group rất có thể quy đổi những đơn vị chức năng trừu tượng này trở nên những mốc thời hạn thực.

Những lỗi thông thường phạm phải Lúc dùng Story Point

Chuyển thay đổi story point thanh lịch giờ: Bằng cơ hội quy đổi story point thanh lịch giờ/ngày/tuần, group tiếp tục chính thức thao tác làm việc và cần nguy hiểm thể hiện khẳng định thời hạn triển khai xong đúng mực. Giả sử story point được ước lượng đem phạm vi thời hạn kể từ 10 – trăng tròn giờ, tuy nhiên Lúc ước tính theo dõi giờ, group cần thể hiện một số lượng đúng mực như 15 giờ, kể từ này sẽ dẫn tới việc sai chéo, dẫn theo khó khăn đạt được khẳng định rộng lớn khi chúng ta thao tác làm việc theo dõi giờ đúng mực.
Đưa đi ra story point trung bình: Trong Planning Poker, 1/2 member nhập group ước tính một product backlog item là 3 story point và nửa còn sót lại dự tính 5 story point. Nhóm xử lý bằng phương pháp bịa đặt 4 story point thực hiện số lượng ước tính. Nhóm tránh việc thực hiện điều này vì thế group đang được thỏa hiệp với việc hỗ trợ sai về chừng đúng mực. Tốt nhất là group nên mang trong mình một cuộc thảo luận nhằm làm rõ rộng lớn chứ không lấy độ quý hiếm khoảng.
Điều chỉnh ước lượng Story Point của những user story nhập Sprint: Khi group chính thức xử lý một yếu tố, group tránh việc kiểm soát và điều chỉnh ước lượng story point trong cả Lúc ước tính của mình ko đúng mực. Việc ước tính nhiều lúc bị sai chéo là vấn đề thông thường, nên group tránh việc kiểm soát và điều chỉnh nhưng mà hãy ghi lại vấn đề này, nhằm thực hiện hạ tầng mang lại việc xác lập story point ở những lượt sau đúng mực rộng lớn.
Ước lượng Story point mang lại những yếu tố ko triển khai xong một lượt nữa: Khi fake một product backlog item ko triển khai xong thanh lịch Sprint tiếp theo sau, ko quan trọng cần ước lượng lại. Ước lượng rất có thể ko đúng mực, tuy nhiên cơ ko cần là yếu tố. Nhờ Sprint Planning, group tiếp tục biết toàn bộ những trọng trách (task) quan trọng nhằm triển khai xong user story. Ước lượng của những trọng trách này là theo dõi giờ. Vì vậy, Sprint tiếp theo sau, group tiếp tục biết cần thiết từng nào thời hạn nhằm triển khai xong product backlog item này.
Điều chỉnh ước lượng Story Point phụ thuộc người làm: User story rất có thể là 3 story point so với member nhiều kinh nghiệm tay nghề, tuy nhiên 8 story point so với member mới nhất. Đây là thủ tục ko đích. Chúng tao tránh việc kiểm soát và điều chỉnh story point vì thế một người rõ ràng tiếp tục triển khai việc làm. Vì story point chỉ phụ thuộc sự cân đối, chừng phức tạp, Mức độ cạnh tranh của user story.
Tuân theo dõi chủ ý của những Chuyên Viên nhập nhóm: Khi triển khai Planning Poker, đem khủng hoảng là group tiếp tục tuân theo dõi chủ ý của những Chuyên Viên tuy nhiên ko cần là sự việc phối kết hợp kể từ phía từng member. Nhóm thông thường xử lý việc làm bằng phương pháp nhằm Chuyên Viên trình diễn cụ thể về việc làm. Sau cơ, nhằm phần còn sót lại của tập thể nhóm ước lượng tuy nhiên ko cần thiết những Chuyên Viên. Chúng tao nên nhớ rằng ước tính story point là sự việc nỗ lực của tất cả group ko cần của riêng biệt ngẫu nhiên member này.
Không thảo luận lại những yếu tố ko đúng mực về sự việc ước lượng story point nhập Sprint Retrospective: Thỉnh phảng phất, group xác lập được những yếu tố rõ rệt là ước lượng story points đang được trọn vẹn sai chéo. Điều cần thiết là cần thảo luận về những yếu tố này và nỗ lực học hỏi và chia sẻ, nâng cấp, nhằm những ước tính nhập sau này đúng mực rộng lớn.

Tổng kết

Khái niệm về story point giản dị tuy nhiên khó khăn vận dụng. Hầu không còn từng group Scrum đều dùng bọn chúng, tuy nhiên bọn chúng ko cần là 1 trong phần những dụng cụ cốt lõi của Scrum. Bởi vì thế điều này, từng người dân có chủ ý khác nhau về kiểu cách chúng ta nên dùng bọn chúng. Ban đầu Lúc dùng story points rất có thể tiếp tục thực hiện group ước lượng sai chéo, tuy nhiên sau thời hạn hiểu và trấn áp plan bên cạnh nhau, nhất quán rộng lớn về số điểm chúng ta hỗ trợ trong những Sprint chung group nhuần nhuyễn rộng lớn và thực hiện mang lại việc làm ước tính trở thành nhẹ dịu, đơn giản dễ dàng rộng lớn thật nhiều.

Kiến thức tổ hợp bởi Trainer Nguyễn Hải Hà (PMP®, PMI-ATP Instructor)

References: PMI-ACP Exam Prep, Head First Agile, Visual-Paradigm, Moutaingoatsoftware, Medium, Ruby.garage