Giới thiệu phát triển Agile sau khi bắt đầu dự án truyền thống

Khoảng một năm rưỡi trước, tôi bước vào một nơi làm việc tuyên bố sẽ phát triển Agile. Điều tôi học được là nơi này đã áp dụng một số thực tiễn nhanh nhẹn (như đứng lên hàng ngày, quy hoạch nước rút và đánh giá nước rút) nhưng không có nguyên tắc nào (chỉ trong thời gian / chỉ cần tâm lý đủ tốt, phơi bày thất bại sớm, giao tiếp phong phú).

Bây giờ tôi đã được giao nhiệm vụ làm cho nhóm nhanh nhẹn hơn và tôi đã được đảm bảo rằng tôi đã mua hoàn toàn từ các nhà phát triển và nhóm kinh doanh. Là một chương trình thí điểm, họ đã giao cho tôi một dự án vừa hoàn thành 15 tháng thu thập yêu cầu, có tài liệu Phân tích & Thiết kế 110 trang (được coi là "viết bằng đá") và nơi tôi không có quyền truy cập vào cuối người dùng (chỉ cho ủy ban gồm những người quản lý của người dùng thực sự sẽ không sử dụng sản phẩm).

Tôi bắt đầu nhỏ, đưa cho họ một danh sách các sản phẩm dự kiến ​​cho 5 lần chạy nước rút đầu tiên (không xác định được các lần chạy nước rút trong tương lai), một danh sách các mục tiêu cho lần chạy nước rút đầu tiên và tôi đã mổ xẻ tài liệu A & D để có đủ câu chuyện của người dùng để đáp ứng các mục tiêu của lần chạy nước rút đầu tiên .

Kể từ đó, họ đã hỏi tại sao chúng tôi không có tất cả các yêu cầu cho tất cả các lần chạy nước rút, tại sao tôi chưa bắt đầu làm việc cho lần chạy nước rút thứ ba (điều mà họ cho là quan trọng hơn nhưng dựa trên các sản phẩm đầu tiên 2 lần chạy nước rút) và đang nhấn mạnh để có thêm tài liệu mà toàn bộ nhóm CNTT của tôi coi là công việc bận rộn hoặc không liên quan đến chúng tôi (chẳng hạn như viết hướng dẫn sử dụng lên phía trước, ghi lại tất cả các trường dữ liệu từ tất cả các lần chạy nước rút và hơn thế nữa công việc "trước mắt").

Điều này khá khó khăn đối với tôi khi là người quản lý dự án mới, nhưng có những cải tiến tôi đã thực hiện một cách hiệu quả như quản lý câu chuyện, lập trình cặp và yêu cầu doanh nghiệp cho chúng tôi kiểm tra chấp nhận khách hàng (như một phần của tài liệu yêu cầu) .

Vì vậy, câu hỏi của tôi là:

1. Tôi có thể làm gì để giới thiệu thay đổi hiệu quả hơn đối với một doanh nghiệp kháng chiến?
2. Có những thực tiễn khác mà tôi có thể giới thiệu về phía CNTT để giúp cho doanh nghiệp thấy những lợi ích của việc nhanh nhẹn?
3. Gánh nặng tài liệu đang bóp nghẹt chúng tôi - doanh nghiệp vẫn coi đó là một chiến lược quản lý rủi ro thay vì rủi ro. Chúng ta có thể làm gì để giảm bớt những lo ngại và nhu cầu về tài liệu của họ (cụ thể là số lượng tài liệu và nhu cầu của họ đối với tất cả các tài liệu đó)?
4. Chúng tôi ở trong một tòa nhà riêng biệt từ doanh nghiệp của chúng tôi, cách đó khoảng 3 dãy nhà và họ từ chối cho người của họ tham gia dự án cùng với người đó "sẽ không thể làm việc với các dự án khác của họ trong khi họ ở xây dựng." Họ hy vọng chúng tôi sẽ luôn đi đến đó và đưa ra các câu hỏi của chúng tôi để chúng tôi có thể hỏi tất cả họ cùng một lúc và không lãng phí thời gian của người đó với "sự gián đoạn liên tục". Chúng ta có thể làm gì để có được sự giao tiếp phong phú hơn từ họ?

Bất kỳ lời khuyên bổ sung cũng sẽ được đánh giá cao.

Cảm ơn!

