Lập dự toán dự án phần mềm chính xác

dự toán dự án phần mềm

Pixabay

Giới thiệu

Ước tính chỉ là khó khăn. Thật không may, nó cũng rất cần thiết. Các công ty sử dụng ước tính để dự đoán lịch phát hành, đưa ra cam kết với khách hàng của họ, quyết định xem một tính năng được đề xuất có đáng được triển khai hay không, theo dõi tốc độ của các nhóm và ưu tiên công việc một cách hiệu quả. Các giám đốc điều hành thường muốn biết khi nào một tính năng hoặc sản phẩm có thể phân phối sẽ sẵn sàng để sản xuất. Rốt cuộc, phát triển phần mềm không phải là một khoản đầu tư tầm thường. Nếu không có ước tính, người quản lý dự án sẽ đánh giá như thế nào? Nếu con người có thể dự đoán tương lai chính xác, thì con người sẽ không thắng trong các cuộc đua ngựa 2% thời gian. Ước tính là một câu hỏi hóc búa lớn. Việc các công ty yêu cầu người của họ làm điều không thể: dự đoán tương lai là điều cần thiết và cần thiết.

Đầu tiên, chúng ta hãy xem xét một số phương pháp ước tính phổ biến (trong trường hợp bạn bỏ lỡ một số hứng thú). Sau đó, chúng tôi có thể xem điều này có ý nghĩa gì đối với chúng tôi và các dự án của chúng tôi.

Mô hình Thầy bói

Mô hình này hầu như không cần nỗ lực để tạo ra một ước tính. Các nhà ước tính suy nghĩ một chút về những gì cần phải làm để triển khai và thử nghiệm một tính năng, sau đó họ đưa ra một con số. Nghe có vẻ giống như "… (tạm dừng lâu)… Ummmmm… 6 tuần." Sau đó mọi người gật đầu và chúng tôi tiếp tục. Họ có thể dành khá nhiều thời gian ở giao diện người dùng để nói về những gì họ biết về các yêu cầu (có thể không phải là bức tranh hoàn chỉnh). Phân tích cẩn thận này làm cho ước tính của họ cảm thấy đáng tin cậy hơn. Vào cuối dự án, luôn có một cơ sở lý luận được chấp nhận cho lý do tại sao ước tính quá xa so với thực tế. Luôn luôn có những trường hợp không lường trước được có thể coi như vật tế thần. Thường không xảy ra với bất kỳ ai rằng mô hình bị sai sót nghiêm trọng.

Vì vậy, làm thế nào chúng ta có thể làm cho quá trình này tốt hơn? Tôi biết! Chúng ta có thể sử dụng Kỹ thuật phân hủy (tức là chia để trị). Cách tiếp cận này giả định rằng bạn biết toàn bộ phạm vi của đối tượng địa lý hoặc dự án trên giao diện người dùng. Mọi tính năng đều được chia nhỏ thành các phần nhỏ vừa ăn. Mỗi phần được ước tính (theo kiểu thầy bói), sau đó chúng tôi cộng chúng lại để có được ước tính tổng thể về tính năng / dự án. Đây chắc chắn là một cách tiếp cận phức tạp hơn, nhưng nó có vẻ tốt hơn vì hai lý do:

• Các khối công việc nhỏ hơn có xu hướng dễ ước tính hơn một cách đáng tin cậy.
• Mặc dù vẫn có cơ hội xảy ra lỗi (+/- một số lượng), có một giả định rằng các lỗi sẽ triệt tiêu lẫn nhau khi bạn cộng lại tất cả và bạn sẽ nhận được ước tính tổng thể đáng tin cậy hơn.

Lỗ hổng cơ bản của cách tiếp cận này là những người đóng góp cá nhân (những người thực sự làm công việc) thường đánh giá thấp. Họ vẫn tốt hơn đáng kể so với những người ở trên và xung quanh họ, nhưng đó không phải là một thanh cao. Điều này có vẻ không giống trường hợp này vì chúng ta đều đã thấy những trường hợp mà các nhà phát triển tự ngạc nhiên khi hoàn thành một điều gì đó trước thời hạn. Nhưng đây là một điểm dữ liệu duy nhất, không phải là một xu hướng. Mọi người thực sự đôi khi giành chiến thắng tại sòng bạc; tiêu tiền tại sòng bạc mỗi ngày trong một năm và bạn sẽ có ít tiền hơn lúc đầu. Nếu bạn theo dõi ước tính so với thực tế trong một hoặc hai năm, bạn sẽ phát hiện ra rằng ước tính không thực tế. Trong khi nhiều người kinh doanh hoàn toàn chắc chắn rằng các nhà phát triển đang lười biếng đưa các ước tính của họ vào và sử dụng thêm thời gian để "đúc vàng" hoặc kiểm tra cổ phiếu của họ,dữ liệu hiển thị khác. Chiến lược "hủy bỏ" không hoạt động.

