Đáp ứng thời hạn của bạn: phương pháp mà các nhà phát triển sử dụng để ước tính nỗ lực

Xin chào tất cả mọi người! Có rất nhiều lý thuyết mà bạn cần biết để bắt đầu phát triển phần mềm. Một số chuyên gia (ví dụ: nhà phát triển phụ trợ sử dụng Java và các ngôn ngữ khác) biết nhiều hơn về nó, trong khi những người khác (ví dụ: nhà phát triển giao diện người dùng sử dụng JavaScript và React Native) có thể biết ít hơn một chút. Điều đó nói rằng, cả hai nhóm phải sở hữu một khối lượng lớn kiến ​​thức không chỉ về kỹ thuật mà còn về "tổ chức". Kiến thức "tổ chức" này là một lĩnh vực chồng chéo cho các nhà phát triển giao diện người dùng và phụ trợ. Hôm nay tôi muốn nói về một khía cạnh của kiến ​​thức tổ chức, phi kỹ thuật này. Hôm nay chúng ta sẽ nói về ước tính nỗ lực . Bởi vì tôi chỉ có kinh nghiệm sử dụng phương pháp Agile(được coi là phổ biến nhất), cụ thể hơn là khung Scrum, tôi sẽ xem xét ước tính nỗ lực trong ngữ cảnh của Scrum . Ngay từ đầu, tôi phải nói rằng việc ước tính nỗ lực là rất khó. Đối với tôi, đó là một trong những khía cạnh thách thức/khó chịu nhất trong công việc của tôi với tư cách là một nhà phát triển. Có nhiều yếu tố khác nhau cần xem xét có thể ảnh hưởng đến ước tính của bạn về nỗ lực cần thiết cho một nhiệm vụ. Ngoài ra, các kế hoạch phát triển trong tương lai sẽ dựa trên ước tính của bạn.

Nếu bạn cung cấp một ước tính xấu thì sao?

Nếu một nhà phát triển ước tính số giờ dành cho một nhiệm vụ nhiều hơn số giờ cuối cùng dành cho nhiệm vụ đó, chuyên môn của họ có thể bị nghi ngờ vì ước tính quá không chính xác. Nói cách khác, đó là một phỏng đoán hoang dã. Đồng thời, nếu một nhà phát triển không hoàn thành công việc trong thời gian dự kiến, cô ấy sẽ gây nguy hiểm cho kế hoạch phát hành sản phẩm hoặc tính năng mới của khách hàng. Đây là kinh doanh, và kinh doanh là tiền. Rất ít khách hàng sẽ hài lòng với một cú trượt như vậy. Trên thực tế, đó là lý do tại sao tôi không thích ước tính - bởi vì đôi khi rất khó để xác định chính xác thời gian cần thiết để hoàn thành một nhiệm vụ.

Cách ước tính thời gian

Theo quy định, ước tính được thực hiện theo giờ hoặc điểm câu chuyện. Sở thích cá nhân của tôi là thực hiện quá trình ước tính bằng cách sử dụng các điểm câu chuyện . Thật khó để nhầm lẫn về các vật thể cụ thể, nhưng các điểm của câu chuyện trừu tượng hơn một chút. Các nhóm phát triển phần mềm thường cung cấp các ước tính dưới dạng lượng thời gian: giờ, ngày, tuần, tháng. Những ước tính thời gian này chủ yếu dựa trên kinh nghiệm cá nhân, phỏng đoán và/hoặc trực giác. Trong trường hợp này, các nhà phát triển chỉ cần xem xét nhiệm vụ và đưa ra giả định của họ về việc họ sẽ mất bao nhiêu thời gian để thực hiện. Do đó, những ước tính này rất hiếm khi chính xác, vì có quá nhiều yếu tố có thể ảnh hưởng đến thời lượng của công việc. Đó là lý do tại sao nhiều nhóm sử dụng phương pháp Agile cũng sử dụng các điểm câu chuyện. Hãy đi sâu vào!

Điểm câu chuyện là gì?

