Story points là 1 thuật ngữ được sử dụng trong cai quản và cải tiến và phát triển dự án để ước lượng độ lớn, độ khó, độ tinh vi cho công việc triển khai một user story duy nhất định, là 1 thước đo trừu tượng về nỗ lực cần thiết để tiến hành nó. Nói một giải pháp dễ hiểu, story points là một trong những con số, một đơn vị đo lường cho cả nhóm biết về độ khó của story, khó khăn khăn có thể liên quan cho khối lượng quá trình phải làm, nấc độ tinh vi của công việc, rủi ro khủng hoảng hoặc sự không chắc chắn là của công việc để thực hiện tương đối đầy đủ một hạng mục trong sản phẩm Backlog (backlog item) hoặc ngẫu nhiên phần công việc nào khác.
Bạn đang xem: Story point là gì
Như đã share trong nội dung bài viết “User stories - luật lên kế hoạch của Agile”, họ đã đề cập mang đến User stories - giữa những công gắng được những nhóm Agile áp dụng để lập mưu hoạch thao tác và thể hiện các hạng mục cần triển khai một giải pháp hiệu quả. Tiếp tục với chuỗi các công cụ, nghệ thuật này, bọn họ sẽ cùng mày mò công cụ thứ 2 không thua kém phần quan trọng đặc biệt đó chủ yếu là Story Points.
Theo thoải mái và tự nhiên thì chúng ta khó có thể đưa ra những ước lượng tuyệt đối một cách chính xác, nhưng lại sẽ dễ dãi và thoải mái và dễ chịu hơn trong bài toán đưa ra các ước lượng bằng phương pháp so sánh với một yếu tố không giống (ước lượng tương đối). Những nhóm Agile cũng vậy, họ đề cao việc mong lượng tương đối. Bọn họ thực hiện hầu hết các ước lượng của họ không phải theo giờ/ngày/tuần, mà bằng một đối chọi vị tương đối được điện thoại tư vấn là "Story points".
Một nguyên nhân khác để thực hiện ước lượng kha khá đó là từng thành viên trong nhóm làm việc ở vận tốc khác nhau. Ví dụ như một user story bao gồm ước lượng là 3 points (3 điểm) hoàn toàn có thể được chấm dứt bởi một nhân viên có kinh nghiệm tay nghề trong một trong những buổi sáng nhưng lại một nhân viên mới có thể phải mất suốt một ngày new hoàn thành. Buộc phải story point chỉ tập trung vào cầu lượng độ lớn, độ phức hợp của story.
Story points là gì?
Story points là 1 trong thuật ngữ được thực hiện trong quản lý và cách tân và phát triển dự án để mong lượng độ lớn, độ khó, độ phức tạp cho quá trình triển khai một user story tuyệt nhất định, là một trong thước đo trừu tượng về nỗ lực quan trọng để tiến hành nó. Nói một phương pháp dễ hiểu, story points là một con số, một đơn vị đo lường cho tất cả nhóm biết về độ cực nhọc của story, cạnh tranh khăn hoàn toàn có thể liên quan mang đến khối lượng các bước phải làm, nấc độ phức tạp của công việc, khủng hoảng hoặc sự không chắc hẳn rằng của các bước để thực hiện không thiếu thốn một hạng mục trong product Backlog (backlog item) hoặc bất kỳ phần quá trình nào khác.
Ước lượng bởi story points, một loại ước lượng tương đối, thường được tiến hành tại cuộc đàm luận về sản phẩm Backlog.
Tại sao nên áp dụng story points?
Khi lập chiến lược cho một dự án công trình Agile, hay thì nhóm sẽ không còn thể dự kiến được những tính năng của sản phẩm/phần mượt sẽ tiến hành trong bao lâu hoặc ngày chấm dứt chính xác của chúng. Khi ước tính theo giờ/ngày/tuần, bạn phải gửi ra cam kết thời gian bao gồm xác. Nạm vào đó, khi thực hiện story point, nhóm hướng đẫn một giá trị điểm (point) cho từng story dựa trên độ béo của nó. Đó là nguyên nhân tại sao phần đông nhóm Scrum áp dụng story points nhằm lập kế hoạch dự án công trình của họ, cho phép họ so sánh các stories cùng với nhau. Bằng cách tập trung vào độ tinh vi của những tính năng thay vày thời gian chính xác để cách tân và phát triển chúng, nhóm tham gia lập mưu hoạch bên nhau và chỉ dẫn dự đoán những tính năng ngày càng tăng nào có thể được thêm vào phần mềm/sản phẩm sau mỗi vòng lặp.
Làm cố nào để mong lượng story point trong Agile?
Story points rất đơn giản: nhóm chỉ việc chọn một số điểm trình bày độ lớn, độ khó, độ phức tạp, khối lượng quá trình cần thiết cho từng story với gán số đó cho mỗi user story vào backlog. Cầm vì nỗ lực dự đoán đúng chuẩn sẽ mất bao lâu để xây dừng một tính năng, nhóm chỉ định một cực hiếm điểm cho từng story dựa vào độ tinh vi của nó, sau khi đem đi đối chiếu với những tính năng khác mà lại nhóm đã tạo ra trước đó. Ban đầu, các ước lượng sẽ chuyển đổi rất nhiều từ story này thanh lịch story khác, mà lại sau một thời hạn nhóm vẫn quen cùng với quy mô nhưng mà nhóm thực hiện để ước lượng thì sẽ tiện lợi hơn để tìm ra độ lớn của từng story.
Khi họ ước lượng bằng story points, họ sẽ chỉ định và hướng dẫn một giá trị điểm cho mỗi mục. Những giá trị thô mà các nhóm áp dụng là ko quan trọng. Điều đặc biệt là các giá trị đó phải gồm quan hệ tương đối với nhau. Ví dụ như story được gán điểm 2 yêu cầu lớn gấp rất nhiều lần story được gán điểm 1. Nó cũng phải bằng 2/3 story được mong lượng là 3 story points. Thay vị chỉ định 1, 2 cùng 3, nhóm đó có thể chỉ định 100, 200 với 300. Hoặc 1 triệu, 2 triệu với 3 triệu. Điều đặc trưng là tỷ lệ, không phải là số lượng thực sự về thời hạn (giờ/ngày/tuần).
Trong Scrum, để triển khai Sprint Planning công dụng hơn, product Owner cùng Development Team sẽ đưa ra một mong lượng sơ cỗ khi thực hiện Product Backlog Refinement, trước khi ra mắt Sprint Planning và khám nghiệm xem:
- Đã sẵn sàng chuẩn bị để triển khai Sprint Plan một cách hiệu quả chưa?
- có đủ tin tức để hoàn thành những vụ việc này không?
- User story đã có được phân chia phù hợp chưa?
Có khôn xiết nhiều phương pháp để ước tính story points trong Agile và tùy thuộc vào từng nhóm đang thống độc nhất với nhau về phong thái tính. Trong hầu như các trường hợp, story points áp dụng một trong các các thang đo sau để xác minh kích thước:
Định kích cỡ theo T-shirt form size (size áo):
Scrum teams hoàn toàn có thể dựa vào phát minh chia theo T-shirt sizes để khẳng định độ lớn, độ phức tạp của một story cùng gắn quý giá điểm đến từng size. T-shirt sizes là một trong công thế ước lượng sinh sống high-level - cường độ tổng quát, được thực hiện để thực hiện các ước lượng thuở đầu về những tính năng thành phầm và user story trong giai đoạn bước đầu của một dự án, khi mà đang có ít thông tin đưa ra tiết. Để đề đạt sự không chắc chắn là liên quan đến các ước lượng đó, đơn vị chức năng ước lượng của bọn họ sẽ là T-shirt sizes, từ bỏ Cực nhỏ dại - Extra Small (ES) đến cực đại - Extra Large (XXL). Họ sẽ không cố gắng ước lượng kích thước tuyệt đối của từng danh mục hoặc thậm chí size lớn hơn hay bé dại hơn từng nào so cùng với các form size khác. Toàn bộ những gì chúng ta biết đã là Extra Small nhỏ hơn Small, bé dại hơn Medium và tiếp tục như thế. Ví dụ: nhóm có thể quyết định sử dụng 1 điều cho nhân kiệt rất bé dại (extra small), 2 điểm mang đến tính năng bé dại (small), 3 điểm cho nhân tài trung bình (medium), 4 điểm cho tác dụng lớn (large) cùng 5 điểm mang lại tính năng rất 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 |
Bất cứ điều gì chưa được tiến hành trong Sprint sẽ tiến hành chuyển tự Sprint này lịch sự Sprint tiếp theo. Với tổng số story point được kết thúc trong mỗi Sprint được theo dõi và quan sát như Velocity (vận tốc - chúng ta sẽ tìm hiểu cụ thể hơn về khái niệm này nghỉ ngơi những bài bác tiếp theo) của dự án. Ví như một nhóm hoàn thành 15 story với tổng cộng 55 story points trong một Sprint, chúng ta sẽ nhận định rằng 55 story points này như Sprint velocity và vấn đề này cho nhóm một cái nhìn phổ biến về tốc độ thực hiện quá trình của cả nhóm, dự đoán về tổng cộng story points họ hoàn toàn có thể làm vào Sprint tiếp theo.
Theo thời gian, team ngày càng xuất sắc hơn trong việc gán story points với ngày càng đồng bộ hơn về số story points họ kết thúc trong mỗi Sprint. Bằng cách đó, team sẽ cảm nhận được họ có thể làm được bao nhiêu trong Sprint và kiểm soát điều hành kế hoạch cùng nhau.
Quy trình ước lượng story points
Bước 1: khẳng định Story đại lý - Base StoryĐể kiếm được base story, bọn họ cần tìm kiếm một user story cơ bản, ứng với tiêu chuẩn chỉnh về định nghĩa chấm dứt rõ ràng - DoD, và gán đến nó một story point. Base story được sử dụng làm cơ sở khi so sánh các story khác.
Bước 2: chế tạo ra ma trận để mong lượngNhóm sẽ tiến hành ước lượng story points như đã trình diễn ở bên trên (mục 3). Tiếp theo, nhóm sẽ tạo một ma trận với mỗi hàng cho mỗi story point (ví dụ nghỉ ngơi dưới sử dụng dãy số Fibonacci) với stories liên quan của chúng. Sau đó, team tập hợp toàn bộ stories và bước đầu phân các loại chúng thành những hàng, so sánh những story cùng với nhau với với các story đã xong khác, hoặc đối với base story. Lưu ý rằng base story đã bao gồm trong ma trận này, ở số 1 tiên với cái giá trị là 1 trong story point.
Story point | Story |
1 | Với tư cách là khách truy vấn vào trang web, tôi muốn truy cập trang ra mắt để hiểu biết thêm về các dịch vụ. |
2 | |
3 | |
5 | |
8 | |
Để hướng đẫn story point cho từng story, nhóm bao gồm một cuộc họp, nơi toàn bộ các thành viên của development team sẽ thực hiện Planning Poker để mang ra số lượng story point cho 1 story.
Planning Poker là 1 trong những kỹ thuật ước lượng dựa trên sự đồng thuận, dùng để ước lượng đến Product Backlog. Nó rất có thể được sử dụng với tương đối nhiều đơn vị mong lượng khác nhau, tuy nhiên ở đây bọn họ ví dụ Planning Poker với Story points.
Bước 3: tiến trình ước lượng Planning Poker
từng thành viên cảm nhận một cỗ thẻ bài. Tất cả các thành viên lựa chọn Backlog items để ước lượng, bàn luận các chức năng và đặt câu hỏi. Lúc một tính năng sẽ được thảo luận đầy đủ, mỗi cá nhân tự đưa ra số lượng ước lượng mang lại riêng bản thân - bảo vệ bí mật, và lựa chọn một thẻ bài xích để đại diện thay mặt cho ước lượng của mình. Khi tất cả đã bao gồm cho mình ước lượng của story, bọn họ sẽ bật mí thẻ bài của họ cùng một lúc. Nếu toàn bộ các cầu lượng số đông khớp, cả team sẽ chọn Backlog thành tựu khác cùng lặp lại tiến trình tương tự. Khi các ước lượng khác biệt quá nhiều, tất cả sẽ bàn bạc về vụ việc này nhằm đi mang lại thống nhất.Vào cuối Planning Poker, nhóm đang điền toàn bộ tác dụng có được vào ma trận. Các user story của group được chia thành các sản phẩm theo story point tương ứng cần thiết để thực hiện chúng. Có thể có tương đối nhiều story vào một hàng.
Story point | Story |
1 | Với tư bí quyết là người truy cập vào trang web, tôi muốn truy cập trang giới thiệu để hiểu thêm về các dịch vụ. |
Với tư cách là người truy cập vào trang web, tôi muốn có thể đặt lại mật khẩu của mình trong trường phù hợp tôi quên mật khẩu. | |
2 | Với tư biện pháp là người dùng đã đăng nhập, tôi muốn hoàn toàn có thể xem lịch sử vẻ vang thanh toán của chính bản thân mình trên trang cài đặt đặt. |
Với tư giải pháp là người truy cập trang web, tôi muốn có thể gửi bình luận hoặc report sự cố bằng cách sử dụng biểu chủng loại liên hệ. | |
3 | Với tư bí quyết là visitor trang web, tôi ước ao đăng nhập / đk bằng thư điện tử / mật khẩu của mình. |
Với tư phương pháp là người dùng đã đăng nhập, tôi mong thêm nhấn xét vào câu chữ trên trang web. | |
5 | Với tư cách là người truy cập vào trang web, tôi mong sử dụng biểu mẫu tìm kiếm với những bộ lọc để tìm tìm nội dung nỗ lực thể. |
Với tư phương pháp là visitor vào trang web, tôi mong muốn xem thông tin cụ thể về nội dung. | |
8 | Với tư bí quyết là người tiêu dùng đã đăng nhập, tôi muốn rất có thể thêm ngôn từ trên title trang web, mô tả, nội dung phương tiện (hình ảnh, video, âm thanh), địa chỉ địa lý. |
Với tư phương pháp là người dùng đã đăng nhập, tôi muốn có thể giao tiếp qua tin nhắn với những người tiêu dùng khác. |
Bước 4: Sprint Planning
Tại thời gian này, nhóm đã bao gồm ước lượng về độ to dựa theo story points, thắc mắc đặt ra là làm núm nào nhằm nhóm bao gồm thể biến đổi những story points này thành cầu lượng thời hạn thực tế (giờ/ngày/tuần). Vô cùng tiếc, nhóm không thể thực hiện việc này cho đến khi dứt Sprint đầu tiên. Trong những lúc Sprint đầu tiên đang diễn ra, nhóm rất có thể theo dõi Velocity của nhóm. Ngay sau khoản thời gian Sprint kết thúc, đã biết nhóm gồm thể hoàn thành bao nhiêu story points cho từng Sprint. Nhóm thực hiện những con số này để dự báo khả năng của bản thân cho phần nhiều Sprint tiếp theo.
Khi cầu lượng được toàn bộ các công việc trong backlog phụ thuộc vào story point, Scrum hoàn toàn có thể hiểu nhóm vẫn cần bao nhiêu Sprint để xong dự án. Cùng cuối cùng, nhóm có thể đổi khác các đơn vị chức năng trừu tượng này thành các mốc thời gian thực.
Những lỗi thường phạm phải khi thực hiện Story Point
Chuyển thay đổi story point sang giờ: Bằng cách thay đổi story point lịch sự giờ/ngày/tuần, nhóm sẽ bắt đầu làm bài toán và buộc phải mạo hiểm gửi ra cam kết thời gian chấm dứt chính xác. Trả sử story point được mong lượng tất cả phạm vi thời gian từ 10 – 20 giờ, tuy vậy khi mong lượng theo giờ, nhóm đề xuất đưa ra một bé số đúng chuẩn như 15 giờ, từ đó sẽ dẫn đến sự sai lệch, dẫn đến khó khăn đạt được khẳng định hơn khi chúng ta làm bài toán theo giờ thiết yếu xác. Đưa ra story point trung bình: Trong Planning Poker, một nửa thành viên vào nhóm ước lượng một sản phẩm backlog cửa nhà là 3 story point với nửa sót lại ước tính 5 story point. Nhóm giải quyết bằng cách đặt 4 story point làm con số ước lượng. Nhóm cấm kị điều này vày nhóm vẫn thỏa hiệp với sự hỗ trợ sai về độ chính xác. Tốt nhất có thể là nhóm nên có một cuộc thảo luận để hiểu rõ hơn thay vì chưng lấy quý hiếm trung bình.Điều chỉnh cầu lượng Story Point của những user story trong Sprint: Khi nhóm ban đầu giải quyết một vấn đề, đội không nên điều chỉnh ước lượng story point trong cả khi ước lượng của mình không thiết yếu xác. Việc ước lượng nhiều khi bị lệch lạc là điều bình thường, bắt buộc nhóm ko nên điều chỉnh mà hãy lưu lại tin tức này, để làm cơ sở cho việc xác minh story point ở đông đảo lần sau đúng mực hơn.Ước lượng Story point cho những vụ việc chưa dứt một lần nữa: Khi gửi một product backlog tòa tháp chưa ngừng sang Sprint tiếp theo, không cần thiết phải mong lượng lại. Ước lượng có thể không chính xác, dẫu vậy đó chưa phải là vấn đề. Dựa vào Sprint Planning, nhóm sẽ biết toàn bộ các trọng trách (task) cần thiết để xong xuôi user story. Ước lượng của các nhiệm vụ này là theo giờ. Vì chưng vậy, Sprint tiếp theo, nhóm sẽ biết cần bao nhiêu thời gian để kết thúc product backlog thành phầm này.Điều chỉnh cầu lượng Story Point phụ thuộc vào người làm: User story có thể là 3 story point đối với thành viên những kinh nghiệm, nhưng mà 8 story point đối với thành viên mới. Đây là cách làm ko đúng. Bọn họ không nên điều chỉnh story point bởi một người ví dụ sẽ thực hiện công việc. Vày story point chỉ phụ thuộc độ lớn, độ phức tạp, độ nặng nề của user story.Tuân theo ý kiến của các chuyên gia trong nhóm: Khi thực hiện Planning Poker, có rủi ro là nhóm đang tuân theo chủ kiến của các chuyên gia mà không hẳn là sự kết hợp từ phía từng thành viên. Nhóm thường giải quyết và xử lý công việc bằng phương pháp để chuyên gia trình bày chi tiết về công việc. Sau đó, để phần còn lại của tập thể nhóm ước lượng cơ mà không cần các chuyên gia. Họ cần ghi nhớ rằng mong lượng story point là sự việc nỗ lực của tất cả nhóm không hẳn của riêng ngẫu nhiên thành viên nào.Xem thêm: Trắc Nghiệm Sử 12 Bài 9 - Trắc Nghiệm Lịch Sử 12 Bài 9 (Có Đáp Án)
Không trao đổi lại những vấn đề không đúng mực về câu hỏi ước lượng story point trong Sprint Retrospective: Thỉnh thoảng, nhóm khẳng định được đa số vấn đề ví dụ là cầu lượng story points đã hoàn toàn sai lệch. Điều đặc trưng là phải đàm luận về những vấn đề này và cố gắng học hỏi, cải thiện, để số đông ước lượng vào tương lai đúng chuẩn hơn.
Tổng kết
Khái niệm về story point đơn giản nhưng cạnh tranh áp dụng. Phần đông mọi đội Scrum đều thực hiện chúng, cơ mà chúng chưa phải là một trong những phần các biện pháp cốt lõi của Scrum. Cũng chính vì điều này, mọi tín đồ có ý kiến khác nhau về kiểu cách bạn nên sử dụng chúng. Ban đầu khi sử dụng story points rất có thể sẽ có tác dụng nhóm mong lượng sai lệch, nhưng sau thời gian hiểu và kiểm soát và điều hành kế hoạch cùng nhau, đồng hóa hơn về số điểm họ hỗ trợ trong mỗi Sprint giúp team thuần thục hơn và có tác dụng cho công việc ước lượng trở đề nghị nhẹ nhàng, dễ dãi hơn siêu nhiều.
References:PMI-ACP Exam Prep, Head First Agile,Visual-Paradigm,Moutaingoatsoftware,Medium, Ruby.garage