Thế bây giờ thì thế nào? Hãy bỏ mô hình thầy bói và chuyển sang cách tiếp cận dựa trên kích thước. Nó chỉ ra rằng, trong khi con người khá tệ trong việc ước tính thời gian hoàn thành, chúng tôi thực sự khá giỏi trong việc nói rằng một cái gì đó lớn như thế nào. Chúng tôi đặc biệt giỏi trong việc so sánh kích thước ("nó lớn hơn cái kia, nhưng nhỏ hơn cái kia"). Nếu chúng ta nghĩ về kích thước hoặc độ phức tạp hơn là thời gian, bộ não của chúng ta xử lý nó một cách đáng tin cậy hơn. Sau đó, chúng tôi có thể lấy các giá trị kích thước và tính toán số giờ thực tế cho dự án dựa trên một công thức ma thuật tiện lợi! Và đó là khi mô hình điểm chức năng phổ biến đi vào khung cảnh (sân khấu bên trái).

Phân tích điểm chức năng (FPA)

Để phân tích điểm chức năng, chúng ta cần xác định năm loại thứ trong ứng dụng của mình: đầu vào bên ngoài, đầu ra bên ngoài, truy vấn bên ngoài, tệp giao diện bên ngoài và tệp logic nội bộ (đừng lo lắng quá nhiều về định nghĩa; bạn có thể nghiên cứu chúng sau). Mỗi ví dụ trong số đó (một hàm) có độ phức tạp đi kèm với nó (thấp, trung bình hoặc cao). Chúng tôi sử dụng bảng dưới đây để tìm ra số điểm mà mỗi hàm được gán.

Bây giờ nếu chúng ta cộng điểm cho tất cả các chức năng của mình, chúng ta có thể nhận được một số như 457 điểm chức năng cho dự án của chúng ta. Sau đó, chúng tôi chỉ cần một công thức để tìm ra số giờ… Dựa trên dự án cuối cùng của chúng tôi, “tỷ lệ phân phối” của chúng tôi là 15 điểm chức năng cho mỗi người mỗi tháng. Đó là khoảng 30 tháng làm việc của người, sẽ mất hơn hai tháng rưỡi một chút cho nhóm 12. Ta-da!

Điều này chắc chắn phức tạp hơn mô hình trước đây của chúng tôi. Trên thực tế, có bốn lĩnh vực phức tạp chính cần nhận ra.

1. Năm loại thành phần không nhất thiết phải trực quan và rất dễ quên đưa một thứ gì đó vào danh sách hoặc gán nó vào nhóm sai.
2. Bảng được sử dụng để thực sự tạo ra các điểm hàm chứa các số ma thuật mà sẽ cần nhiều nỗ lực để xác nhận. Những con số này có được hiệu chỉnh đúng cách để tạo ra các ước tính đáng tin cậy cho nhóm của tôi không?
3. Tỷ lệ phân phối (một phần quan trọng của câu đố) được tính toán dựa trên năng suất của nhóm của bạn. Bao lâu chúng ta cần tính một số mới? Thực sự có rất ít hướng dẫn về điều này.
4. Điều gì tạo nên độ phức tạp thấp, trung bình hoặc cao? Làm thế nào để chúng tôi xác định điều đó để mọi người hiểu nó? Việc đạt được điều đó không quan trọng đối với độ chính xác của các tính toán của chúng ta sao?