Điểm câu chuyện là một đơn vị đo lường để thể hiện ước tính tổng nỗ lực cần thiết để thực hiện đầy đủ một phần chức năng nhất định. Đó là, chúng ta đang nói về tương đốisự phức tạp. Các nhóm chỉ định ước tính theo điểm câu chuyện dựa trên mức độ phức tạp của công việc, khối lượng công việc và rủi ro hoặc sự không chắc chắn. Các giá trị này thường được chỉ định để phân chia công việc thành các phần nhỏ hiệu quả hơn, do đó loại bỏ sự mơ hồ. Theo thời gian, điều này giúp các nhóm hiểu những gì họ có thể hoàn thành trong một khoảng thời gian nhất định và giúp họ lập kế hoạch chính xác hơn cho các phần công việc tiếp theo. Điều này nghe có vẻ hoàn toàn trái ngược với bạn, nhưng sự trừu tượng hóa này thực sự hữu ích: nó thúc đẩy nhóm đưa ra những quyết định khó khăn về mức độ phức tạp của công việc. Chúng ta hãy xem một số lý do để sử dụng các điểm câu chuyện khi lập kế hoạch:

• Bạn có thể tránh ước tính thời gian không chính xác.
• Không giống như các ước tính được thực hiện theo đơn vị thời gian, các điểm câu chuyện cho phép bạn tính chi phí chung: thông tin liên lạc giữa các thành viên trong nhóm và khách hàng, các hoạt động lập kế hoạch và thảo luận nhóm khác nhau, cũng như các tình huống không lường trước được.
• Mỗi nhóm sẽ đánh giá công việc của họ bằng các thang đo khác nhau, điều đó có nghĩa là năng lực của họ (được đo bằng điểm) sẽ khác nhau.
• Bằng cách xác định thang điểm cho từng điểm câu chuyện, bạn có thể nhanh chóng phân bổ điểm mà không phải tranh cãi nhiều.

Cách KHÔNG sử dụng điểm câu chuyện

Thật không may, các điểm câu chuyện thường bị lạm dụng. Điểm câu chuyện có thể gây hiểu nhầm khi chúng được sử dụng để đánh giá con người, xác định thời hạn và nguồn lực chi tiết cũng như khi chúng bị nhầm lẫn với thước đo hiệu suất. Thay vào đó, các nhóm nên sử dụng chúng để hiểu phạm vi/mức độ phức tạp của từng nhiệm vụ và đặt ưu tiên. Có lẽ những phần được coi là khó hơn nên được giải quyết trước, để chúng có thể được hoàn thành trước khi kết thúc nước rút , có thể chuyển những nhiệm vụ dễ hơn sang sau. Để tôi nhắc bạn một lần chạy nước rút là gì trong ngữ cảnh của phương pháp Scrum : Độ dài của khoảng thời gian này được xác định khi quá trình phát triển bắt đầu và được thỏa thuận giữa nhóm và khách hàng. Đây có thể là khoảng thời gian hai tuần hoặc một tháng hoặc bất kỳ khoảng thời gian nào khác. Theo quy định, ước tính nỗ lực được thực hiện vào đầu mỗi lần chạy nước rút để lập kế hoạch cho công việc có thể hoàn thành vào cuối lần chạy nước rút, khi công việc đã hoàn thành được giao cho khách hàng. Bản demo giúp bạn thấy được tiến độ của mình trong việc phát triển sản phẩm, nhận phản hồi từ khách hàng và điều chỉnh quỹ đạo của dự án theo tầm nhìn của khách hàng. Nhưng chúng ta lạc đề một chút. Hãy quay trở lại với ước tính. Sẽ là quá chủ quan nếu chỉ có một nhà phát triển cung cấp ước tính cho tất cả các nhiệm vụ. Vì vậy, quá trình này thường là nỗ lực của cả nhóm. Có khá nhiều kỹ thuật mà các nhóm có thể sử dụng để tạo ước tính. Hôm nay chúng ta sẽ xem xét kỹ thuật phổ biến nhất: scrum poker . Kỹ thuật này yêu cầu một người quản lý sẽ đóng vai trò là người điều hành cho bài xì phé scrum . Đây có thể là một người nào đó là một bậc thầy scrum hoặc có thể là một PM .

