Các nhà phát triển sử dụng phương pháp nào để đánh giá nhiệm vụ?

Chào mọi người! Lý thuyết cần thiết để bắt đầu phát triển là rất rộng rãi. Một số chuyên gia (nhà phát triển phụ trợ trong Java và các ngôn ngữ khác) có nhiều thứ hơn, trong khi những chuyên gia khác (ví dụ: nhà phát triển giao diện người dùng trong JavaScript - React Native) có ít hơn một chút. Tuy nhiên, cả hai đều phải có một kho kiến ​​thức lớn không chỉ về kỹ thuật mà còn cả kiến ​​thức “tổ chức”. Kiến thức “tổ chức” này là một trong những điểm giao nhau giữa các nhà phát triển frontend và backend. 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 đó - về đánh giá nhiệm vụ (ước tính). Và vì tôi chỉ làm việc theo phương pháp Agile (trên thực tế được coi là phương pháp phổ biến nhất), nên trong phần phụ của nó, Scrum , tôi sẽ xem xét đánh giá nhiệm vụ trong bối cảnh Scrum . Tôi sẽ nói ngay rằng việc đánh giá, còn gọi là ước tính, rất khó. Đối với cá nhân tôi với tư cách là một nhà phát triển, đây là một trong những khía cạnh khó khăn/không mong muốn nhất của công việc. Có nhiều yếu tố khác nhau cần xem xét có thể ảnh hưởng đến việc đánh giá một nhiệm vụ. Đồng thời, các kế hoạch phát triển hơn nữa sẽ dựa trên dự báo của bạn.

Điều gì sẽ xảy ra nếu bạn không được đánh giá đúng?

Nếu một nhà phát triển dành nhiều giờ cho một nhiệm vụ hơn số giờ cuối cùng sẽ tiêu, thì có vẻ như anh ta không phải là chuyên gia giỏi nhất vì ước tính đó rất không chính xác. Có thể nói, một ngón tay trên bầu trời. Đồng thời, nếu nhà phát triển không đầu tư đúng thời gian đã dự đoán sẽ gây nguy hiểm cho kế hoạch phát hành sản phẩm/tính năng mới của khách hàng. Đây là một công việc kinh doanh, và kinh doanh có nghĩa là tiền bạc, và rất ít khách hàng sẽ thích sự thủng lỗ như vậy. Đây thực sự là lý do tại sao tôi không thích việc ước tính, vì đôi khi rất khó xác định chính xác thời gian hoàn thành một nhiệm vụ.

Thời gian được đánh giá như thế nào?

Theo quy định, việc ước tính được thực hiện theo giờ hoặc điểm câu chuyện. Cá nhân tôi tiến gần hơn đến quá trình đánh giá các điểm trong câu chuyện . Nếu một chiếc đồng hồ là một thứ gì đó vật chất, thì một thứ có thể bị nhầm lẫn, các điểm trong câu chuyện hơi liên quan đến một thứ khác, trừu tượng hơn. Thông thường, các nhóm phát triển phần mềm đưa ra ước tính theo định dạng thời gian: giờ, ngày, tuần, tháng. Những ước tính thời gian như vậy chủ yếu dựa trên kinh nghiệm cá nhân, phỏng đoán hoặc trực giác. Trong trường hợp này, các nhà phát triển chỉ cần nhìn vào nhiệm vụ và ước tính thời gian thực hiện của họ. Kết quả là chúng rất hiếm khi chính xác, bởi có quá nhiều yếu tố có thể ảnh hưởng đến thời hạn hoàn thành công việc. Do đó, nhiều nhóm làm việc theo phương pháp Agile sử dụng các điểm câu chuyện. Hãy tìm ra nó.

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

• có thể tránh được sự thiếu chính xác trong ước tính trong các khoảng thời gian;
• Không giống như ước tính theo thời gian, chi phí chung có thể được tính đến tốt hơn: 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 cuộc thảo luận và lập kế hoạch khác nhau của nhóm cũng như các tình huống không lường trước được;
• Mỗi đội sẽ chấm điểm bài làm theo một thang điểm khác nhau, nghĩa là tốc độ của họ (được tính bằng điểm) sẽ khác nhau;
• Bằng cách xác định thang điểm để chỉ định từng điểm câu chuyện, bạn có thể nhanh chóng phân bổ điểm mà không cần tranh cãi nhiều.

Làm thế nào KHÔNG sử dụng điểm câu chuyện

