Làm thế nào để ngăn chặn các đặc tả phát triển thay đổi trong phát triển giữa?

Vấn đề : Dường như với hầu hết mọi nỗ lực phát triển mà tôi tham gia, cho dù có dành bao nhiêu thời gian để lập kế hoạch trước khi bắt đầu phát triển, luôn có một lượng lớn thay đổi cần thiết giữa chừng hoặc đến cuối dự án. Đây đôi khi là những thay đổi lớn đòi hỏi rất nhiều sự phát triển lại.

Tôi không làm việc cho những khách hàng trả tiền, đây là nhóm phát triển nội bộ trên các trang web phát triển nội bộ. Vì vậy, nó không giống như tôi có thể tính phí cho nó hoặc bất cứ điều gì. Và vào cuối ngày, chúng tôi phải cố gắng để đạt được thời hạn.

Câu hỏi : một số cách tốt nhất mà các bạn đã tìm thấy để giảm thiểu và ngăn chặn các thay đổi thông số từ việc cắt xén giữa chừng hoặc sau khi phát triển là gì?

Có một câu nói quân sự nổi tiếng, được gán cho Helmut von Moltke: "Không có kế hoạch chiến đấu nào sống sót tiếp xúc với kẻ thù". Cùng quan điểm, tôi không nghĩ có thể đưa ra một thông số sẽ không phải thay đổi - trừ khi bạn có thể dự đoán tương lai và đọc được suy nghĩ của các bên liên quan (ngay cả khi đó họ có thể chưa nghĩ ra, ngay cả khi họ tuyên bố họ đã làm). Tôi sẽ đề nghị thay vì tiếp cận nó theo một số cách:

1. Phân biệt rõ ràng những gì có thể thay đổi và những gì không thể. Truyền đạt rõ ràng cho các bên liên quan, làm cho họ ký rõ ràng vào những thứ không thể thay đổi càng sớm càng tốt.
2. Chuẩn bị cho sự thay đổi trước. Sử dụng các phương pháp mã cho phép thay đổi các phần có thể thay đổi dễ dàng hơn, đầu tư vào cấu hình, đóng gói và các giao thức rõ ràng sẽ cho phép các phần được thay đổi và thay thế một cách độc lập.
3. Nói chuyện với các bên liên quan thường xuyên, thu hút phản hồi và phê duyệt. Điều này sẽ giúp bạn đồng bộ và tránh cho họ tuyên bố "ồ, đó không phải là điều chúng tôi muốn" khi quá muộn. Như đã lưu ý trong các câu trả lời khác, các phương pháp nhanh và phát hành nhỏ thường xuyên sẽ giúp bạn điều đó.
4. Đưa vào lịch trình thời gian để chứa đựng những thay đổi không thể tránh khỏi. Đừng ngại nói "chúng tôi sẽ cần nhiều thời gian hơn" sớm nếu bạn nghĩ rằng bạn sẽ làm - nếu lịch trình bạn đưa ra là không thực tế, tốt hơn là bạn nên biết điều đó (và bạn có trong hồ sơ nói rằng) ngay từ đầu kết thúc.
5. Nếu các thay đổi quá rộng và đe dọa thời hạn - hãy đẩy lùi và nói điều gì đó như "thay đổi này là có thể, nhưng sẽ đẩy thời hạn đến X lần, hãy đưa ra lựa chọn của bạn".
6. Tạo một quy trình chính thức để yêu cầu thay đổi, ưu tiên thay đổi và chỉ định thay đổi cho các phiên bản hoặc bản phát hành. Nếu bạn có thể nói với mọi người "Tôi không thể làm điều đó trong bản phát hành này, nhưng sẽ rất vui khi đưa nó vào lịch trình cho lần tiếp theo", tốt hơn là nói với họ "bạn đã quá muộn, thay đổi của bạn không thể đi vào , tạm biệt "và sẽ biến họ thành bạn của bạn - họ sẽ rất vui khi bạn phát hành kịp thời để bạn có thể sớm được tự do đến phiên bản tiếp theo sẽ có sự thay đổi của họ - chứ không phải kẻ thù của bạn.