Scrum poker là gì?

Scrum poker , hay poker lập kế hoạch, là một kỹ thuật ước tính dựa trên việc đạt được thỏa thuận. Nó chủ yếu được sử dụng để ước tính mức độ phức tạp của công việc phía trước hoặc quy mô tương đối của các nhiệm vụ phát triển phần mềm. Tôi sẽ nói ngay rằng scrum pokerlà một phương pháp phát triển phần mềm phổ biến và bạn cần biết tất cả những gì về nó. Nó thường liên quan đến một ứng dụng hoặc trang web để tạo điều kiện thuận lợi cho việc tạo ước tính cộng tác của nhóm cho một nhiệm vụ cụ thể. Làm thế nào để điều này xảy ra? Nhóm lấy một cái gì đó từ công việc tồn đọng (một nhiệm vụ mới, một số chức năng) và thảo luận ngắn gọn về những cạm bẫy có thể xảy ra cũng như các sắc thái khác liên quan đến nó. Sau đó, mỗi người tham gia chọn một thẻ có số phản ánh ước tính độ phức tạp của họ. Ồ, một điều nữa, khi thực hiện các ước tính này, chúng tôi sử dụng các số trong dãy Fibonacci thay vì các số thông thường. Số Fibonacci phổ biến trong scrum poker, bởi vì có một khoảng cách ngày càng lớn giữa chúng (giống như các mức của một kim tự tháp). Một số nhiệm vụ sẽ rất phức tạp và chúng tôi sẽ không thể bỏ qua một số điểm nhỏ trong câu chuyện. Có một số thẻ bất thường có ý nghĩa sau:

Số điểm cuối không xác định

Nhiệm vụ dài vô tận

Cần nghỉ ngơi

Các phương pháp ước tính ít phổ biến hơn sử dụng:

• Cỡ áo phông — S, M, L, XL
• Các giống chó — chihuahua, pug, dachshund, bulldog, v.v. (cá nhân tôi nghĩ đây là đơn vị đo lường nỗ lực kỳ lạ nhất =D)

Sau đó, nhóm so sánh các ước tính do các nhà phát triển khác nhau đưa ra cho cùng một nhiệm vụ. Nếu họ đồng ý, thì thật tuyệt! Nếu không, thì các lý do (đối số) cho các ước tính khác nhau cần phải được thảo luận. Sau đó, nhóm làm việc cùng nhau để tạo thành một ước tính duy nhất mà mọi người ít nhiều đều chấp nhận. Vậy tại sao poker thậm chí còn được sử dụng để lập kế hoạch cho các dự án phần mềm nghiêm túc? Bạn phải thừa nhận rằng điều này thật kỳ lạ. Thực tế là kiểu trò chơi hóa này khuyến khích các thành viên trong nhóm suy nghĩ độc lập, mời họ tiết lộ ước tính của mình cùng lúc với đồng đội. Điều này sẽ tránh tạo ra tình huống một số thành viên trong nhóm phụ thuộc vào ý kiến ​​của người khác. Nếu nó không được thực hiện theo cách này, thì các nhà phát triển ít kinh nghiệm hơn sẽ xem xét và tập trung vào các ước tính được cung cấp bởi các thành viên nhóm có kinh nghiệm hơn, và điều đó sẽ làm cho ước tính của riêng họ ít hữu ích hơn. Nhưng đồng thời hiển thị các ước tính khiến điều này về cơ bản là không thể. Ưu đãi của Atlassianmột ứng dụng poker scrum để sử dụng trong quá trình lập kế hoạch.

Ví dụ về ước tính nỗ lực

Giả sử nhóm của bạn đã thiết lập thang đo sau để gán điểm câu chuyện cho các ước tính: Scrum poker được chơi cho từng nhiệm vụ và bạn đưa ra ước tính như sau:

• Bạn chưa bao giờ triển khai chức năng tương tự trước đây: +3
• Chức năng có kích thước trung bình: +2
• Việc triển khai sẽ rất phức tạp : +3
• Viết test cho chức năng sẽ rất phức tạp : +3

