Những thách thức đối với cách tiếp cận Agile trong các dự án của chính phủ

Một cuộc thảo luận Agile trước đây đã có câu trả lời tốt xác định những gì là quan trọng cho sự thành công của việc thực hiện phương pháp Agile phát triển phần mềm. Hầu hết các điểm là những thách thức tổ chức và quản lý điển hình, nhưng một điểm khiến tôi lo lắng và đó là khách hàng phải tham gia trong suốt quá trình.

Khách hàng là điều mà bạn không thể kiểm soát một cách thực tế, có lẽ mô hình kinh doanh của bạn đưa bạn đến với công việc được ký hợp đồng của chính phủ, ví dụ như một hợp đồng nghiêm ngặt bắt buộc công ty phải:

• Cung cấp các tính năng X chính xác theo yêu cầu

• Yêu cầu tính năng sẽ được ném qua một bức tường, đừng làm phiền chúng tôi, chúng tôi không muốn nghe nó.

• Không có khái niệm ưu tiên tính năng trong tâm trí khách hàng, tất cả đều quan trọng hoặc chúng tôi sẽ không yêu cầu họ.

• Dự án sẽ có chi phí không hơn và không ít hơn Y bất kể vượt quá hoặc thời hạn.

• Thời hạn tuyệt đối, nghiêm ngặt, cuối cùng và không thể thương lượng để hoàn thành tất cả các công việc.

Chúng tôi chưa bao giờ làm việc với một khách hàng như vậy trước đây nhưng tiền cho dự án chỉ là quá tốt để vượt qua. Chúng tôi cần công việc này.

Tôi đã đến đây và làm việc CỨNG để thay đổi các quy trình bên trong để tiến tới phát triển Agile và ở đây tôi không biết làm thế nào để điều hòa nơi dự án này phù hợp với quy trình mới của chúng tôi. Trước đây tôi chưa bao giờ có sự quản lý chặt chẽ, cởi mở, tin tưởng tôi lãnh đạo nhóm phát triển và xử lý con đường này và bây giờ chúng tôi ở đây tôi không thể thành thật nói rằng dự án này sẽ thực sự được thực hiện trong một Cách nhanh nhẹn. Tôi cảm thấy như ban quản lý đã tin tưởng tôi dẫn dắt con đường này và tôi đã làm họ thất vọng bởi vì tình huống này hiện tại chúng tôi đang kêu gọi Thác nước rõ ràng. Tôi sợ rằng tôi có thể mất lòng tin của họ nếu tôi quay lại bây giờ.

Các câu trả lời khác giống như ở đây nói Agile là không thể với loại khách hàng này, bạn có đồng ý không? Có ai trong các bạn đã ở trong một tình huống tương tự và làm cho nó hoạt động? Những chiến lược nào bạn đã thực hiện để làm cho Agile xảy ra thành công?

Tôi nghĩ điều đầu tiên nhận ra là có một sự khác biệt giữa nhanh nhẹn và nhanh nhẹn. Từ từ đưa ra các kỹ thuật và đặc điểm nhanh - các nhóm chức năng chéo, lập kế hoạch thích ứng, phân phối tiến hóa / tăng dần, lặp lại theo thời gian và thậm chí giới thiệu các khái niệm từ Lean rất khác so với giới thiệu Extreme Lập trình, Scrum hoặc Crystal.

Bạn đề cập rõ ràng sự tham gia của khách hàng. Có, nhiều phương pháp của Agile kêu gọi sự tham gia của khách hàng, nhưng điều đó không bắt buộc phải nhanh nhẹn. Trong mọi chương trình liên quan đến chính phủ / quốc phòng, tôi luôn có một người quản lý chương trình hoặc dự án là điểm liên lạc với khách hàng. Người này trở thành "tiếng nói của khách hàng". Nó có thể bị chậm lại khi họ giao tiếp hoặc gửi email hoặc gọi điện thoại và làm rõ, nhưng bạn có thể có một người (hoặc một nhóm, nếu bạn cũng có phó thủ tướng) đó là đại diện khách hàng của nhóm của bạn. Phải thừa nhận rằng nó không hoàn toàn giống nhau. Nhưng không phải là nhanh nhẹn về việc linh hoạt và phản ứng với thay đổi?

