Ước tính chi phí thời gian trong cơ sở mã di sản

Gần đây tôi bắt đầu làm việc với một dự án trong đó một ứng dụng nguyên khối rất cũ đang được chuyển sang kiến ​​trúc dựa trên microservice.

Cơ sở mã di sản rất lộn xộn ('mã spaghetti') và thường là một hàm rõ ràng đơn giản (ví dụ: "MultiplyValueByTen") sau đó cho thấy chính nó là "hàng ngàn dòng mã xác thực liên quan đến 10 bảng trên 3 lược đồ khác nhau".

Bây giờ ông chủ của tôi (đúng) yêu cầu tôi ước tính sẽ mất bao lâu để viết tính năng X trong kiến ​​trúc mới. Nhưng tôi đang gặp khó khăn khi đưa ra một ước tính thực tế; thường tôi cực kỳ đánh giá thấp công việc vì lý do tôi đã nêu ở trên và gây rắc rối cho bản thân mình bởi vì tôi không thể hoàn thành trong thời gian.

Điều hợp lý dường như có thể thực sự đi vào mã, lưu ý mọi chi nhánh và gọi đến các chức năng khác và sau đó ước tính chi phí thời gian. Nhưng thực sự có một sự khác biệt rất nhỏ giữa việc ghi lại mã cũ và thực sự viết ra phiên bản mới.

Làm thế nào tôi nên tiếp cận một kịch bản như thế này?

Trong khi tôi hoàn toàn hiểu cách tái cấu trúc mã kế thừa hoạt động, câu hỏi của tôi không phải là "làm thế nào để thực hiện tái cấu trúc / viết lại?" nhưng về việc đưa ra một câu trả lời thực tế cho "mất bao lâu để tái cấu trúc / viết lại phần X?"

Đọc "Bộ giải mã sạch" của Bob Martin (và "Mã sạch" trong khi bạn ở đó). Sau đây là từ bộ nhớ nhưng tôi mạnh mẽ đề nghị bạn mua bản sao của riêng bạn.

Những gì bạn cần làm là một trung bình có trọng số ba điểm. Bạn thực hiện ba ước tính cho mỗi phần công việc:

• một trường hợp tốt nhất - giả sử mọi thứ đều đúng (a)
• một trường hợp xấu nhất - giả sử mọi thứ đều sai (b)
• dự đoán thực tế - những gì bạn nghĩ có thể sẽ mất (c)

Ước tính của bạn là sau đó (a + b + 2c) / 4

• Không, nó sẽ không chính xác. Có nhiều cách ước tính tốt hơn nhưng phương pháp này nhanh chóng, dễ hiểu và giảm nhẹ sự lạc quan bằng cách khiến bạn xem xét trường hợp xấu nhất.
• Có, bạn sẽ phải giải thích với người quản lý của mình rằng bạn không quen với mã và rằng bạn không thể đoán trước được việc ước tính chính xác, chắc chắn mà không mất nhiều thời gian để điều tra mã mỗi lần để cải thiện ước tính (đề nghị thực hiện điều này nhưng nói rằng bạn cần n ngày chỉ để đưa ra ước tính chắc chắn về việc sẽ mất bao nhiêu ngày nữa). Nếu bạn là "JuniorDev" thì điều này có thể được chấp nhận đối với người quản lý hợp lý.
• Bạn cũng nên giải thích với người quản lý của mình rằng các ước tính của bạn được tính trung bình, dựa trên trường hợp tốt nhất, trường hợp xấu nhất và trường hợp có thể xảy ra và cung cấp cho họ số liệu của bạn cũng cung cấp cho họ các thanh lỗi.
• KHÔNG đàm phán về ước tính - nếu người quản lý của bạn cố gắng sử dụng trường hợp tốt nhất cho mọi ước tính (họ là một kẻ ngốc - nhưng tôi đã gặp một số người như vậy) và sau đó bắt nạt / thúc đẩy bạn cố gắng hoàn thành đúng hạn, họ sẽ đôi khi sẽ thất vọng. Tiếp tục giải thích lý do đằng sau các ước tính, (trường hợp tốt nhất, trường hợp xấu nhất và trường hợp có thể xảy ra) và tiếp tục tiến gần đến mức trung bình có trọng số nhiều lần và bạn sẽ ổn. Ngoài ra, cho mục đích riêng của bạn, hãy giữ một bảng tính các ước tính của bạn và thêm thực tế của bạn khi bạn hoàn thành. Điều đó sẽ cho bạn một ý tưởng tốt hơn về cách điều chỉnh các ước tính của bạn.