Cung cấp một cái gì đó (tôi ngần ngại sử dụng từ bất cứ điều gì) sớm và giao hàng thường xuyên. Đó là - sử dụng một số loại phương pháp phát triển lặp.

Đây là cơ sở của sự phát triển Agile, nhưng có thể được sử dụng với (gần như) bất kỳ phương pháp nào.

Bằng cách chia dự án thành một loạt các dự án nhỏ, bạn sẽ có nhiều quyền kiểm soát hơn vì bạn có thể đặt thứ gì đó trước mặt khách hàng sớm, bạn không bị khóa trong một lịch trình phát triển dài bị lỗi thời khi khách hàng thay đổi ý định (như họ sẽ).

Khi họ thấy hệ thống phát triển, một số yêu cầu sẽ thay đổi, một số sẽ trở nên dư thừa và những yêu cầu khác sẽ tăng mức độ ưu tiên. Tuy nhiên, bằng cách có vòng đời dự án ngắn, bạn sẽ có thể đối phó với những thay đổi này.

Lý thuyết cho rằng có thể hoàn toàn chỉ ra một dự án phần mềm có kích thước đáng kể là một sự tưởng tượng hoàn chỉnh. Lý thuyết này đã được tìm thấy không hoạt động trong các tổ chức từ lớn đến nhỏ trong toàn bộ lịch sử phát triển phần mềm.

Bạn PHẢI tìm cách nào đó để thích ứng với những thay đổi khi bạn đi! Chúng sẽ xảy ra, bởi vì hầu hết các bên liên quan, ngay cả khi họ nói 'phải, đó là điều tôi muốn' thực sự không biết họ muốn gì cho đến khi nó ở trước mặt họ. Đó là lý do tại sao chúng ta có rất nhiều người áp dụng các phương pháp lặp.

Cho dù bạn lặp lại sản phẩm hay bất cứ điều gì, bạn PHẢI tìm cách nào đó để thích ứng với những thay đổi này, bởi vì cố gắng tìm cách để không có thay đổi chỉ là yêu cầu tắt trọng lực trong vài phút để bạn có thể bay.

Đừng cố gắng ngăn chặn sự thay đổi, hãy nắm lấy nó. Bạn càng lên kế hoạch trước, kế hoạch của bạn sẽ càng thay đổi. Vì vậy, kế hoạch ít hơn , không nhiều hơn. Áp dụng một phương pháp phát triển nhanh, trong đó bạn thường xuyên cung cấp các đoạn mã làm việc nhỏ, cho khách hàng cơ hội thay đổi các thông số kỹ thuật cứ sau vài tuần.

Bạn đang hỏi sai câu hỏi. Thay đổi Spec sẽ luôn xảy ra trong các dự án phát triển phần mềm ở mọi quy mô.

Thường là do yêu cầu kinh doanh thay đổi nhưng tôi cũng thấy điều đó xảy ra vì khách hàng (bên trong hoặc bên ngoài) có thể khó hình dung những gì có thể mà không thấy điều gì lặp đi lặp lại, vì vậy họ có tầm nhìn thay đổi từ từ khi họ tham gia phát triển giải pháp.

Câu hỏi bạn nên đặt ra không phải là "làm thế nào tôi có thể khóa thông số kỹ thuật", mà là "làm cách nào tôi có thể cấu trúc mã và quy trình của mình để đáp ứng với môi trường thay đổi mà không vứt bỏ mọi thứ tôi đã viết?"

Điều này sau đó dẫn bạn vào lĩnh vực bingo buzzword: phương pháp nhanh, phát triển lặp và các giải pháp kỹ thuật như mã hóa dựa trên thành phần / mô đun, tích hợp liên tục ... danh sách này tiếp tục.

Tôi không nói rằng đây là một viên đạn bạc cho tất cả các vấn đề của bạn nhưng tất cả chúng đều xuất hiện vì mong muốn quản lý chính tình huống mà bạn mô tả nên ít nhất chúng đáng để điều tra.

