Velocity trong Scrum là gì
Story points là một thuật ngữ được sử dụng trong quản trị và tăng trưởng dự án Bất Động Sản để ước đạt độ lớn, độ khó, độ phức tạp cho việc làm tiến hành một user story nhất định, là một thước đo trừu tượng về nỗ lực thiết yếu để triển khai nó. Nói một cách dễ hiểu, story points là một số lượng, một đơn vị chức năng thống kê giám sát cho cả nhóm biết về độ khó của story, khó khăn vất vả hoàn toàn có thể tương quan đến khối lượng việc làm phải làm, mức độ phức tạp của việc làm, rủi ro đáng tiếc hoặc sự không chắc như đinh của việc làm để triển khai khá đầy đủ một khuôn khổ trong Product Backlog ( backlog item ) hoặc bất kể phần việc làm nào khác . Như đã chia sẻ trong bài viết “User stories – Công cụ lên kế hoạch của Agile”, chúng ta đã đề cập đến User stories – một trong những công cụ được các nhóm Agile sử dụng để lập kế hoạch làm việc và thể hiện các hạng mục cần thực hiện một cách hiệu quả. Tiếp tục với chuỗi những công cụ, kỹ thuật này, chúng ta sẽ cùng tìm hiểu công cụ thứ 2 không kém phần quan trọng đó chính là Story Points. Show Theo tự nhiên thì chúng ta khó có thể đưa ra các ước lượng tuyệt đối một cách chính xác, nhưng sẽ dễ dàng và thoải mái hơn trong việc đưa ra các ước lượng bằng cách so sánh với một yếu tố khác (ước lượng tương đối). Các nhóm Agile cũng vậy, họ đề cao việc ước lượng tương đối. 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 đơn vị tương đối được gọi là “Story points“. Một lý do khác để sử dụng ước lượng tương đối đó là mỗi thành viên trong nhóm làm việc ở tốc độ khác nhau. Ví dụ một user story có ước lượng là 3 points (3 điểm) có thể được hoàn thành bởi một nhân viên có kinh nghiệm trong một buổi sáng nhưng một nhân viên mới có thể phải mất suốt một ngày mới hoàn thành. Nên story point chỉ tập trung vào ước lượng độ lớn, độ phức tạp của story.
Bạn đang đọc: Story points – Công cụ ước lượng của Agile Story points là gì ?Story points là một thuật ngữ được sử dụng trong quản trị và tăng trưởng dự án Bất Động Sản để ước đạt độ lớn, độ khó, độ phức tạp cho việc làm tiến hành một user story nhất định, là một thước đo trừu tượng về nỗ lực thiết yếu để thực thi nó. Nói một cách dễ hiểu, story points là một số lượng, một đơn vị chức năng đo lường và thống kê cho cả nhóm biết về độ khó của story, khó khăn vất vả hoàn toàn có thể tương quan đến khối lượng việc làm phải làm, mức độ phức tạp của việc làm, rủi ro đáng tiếc hoặc sự không chắc như đinh của việc làm để thực thi rất đầy đủ một khuôn khổ trong Product Backlog ( backlog item ) hoặc bất kể phần việc làm nào khác .Ước lượng bằng story points, một loại ước đạt tương đối, thường được thực thi tại cuộc tranh luận về Product Backlog . Tại sao nên sử dụng story points ?Khi lập kế hoạch cho một dự án Bất Động Sản Agile, thường thì nhóm sẽ không hề Dự kiến được những tính năng của loại sản phẩm / ứng dụng sẽ thực thi trong bao lâu hoặc ngày hoàn thành xong đúng chuẩn của chúng. Khi ước tính theo giờ / ngày / tuần, bạn phải đưa ra cam kết thời hạn đúng chuẩn. Thay vào đó, khi sử dụng story point, nhóm chỉ định một giá trị điểm ( point ) cho mỗi story dựa trên độ lớn của nó. Đó là nguyên do tại sao hầu hết nhóm Scrum sử dụng story points để lập kế hoạch dự án Bất Động Sản của họ, được cho phép họ so sánh những stories với nhau. Bằng cách tập trung chuyên sâu vào độ phức tạp của những tính năng thay vì thời hạn đúng chuẩn để tăng trưởng chúng, nhóm tham gia lập kế hoạch cùng nhau và đưa ra Dự kiến những tính năng ngày càng tăng nào hoàn toàn có thể được thêm vào ứng dụng / mẫu sản phẩm sau mỗi vòng lặp .( Xem thêm : Khoá huấn luyện và đào tạo thực hành thực tế Quản lý dự án Bất Động Sản theo quy mô Agile ) Làm thế nào để ước đạt story point trong Agile ?Story points rất đơn thuần : nhóm chỉ cần chọn một số ít điểm bộc lộ độ lớn, độ khó, độ phức tạp, khối lượng việc làm thiết yếu cho mỗi story và gán số đó cho mỗi user story trong backlog. Thay vì cố gắng nỗ lực Dự kiến đúng chuẩn sẽ mất bao lâu để thiết kế xây dựng một tính năng, nhóm chỉ định một giá trị điểm cho mỗi story dựa trên độ phức tạp của nó, sau khi đem đi so sánh với những tính năng khác mà nhóm đã thiết kế xây dựng trước đó. Ban đầu, những ước đạt sẽ đổi khác rất nhiều từ story này sang story khác, nhưng sau một thời hạn nhóm đã quen với quy mô mà nhóm sử dụng để ước đạt thì sẽ thuận tiện hơn để tìm ra độ lớn của mỗi story .Khi tất cả chúng ta ước đạt bằng story points, tất cả chúng ta sẽ chỉ định một giá trị điểm cho mỗi mục. Các giá trị thô mà những nhóm sử dụng là không quan trọng. Điều quan trọng là những giá trị đó phải có quan hệ tương đối với nhau. Ví dụ như story được gán điểm 2 nên lớn gấp đôi story được gán điểm 1. Nó cũng phải bằng 2/3 story được ước đạt là 3 story points. Thay vì chỉ định 1, 2 và 3, nhóm đó hoàn toàn 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ỷ suất, 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 hiệu suất cao hơn, Product Owner và Development Team sẽ đưa ra một ước đạt sơ bộ khi triển khai Product Backlog Refinement, trước khi diễn ra Sprint Planning và kiểm tra xem :- Đã sẵn sàng chuẩn bị để thực thi Sprint Plan một cách hiệu suất cao chưa ?- Có đủ thông tin để hoàn thành xong những yếu tố này không ?- User story đã được phân loại hài hòa và hợp lý chưa ?Có rất nhiều cách để ước tính story points trong Agile và tùy theo từng nhóm sẽ thống nhất với nhau về cách tính. Trong hầu hết những trường hợp, story points sử dụng một trong số những thang đo sau để xác lập kích cỡ : Định cỡ theo T-shirt size (size áo):
Extra SmallSmallMediumLargeExtra Large1 điểm2 điểm3 điểm4 điểm5 điểm
Bất cứ điều gì chưa được thực hiện trong Sprint sẽ được chuyển từ Sprint này sang Sprint tiếp theo. Và tổng số story point được hoàn thành trong mỗi Sprint được theo dõi 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 ở những bài tiếp theo) của dự án. Nếu một nhóm hoàn thành 15 story với tổng số 55 story points trong một Sprint, họ sẽ cho rằng 55 story points này như Sprint velocity và điều này cho nhóm một cái nhìn chung về tốc độ thực hiện công việc của cả nhóm, dự đoán về tổng số story points họ có thể làm trong Sprint tiếp theo. Theo thời hạn, nhóm ngày càng tốt hơn trong việc gán story points và ngày càng đồng nhất hơn về số story points họ triển khai xong trong mỗi Sprint. Bằng cách đó, nhóm sẽ cảm nhận được họ hoàn toàn có thể làm được bao nhiêu trong Sprint và trấn áp kế hoạch cùng nhau . Quy trình ước đạt story points
Để tìm được base story, tất cả chúng ta cần tìm một user story cơ bản, ứng với tiêu chuẩn về định nghĩa hoàn thành xong rõ ràng – DoD, và gán cho nó một story point. Base story được dùng làm cơ sở khi so sánh những story khác .
Nhóm sẽ thực thi ước đạt story points như đã trình diễ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ụ ở dưới sử dụng dãy số Fibonacci ) và stories tương quan của chúng. Sau đó, nhóm tập hợp tổng thể stories và mở màn phân loại chúng thành những hàng, so sánh những story với nhau và với những story đã triển khai xong khác, hoặc so với base story. Lưu ý rằng base story đã có trong ma trận này, ở hàng tiên phong với giá trị là một story point . Story point Story 1Với tư cách là khách truy vấn vào website, tôi muốn truy vấn trang trình làng để biết thêm về những dịch vụ .2358 Để chỉ định story point cho mỗi story, nhóm có một cuộc họp, nơi tất cả các thành viên của development team sẽ sử dụng Planning Poker để đưa ra con số story point cho một story.
Xem thêm: favorable là gì ? nghĩa của từ favorable trong tiếng việt Planning Poker là một kỹ thuật ước lượng dựa trên sự đồng thuận, dùng để ước lượng cho Product Backlog. Nó có thể được sử dụng với nhiều đơn vị ước lượng khác nhau, nhưng ở đây chúng ta ví dụ Planning Poker với Story points. Bước 3: Quy trình ước lượng Planning Poker
Vào cuối Planning Poker, nhóm sẽ điền hàng loạt hiệu quả có được vào ma trận. Các user story của nhóm được chia thành những hàng theo story point tương ứng thiết yếu để thực thi chúng. Có thể có nhiều story trong một hàng . Story point Story 1Với tư cách là người truy vấn vào website, tôi muốn truy vấn trang trình làng để biết thêm về những dịch vụ .Với tư cách là người truy vấn vào website, tôi muốn hoàn toàn có thể đặt lại mật khẩu của mình trong trường hợp tôi quên mật khẩu .2Với tư cách 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 giao dịch của mình trên trang setup .Với tư cách là người truy vấn website, tôi muốn hoàn toàn có thể gửi phản hồi hoặc báo cáo giải trình sự cố bằng cách sử dụng biểu mẫu liên hệ .3Với tư cách là người truy vấn website, tôi muốn đăng nhập / Đ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 website .5Với tư cách là người truy vấn vào website, tôi muốn sử dụng biểu mẫu tìm kiếm với những bộ lọc để tìm kiếm nội dung đơn cử .Với tư cách là người truy vấn vào website, tôi muốn xem thông tin cụ thể về nội dung .8Với tư cách là người dùng đã đăng nhập, tôi muốn hoàn toàn có thể thêm nội dung trên tiêu đề website, miêu tả, nội dung phương tiện đi lại ( hình ảnh, video, âm thanh ), vị trí địa lý .Với tư cách là người dùng đã đăng nhập, tôi muốn hoàn toàn có thể tiếp xúc qua tin nhắn với những người dùng khác . Tại thời gian này, nhóm đã có ước đạt về độ lớn dựa theo story points, câu hỏi đặt ra là làm thế nào để nhóm hoàn toàn có thể quy đổi những story points này thành ước đạt thời hạn trong thực tiễn ( giờ / ngày / tuần ). Rất tiếc, nhóm không hề thực thi việc này cho đến khi hoàn thành xong Sprint tiên phong. Trong khi Sprint tiên phong đang diễn ra, nhóm hoàn toàn có thể theo dõi Velocity của nhóm. Ngay sau khi Sprint kết thúc, sẽ biết nhóm hoàn toàn có thể triển khai xong bao nhiêu story points cho mỗi Sprint. Nhóm sử dụng những số lượng này để dự báo năng lực của mình cho những Sprint tiếp theo .Khi ước đạt được toàn bộ những việc làm trong backlog dựa vào story point, Scrum hoàn toàn có thể hiểu nhóm sẽ cần bao nhiêu Sprint để triển khai xong dự án Bất Động Sản. Và sau cuối, nhóm hoàn toàn có thể quy đổi những đơn vị chức năng trừu tượng này thành những mốc thời hạn thực . Những lỗi thường mắc phải khi sử dụng Story Point
Tổng kếtKhái niệm về story point đơn thuần nhưng khó vận 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 những công cụ cốt lõi của Scrum. Bởi vì điều này, mọi người có quan điểm khác nhau về cách bạn nên sử dụng chúng. Ban đầu khi sử dụng story points hoàn toàn có thể sẽ làm nhóm ước đạt rơi lệch, nhưng sau thời hạn hiểu và trấn áp kế hoạch cùng nhau, đồng nhất hơn về số điểm họ phân phối trong mỗi Sprint giúp nhóm thuần thục hơn và làm cho việc làm ước đạt trở nên nhẹ nhàng, thuận tiện hơn rất nhiều . Kiến thức tổng 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 Product Backlog là gì? Có quan hệ như thế nào với WBS Bản tuyên ngôn Agile – lịch sử hình thành Agile 12 nguyên tắc của AgileTrong dự án Bất Động Sản Agile, việc làm ước tính có thật sự thiết yếu ? Quản lý dự án với Scrum Scrum of Scrums User stories – Công cụ lên kế hoạch của Agile Story points – Công cụ ước lượng của Agile Velocity là gì – Công cụ đo lường tốc độ hoàn thành công việc của nhóm Agile Story Map – Lập kế hoạch tổng quát trong Agile Agile Retrospectives – Nhìn lại và cải tiến hiệu quả công việc dự án Kanban – giải pháp giúp nâng cấp cải tiến quy trình tiến độ thao tác của dự án Bất Động Sản PDCA – Chu trình cải tiến liên tục Personas – Công cụ xây dựng hình tượng khách hàng trong Agile Lean – Tinh gọn hóa quy trình một cách hiệu quả Hướng Dẫn Scrum 2020 – The Scrum Guide 2020 Bóng đá có 3-5-2, Scrum có 3-5-3
Xem thêm: Tứ niệm xứ – Wikipedia tiếng Việt Bắt đầu với Scrum từ đâu đây ta? Một số cách chạy Daily scrum hiệu suất cao |