Bạn cũng đề cập đến một vài khái niệm chính: các yêu cầu được xác định trước, có các yêu cầu tính năng "ném qua tường", thiếu ưu tiên vì "tất cả chúng đều quan trọng", và các dự án chi phí cố định và / hoặc lịch trình cố định. Mỗi trong số này có thể được giải quyết theo những cách khác nhau.

Nếu bạn nghĩ rằng bạn có tất cả các yêu cầu của bạn ở phía trước, rất có thể bạn không. Yêu cầu thay đổi. Chỉ vì bạn có một đặc tả "đã hoàn thành và đã ký" không có nghĩa là nó được đặt trong đá. Đưa ra bất kỳ tài liệu yêu cầu nào bạn có, nắm bắt chúng theo cách bạn cảm thấy thoải mái và / hoặc theo cách thức được quy định trong hợp đồng và cung cấp các yêu cầu, thiết kế và kiến ​​trúc. Ngoài ra, hãy xem liệu bạn có thể coi đây là những tài liệu sống hay không (một tài liệu thiết kế mà tôi thấy hôm nay tại nơi làm việc được dán nhãn là Bản sửa đổi G, có nghĩa là bản cập nhật thứ 8 của nó). Hỏi về số tiền bạn có thể để lại như TBD trong bất kỳ lần lặp nào và bao nhiêu cần phải được cải thiện ngay bây giờ - có thể có một số cho và nhận.

Hãy nhanh nhẹn với tài liệu của bạn. Đừng lặp lại những nỗ lực giữa "những gì nhóm của bạn muốn" và "những gì khách hàng muốn". Ví dụ: nếu khách hàng của bạn muốn một đặc tả yêu cầu phần mềm truyền thống và nhóm của bạn muốn sử dụng các câu chuyện của người dùng, hãy thử điều chỉnh SRS truyền thống và sử dụng các mục hành động và danh sách các mục hành động thay vì các câu chuyện của người dùng để bạn không mất thời gian xây dựng cả "hệ thống sẽ ..." và "phải có thể vì". Điều này không có kỷ luật về phía nhóm, tuy nhiên, để thích ứng với sự khác biệt giữa các dự án. Chụp các vấn đề trong phản xạ.

Khi bạn bắt đầu phát triển, bạn có thể chạy 5 hoặc 6 lần lặp và sau đó mời khách hàng của bạn đến cơ sở của bạn để xem một tập hợp con thực hiện của bạn. Rửa sạch và lặp lại quá trình này. Đó không phải là sự tham gia liên tục được yêu cầu bởi một số phương pháp, nhưng bạn có lợi thế về khả năng hiển thị cao. Nếu khách hàng của bạn nói không, ít nhất bạn đã thử. Nếu họ nói có, bạn có thể khai sáng cho họ là nhanh nhẹn. Trong một dự án tôi đã thực hiện, khách hàng đã truy cập trang web cứ sau vài tháng (thường là 3-5 tháng). Họ sẽ xem chúng tôi trải qua kiểm tra QA, họ sẽ thảo luận về mối quan tâm với các kỹ sư và kinh doanh với văn phòng chương trình / dự án. Đó là một cơ hội cho tất cả mọi người để có được trên cùng một trang.

Thử nghiệm và bảo trì xảy ra giống như trên dự án nhanh nhẹn khác. Tạo quy trình kiểm tra của bạn và khiếm khuyết tài liệu theo cách thích hợp, theo dõi số liệu theo nghĩa vụ hợp đồng và kết quả kiểm tra tài liệu. Nếu bạn muốn theo TDD, hãy cho nó. Tích hợp liên tục là một ý tưởng tốt. Trong các cuộc họp trạng thái dự án, người quản lý dự án của bạn có thể sử dụng thông tin này để nói rằng "chúng tôi đã thực hiện các yêu cầu N, kiểm tra M, vượt qua các bài kiểm tra X" và cập nhật về tình trạng và tình trạng dự án cho những người có tiền.