Xin lỗi nếu điều đó không đưa ra giải pháp cụ thể nhưng tôi có xu hướng nghĩ rằng một sự thay đổi tư duy trong việc chấp nhận và quản lý thay đổi sẽ trả cổ tức lớn hơn là cố gắng tránh nó.

Một sự thay đổi chỉ là một bất ngờ ... nếu đó là một bất ngờ!

Tôi đề nghị suy nghĩ về:

• Những thay đổi này đến từ đâu?
• Tại sao bạn không biết về chúng sớm hơn?
• tại sao bạn không đóng góp cho những thay đổi này (và có khả năng tạo ra nhiều hơn nữa)?

Thay đổi là bản chất của những gì chúng ta làm. Từ khi nào bạn viết mã thuật toán chính xác như được hình dung vào ngày 1?

Nhưng nếu bạn muốn tránh việc nhà phát triển nản lòng "ngạc nhiên" trước những thay đổi, tôi nghĩ bạn cần tìm cách tiếp cận gần hơn với hành động đưa ra quyết định. Rốt cuộc, tôi chắc chắn rằng bạn có rất nhiều ý tưởng về cách bạn có thể làm cho sản phẩm tốt hơn. Có một chỗ ngồi tại bàn, hoặc mãi mãi chấp nhận rằng bạn sẽ chỉ phải đối phó với những "thay đổi bất ngờ" đó.

Vâng, đó là một cuộc gọi mặc dù, khách hàng luôn muốn nhiều hơn nhưng đây là một vài điểm bạn nên xem xét:

Mock-up HTML: Luôn tạo các mô hình HTML để xác định phần UI của ứng dụng, cho chúng thấy nó trông như thế nào và hỏi ý kiến ​​của chúng. Nếu bạn thấy bất cứ điều gì hợp lý để thay đổi, hãy thực hiện nó trong nguyên mẫu HTML. Sử dụng điều này, bạn sẽ sắp xếp rất nhiều thứ như các vấn đề về UI, luồng cơ bản và một số tiện ích bổ sung (như Sắp xếp, Phân trang, số bản ghi sẽ được hiển thị, v.v.)

Sự tham gia tích cực từ đầu bên kia: Điều này rất quan trọng nếu bạn đang phát triển cho một tổ chức kinh doanh, hãy tham gia vào công việc của họ yêu cầu họ làm rõ nghi ngờ của bạn và không thất bại hỏi họ những thay đổi nào họ muốn trong dòng chảy của họ (nếu cần).

Phát hành mô-đun: Phát hành mã của bạn theo kiểu mô-đun, phát hành, kiểm tra, nhận phản hồi và phát hành lại.

Đây là lý do tại sao gần như không thể lập kế hoạch trước quá xa, nhưng không phải là một lý do để không lên kế hoạch gì cả. Đừng quá yêu những kế hoạch của bạn và bạn sẽ không phải lo lắng về việc chúng sẽ phá vỡ trái tim bạn.

Bên trong công ty của bạn có một chi phí để sử dụng tài nguyên CNTT cho dù có ai thừa nhận nó, theo dõi nó hay phải dự trù ngân sách cho nó hay không. Thực tế là, nhóm của bạn chỉ có thể tạo rất nhiều mã trong một khoảng thời gian nhất định. Tất cả các phòng ban và dự án đang chia sẻ trong ngân sách này.

Bạn không thể ngăn cản bất cứ ai muốn thay đổi các yêu cầu, nhưng họ không thể thoát khỏi hậu quả. Thay đổi có thể làm tăng đáng kể thời gian phát triển. Đó là một thực tế họ phải đối phó hoặc quyết định không thực hiện thay đổi. Có một yêu cầu từ một bộ phận ảnh hưởng đến một bộ phận khác? Bạn có thể phải hoàn toàn di chuyển dự án của họ đằng sau các phòng ban khác vì yêu cầu thay đổi sẽ lấn sang lịch trình thời gian của nhóm khác.

