Có thể thực hiện một cách tiếp cận linh hoạt linh hoạt cho các dự án đòi hỏi ước tính cả thời gian thực hiện và thời gian tiết kiệm?

Là một người đã làm việc hiệu quả với Agile trước đây, tôi đang cố gắng thuyết phục các chủ nhân hiện tại của mình về lợi ích của nó. Tuy nhiên, ban quản lý khăng khăng rằng chúng tôi giữ khả năng lập dự toán trả trước để đánh giá giá trị kinh doanh của các dự án.

Hầu hết các khách hàng của tôi là nội bộ, và gần đây tôi được giao nhiệm vụ đi theo nhóm và yêu cầu họ cho ý tưởng về quy trình kinh doanh để tự động hóa. Sau đó tôi đã tìm hiểu xem điều này đã khiến họ mất bao nhiêu thời gian, tìm ra giải pháp sẽ tiết kiệm được bao nhiêu thời gian và ước tính tổng thời gian phát triển. Bằng cách đó, các nhà quản lý có thể cố gắng đo lường mức độ hiệu quả của một giải pháp về mặt thời gian được lưu.

Tuy nhiên, có vẻ như tôi không có cách nào để tiếp cận yêu cầu này theo cách "Agile". Yêu cầu linh hoạt có nghĩa là không chỉ ước tính thời gian thực hiện là sai, do đó, ước tính thời gian tiềm năng sẽ được lưu. Tôi đã giải thích rất nhiều, giải thích lý do tại sao nó có khả năng là vấn đề, nhưng được nói rằng nó không thể thương lượng.

Câu hỏi Làm thế nào để bán phát triển Agile cho khách hàng (thác nước) có một số lời khuyên hữu ích về cách "bán" Agile cho khách hàng bên ngoài. Tôi không cố bán nó cho khách hàng bên ngoài: Tôi đang cố gắng tìm ra cách để tôi có thể điều hòa tốt nhất các yêu cầu của quản lý nội bộ trong khi vẫn duy trì một phương pháp mà tôi tin là hoạt động tốt.

Có cách nào để tiếp cận nhiệm vụ này một cách linh hoạt cho phép tôi giữ lại ít nhất một số lợi ích Agile không?

Như các câu trả lời khác đã nêu, Ban quản lý có mọi quyền để có được ước tính cao cấp trước của một dự án. Chúng không phải là không có lý khi cố gắng xác định ROI.

Tuy nhiên, một trong những cách tiếp cận mà tôi thích về Agile là phạm vi của một dự án không cố định. Nó có thể được định cỡ ban đầu ở cấp Tính năng và Sử thi, sau đó doanh nghiệp có thể xác định ROI dựa trên các tính năng quan trọng nhất. Có thể giao diện người dùng ưa thích với chuông và còi có giá trị kinh doanh thấp, nhưng công cụ xử lý công việc để xử lý khiếu nại có ROI cao.

Khi bạn gộp toàn bộ dự án lại với nhau thì việc gặp ROI sẽ khó hơn nếu bạn tập trung vào chức năng kinh doanh quan trọng mong muốn.

Đây là một cách mà tôi đã làm điều này:

Lấy các cột mốc WBS của bạn và biến từng điểm này thành một tính năng có thể phân phối

Điều này cho phép bạn phân loại dự án của bạn thành các tiểu dự án nhỏ có giá trị kinh doanh khác nhau. Mỗi người trong số họ nên tự đứng về giá trị kinh doanh.

Kích cỡ áo phông cho các tính năng

Đây là một cách rất dễ dàng để có được một ý tưởng sơ bộ về mức độ lớn hoặc liên quan đến một tính năng cụ thể có thể. Có lẽ các tính năng giá trị thấp vẫn có ROI tuyệt vời nếu chúng trông giống như chiến thắng dễ dàng.

Chia nhỏ một tính năng thành câu chuyện

Đi qua bài tập để tìm một đặc điểm nhỏ được hiểu rõ và chia nó thành các câu chuyện ban đầu. Ước tính những câu chuyện bằng điểm. Bây giờ bạn có một cơ sở nơi

Nhỏ -> 40 điểm

Đây sẽ là một cơ sở so sánh với các tính năng khác

Liên kết nỗ lực điểm câu chuyện cho tất cả các tính năng