Biên tập:

Giả định của tôi khi tôi trả lời điều này:

1. OP là Nhà phát triển cơ sở (dựa trên tên người dùng đã chọn). Do đó, mọi lời khuyên được đưa ra không phải theo quan điểm của Quản lý dự án hoặc Trưởng nhóm, người có thể được kỳ vọng có thể thực hiện các ước tính phức tạp hơn tùy thuộc vào sự trưởng thành của môi trường phát triển.
2. Người quản lý dự án đã tạo ra một kế hoạch dự án bao gồm một số lượng khá lớn các nhiệm vụ được lên kế hoạch mất vài tháng để giao.
3. OP đang được yêu cầu cung cấp một số ước tính cho các nhiệm vụ được giao bởi Người quản lý dự án của họ, người muốn có một con số chính xác hợp lý (không phải đường cong xác suất :)) để đưa vào kế hoạch dự án và sử dụng để theo dõi tiến độ.
4. OP không có nhiều tuần để đưa ra từng ước tính và đã bị đốt cháy trước đó bằng cách đưa ra các ước tính quá lạc quan và muốn có một phương pháp chính xác hơn là dán một ngón tay lên không trung và nói "2 tuần, trừ khi mã đặc biệt phức tạp trong trường hợp 2 tháng hoặc hơn".

Trung bình trọng số ba điểm hoạt động tốt trong trường hợp này. Nó nhanh chóng, dễ hiểu đối với những người phi kỹ thuật và qua một số ước tính nên trung bình với một cái gì đó tiếp cận với độ chính xác. Đặc biệt là nếu OP có lời khuyên của tôi về việc lưu giữ hồ sơ ước tính và thực tế. Khi bạn biết thế nào là "Trường hợp xấu nhất" và "Trường hợp tốt nhất" trong thế giới thực, bạn có thể đưa thực tế vào các ước tính trong tương lai của mình và thậm chí điều chỉnh các ước tính cho người quản lý dự án của bạn nếu trường hợp xấu nhất tồi tệ hơn bạn nghĩ.

Hãy làm một ví dụ hoạt động:

• Trường hợp tốt nhất, từ kinh nghiệm nhanh nhất tôi đã thực hiện một cách thực sự đơn giản là bắt đầu một tuần để kết thúc (5 ngày)
• Trường hợp xấu nhất, từ kinh nghiệm, có thời gian đó có liên kết ở khắp mọi nơi và cuối cùng tôi phải mất 6 tuần (30 ngày)
• Ước tính thực tế, có lẽ tôi sẽ mất 2 tuần (10 ngày)

5 + 30 + 2x10 = 55

55/4 = 13,75 đó là những gì bạn nói với PM của bạn. Có thể bạn làm tròn đến 14 ngày. Theo thời gian, (ví dụ mười nhiệm vụ), nó sẽ trung bình ra.

Đừng ngại điều chỉnh công thức. Có thể một nửa nhiệm vụ kết thúc cơn ác mộng và chỉ mười phần trăm là dễ dàng; vì vậy bạn tạo estmate a / 10 + b / 2 + 2c / 5. Học hỏi kinh nghiệm của bạn.

Lưu ý, tôi không đưa ra bất kỳ giả định nào về chất lượng của PM. Một PM xấu sẽ đưa ra một ước tính ngắn cho ban dự án để được chấp thuận và sau đó bắt nạt nhóm dự án để cố gắng đạt được thời hạn không thực tế mà họ đã cam kết. Cách phòng thủ duy nhất là giữ một bản ghi để bạn có thể được nhìn thấy đưa ra ước tính của mình và tiến gần đến chúng.