Sự tham gia tích cực của người dùng trong suốt chu kỳ phát triển và sử dụng phương pháp Agile càng nhiều càng tốt thực sự giúp chúng tôi với các sản phẩm của mình.

Thay đổi thông số là không thể tránh khỏi, nhưng bằng cách minh bạch với người dùng và trên hết, thường xuyên tư vấn cho họ có nghĩa là hầu hết các thay đổi được nắm bắt càng sớm càng tốt.

Đối với tôi nó khá dễ dàng.
Nói với một người, "chủ sở hữu sản phẩm" , người đã đặt hàng các tính năng này là ổn, nhưng anh ta phải chọn một vài tính năng theo kế hoạch mà anh ta có thể không có trong thời hạn này.
Hãy nghĩ về nó như một cuộc họp chạy nước rút một nửa với PO nơi bạn nói với anh ta rằng cuộc chạy nước rút sẽ không giảm xuống 0.

Thi thiên Nếu đó không phải là "PO", tôi sẽ nói đừng nói chuyện với tôi qua "PO"

Một số cách tốt nhất mà các bạn đã tìm thấy để giảm thiểu và ngăn chặn các thay đổi thông số từ cắt xén giữa chừng hoặc sau khi phát triển là gì?

Không có cách nào tốt nhất. Tùy thuộc vào quản lý để giới hạn các thay đổi đối với thông số kỹ thuật trong giai đoạn phát triển nhất định.

Tuy nhiên, bạn nên thiết kế phần mềm của mình theo cách như vậy để mong đợi những thay đổi. Sau đó, tác động của những thay đổi sẽ ít hơn nhiều. Phát triển lặp lại và gia tăng là một khởi đầu tốt.

Tôi đã thấy rằng, trực tiếp hoặc gián tiếp, khách hàng là nguyên nhân của hầu hết các thay đổi (và cũng là lỗi nghiêm trọng nhất, BTW). Vì vậy, giải pháp rõ ràng là loại bỏ khách hàng. (Dù sao họ cũng tốt?)

Vì bạn không thể ngăn chặn sự thay đổi, bạn cần nắm lấy nó. Tôi nghĩ rằng điều quan trọng nhất bạn có thể làm là: bạn cần cố gắng nhận được các yêu cầu thay đổi từ khách hàng càng sớm càng tốt , bởi vì việc thay đổi mọi thứ sẽ ít tốn kém hơn khi chỉ có ít mã. Vì vậy, bạn cần trình bày thiết kế của mình càng sớm càng tốt cho khách hàng bằng cách sử dụng các nguyên mẫu (thậm chí có thể là nguyên mẫu giấy), sử dụng các phương thức nhanh và vv.

Bạn có thể xem xét giới thiệu một số kỷ luật trong quy trình phát triển bằng phương pháp như SCRUM. Trong SCRUM, một nhóm lập kế hoạch ban đầu bằng cách chia việc triển khai các tính năng thành các câu chuyện và gán cho mỗi câu chuyện một ước tính nỗ lực (số giờ hoặc ngày làm việc cần thiết để thực hiện câu chuyện đó).

Nếu một thay đổi muộn được yêu cầu (đối với một câu chuyện đã được thực hiện), bạn cần tạo một câu chuyện mới và ước tính nỗ lực thực hiện cho nó. Sau đó, bạn có thể đến người quản lý của mình ( chủ sở hữu sản phẩm ) và giải thích đơn giản rằng tính năng mới sẽ tiêu tốn thêm thời gian đó. Người quản lý dự án sau đó có trách nhiệm chấp nhận nỗ lực thêm và điều chỉnh lịch trình (có thể hủy bỏ các câu chuyện khác chưa được thực hiện).

Ngay cả khi nhóm của bạn sẽ không thực hiện đầy đủ SCRUM hoặc quy trình phát triển khác, ít nhất bạn có thể giới thiệu kế hoạch dựa trên các câu chuyện , ước tính nỗ lực phát triển cho mỗi câu chuyện và điều chỉnh lịch trình khi có câu chuyện mới.