So sánh tính năng nhỏ của bạn với các tính năng khác. Ví dụ,

Tính năng trung bình Y cảm thấy như nó gấp đôi kích thước và nỗ lực của Tính năng nhỏ X với 40 điểm câu chuyện.

Tính năng trung bình Y có lẽ là 80 điểm. Tiếp tục điều này cho đến khi bạn có điểm câu chuyện ước tính ở mức cao cho tất cả các tính năng.

Ước tính Vận tốc nhóm của bạn

Nhìn vào nhóm phát triển của bạn, hãy cố gắng xác định nhóm này có thể cung cấp hiệu quả bao nhiêu điểm trong một lần chạy nước rút nhất định. Nếu bạn có các dự án Agile trước đây làm ví dụ với nhóm này thì đó là một nơi tuyệt vời để bắt đầu. Nếu bạn không có lịch sử như vậy đằng sau nhóm thì hãy tham gia Lập kế hoạch Sprint giả với nhóm của bạn, nơi bạn bắt đầu xem xét tính năng Nhỏ mà bạn đã nêu chi tiết. Những loại ước tính hàng giờ mà mọi người đưa ra cho nhiệm vụ của họ về những câu chuyện này?

Dựa trên số lượng công việc mà nhóm nghĩ rằng họ có thể giao trong 2 tuần, hãy sử dụng tổng số điểm câu chuyện đó làm vận tốc tiềm năng trung bình của nhóm của bạn!

Tìm ngày hoàn thành dự kiến ​​của bạn

Nếu nhóm của bạn trong kế hoạch chạy nước rút giả cảm thấy thoải mái khi cung cấp 25 điểm câu chuyện trong một lần chạy nước rút và tổng số tồn đọng của bạn trông giống như 300 điểm câu chuyện cho phiên bản Cadillac vàng của dự án của bạn, thì có vẻ như nhóm của bạn sẽ mất 12 lần chạy nước rút hoặc 24 tuần hoàn thành mọi thứ

Bây giờ thật tầm thường khi biến chi phí tài nguyên trong nhóm của bạn thành đô la mỗi tuần để đạt được chi phí cho ROI so với Giá trị doanh nghiệp. Việc đàm phán có thể tiếp tục về các tính năng quan trọng nhất và sau đó quản lý dự án của bạn về cơ bản trở thành một vấn đề Knapsack.

Đây không phải là một vấn đề với "quản lý". Đó là một yêu cầu tuyệt đối để có thể ước tính chi phí và lợi ích của bất kỳ dự án tiềm năng nào trước khi bắt đầu. Nếu không, làm thế nào bất cứ ai sẽ biết những gì đáng làm (hoặc cố gắng)?

Vậy thì tại sao Agile?

Tôi sẽ lập luận rằng sử dụng các phương thức Agile không phải là không chắc chắn. Thay vào đó, Agile là một lập luận rằng sự không chắc chắn là không thể tránh khỏi, và các thông số kỹ thuật và ước tính chi tiết của các phương pháp truyền thống đưa ra sự chắc chắn sai - có thể khá tốn kém.

Một số điểm chính về ước tính thời gian:

• Thay đổi yêu cầu trong suốt một dự án là không thể tránh khỏi; Agile tính đến điều này thay vì giả vờ sẽ không có thay đổi.
• Thông số kỹ thuật chi tiết thường chứa các lỗi thiết kế không được phát hiện cho đến khi vào dự án. Điều này có thể có nghĩa là những thay đổi lớn hơn trong một dự án truyền thống so với dự án Agile.
• Một ước tính thời gian dựa trên "tôi nghĩ toàn bộ dự án này lớn đến mức nào?" có khả năng chính xác như cộng thêm thời gian ước tính cho nhiều yêu cầu chi tiết.
• Điều chính dẫn đến các ước tính tốt là một chu trình ước tính, đo lường và xem xét - có thể được áp dụng cho bất kỳ quy trình nhất quán nào.
• Ước tính "công việc được lưu" sẽ được điều khiển bởi các yêu cầu chính cho dự án chứ không phải chi tiết, vì vậy tôi nghi ngờ Agile sẽ làm hại nhiều đến khả năng ước tính này.

Cập nhật:

Chỉ cần làm rõ, phản ứng của bạn với các ông chủ của bạn dường như là "Chúng tôi không thể ước tính thời gian tiết kiệm hoặc tổng nỗ lực phát triển rất tốt khi sử dụng Agile, vì nó linh hoạt." Tôi nghĩ rằng điều này là sai. Tôi tin rằng những ước tính này cũng có thể được thực hiện khi sử dụng quy trình Agile, vì dù sao thì sự không chắc chắn cũng có. Và tất nhiên Agile cho phép một quy trình linh hoạt và nhạy bén hơn khi dự án mở ra.

Đây chắc chắn là một trong những phần khó nhất khi giới thiệu Agile

"Quản lý vẫn cần ước tính thời gian"

Cách tiếp cận của tôi là:

• Đệm 300%. Câu nói cũ 300% rất hữu ích khi bạn ở trong tình huống thực sự nhanh nhẹn ở cấp quản lý sẽ không xảy ra. Đây không phải là một "cách tiếp cận nhanh" có lẽ là một sự thỏa hiệp cho tình huống này. Bạn sẽ có thể đến trước một vài lần - nhưng đừng tin vào điều đó!

• Yêu cầu đánh giá dựa trên công việc đạt được tại điểm sẽ là 'nửa chặng đường' của dự án. Dự án khi bạn sẽ hoàn thành dựa trên công việc được thực hiện. Sau đó nói chuyện với ban quản lý và xem qua cái mà họ phải hy sinh - chức năng hoặc chất lượng - cho rằng thời gian đó được cố định dựa trên dự đoán khi bắt đầu dự án.

• Hãy chắc chắn rằng bạn đang cộng tác trên các tính năng được thực hiện và chất lượng với quản lý để họ thực sự đưa ra các quyết định đó

• Đi theo dòng chảy cho dự án này và cho phép những điều thông thường xảy ra - thời hạn bị bỏ lỡ, chất lượng bị tổn hại, bị đốt cháy và căng thẳng (và có thể rời đi) nhân viên rời đi. Khi dự án tiếp theo của giai đoạn xuất hiện, hãy thảo luận về những 'tác dụng phụ' này.

• Tập trung và chứng minh những lợi thế của cách tiếp cận nhanh "thực sự". Nói về sự cải thiện về chất lượng. Nói về khả năng thực hiện các thay đổi vào cuối ngày cho đến khi chúng đi vào sản xuất. Nói về nhu cầu làm việc lại ít hơn. Nói về nợ kỹ thuật ít hơn mà cuối cùng sẽ mang lại sự phát triển. Ví dụ, tạo ra sự tương tự với thế giới thực, chúng ta có thể ngừng thay dầu vào bất kỳ ngày nào, nhưng tắt nó đủ lâu và động cơ phải chịu đựng, hoạt động kém và cuối cùng thổi một thanh.

• Giữ sơ yếu lý lịch của bạn và liên kết Trong hồ sơ cập nhật. Nếu bạn không thể nhận được hỗ trợ quản lý sau khi thực hiện trường hợp của mình một vài lần, hãy tiếp tục. Một số tổ chức sẽ không được liệt kê vào các đối số của bạn để chuyển sang các đối số đó. Được gọi là việc làm Darwinism;)

Tôi nghĩ rằng bạn đang đưa ra những giả định sai lầm về phát triển Agile. Tính linh hoạt và các yêu cầu thay đổi theo nghĩa đen được đưa vào Tuyên ngôn Agile .

Chào mừng các yêu cầu thay đổi, thậm chí muộn trong phát triển. Agile quy trình khai thác thay đổi cho lợi thế cạnh tranh của khách hàng.

Yêu cầu linh hoạt (đọc: thay đổi) được chào đón trong Agile. Cấp nếu bạn hỏi hầu hết các nhà phát triển, họ sẽ thêm một cảnh báo rằng thay đổi phải hợp lý. Yêu cầu một nhóm xây dựng trò chơi 3D sau đó thay đổi các yêu cầu để trở thành "hệ thống điều khiển cho lò phản ứng hạt nhân" là hơi nhiều. Nhưng việc thêm, xóa hoặc sửa đổi các yêu cầu trong phạm vi của dự án là hoàn toàn tốt.