Đây có thể là một thời điểm tốt để giới thiệu một cách tiếp cận gần như nhanh nhẹn. Nếu thay vì ước tính theo số giờ / ngày, bạn đã phân bổ thang đo loại Wikipedia & cho mỗi nhiệm vụ một giá trị dựa trên mức độ lớn của nó:

• 0 - tức thì
• 0,5 - thắng nhanh
• 1 - thay đổi đơn giản
• 2 - một vài thay đổi đơn giản
• 3 - nhiều thử thách hơn
• 5 - sẽ yêu cầu một số suy nghĩ về
• 8 - một lượng công việc đáng kể
• 13 - một khối lượng lớn công việc có lẽ cần phải được chia nhỏ
• 20 - một khối lượng lớn công việc chắc chắn cần phải được chia nhỏ

Sau đó, một khi bạn ước tính một loạt các nhiệm vụ như thế này, bạn làm việc với chúng. Trong một môi trường nhanh nhẹn, bạn phát triển 'vận tốc', đó là thước đo xem bạn đạt được bao nhiêu điểm trong một tuần. Sau khi bạn thực hiện một vài tuần thử nghiệm (bạn có thể bán nó cho người quản lý của mình như một phần của quy trình - "Tôi sẽ cần một vài tuần thử nghiệm và tìm hiểu để hiểu quy trình ước tính") bạn sẽ tự tin hơn về số điểm bạn có thể đẩy qua mỗi tuần và do đó bạn có thể dịch ước tính điểm của mình dễ dàng hơn theo thời gian.

https://pm.stackexchange.com/questions/4251/why-would-teams-use-the-fiborie-fterence-for-story-point

https://stackoverflow.com/questions/9362286/why-is-the-fiborie-series-use-in-agile-planning-poker

Điều này không thực sự nhanh nhẹn vì nó sẽ không liên quan đến các nghi lễ nhưng tôi có ý tưởng từ OP rằng anh ấy tự mình làm. Hy vọng phương pháp này có thể đưa ra một số ước tính tự tin hơn.

Điều đầu tiên bạn làm là bắt đầu thu thập dữ liệu về việc bạn mất bao lâu để hoàn thành mọi việc ngay bây giờ. Bạn càng có nhiều dữ liệu về hiệu suất của nhóm, thì càng tốt. Nó sẽ xuất hiện trên bảng, nhưng đừng lo lắng về điều đó ngay bây giờ. Đó là sự thật và bạn cần thể hiện thực tế của sếp.

Sau đó, bạn sẽ đi mua một vài cuốn sách.

1. Ước tính phần mềm: Làm sáng tỏ nghệ thuật đen của Steve McConnell
2. Làm việc hiệu quả với Bộ luật kế thừa của Michael Feathers

Cuốn sách của McConnell sẽ bảo bạn bắt đầu thu thập dữ liệu và sau đó giải thích cách sử dụng nó để có được ước tính chính xác hơn. Luôn đưa ra ước tính 3 điểm! Luôn luôn. Hãy chắc chắn làm nổi bật các phần của cuốn sách nói về chất lượng mã kém sẽ thổi các ước tính của bạn như thế nào. Cho họ xem sếp của bạn.

Giải thích rằng nếu ước tính chính xác là quan trọng đối với công ty, bạn sẽ cần bắt đầu áp dụng những điều bạn học được từ cuốn sách của Feather. Nếu bạn muốn đi nhanh chóng, suôn sẻ và có thể dự đoán được, bạn sẽ cần bắt đầu cấu trúc lại mã và đưa nó vào khai thác thử nghiệm. Tôi đã ở đúng nơi bạn đang ở. Thời gian phát triển là hoàn toàn không thể đoán trước bởi vì bạn không biết những gì bạn có thể phá vỡ, phải không? ... Vâng. Nhận nó vào một khai thác thử nghiệm. Một máy chủ CI để chạy các thử nghiệm đó cũng không thể làm tổn thương.