Cộng từng thành phần, bạn nhận được tổng cộng 11 điểm câu chuyện, nhưng không có thẻ như vậy, vì vậy bạn đề xuất 13. Một đồng nghiệp đưa ra ước tính sau cho nhiệm vụ:

• Anh ấy đã từng làm việc với một nhiệm vụ tương tự trước đây: +1
• Chức năng có kích thước trung bình: +2
• Việc triển khai sẽ có độ phức tạp trung bình: +2
• Viết bài kiểm tra chức năng sẽ có độ phức tạp trung bình: +2

Kết quả trung gian của anh ấy là 7 điểm câu chuyện, nhưng con số đó không tồn tại trong dãy Fibonacci, vì vậy anh ấy nộp thẻ có số gần đúng nhất — 8. Các thành viên khác trong nhóm cũng đưa ra ước tính dựa trên quan điểm chủ quan của họ. Sau đó, mọi người đưa thẻ của họ ra và bạn thấy rằng hầu hết tất cả đồng nghiệp của bạn đều đưa ra ước tính là 13, ngoại trừ một nhà phát triển đã đề xuất con số 8. Trong trường hợp này, anh ta được phép nói để đưa ra lý do cho ước tính thấp hơn của mình. Giả sử anh ta đưa ra lời biện minh này: trước đây anh ta đã làm cùng một nhiệm vụ và nó không khó như người ta tưởng. Cuối cùng, anh ấy thuyết phục được những người còn lại trong nhóm thay đổi ý định từ 13 xuống 8 điểm câu chuyện, nói rằng anh ấy sẽ giúp đỡ bất kỳ ai nhận nhiệm vụ này. Hoặc có lẽ anh ấy sẽ tự làm điều đó. Trong mọi trường hợp, nó không Việc những người khác có chấp nhận lập luận của anh ấy hay không không quan trọng, bởi vì bằng cách này hay cách khác, một ước tính sẽ được giao cho nhiệm vụ và nhóm sẽ chuyển sang xem xét điều tiếp theo. Ban đầu, các ước tính sẽ không chính xác, cũng như các ước tính về khối lượng công việc mà bạn dự định hoàn thành trong khoảng thời gian tiếp theo (chạy nước rút). Rốt cuộc, những ước tính này được thực hiện bằng cách sử dụng ước tính. Sau một thời gian, có thể là ba tháng sau, nhóm sẽ bắt đầu ước tính thời gian cần thiết cho các nhiệm vụ chính xác hơn và khối lượng công việc trung bình mà nhóm có thể thực hiện trong một lần chạy nước rút sẽ trở nên rõ ràng. Nhưng đây là một quá trình để lập một kế hoạch chung cho phạm vi công việc. Nó tập trung chủ yếu vào thời gian, nhưng trong trường hợp này có thể có nhiều yếu tố liên quan khác nhau. Ví dụ: giả sử một nhà phát triển đã đi nghỉ trong hai tuần. Bạn sẽ cần phải cắt giảm một số lượng công việc theo kế hoạch (chức năng theo kế hoạch). Hoặc giả sử một nhà phát triển mới đã tham gia vào nhóm, nhưng vẫn chưa hoàn toàn bắt kịp tốc độ, vì vậy bạn cần cho phép cô ấy có thời gian làm quen với dự án thông qua một cuộc trò chuyện.quá trình giới thiệu . Điều này có thể là hai tuần, cho hoặc mất một tuần, tùy thuộc vào mức độ phức tạp của dự án. Đó là tất cả cho ngày hôm nay! Tôi hy vọng tôi đã cải thiện một chút kiến ​​thức của bạn về ước tính nỗ lực, một khía cạnh phi kỹ thuật cần thiết của phát triển phần mềm. Nếu bạn muốn tìm hiểu sâu hơn về chủ đề này và chi tiết về scrum, tôi thực sự khuyên bạn nên đọc cuốn sách "SCRUM" của Jeff Sutherland. Tôi không thể hứa trước hậu quả, vì sau khi đọc nó, bạn sẽ có một mong muốn khó chịu để trở thành một bậc thầy scrum =D