Có một số phần chuyển động trong ví dụ rất đơn giản này và chúng tôi thậm chí chưa thảo luận về các mô hình phức tạp phức tạp hơn và các dữ liệu khác có thể phát huy tác dụng (ví dụ: tỷ lệ chi phí, tỷ lệ hỗ trợ, mật độ lỗi, v.v.). Nhiều bộ phận chuyển động hơn đồng nghĩa với nhiều cơ hội xảy ra lỗi hơn. Hiện tại chúng ta đang lập ước tính quá phức tạp? Chúng tôi không trả tiền cho các nhà phát triển để dành nhiều thời gian cho việc ước tính. Tôi không thể bán ước tính cho khách hàng của mình. Tôi cần phần mềm làm việc. Có gì khác ngoài đó không?

Nhanh nhẹn

Bây giờ chúng ta hãy xem xét ngắn gọn về nhanh nhẹn scrum (chỉ đủ để làm một phép so sánh). Như đã nói trước đó, con người rất tệ trong việc ước lượng thời gian và khá giỏi trong việc so sánh kích thước. Dưới đây là một số thuật ngữ cần hiểu:

• Chạy nước rút - một khoảng thời gian được đóng hộp theo thời gian (thường là hai tuần).

• Câu chuyện người dùng - một phần công việc rời rạc, tốt nhất là đủ nhỏ để một người thực hiện trong sprint. Đây là điều chúng tôi đang ước tính.

Chiến lược phổ biến nhất là sử dụng chuỗi fibonacci (0, 1, 2, 3, 5, 8, 13) để ước tính. Nó không tuyến tính - khi bạn tăng quy mô, kích thước của các khoảng trống sẽ tăng lên. Điều quan trọng là khoảng cách phải đủ rộng để không có lý do gì để tranh cãi về những khác biệt không đáng kể. Khi bạn vượt lên trên 3, sự khác biệt giữa 4 và 5 hoặc 7 và 8 là không đáng kể đến mức việc dành thời gian băm ra xem đó là giá trị nào. Chuỗi cơ số 2 cũng sẽ hoạt động (0, 1, 2, 4, 8, 16, v.v.).

“Nhưng khoan đã, đây chỉ là một con số. Nó có nghĩa là gì? Bao nhiêu giờ là một điểm? ” Điểm không có ý định tương quan trực tiếp với giờ, bởi vì nếu có, các đội sẽ bị cám dỗ quay lại ước tính theo giờ và sau đó chuyển đổi thành điểm bằng cách nào đó. Như đã thảo luận trước đó, độ chính xác của các ước tính của chúng tôi đến từ việc so sánh kích thước và không ước tính số giờ một cái gì đó sẽ mất. Nếu bạn cung cấp cho nhóm khả năng suy nghĩ về thời gian, bạn đang làm mất khả năng ước tính chính xác của mình.

Giả sử bạn bắt đầu với một bài tập hiệu chuẩn. Kéo nhóm của bạn vào một căn phòng và hướng dẫn họ xem qua danh sách 10-12 câu chuyện của người dùng. Chọn một cái nhỏ nhưng không nhỏ nhất và làm cái đó trước. Đánh giá nó và thông báo rằng câu chuyện này là một "3". Bạn không hỏi. Bạn đang nói. Sau đó chuyển sang câu chuyện tiếp theo. "Nếu đó là 3, thì đây là gì?" Bây giờ nhóm đang định cỡ các câu chuyện tương đối với các câu chuyện khác. Cuối cùng, họ sẽ có một ý tưởng khá tốt về những gì tạo thành “1”, “2”, v.v. Họ không ước tính. Thời gian không quan trọng. Họ đang định cỡ những câu chuyện, so với những câu chuyện khác đã có số. Sau đó, bạn có thể đặt các câu chuyện ví dụ cho mỗi số trong chuỗi trong một tài liệu được gọi là thước kẻ. Họ có thể sử dụng nó làm tài liệu tham khảo nếu họ không chắc chắn "5" là gì.

Bây giờ đây là chìa khóa. Nước sốt thần kỳ tạo nên công việc này là “vận tốc” (số điểm mà một đội có thể hoàn thành trong một lần chạy nước rút được tính trung bình trong 3-4 lần chạy nước rút). Giả sử thời gian chạy nước rút của bạn là hai tuần và nhóm của bạn gồm 8 người có vận tốc trung bình là 35 điểm. Bạn nhận được 35 điểm trong 640 giờ làm việc (8 x 80 giờ). Nếu chúng tôi nhận ra rằng một tính năng sẽ mất khoảng 100 điểm để bắt đầu hoàn thành thì tôi biết rằng đó là khoảng 6 tuần làm việc và ~ 1900 giờ. Nhóm rất giỏi trong việc định cỡ các câu chuyện một cách nhất quán và bạn tận dụng điều đó để lập kế hoạch dự án của mình. Tính toán này hoạt động vì khoảng thời gian nhất quán từ nước rút đến nước rút.