Nói về tiền, chúng ta có vấn đề chi phí cố định và / hoặc lịch trình cố định.

Đối phó với một lịch trình cố định là khá đơn giản. Đưa ra yêu cầu của bạn, bạn biết bạn có thể hoàn thành bao nhiêu lần lặp. Khối lượng công việc của bạn cho mỗi lần lặp được đặt khá nhiều về các tính năng để thực hiện, kiểm tra và tích hợp. Điều này có thể khó khăn, nhưng không thể phá vỡ các tính năng và gán chúng cho các lần lặp trước. Điều này quay trở lại quan điểm của tôi về việc mời khách hàng - nếu bạn có một năm và đang sử dụng các vòng lặp 2 tuần, có thể mời khách hàng hàng quý (và mời họ hàng quý) và cho họ thấy kết quả của công việc trước đó. Hãy cho họ thấy mức độ ưu tiên của bạn đối với các yêu cầu, kế hoạch tương lai của bạn và cách bạn sắp xếp lịch trình.

Đối phó với một ngân sách cố định là tương tự. Bạn biết bạn có bao nhiêu thời gian, bao nhiêu tài nguyên cho dự án, chi phí bao nhiêu và do đó mọi người có thể làm việc bao nhiêu giờ cho mỗi lần lặp. Đó chỉ là vấn đề đảm bảo mọi người theo dõi điều này một cách cẩn thận. Nếu công ty của bạn có thể ăn chi phí làm thêm giờ, hãy cho nó. Mặt khác, đảm bảo mọi người đều làm việc trong khoảng thời gian thích hợp và sử dụng các kỹ năng quản lý thời gian và quyền anh thời gian tốt để giữ cho mọi người làm việc hiệu quả. Giờ làm việc hiệu quả hơn là những gì bạn cần để giảm chi phí - cung cấp nhiều tài liệu và phần mềm giá trị gia tăng hơn mà không phải trả chi phí cho các cuộc họp và chi phí chung.

Cuối cùng, không nhất thiết phải là Agile, mà là áp dụng những điều khiến Agile trở nên tốt và nhanh nhẹn. Có thể đáp ứng các thay đổi trong yêu cầu, có thể cung cấp phần mềm thường xuyên ngay cả khi khách hàng không muốn, chỉ tạo tài liệu bổ sung giá trị (cùng với bất cứ điều gì bạn có nghĩa vụ sản xuất theo hợp đồng), v.v.

Đúng, nhanh nhẹn không phù hợp với một dự án như vậy, vì có vẻ như các yêu cầu đã được thực hiện và cố định trong đá, có lẽ là kết quả của nhiều năm phân tích bởi các chuyên gia tư vấn đắt tiền, các cuộc họp của ủy ban và thỏa hiệp chính trị. Thác nước hoạt động tốt nếu khách hàng kỷ luật đến mức họ có thể nói với bạn bằng văn bản chính xác những gì họ muốn. Họ có thể sai, nhưng ít nhất bạn có nó bằng văn bản và bạn sẽ được trả tiền nếu bạn giao nó. (Tất nhiên, điều này không nói lên sự hài lòng của khách hàng. Cơ hội là bạn sẽ cung cấp thứ gì đó mà họ không thực sự cần.)

Agile được tạo ra để giải quyết vấn đề mà bạn không gặp phải: rủi ro do sự không chắc chắn trong các yêu cầu.

Đúng là khách hàng có thể yêu cầu thay đổi, nhưng bạn theo một trong hai đường dẫn:

1. Tiền rất tốt đến nỗi bạn biết rằng bạn có thể hấp thụ X lượng tính năng mới ở các giai đoạn khác nhau của dự án và vẫn ra mắt mà không bị mất áo, hoặc
2. Bạn nói rõ với khách hàng ngay từ đầu rằng do họ thương lượng giá chặt chẽ, mỗi yêu cầu tính năng mới sẽ tạo ra một lệnh thay đổi với giá sẽ phải được họ chấp thuận, với một đơn đặt hàng kèm theo (hoặc sửa đổi đơn đặt hàng ban đầu) để bạn thực hiện điều đó. Thứ tự thay đổi sẽ đánh vần bất kỳ tác động nào đến chức năng hoặc lịch trình. Nếu họ nói rằng thời hạn không thể được di chuyển, thì việc thay đổi đơn hàng sẽ trở nên đắt hơn theo cấp số nhân khi dự án tiến triển vì việc thay đổi công cụ sau này sẽ tốn kém hơn.

Mối quan hệ cảm thấy thân thiện hơn rất nhiều trong tình huống # 1, nhưng thực tế là rất hiếm khi tìm thấy các bộ phận mua hàng sẽ không ép bạn về giá cả, vì vậy, hầu hết thời gian bạn ở trong tình huống # 2. Điều đó có nghĩa là mối quan hệ là đối đầu, nhưng nếu bạn muốn tồn tại trong kinh doanh, bạn phải giỏi quản lý mối quan hệ trong khi giữ vững lập trường của mình. Đây là một phần lớn trong công việc của người quản lý dự án.

Có vẻ như bạn có thể ở tình huống # 1, điều này là tốt. Tôi tưởng tượng rằng các hợp đồng của chính phủ là nơi duy nhất họ không quan tâm đến tiền, bởi vì, sau tất cả, họ không tiêu tiền của họ , họ đang tiêu tiền của bạn .

... ví dụ như hợp đồng làm việc của chính phủ trong đó hợp đồng cực kỳ nghiêm ngặt bắt buộc công ty phải:

Đầu tiên. Đó là nghiêm ngặt. Nhưng nó không phải là không linh hoạt. Nó chỉ đơn giản đòi hỏi sự chú ý đến chi tiết và một chuỗi dài các đơn đặt hàng thay đổi.

Các cơ quan chính phủ thực sự nhanh nhẹn một cách chậm chạp, kém hiệu quả. Bạn phải viết (và đàm phán) các đơn đặt hàng thay đổi chính thức, chi tiết mọi lúc.

Cung cấp các tính năng X chính xác theo yêu cầu

Cho đến khi sửa đổi bởi một lệnh thay đổi.

Yêu cầu tính năng sẽ được ném qua một bức tường, đừng làm phiền chúng tôi, chúng tôi không muốn nghe nó.

Kênh truyền thông là thứ tự thay đổi. Ngân sách và tiến độ tác động.

Không có khái niệm ưu tiên tính năng trong tâm trí khách hàng, tất cả đều quan trọng hoặc chúng tôi sẽ không yêu cầu họ.

Điều này là khó để làm việc xung quanh. Ngay cả các doanh nghiệp phi chính phủ chi nhiều tiền cho "phân tích yêu cầu" cũng không muốn nói rằng một đống yêu cầu lớn, bằng phẳng, không bị cản trở bởi ưu tiên và thông tin đánh đổi là không đầy đủ. Họ đã trả tiền tốt để có được tất cả các yêu cầu. Làm thế nào bạn có thể muốn biết thêm thông tin?

Đây là một vấn đề khó khăn.

Dự án sẽ có chi phí không hơn và không ít hơn Y bất kể vượt quá hoặc thời hạn.

Ngoại trừ các đơn đặt hàng thay đổi. Mà sửa đổi Y và Hạn chót.

Thời hạn tuyệt đối, nghiêm ngặt, cuối cùng và không thể thương lượng để hoàn thành tất cả các công việc.

"Không thể thương lượng" nói chung là không đúng sự thật. Nó có thể thương lượng. Thật đau đớn khi phải thương lượng.

Phần quan trọng của việc đàm phán với các cơ quan chính phủ là thực tế rằng bạn cần "bằng chứng cấp luật sư" cho chi phí và thay đổi lịch trình của bạn. Một vài bài thuyết trình kỹ thuật cẩn thận với slide power-point đẹp không phải là "bằng chứng". Bạn cần rất nhiều tài liệu để làm cho trường hợp của bạn.