Câu hỏi là làm thế nào để bạn đối phó với các yêu cầu thay đổi? Câu trả lời điển hình là sử dụng các bước lặp ngắn để bạn có thể điều chỉnh khóa học sớm trước khi bạn lãng phí quá nhiều thời gian. Nó cũng buộc nhóm phải phân tách các yêu cầu thành các phần nhỏ hơn để mọi người có thể hiểu rõ hơn về chúng và thực hiện chúng trong một khoảng thời gian và nỗ lực hợp lý.

Đơn giản - nghệ thuật tối đa hóa số lượng công việc không được thực hiện - là điều cần thiết.

Tôi cũng thích nguyên tắc Agile này. Nó thường được hiểu là một đội nên cố gắng chỉ cung cấp những thứ cần thiết thông qua hiệu quả tàn nhẫn. Ví dụ: nếu khách hàng nghĩ rằng họ cần thứ gì đó nhưng có vẻ tanh, hãy đào xung quanh. Có thể người dùng cuối thực sự không có sử dụng cho nó, vì vậy công việc không nên được thực hiện.

Tuy nhiên, tôi nghĩ rằng câu hỏi của bạn đánh vào một khía cạnh khác của nguyên tắc này. Phần mềm thường phục vụ mục đích tự động hóa một quy trình thủ công. Bản thân phần mềm tồn tại để tối đa hóa lượng công việc không được thực hiện - bởi người dùng cuối.

Đo lường số lượng lao động mà phần mềm sẽ cứu người dùng cuối chắc chắn là một thước đo xứng đáng. Tôi đã tự đo lường điều này trong sự nghiệp của mình. Nó thực sự là một thành phần quan trọng của phân tích chi phí / lợi ích: dự án phần mềm sẽ mất bao nhiêu nỗ lực để thực hiện, so với bao nhiêu nỗ lực mà sản phẩm cuối cùng sẽ cứu được người dùng cuối.

Điều này hoàn toàn tương thích với triết lý phát triển Agile (hoặc bất kỳ loại nào khác) và quản lý của bạn hoàn toàn nên mua vào điều này.

Vâng, nhanh nhẹn có một số lợi thế.

• Nó cho phép những người kinh doanh thay đổi suy nghĩ giữa chuyến bay.
• Nó bảo vệ doanh nghiệp chống lại các ước tính xấu liên tục của kỹ sư.
• Nó mang lại giá trị sớm và thường xuyên, trước khi đạt được tầm nhìn cuối cùng.
• Nó phụ tùng bạn một số các chi phí quy hoạch lên phía trước, mà thường có thể sản xuất kế hoạch xấu nào .
• Nó thật tuyệt Đúng?

Nhưng, bạn vẫn cần đưa ra ước tính chính xác hợp lý.

Nếu bạn không, bạn thực sự yêu cầu doanh nghiệp đầu tư vào sản phẩm của mình mà không có bất kỳ bằng chứng nào cho thấy sản phẩm của bạn thậm chí có giá trị đầu tư ban đầu - và trong một số trường hợp, mọi thứ đều ổn.

Và tôi có thể nghe thấy nó bây giờ.

Tôi đã nghe nó trước đây. Tôi khá chắc chắn rằng tôi đã nói điều đó trước đây:

Ồ - Nhưng Haow!? HAOW làm một người phàm trần như tôi nhìn thẳng vào vận mệnh của những thứ như vậy! Những điều mà chỉ có các vị thần mới có thể thiêng liêng và chỉ đạo. Những điều mà người phàm trần chỉ có thể mơ trong những khu ổ chuột sâu nhất và quên đi sau một ngày! Ôi những kiểu quản lý chuyên chế, những nhu cầu như vậy có thể được đáp ứng!?

Sử dụng hiệu suất trong quá khứ của bạn như một hướng dẫn và trung thực .

• Có đủ cuộc trò chuyện với các bên liên quan và / hoặc người dùng cuối để xác định mức độ phức tạp của sản phẩm và / hoặc các thành phần chính của nó so với các thành phần chính khác mà bạn đã làm việc. Lập một ước tính điểm ban đầu, tương đối.
• Thổi phồng con số đó bằng số lượng thay đổi phạm vi lịch sử và lỗi phát sinh lỗi mà bạn đã thấy trong lịch sử.
• Áp dụng vận tốc lịch sử của bạn để ước tính điểm để đến một mốc thời gian thô. Và, áp dụng một hình nón hợp lý của sự không chắc chắn .
• Xem xét lại ước tính và hiểu biết của bạn về dự án. Hãy tự tin rằng bạn sẽ sẵn sàng đưa ra quyết định về việc giải quyết một dự án dựa trên đánh giá của bạn.