Để lập kế hoạch cấp cao dài hạn, bạn có thể yêu cầu khách hàng tiềm năng chia nhỏ các tính năng cấp cao thành các câu chuyện ngắn gọn tạm thời và đặt giá trị điểm cho chúng. Sẽ có một mức độ chính xác bị mất, nhưng bạn đang tận dụng mô hình mà họ đã hiểu. Một đường dẫn chính xác hơn sẽ là định cỡ tương đối ở cấp tính năng. “Tính năng này lớn hơn tính năng 40 điểm đó, nhỏ hơn tính năng 120 điểm ở đó và lớn hơn một chút so với tính năng 65 điểm mà chúng tôi vừa làm.” Các câu chuyện được nhóm thành "sử thi". Nếu mỗi tính năng là một sử thi, thì cuối cùng, bạn sẽ biết cần bao nhiêu điểm để hoàn thành tính năng đó. Giữ lịch sử về điều đó và bạn có thể sử dụng nó cho kế hoạch phát hành của mình.

Phần kết luận

Ngày nay có rất nhiều phương pháp luận được sử dụng. Mỗi cái đều có ưu và nhược điểm. Bằng cách nào đó, chúng ta cần tìm ra cách tối đa hóa độ chính xác của các ước tính để chúng ta có thể đưa ra quyết định đúng đắn. Điều đó không có nghĩa là ước tính của chúng tôi phải chính xác. Chúng chỉ cần đủ chính xác để chúng hữu ích. Nếu bạn không hiểu về ước tính, bạn có thể cho rằng ước tính không chính xác vì nhóm không làm tốt công việc. Họ đã không ước tính chính xác, hoặc họ không thực hiện dự án một cách chính xác. Đánh bại sẽ tiếp tục cho đến khi ước tính được cải thiện. Nhưng ước tính không bao giờ được sử dụng như một cam kết. Đó là phỏng đoán tốt nhất dựa trên thông tin hạn chế mà chúng tôi có ngày hôm nay. Khi thông tin mới xuất hiện, chúng tôi phải cho phép các ước tính được xem xét lại. Bất cứ điều gì khác đều mong đợi điều không thể, đó là vấn đề với lãnh đạo (không phải với nhóm).

Cách tiếp cận của Scrum đơn giản hơn nhiều so với những gì chúng ta thấy trong phân tích điểm chức năng. Và tôi có thể nói rằng nó đáng tin hơn nhiều so với những bảng ma thuật với những con số ma thuật. Nó nhận được nhiều tiếng nổ nhất (nỗ lực tối thiểu với mức độ chính xác hợp lý cao). Từ góc độ nỗ lực, nó không tạo ra một quy trình nặng nề để các nhóm hiểu và sử dụng. Phần ước lượng của agile thực sự có thể xảy ra rất nhanh khi mọi người đều hiểu chi tiết về công việc được ước tính. Nó chắc chắn tốt hơn là kéo những con số ra khỏi không khí loãng. Vận tốc tận dụng thực hiện một điều rất quan trọng: nó đưa dữ liệu lịch sử vào tính toán. Mỗi lần chạy nước rút, bạn tính toán lại vận tốc của mình. Điều này rất quan trọng, bởi vì thông lượng thay đổi theo thời gian. Các nhóm sử dụng FPA có thể lấy được tỷ lệ phân phối từ dự án trước của họ,mà trong một số trường hợp là vài tháng trước. Rất nhiều có lẽ đã thay đổi kể từ đó. Đề xuất của tôi là dành cho bạn để khám phá Agile và thực sự nỗ lực để hiểu các điểm và tốc độ câu chuyện. Đừng quay lại ước tính trong nhiều giờ chỉ vì đó là những gì bạn hiểu. Tôi tin rằng bạn sẽ cảm ơn chính mình sau này.

Thăm dò ý kiến ​​nhanh