Chính phủ cần cung cấp bằng chứng không thể tin được rằng họ đã làm mọi thứ trong khả năng của mình để làm cho điều này rẻ và hiệu quả nhất có thể. Họ biết rằng mọi quyết định đều được phát lại trên báo chí công cộng và xem xét kỹ lưỡng về tầm nhìn.

Sự phức tạp của phát triển phần mềm và khía cạnh "thực tế vào buổi sáng thứ hai" sau công việc của chính phủ khiến họ không muốn thay đổi hợp đồng mà không có bằng chứng quá lớn.

Nó làm cho một cách tiếp cận Agile đúng cách khó khăn.

"Cá nhân và tương tác qua các quy trình và công cụ" là khó khăn. Bạn không làm việc với một cá nhân, nhưng một đại diện của chính phủ, công việc của họ bị hạn chế bởi quy trình.

Trong một dự án như thế này, họ đã trói tay bạn về phạm vi, tài nguyên và thời gian. Điều duy nhất bạn còn lại để quản lý là chất lượng. Vì thế...

Bạn sẽ không nhận được phần lớn lợi ích từ cách tiếp cận nhanh mà bạn có thể làm, nhưng bạn có thể cố gắng hết sức để giảm thiểu rủi ro chất lượng và có thể thông báo cho khách hàng về các vấn đề sớm hơn là sau này.

Vì vậy, hãy nhanh nhẹn như bạn có thể:

1. Đi qua các yêu cầu và ưu tiên chúng tốt nhất về rủi ro kỹ thuật. Đặt các yêu cầu ưu tiên làm tồn đọng của bạn.
2. Làm việc thông qua các hồ sơ tồn đọng trong nước rút - thiết kế, kiểm tra và mã hóa các tính năng cho lần chạy nước rút. Bạn đang thiếu tương tác máy khách, vì vậy tài liệu yêu cầu phải đại diện cho khách hàng cho hoạt động này.
3. Mời khách hàng đến từng đánh giá nước rút - họ có thể nói không, nhưng họ có thể nói có. Và bạn sẽ nhận được phản hồi sớm hơn là sau này.

Nếu bạn bắt đầu chạy quá thời hạn, bạn sẽ có thể hiển thị những gì đã hoàn thành và có lẽ tại thời điểm đó, khách hàng biết rằng mình sẽ không nhận được mọi thứ, sẽ ưu tiên đủ để nói cho bạn biết anh ấy muốn gì. Bạn cũng nên hoàn thành công việc rủi ro nhất, có nghĩa là các nhiệm vụ vào thời hạn cuối cùng là dễ dàng nhất để nhồi nhét trong giờ làm việc thêm.

Tôi nghĩ rằng loại khách hàng này không phải là tiêu chuẩn. Bạn đang làm việc với một nhóm đã yêu cầu các dự án tương tự trước đây, vì vậy họ biết chính xác những gì họ muốn. Bạn không bao giờ đề cập rằng thông số kỹ thuật của họ sẽ thay đổi.

Cung cấp các tính năng X chính xác theo yêu cầu

Tôi may mắn nếu tôi cung cấp tính năng X một cách mơ hồ như được đề xuất và sẵn sàng thay đổi nó trong một thông báo khoảnh khắc.

Yêu cầu tính năng sẽ được ném qua một bức tường, đừng làm phiền chúng tôi, chúng tôi không muốn nghe nó.

Nếu bạn biết họ muốn gì, hãy đi và xây dựng nó.

Không có khái niệm ưu tiên tính năng trong tâm trí khách hàng, tất cả đều quan trọng hoặc chúng tôi sẽ không yêu cầu họ.

Bạn không thể thua cái này. Xây dựng chúng khi bạn thấy phù hợp.

Dự án sẽ có chi phí không hơn và không ít hơn Y bất kể vượt quá hoặc thời hạn. Thời hạn tuyệt đối, nghiêm ngặt, cuối cùng và không thể thương lượng để hoàn thành tất cả các công việc.