Cuối cùng, giải thích với sếp của bạn rằng mọi thứ vẫn sẽ hơi khó đoán trong một thời gian. Có thể một vài năm, nhưng sự phát triển đó sẽ trở nên dễ dàng hơn hàng ngày và các ước tính sẽ trở nên chính xác hơn khi bạn có nhiều dữ liệu hơn và mã trở nên tốt hơn. Đây là một khoản đầu tư dài hạn cho công ty. Tôi đã trải qua điều này gần đây, phải mất gần 2 năm để trở thành chủ yếu dự đoán.

Tôi biết tôi đã nói nhiều hơn về việc cải thiện mã hơn là ước tính, nhưng sự thật phũ phàng là ước tính của bạn sẽ tệ hại cho đến khi bạn có thể chế ngự cơ sở mã kế thừa. Trong thời gian đó, sử dụng hiệu suất lịch sử để đánh giá sẽ mất bao lâu. Khi thời gian trôi qua, bạn sẽ muốn tính đến việc bạn đã nhận được mã để xác định trong ước tính của mình hay chưa.

Bây giờ ông chủ của tôi đang hỏi tôi một ước tính chính xác về việc mất bao lâu để viết tính năng X trong kiến ​​trúc mới. Nhưng tôi đang gặp khó khăn khi đưa ra một ước tính thực tế; đôi khi tôi đánh giá thấp nhiệm vụ vì những lý do tôi đã nêu ở trên và lúng túng vì tôi không thể hoàn thành kịp thời gian.

Có lẽ bạn đang suy nghĩ trong hộp gửi một ước tính. Tôi phải làm việc theo mã kế thừa và khi tôi ước tính chính thức hơn, tôi thường thực hiện hai hoặc ba :

1. Ước tính chính - giả sử rằng tôi phải dành thời gian đào nhưng kiến ​​trúc cho phép thay đổi mà chúng ta muốn
2. Ước tính thiên thần - giả định rằng mọi thứ đều minh bạch / dễ tìm và tôi chỉ phải thực hiện các thay đổi nhỏ (đây là điều tôi thỉnh thoảng bỏ qua ... đặc biệt là nếu tôi biết chỉ có quỷ trong một cơ sở mã cụ thể)
3. Ước tính Abyssal - giả định rằng cấu trúc cơ bản của mã kế thừa không tương thích với tính năng được yêu cầu và tôi sẽ thực hiện tái cấu trúc lớn để làm cho mọi thứ hoạt động

Tất cả ba ước tính đều tính đến mức độ khó của tính năng này, bất kỳ trải nghiệm nào tôi có với cơ sở mã chung đó và cảm nhận của tôi về sự thay đổi (mà tôi thấy có thể khá chính xác)

Sau khi những ước tính này được đưa ra, tôi luôn cập nhật cho người quản lý của mình về cái mà nó trông giống như chúng ta đang giải quyết. Nếu hóa ra chúng ta đang nhìn vào một tính năng vực thẳm, thì chúng ta có thể phải hy sinh nó - nó đã xảy ra. Nếu ông chủ của bạn không thể chấp nhận rằng có những tính năng tuyệt vời cho một đoạn mã kế thừa nhất định, thì tôi chúc họ may mắn, vì họ sẽ có một cuộc sống rất khó khăn và bực bội.

Khi tôi phải đối mặt với loại vấn đề này, tôi đã dựa vào việc đưa ra các phạm vi theo ước tính của mình. Tôi đã nhận được bằng cách nói với các sếp của tôi rằng "thật khó để thực hiện các ước tính ngoài lề tốt cho cơ sở mã này. Nếu bạn yêu cầu, đó sẽ là một ước tính rất rộng." Tôi đã ước tính "3 ngày đến 3 năm" một lần. Không cần phải nói đó không phải là một ước tính phổ biến, nhưng đó là những gì tôi đã đưa ra.