http://teddziuba.com/2010/05/why-engineers-hop-jobs.html

Tôi đã dành quá nhiều buổi tối sau giờ làm việc căng thẳng và không vui vì một chap khác không hiểu hoặc không quan tâm đến việc kinh doanh phần mềm hoạt động như thế nào. Tôi không có vấn đề gì khi đối đầu với bất cứ ai cao hơn, nhưng tôi không có sự ủng hộ của những người bạn đồng nghiệp của mình. Có con là một con chó cái, hả? Tôi có thể sẽ bỏ việc sớm.

Thành thật mà nói, tôi muốn các lập trình viên nói chung có nhiều bóng hơn. Hãy nhìn vào điều này:

"" "Tôi không làm việc cho những khách hàng trả tiền, đây là nhóm phát triển nội bộ trên các trang web phát triển nội bộ. Vì vậy, tôi không thể tính phí cho nó hay bất cứ điều gì. Vào cuối ngày, chúng ta phải cố gắng đạt đến thời hạn. "" "

Nếu bạn đang giao dịch với một khách hàng thanh toán $ và nếu bạn bảo vệ mông của mình bằng cách có hợp đồng (http://vimeo.com/22053820?utm_source=swissmiss), thì những thay đổi trong thông số sẽ khiến khách hàng này tốn nhiều thời gian hơn và nhiều tiền hơn ( hoặc có khả năng cùng hoặc ít thời gian hơn nhưng theo cấp số nhân theo cấp số nhân). Công ty của bạn đang cố gắng thoát khỏi việc thay đổi thông số kỹ thuật mà không phải chịu chi phí nhiều thời gian hơn và nhiều tiền hơn.

Trong khi đó, cố gắng để đạt được thời hạn khiến bạn và đồng nghiệp của bạn căng thẳng KHÔNG GIỚI HẠN; bạn không thể dành một ngày cuối tuần chất lượng với bạn bè / gia đình. Nó thực sự là không cần thiết, bởi vì bất cứ ai đang ném công việc vào bạn có thể thậm chí không biết điều đó, điều đó thật đáng buồn.

Giải pháp đề xuất của tôi: cùng nhau có những quả bóng để đối đầu với họ và giải thích rằng không có bữa ăn trưa miễn phí và mọi thứ đều có giá, rằng một thợ sửa xe sẽ mất nhiều thời gian hơn và tính phí nhiều hơn nếu thông số kỹ thuật được thay đổi giữa chừng, rằng một cơ quan hợp đồng sẽ mất nhiều thời gian hơn và tính phí nhiều hơn nếu thông số kỹ thuật được thay đổi giữa công việc, và có một lý do chính đáng cho nó. Nếu họ không sẵn sàng làm việc với bạn một cách hợp lý, thì bạn với tư cách là một nhóm sẽ đứng dậy và rời đi, và họ sẽ phải thuê các nhà phát triển có thể nhận dự án nơi nó bị hoãn và giao đúng hạn.

Sau đó, cũng có một lời hứa về sự phát triển nhanh, ngụ ý không có thời hạn khó khăn.

Tôi vẫn chưa thấy các lập trình viên đình công, nhưng đây sẽ là một cái gì đó. Các nhà quản lý thiếu năng lực quá phong phú trong các công ty phần mềm. Có quá nhiều người muốn nhận được thứ gì đó mà không cần gì, trên Craigslist hoặc trong một công ty thực tế. http://teddziuba.com/2011/07/the-craigslist-reverse-programmer-troll.html

Lập trình viên cần phải có nhiều bóng hơn.

Một cách tiếp cận mà tôi đã thấy rằng hoạt động khá ổn (không phải với tất cả các nhà quản lý rõ ràng) là "Tôi nghĩ tôi có thể làm điều đó, vâng. Nó phụ thuộc - bạn dành bao nhiêu thời gian cho dự án này? Đó là một thay đổi khá lớn yêu cầu. "