Đó là một khó khăn nếu bạn chưa bao giờ xây dựng một dự án cho chính phủ. Nếu bạn có một số lịch sử, bạn có thể xác định xem bạn có thể giao hàng không. Điều này không có nghĩa là họ không trả tốt (họ nổi tiếng vì đã trả 50 đô la cho một chiếc búa 10 đô la.) Hoặc có những kỳ vọng không hợp lý. Với các thông số kỹ thuật này, ai đó trong nhóm của bạn nên đóng vai trò là khách hàng và phê duyệt công việc so với thông số kỹ thuật. Ngay cả khi bạn tìm thấy một lỗ hổng và cầu xin họ thay đổi các yêu cầu, họ có thể sẽ không làm thế.

Đáng buồn thay, những gì bạn đã mô tả là quan điểm khách hàng điển hình về cách giải quyết một dự án phần mềm. Điều này không có nghĩa là khách hàng đang không hợp lý; Rốt cuộc - đây không phải là cách người ta thực hiện việc xây dựng bất cứ thứ gì khác (ví dụ như một ngôi nhà?). Mặc dù vậy, tôi không thực sự cung cấp bất cứ điều gì nhiều hơn những gì chúng ta đã biết. Những gì bạn đang hỏi là ... việc áp dụng các thực hành nhanh có khả thi trong tình huống này không?

Tôi có lợi ích khi vừa hoàn thành một dự án tương tự ở nhiều khía cạnh với tình huống mà bạn mô tả, nghĩa là,

1. Đã sửa lỗi (trong đá, đến địa ngục hoặc nước cao).
2. Tài liệu yêu cầu chức năng ("kinh thánh"). Không đáng ngạc nhiên
3. Vai trò truyền thống: Quản lý dự án, Chuyên viên phân tích kinh doanh.
4. Người dùng doanh nghiệp tham gia yếu (bạn có thể nói "không có nhà tài trợ sản phẩm" không?).

... Và tất nhiên, nhóm phát triển tư duy tiến bộ đang cố gắng làm việc theo kiểu nhanh nhẹn, bất chấp những điều trên:

1. Lặp lại 2 tuần;
2. Đứng lên;
3. Hồi tưởng;
4. Lập trình cặp;
5. TDD;
6. Hội nhập liên tục.

Có ai trong số này có ý nghĩa từ xa đối với Kinh doanh không? Không còn hai tháng nữa, thời hạn lặp đi lặp lại được quan sát cẩn thận và các cuộc họp lập kế hoạch bị bỏ rơi trong sự điên cuồng của những con gà không đầu.

Các câu trả lời mà những người khác đã cung cấp ở trên là thỏa hiệp mức độ lớn hơn hoặc thấp hơn. Theo tôi, nhanh nhẹn (dù là "Nhanh nhẹn" hay "nhanh nhẹn") là "được thực hiện" theo cách nguy hiểm khi chúng ta thỏa hiệp. Theo ý kiến ​​của tôi:

Không có thỏa hiệp, hoặc không có nhanh nhẹn.

Tinh thần rất nhanh nhẹn là về việc cắt giảm để đuổi theo, loại bỏ chất thải, trung thực một cách tàn nhẫn với chính mình. Một thực tế đã được chứng minh rõ ràng và không thể phủ nhận rằng ước tính phần mềm cho các dự án lớn là một canh bạc tốt nhất. Có phải nhiệm vụ của chúng tôi là các chuyên gia phần mềm để giáo dục khách hàng tiềm năng về điều này? Nếu khách hàng không sẵn lòng chấp nhận rằng chúng tôi là chuyên gia, thì đó không phải là nghĩa vụ chuyên nghiệp của chúng tôi phải bỏ đi?

Khi tôi bắt đầu làm việc tại nơi tôi đang ở, tôi thấy mình hỏi cùng một câu hỏi mà bạn đã hỏi khá nhiều. Có một cái gì đó để nói về thác nước với hợp đồng của chính phủ. Trớ trêu thay, giờ đây Agile đã trở thành một từ thông dụng với các khách hàng chính phủ (những người thực sự làm việc theo kiểu thác nước), vì vậy bây giờ chúng tôi còn cố gắng hơn nữa để thực hiện quy trình nhanh với một khách hàng cơ bản không linh hoạt.