Tôi đã được đảm bảo rằng tôi đã mua hoàn toàn từ các nhà phát triển và nhóm kinh doanh [...] Tôi không có quyền truy cập cho người dùng cuối [...]

Một điều khá rõ ràng là sự khác biệt giữa việc được đảm bảo bằng lời nói rằng bạn "đã mua", mặt khác, và mặt khác , cam kết thực tế từ bất cứ ai tài trợ cho công việc của bạn.

Lời khuyên tốt nhất của tôi cho bạn là hãy đặt nhãn "Agile" hoàn toàn. Cấm từ trong cuộc trò chuyện trong chừng mực có thể. Thay vào đó, hãy tập trung vào những điều sau đây:

• Có gì kết quả bạn sẽ được yêu cầu cung cấp (bạn đặc biệt, không phải là đội)
• Những gì các tiêu chí thành công cho nhiệm vụ của bạn là (một lần nữa, bạn chứ không phải là đội bóng)
• Điều gì có nghĩa là bạn có sẵn (bao gồm mọi người, quyền truy cập vào mọi người, thời gian, thông tin, ngân sách đào tạo, bất cứ điều gì)

"Làm cho nhóm nhanh nhẹn hơn" không phải là một mục tiêu hành động. Nó không đủ cụ thể, nó không thể đo lường được, nó không có điều kiện kết thúc. Những gì bạn cần là một cái gì đó cụ thể: một mục tiêu được thể hiện dưới dạng X phần trăm ít khiếm khuyết hơn, hoặc Y phần trăm của ngày phân phối tính năng của bạn thực sự được tôn vinh, theo ngày Z.

Để đạt được những mục tiêu này, bạn có thể cần phải giới thiệu những thay đổi. Bây giờ một vài quy tắc của ngón tay cái áp dụng. Mỗi cải tiến là một thay đổi, nhưng không phải mọi thay đổi đều là cải tiến. Người ta thường nói rằng mọi người chống lại sự thay đổi, nhưng thực ra mọi người chống lại sự thay đổi và không biết liệu sự thay đổi đó có phải là một sự cải tiến hay không.

Tập trung vào các thực hành mà bạn nghĩ sẽ dễ dàng chiến thắng, quả treo thấp. Tập trung vào các thực tiễn thiết lập một khuôn khổ không chỉ để thực hiện thay đổi, mà còn để đánh giá tác động của thay đổi và trấn an mọi người rằng họ đang dẫn đến cải thiện thay vì hồi quy. "Bộ tản nhiệt thông tin" là tốt, cũng như nhìn lại.

Một số thay đổi này có thể là cần thiết và được coi là đe dọa, như có nhiều quyền truy cập hơn vào những người có thông tin chính. Đừng thỏa hiệp với những điều này: "mua vào" có nghĩa là một quá trình đàm phán trong đó bạn thực sự có cơ hội cung cấp những gì bạn được yêu cầu, không bị dẫn dắt như một con cừu đến tàn sát chính trị.

Cố gắng thiết lập mọi thứ sao cho thật khó để đổ lỗi cho bạn nếu mọi thứ không ổn (và rất nhiều điều có thể sẽ sai). Hãy lưu ý rằng điều này có thể xảy ra và hãy chuẩn bị nếu nó xảy ra: biết chiến lược thoát hiểm của bạn.

Để giới thiệu một điều mới một cách suôn sẻ, bạn cần đảm bảo rằng mọi người sẽ không xem đó là mối đe dọa và vĩnh viễn .

Nhiều người trong chúng ta có dây tự nhiên để tránh mọi thứ mới. Đó là sinh học. Mọi người thường tìm kiếm sự mới lạ sẽ không bao giờ gây ra cho bạn bất kỳ vấn đề. Bạn cần chắc chắn rằng những người lo lắng hơn sẽ không xem đề xuất của bạn là mối đe dọa cho sự thoải mái hiện tại của họ.

Cách lý tưởng để một nhóm áp dụng thực tiễn hoặc ý tưởng là đảm bảo ý tưởng đến từ họ, và không phải bất kỳ người bên ngoài nào như quản lý, hoặc tệ hơn, một số chuyên gia tư vấn ngẫu nhiên. Để thực hiện điều này, hãy tạo ra các cuộc họp động não với cả nhóm chỉ với một chủ đề. Chủ đề nên là vấn đề. Trong cuộc họp, bạn sẽ phải đưa ra một cách cẩn thận các ý tưởng và đi kèm với các lập luận và sự kiện.