Cuối cùng, trình bày hình nón không chắc chắn của bạn cho các bên liên quan, nêu các giả định và mối quan tâm của bạn, và để nó ở đó.

Bên cạnh đó, tôi cũng đề nghị đưa ra một ước tính khách quan - ước tính heuristic để tỉnh táo - kiểm tra bạn và / hoặc ước tính bình thường của nhóm bạn.

Bạn có thể sử dụng ước tính này như một phiếu bầu thứ N trong khi lập kế hoạch chơi bài xì phé hoặc xác thực ước tính riêng tư của bạn nếu bạn đi một mình. Ví dụ, nhóm của tôi có xu hướng ước tính khoảng 1 điểm mỗi phút về kỹ thuật khám phá lỏng lẻo thảo luận về một câu chuyện. Điều này đặc biệt hữu ích nếu ruột của bạn kể cho bạn một câu chuyện được 5 điểm, nhưng bạn phải mất 20 phút để hiểu những gì cần phải làm - đó thường là một dấu hiệu tốt cho thấy vẫn còn những phức tạp và hiểu lầm ẩn giấu xung quanh.

Tôi chưa bao giờ làm việc trong bất kỳ công ty nào có thể có ước tính thời gian tốt liên tục, tôi cũng chưa từng làm việc với bất kỳ ai tuyên bố đã làm như vậy. Tìm kiếm sẽ cho bạn thấy rằng ước tính là một vấn đề chưa được giải quyết trên toàn ngành.

Tôi sẽ cố gắng mua để đo vận tốc dựa trên các điểm câu chuyện trừu tượng và nếu bạn không thể làm điều đó, tôi sẽ ước tính nhiều hơn.

Agile là một giải pháp tuyệt vời cho toàn bộ các vấn đề, nhưng mặc dù những gì một số nhà truyền giáo sẽ đề xuất, nó không phải là giải pháp duy nhất và nó không phải luôn luôn là giải pháp đúng đắn.

Trường hợp đã nêu của bạn đơn giản không phải là một vấn đề nhanh:

Gần đây tôi được giao nhiệm vụ đi theo nhóm và yêu cầu họ cho ý tưởng về quy trình kinh doanh để tự động hóa. Sau đó tôi đã tìm hiểu xem điều này đã khiến họ mất bao nhiêu thời gian, tìm ra giải pháp sẽ tiết kiệm được bao nhiêu thời gian và ước tính tổng thời gian phát triển. Bằng cách đó, các nhà quản lý có thể cố gắng đo lường mức độ hiệu quả của một giải pháp về mặt thời gian được lưu.

Bạn được giao nhiệm vụ xác định chi phí và lợi ích của việc tự động hóa một số quy trình kinh doanh, đó không phải là một nhiệm vụ nhanh để thay đổi, đó là một vấn đề cụ thể với giải pháp cụ thể. Bạn sẽ tạo một danh sách với số lượng quy trình kinh doanh tùy ý và đối với mỗi quy trình, sẽ có một chi phí ước tính tự động hóa, chi phí ước tính không tự động hóa và lợi ích ước tính của tự động hóa. Ban quản lý sẽ đối chiếu điều này với ngân sách, tài nguyên, yêu cầu và mục tiêu chiến lược của họ và xác định (nếu có) của các quy trình này để tự động hóa. Nếu bạn có lương tâm, thì bạn sẽ làm nổi bật các nhiệm vụ được chọn có khả năng ROI thấp hơn nhưng sẽ giảm chi phí cho các giai đoạn khác để cải thiện tổng ROI. Bạn cũng có thể đã xác định các cách khác nhau để đạt được tự động hóa bao gồm phát triển bespoke trong nhà và thuê ngoài (sử dụng các kỹ thuật nhanh và / hoặc thác nước), mua các giải pháp kệ, sử dụng các nhà cung cấp dịch vụ bên thứ ba, v.v. Toàn bộ quá trình này rất thời trang vào những năm 90 khi nó được gọi là tái cấu trúc quy trình kinh doanh.