Thật không may, điểm câu chuyện thường được sử dụng cho các mục đích khác. Điểm câu chuyện có thể có sai sót 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ị coi nhầm là thước đo hiệu suất. Thay vào đó, các nhóm cần sử dụng chúng để hiểu khối lượng/độ phức tạp của công việc trong từng nhiệm vụ và để sắp xếp thứ tự ưu tiên. Có thể những phần được đánh giá là khó hơn nên làm trước để có thể hoàn thành trước khi kết thúc sprint , còn những phần dễ hơn thì có thể đẩy lùi về sau. Hãy để tôi nhắc bạn rằng chạy nước rút là gì trong bối cảnh phương pháp Scrum : Khoảng thời gian này được xác định trong bao lâu khi bắt đầu phát triển theo 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, việc ước tính nhiệm vụ được thực hiện khi bắt đầu chạy nước rút để lập kế hoạch về khối lượng công việc có thể hoàn thành vào cuối nước rút, khi công việc đã hoàn thành được giao cho khách hàng. Nó giúp bạn thấy được tiến trình phát triển sản phẩm của mình, nhận phản hồi từ khách hàng và điều chỉnh quá trình phát triển dự án theo tầm nhìn của khách hàng. Tuy nhiên, chúng ta vẫn lạc đề một chút: hãy quay lại với ước tính. Việc đánh giá nhiệm vụ của chỉ một nhà phát triển sẽ quá chủ quan. Vì vậy, theo quy định, đây là công việc nhóm. Có khá nhiều kỹ thuật để đánh giá nhóm. Hôm nay chúng ta sẽ xem xét chúng được sử dụng nhiều nhất - Scrum poker . Kỹ thuật này đòi hỏi người quản lý phải là người giống như người lãnh đạo trò chơi poker Scrum này . Đây có thể là người chuyên về Scrum Master , hoặc PM .

Scrum Poker là gì

Scrum poker - hay lập kế hoạch poker - là một kỹ thuật đánh giá dựa trên việc đạt được thỏa thuận. Chủ yếu được sử dụng để đánh giá mức độ phức tạp của công việc phía trước hoặc khối lượng nhiệm vụ tương đối cần giải quyết trong quá trình phát triển phần mềm. Tôi sẽ lưu ý ngay rằng Scrum poker là một phương pháp phổ biến trong quá trình phát triển và bạn chắc chắn cần phải biết nó là loại quái thú gì. Đối với quá trình này, chúng tôi thường sử dụng một số loại ứng dụng hoặc trang web cho phép chúng tôi tổ chức đánh giá nhóm về 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 mục tồn đọng (nhiệm vụ mới, chức năng), thảo luận ngắn gọn về những cạm bẫy có thể xảy ra và các sắc thái khác liên quan đến nó. Sau đó, mỗi người tham gia sẽ chọn một thẻ có số đại diện cho mức độ khó của họ. Ồ, và khi ước tính, người ta không sử dụng chuỗi thông thường mà là các số Fibonacci . Các số Fibonacci rất phổ biến trong trò chơi poker scrum vì khoảng cách giữa chúng tăng dần theo thời gian (gợi nhớ đến các cấp độ kim tự tháp). Có những nhiệm vụ sẽ có độ phức tạp rất lớn và không thể đạt được một số lượng nhỏ điểm câu chuyện. Giải thích cho các thẻ bất thường:

số lượng điểm cuối không xác định

một nhiệm vụ dài vô tận

cần nghỉ ngơi

Các phương pháp ước tính hiếm gặp hơn:

• với các cỡ áo phông - S, M, L, XL
• hoặc ở chó - chihuahua, pug, dachshund, bulldog, v.v. (theo tôi, đây là đơn vị kỳ lạ nhất để đánh giá nhiệm vụ =D)

Sau đó, nhóm so sánh các ước tính được đưa ra cho cùng một vấn đề bởi các nhà phát triển khác nhau và nếu họ đồng ý thì thật tuyệt! Nếu không thì cần bàn lại nguyên nhân dẫn đến sự khác biệt trong đánh giá (lý lẽ). Sau đó, chúng ta có thể cùng nhau đưa ra một ước tính duy nhất mà mọi người dù cộng hay trừ đều sẽ đồng ý. Chà, tại sao poker lại được sử dụng để lập kế hoạch cho một dự án phần mềm nghiêm túc? Rốt cuộc, điều này có phần kỳ lạ. Trên thực tế, trò chơi như vậy khuyến khích các thành viên trong nhóm suy nghĩ độc lập, yêu cầu họ thể hiện kết quả của mình cùng lúc với đồng đội của mình. Ngược lại, điều này sẽ tránh được sự phụ thuộc vào quan điểm của các thành viên khác trong nhóm. Nếu không, các nhà phát triển ít kinh nghiệm hơn sẽ xem xét và dựa vào đánh giá của các thành viên trong nhóm có kinh nghiệm hơn, điều này sẽ phủ nhận tính hữu ích của đánh giá của chính họ. Nhưng với việc mở kết quả đồng thời, điều này về cơ bản là không thể. Một ví dụ về ứng dụng lập lịch Scrum Poker là từ Atlassian .