Chúng tôi không muốn đưa ra quyết định về công cụ vĩnh viễn. Chúng tôi đã lo lắng bởi ảnh hưởng của một sự thay đổi tiềm năng. Hành vi đó được biết đến bởi các cửa hàng thú cưng. Mua một con chó là một quyết định rất lớn và có khả năng sẽ thay đổi hoàn toàn cuộc sống của bạn. Khi bạn ở cửa hàng, nhân viên bán hàng sẽ thường đề nghị bạn mang nó về nhà, và trả lại nếu bạn đổi ý. Như bạn có thể mong đợi, có rất ít lợi nhuận. Đề xuất chỉ có một mục tiêu: giảm bớt sự lo lắng ngăn cản mọi người đưa ra quyết định. Đề xuất với nhóm thực hành của bạn rằng bạn cố gắng trong một khoảng thời gian cố định sau những gì bạn sẽ đánh giá hiệu quả của nó.

Về câu hỏi thứ hai của bạn, tôi khuyên bạn nên mang theo một thứ một lúc.

Vấn đề tài liệu của bạn xứng đáng được đăng ở đây trên P.SE và tôi không thấy có vấn đề gì với thực tế bạn ở hai tòa nhà khác nhau nếu cả hai đều sẵn sàng đáp ứng quy định. Có một tình huống mà một trong hai bên không muốn gặp nhau;)

Agile không dành cho tất cả mọi người, có vẻ như doanh nghiệp của bạn chỉ thích nói nhanh vì đó là từ thông dụng nhất. Trước hết, có lẽ nên là một ý tưởng tốt để thúc đẩy một dự án hoàn toàn mới hoặc các dự án bảo trì nhỏ hơn để bắt đầu thực hiện quy trình của họ giống như các phương pháp nhanh nhẹn thực sự. Cố gắng thiết kế lại một phương pháp bằng cách sử dụng một dự án đang được tiến hành cũng giống như cố gắng thay lốp ở giữa đường cao tốc 8 làn. Bạn cần một cách để thể hiện sự nhanh nhẹn trong kinh doanh của bạn có thể hoạt động, nhưng bạn cần một môi trường nơi nó có cơ hội làm việc, nhưng dựa trên những gì bạn đã nói, agile khó có thể hoạt động tốt với văn hóa đã thiết lập của họ.

Tùy thuộc vào những gì họ muốn cho tài liệu, bạn có thể cho họ thấy rằng tài liệu này được tạo tự động từ một công cụ bạn đang sử dụng hoặc là dự phòng và tài liệu B có tài liệu thông tin A được yêu cầu hiển thị. Bạn cũng cần điều chỉnh kế hoạch cho tài liệu của mình, cho họ biết lý do tại sao các ước tính của bạn thay đổi và yêu cầu họ giảm số lượng tài liệu được yêu cầu hoặc dành tài nguyên như nhà phân tích kinh doanh để tạo tài liệu.

Since then, they've asked why we don't have all the requirements for all the sprints, why I haven't started working on stuff for the third sprint (which they consider more important but is based off of the deliverables of the first 2 sprints) and are pressing for even more documentation that my entire IT team considers busy-work or un-related to us (such as writing the user manual up-front, documenting all the data fields from all the sprints up front, and more "up-front" work).

Đó là vấn đề của bạn. Họ không hiểu điều đó. Ai đó không thể yêu cầu bạn nhanh nhẹn hơn và không sẵn sàng đi cùng. Họ có những kỳ vọng sai lầm. Mọi thứ đã bị phá vỡ, lên phía trước, trước khi bạn bắt đầu. Đúng những kỳ vọng hoặc bạn sẽ thất bại. Nó giống như tôi yêu cầu bạn lái 150 MPH và tôi đưa cho bạn một chiếc Chevette để làm điều đó.

Xây dựng trong thời gian / tài nguyên / chi phí của tài liệu họ muốn và cho họ xem nó đẩy lịch trình đi bao xa.

Điều này có thể giúp chỉ cho họ biết họ đang đẩy bao nhiêu công việc lên nhóm dự án và làm thế nào để giảm bớt điều này nếu họ không làm điều đó.