Chìa khóa cho vấn đề này là một thỏa thuận mà tôi sẽ cập nhật các ước tính của mình khi tiến độ công việc. Vì vậy, nếu tôi được thông báo "Thực hiện XYZ, sẽ mất bao lâu?" Câu trả lời của tôi có thể là "ở đâu đó giữa một ngày và 4 tháng. Tuy nhiên, nếu bạn để tôi thực sự xem mã trong vài giờ, tôi có thể giảm sự không chắc chắn trong cửa sổ đó." Sau đó tôi đi xem mã và quay lại với "2 đến 4 tuần." Đó vẫn chưa phải là một cửa sổ lý tưởng, nhưng ít nhất nó là thứ có thể quản lý được.

Có một vài chìa khóa để làm điều này:

• Thuyết phục sếp rằng những ước tính này được coi là một cuộc trò chuyện tốt hơn bởi vì bạn sẽ tìm hiểu thêm về nhiệm vụ trông như thế nào trong khi bạn thực hiện nó. Đây là cơ hội để sếp của bạn có thông tin mà họ sẽ không có nếu họ chỉ yêu cầu một ước tính duy nhất.
• Cung cấp các tùy chọn như làm thế nào để chuyển tiếp tốc độ phát triển mã giao dịch so với cải thiện ước tính. Cung cấp cho họ một núm thêm họ có thể biến. Đôi khi các ông chủ biết một nhiệm vụ chỉ cần hoàn thành và họ chỉ cần ước tính sân bóng. Những lần khác, họ đang chạy những ưu và nhược điểm của một nhiệm vụ và khả năng tinh chỉnh các ước tính là có giá trị.
• Nếu có thể, tôi cũng sẽ cung cấp tiền thưởng tổng hợp. Thường có những cải tiến về kiến ​​trúc sẽ mang lại lợi ích cho nhiều nhiệm vụ. Nếu tôi có 10 nhiệm vụ thì tất cả chỉ mất "1-2 tháng nay, nhưng sẽ mất 2 tuần với nâng cấp X", việc bán 20 tuần có thể mất để nâng cấp X sẽ dễ dàng hơn.

Nếu tôi có một ông chủ không thoải mái khi nhận được một phạm vi được cập nhật khi tôi đi, tôi sẽ cung cấp cho họ một số duy nhất và phương pháp của tôi. Phương pháp luận của tôi là sự kết hợp của một quy tắc ngón tay cái mà tôi đã được nói với tư cách là một nhà phát triển trẻ và luật của Hofstader .

Ước tính thời gian bạn nghĩ rằng nhiệm vụ sẽ mất bao lâu, sau đó tăng gấp bốn lần số đó và đưa ra như ước tính của bạn.

và

Luật của Hofstadter: "Luôn mất nhiều thời gian hơn bạn mong đợi, ngay cả khi bạn tính đến Luật của Hofstadter."

Điều hợp lý dường như có thể thực sự đi vào mã, lưu ý mọi chi nhánh và gọi đến các chức năng khác và sau đó ước tính chi phí thời gian. Nhưng thực sự có một sự khác biệt rất nhỏ giữa việc ghi lại mã cũ và thực sự viết ra phiên bản mới.

Đây là giải pháp cho vấn đề của bạn. Bạn không thể ước tính nếu bạn không có yêu cầu. Nói với sếp của bạn, bạn sẽ cần phải làm điều này trước khi bạn có thể bắt đầu viết mã. Sau một vài chức năng và mô-đun, bạn có thể phát hiện ra tất cả chúng đều được mã hóa một cách nhất quán (trong trường hợp này là kém), vì vậy bạn có một đường cơ sở để xác định các ước tính trong tương lai. Chỉ cần chắc chắn rằng bạn điều chỉnh ước tính của mình nếu bạn phát hiện ra mã hóa trở nên tồi tệ hơn.