Ví dụ về đánh giá nhiệm vụ

Hãy tưởng tượng rằng nhóm của bạn đã xác định một thang đo nhất định để đánh giá điểm câu chuyện: Scrum Poker bắt đầu một nhiệm vụ và bạn đánh giá nó như sau:

• trước đây bạn chưa bao giờ làm việc với việc triển khai chức năng tương tự - +3
• chức năng của một nhiệm vụ cỡ trung bình - +2
• việc thực hiện nhiệm vụ có độ phức tạp cao - +3
• độ phức tạp cao của việc viết bài kiểm tra cho chức năng này - +3

Kết quả là bạn nhận được 11 điểm câu chuyện, nhưng vì không có thẻ nào như vậy nên bạn đưa ra 13 điểm. Một đồng nghiệp khác của bạn đánh giá nhiệm vụ:

• đã từng giải quyết vấn đề tương tự trước đây - +1
• chức năng của một nhiệm vụ cỡ trung bình - +2
• việc thực hiện nhiệm vụ có độ phức tạp trung bình - +2
• độ phức tạp trung bình của việc viết bài kiểm tra cho chức năng này - +2

Kết quả là anh ta nhận được 7 điểm câu chuyện, nhưng không có điều đó trong các số Fibonacci và anh ta đặt một thẻ có số gần nhất có thể - 8. Các thành viên khác trong nhóm, theo đó, đưa ra ước tính dựa trên quan điểm chủ quan của họ. Tiếp theo, bạn trình bày kết quả của mình và phát hiện ra rằng hầu hết tất cả đồng nghiệp của bạn đều đưa ra ước tính 13, ngoại trừ một nhà phát triển đưa ra ước tính 8. Trong trường hợp này, anh ta được đưa ra mức sàn và anh ta đưa ra lý do. Và họ, chẳng hạn, là như thế này: trước đây anh ấy đã làm việc với cùng một vấn đề, và nó không khó như người ta tưởng, và cuối cùng anh ấy thuyết phục các thành viên còn lại trong nhóm thay đổi giải pháp của họ từ câu chuyện 13 thành câu chuyện 8 điểm, nói rằng anh ấy sẽ giúp bất cứ ai đảm nhận nhiệm vụ này sẽ tìm ra nó. Hoặc cuối cùng, anh ấy sẽ tự mình làm điều đó. Và nói chung, việc người khác có lắng nghe lập luận của anh ta hay không không quan trọng, bởi vì bằng cách này hay cách khác, nhiệm vụ này sẽ được đánh giá và nhóm sẽ chuyển sang làm quen với nhiệm vụ tiếp theo. Lần đầu tiên, ước tính sẽ không chính xác, cũng như ước tính về khối lượng công việc bạn dự định thực hiện 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 chính xác dựa trên ước tính. Sau một thời gian, khoảng ba tháng, nhóm sẽ bắt đầu ước tính chính xác hơn các nhiệm vụ và khối lượng công việc trung bình mà nhóm có thể hoàn thành trong mỗi lần chạy nước rút sẽ trở nên rõ ràng. Nhưng đây là kế hoạch chung về phạm vi công việc, thiên về thời gian hơn và trong trường hợp này có thể có nhiều yếu tố khác nhau tác động. Ví dụ: một trong những nhà phát triển đã đi nghỉ hai tuần. Nghĩa là, bạn cần gạch bỏ một lượng công việc đã lên kế hoạch (chức năng đã lên kế hoạch) nhất định. Hoặc một nhà phát triển mới đến nhóm, nhưng bạn không cần phải hoàn toàn tin tưởng vào anh ta, bởi vì... bạn cần tính đến thời gian cần thiết để thích ứng với dự án, được gọi là onboarding . Thời gian này có thể là hai tuần, cộng hoặc trừ 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 được một chút kiến ​​thức của bạn về phần kiến ​​thức phi kỹ thuật như ước lượng bài toán. Nếu bạn muốn tìm hiểu sâu hơn về chủ đề này cũng như 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ể đảm bảo về hậu quả, vì có lẽ sau đó bạn sẽ có mong muốn khó chịu là trở thành Scrum Master =D