Chúng tôi có một hệ thống được mô tả là "Scrummerfall" "Agilefall" hoặc "A mess", nhưng trong nhiều khía cạnh, chúng tôi đã dần dần có thể áp dụng một quy trình ngày càng nhanh nhẹn hơn vì dự án (gargantuan) này đã tiến lên trong những năm qua . Một trong những cách mà chúng tôi đã làm đó là về cơ bản là tìm lại các kênh liên lạc với NGƯỜI DÙNG trong hệ thống của chúng tôi, trái ngược với KHÁCH HÀNG của chúng tôi. Khách hàng của chúng tôi là một bộ phận ngột ngạt do các quan chức được chỉ định đứng đầu, những người sẽ không bao giờ chạm vào phần mềm của chúng tôi trong cuộc sống làm việc của họ và không muốn hiểu nó. Người dùng của chúng tôi là nhân viên chính phủ thường xuyên trong lĩnh vực đang cố gắng hoàn thành một nhiệm vụ quan trọng. Đối với chúng tôi, chìa khóa để thiết lập một vòng phản hồi giao tiếp cho phép chúng tôi nhanh nhẹn như chúng tôi là điều cần thiết cho UAT (Kiểm tra chấp nhận người dùng).

Vào thời điểm đầu tiên trong dự án của chúng tôi, chúng tôi đã quyết định rằng một nhóm đại diện của NGƯỜI SỬ DỤNG THỰC TẾ từ các văn phòng khác nhau của khách hàng chính phủ rộng lớn của chúng tôi sẽ được tập trung tại địa điểm TẠI ĐÂY và chúng tôi sẽ có một vài tuần đối mặt với họ khi họ chạy qua một loạt kịch bản thử nghiệm để kiểm tra phần mềm của chúng tôi. Rất giống như một điều không chính thức, nhóm yêu cầu đã biến lần này thành một cách vô giá để nhận phản hồi từ người dùng cuối thực tế. Trong khi đó, nhóm thử nghiệm UAT trong chính phủ đã làm việc thông qua bộ máy quan liêu của họ để có ảnh hưởng ngày càng nhiều hơn đối với quy trình yêu cầu chính thức về kết thúc của họ bao gồm các lệnh thay đổi. Kết quả cuối cùng là các BA như tôi đóng vai trò là chủ sở hữu sản phẩm độc lập được nhúng trong các nhóm scrum và có thể có được thời gian đối mặt vô giá với các khách hàng thực sự cho phép chúng tôi hoạt động một cách rất nhanh nhẹn.

Rõ ràng, có rất nhiều vấn đề, và chúng tôi vẫn chưa thực sự nhanh nhẹn, nhưng chúng tôi đủ nhanh nhẹn để được coi là một ví dụ về một dự án nhanh nhẹn thực sự sử dụng phương pháp đó trong lĩnh vực ký kết của chính phủ.

Tóm lại: sử dụng kinh nghiệm của bạn như một nhà truyền giáo nhanh nhẹn trong chính tổ chức của bạn để thâm nhập vào khách hàng của bạn. Trải qua quá trình học tập với họ, thiết lập mối quan hệ đối tác dựa trên sự tin tưởng với những người chủ chốt về phía họ và làm việc TẠO Quy trình Yêu cầu chính thức, được đưa ra mà họ chắc chắn có. Bạn sẽ được cảm ơn bởi những kẻ trên mặt đất, những người phải thực sự sử dụng những gì bạn đang phát triển!

Bạn đang giả định các yêu cầu được viết tốt và bạn nghĩ chúng có nghĩa là những gì họ nghĩ chúng có nghĩa. Sự trở lại của quy trình nhanh sẽ giúp đảm bảo họ có được những gì họ muốn nói ngoài những gì họ yêu cầu.