Tôi nhận ra rằng sếp của bạn muốn ước tính, nhưng không biết thông tin này được sử dụng như thế nào, chúng tôi không biết chính xác ước tính của bạn cần như thế nào. Có một cuộc trò chuyện với anh ta và tìm hiểu. Nếu anh ta chỉ cần một số để cung cấp cho ông chủ của mình, bạn có thể tăng nhẹ các ước tính và cung cấp một số. Đối với các khách hàng đang chờ thanh toán mã của bạn cho đến khi điều này được thực hiện, hãy đảm bảo bạn tìm hiểu xem liệu ngày hết hạn có hạn sẽ mang lại doanh thu đáng kể hay không.

Trong tình huống như thế này tôi không tin có thể đưa ra ước tính tốt. Vấn đề cơ bản là thường một phần lớn của việc thực hiện nó là tìm ra chính xác những gì cần làm.

Tôi xử lý các trường hợp như thế này bằng cách đưa ra ước tính dựa trên những gì nó có vẻ đòi hỏi nhưng với sự bất ngờ có thể xảy ra. Mặc dù tôi không phải đối phó nhiều với cách viết mã kế thừa, tôi đã có một số bất ngờ rất khó chịu khi xử lý dữ liệu đầu vào - Tôi đã thấy một vài giờ biến thành một vài tuần và một lần là điều này là không thể (Sau đào sâu đáng kể tôi đã tìm ra rằng tôi không có đủ dữ liệu trong một trường hợp nhất định, quay lại bảng vẽ.) May mắn thay, ông chủ của tôi hiểu khi tôi đưa ra ước tính như vậy.

Chà, ước lượng là một kỹ năng mà một số người không bao giờ học tốt. Nó không làm cho bạn trở nên vô dụng như một nhà phát triển mặc dù ngay cả khi bạn không thể đưa ra các ước tính tốt. Có thể đồng đội hoặc quản lý sẽ điền vào những khoảng trống. Tôi rất tệ với nó, vẫn hầu hết các đội thích làm việc với tôi. Giữ bình tĩnh, lập nhóm và tiếp tục tái cấu trúc.

Nợ kỹ thuật mang đến cho bạn những thách thức nhỏ, nhưng hãy nhớ rằng một công ty / nhóm đã kết thúc việc tạo ra nợ sẽ tiếp tục tạo ra nợ trừ khi có những thay đổi về tinh thần nhóm hoặc quản lý. Mã chỉ phản ánh các vấn đề xã hội, vì vậy hãy tập trung vào các vấn đề thực sự.

Chúng tôi đã sử dụng phương pháp phỏng đoán để ước tính các tính năng trong dự án brownfield: Chúng tôi ước tính sẽ mất bao lâu để thực hiện tính năng đó trong dự án greenfield mà không có gì được thực hiện. Sau đó, chúng tôi nhân số ước tính đó lên 2 để đối phó với việc dọn sạch các mảnh vỡ đã tồn tại.

Yếu tố này phụ thuộc vào số lượng khớp nối và kích thước mã tổng thể, nhưng nếu bạn thực hiện một số tính năng theo cách này, bạn có thể nội suy yếu tố đó dựa trên bằng chứng thực tế.

Tôi nghĩ bạn nên ngồi xuống với sếp của bạn, nhìn thẳng vào mắt anh ấy và nói:

'Nghe sếp! Chúng tôi chỉ tái cấu trúc ở đây. Không có chức năng mới để cung cấp, và không có khách hàng chờ đợi chức năng đó; vì vậy không nên có bất kỳ thời hạn. Điều này sẽ mất nhiều thời gian, bạn cần phải quyết định xem chúng tôi có phải làm điều đó hay không. '

Sử dụng tính quyết đoán chắc chắn như chỉ và ngồi về phía trước trên ghế của bạn.

Ngoài ra, bạn có thể tạo ra một số số để làm cho anh ta hạnh phúc. Nhưng hãy đối mặt với nó, cho đến khi bạn đi được nửa đường thì công việc của bạn sẽ không chính xác.