Tôi có một vấn đề với một giám đốc cấp cao, người không hiểu về sự phát triển lặp lại (ít Agile hơn nhiều). Ông nhấn mạnh rằng đặc tả thiết kế phần mềm (SDS) của chúng tôi phải được hoàn thành trước khi bất kỳ dòng mã nào được viết. Hoàn thành, với anh ta, có nghĩa là tất cả các chi tiết chức năng là ở đó. Ngoài ra, là một cựu lập trình viên Cobol, anh ta muốn xem "mô-đun" và sơ đồ. Đây là một ứng dụng web Java cho tiếng khóc lớn!

Dù sao, tôi đang cố gắng tìm một nơi đơn giản để nhẹ nhàng chỉ cho anh ấy thấy rằng SDS không cần phải hoàn thành 100% trước khi chúng tôi bắt đầu viết mã (cũng không thể hoàn thành). Bất kỳ đề xuất?

Cảm ơn!

Là một nhà tư vấn, tôi hiểu một quy tắc tư vấn đơn giản:

• Bạn không thể giúp những người không muốn được giúp đỡ.

Bạn không thể khiến bất cứ ai làm bất cứ điều gì họ không muốn làm ngoại trừ bằng quyền lực mà bạn không có.

Là một huấn luyện viên, tôi giới thiệu Agile với ba quy tắc:

1. Không thể thu thập tất cả các yêu cầu khi bắt đầu dự án.

2. Dù yêu cầu bạn làm thu thập được đảm bảo để thay đổi.

3. Sẽ luôn có nhiều việc để làm hơn là thời gian và tiền bạc sẽ cho phép.

và một mục tiêu:

• Cung cấp một cái gì đó có giá trị mỗi tuần.

Đó là tất cả những gì bạn cần để bắt đầu.

Thuyết phục người quản lý của bạn là một điều khác.

Bạn không thể "làm cho" người quản lý hiểu nhanh nhẹn khác với bạn có thể khiến nhà phát triển hiểu điều đó. Bạn cần trình bày cho anh ấy những lý lẽ (những cuốn sách của Kent Beck là một khởi đầu tốt) và để anh ấy tự quyết định.

Ngoài ra, bạn có thể yêu cầu anh ta cho phép bạn chạy thử nghiệm. Thực hiện một dự án nhỏ và chạy nó với sự phát triển lặp lại và theo dõi chặt chẽ về thời gian, ngân sách, vấn đề chất lượng và sự hài lòng của nhóm. So sánh nó với các dự án trước đó (hoặc phát hành) và xem liệu nó tốt hơn, tệ hơn hay trung tính.

Bạn không

Trước hết, tại sao một Giám đốc cấp cao thậm chí còn tham gia vào việc lựa chọn phương pháp phát triển phần mềm? Quyết định đó thấp hơn mức lương của anh ta, quản lý vi mô và nói lên sự không tin tưởng.

Thứ hai, tại sao anh ta cần phải hiểu nó? Nếu thông số kỹ thuật phần mềm được cố định trong đá thì sẽ có chính xác một lần lặp. Nếu họ không, thì sẽ có nhiều lần lặp lại. Đây không phải là quyết định của anh ấy .

Nếu anh ta nghĩ rằng đó là quyết định của mình, thì anh ta đang làm suy yếu thẩm quyền của Giám đốc CNTT, quản lý dự án, kiến ​​trúc sư CNTT, trưởng nhóm và nhóm phát triển. Vì vậy, anh ta nên tự viết phần mềm @ # $% ing, hoặc STFU và để các chuyên gia thực hiện công việc của họ không bị cản trở bởi bộ não khủng long.

Tôi không đùa. Nếu anh ta không thể tin tưởng bạn làm công việc của bạn, anh ta nên tự làm và bạn nên chạy đi la hét .

"Làm phần mềm giống như làm một bộ phim, bạn cần lên kế hoạch trước nhưng trong quá trình quay phim, bạn cần quay lại, quay lại cảnh cũ và chỉnh sửa sản phẩm cuối cùng để đảm bảo kết quả tốt"

Sau đó, một lần nữa, anh ấy là một người quản lý, vì vậy trong lời nói của anh ấy:

"Chúng ta cần tận dụng sự linh hoạt của mình để tạo ra một giải pháp dịch vụ đầy đủ kịp thời"

Câu nói cũ được áp dụng: Bạn có thể đưa ngựa xuống nước, nhưng bạn không thể làm cho nó uống.

Như những người khác đã chỉ ra, điều thực sự quan trọng đối với giám đốc cấp cao này là giá trị kinh doanh. Bạn có thể cố gắng đưa ra ước tính nhanh về thời gian bạn sẽ dành ra để vẽ sơ đồ và sơ đồ mô-đun của anh ấy và viết một SDS "hoàn chỉnh" (khái niệm lố bịch, nhưng đưa cho anh ấy những gì anh ấy muốn). Nếu tôi biết bất cứ điều gì về những điều này (và khi tôi bắt đầu viết phần mềm, đó là cách nó đã được thực hiện) thì ước tính của bạn sẽ dễ dàng được vài tuần, nếu không muốn nói là nhiều hơn cho một dự án lớn. Thể hiện con số đó bằng tiền.

Sau đó cho anh ta thấy bạn có thể cung cấp bao nhiêu chức năng trong cùng một lúc. Nói chuyện với một vài người trong doanh nghiệp về việc họ sẽ tiết kiệm được bao nhiêu thời gian để có một ứng dụng web cơ bản làm những việc bạn có thể cung cấp trong cùng thời gian đó. Sau đó, nhân số tiết kiệm này bằng cách thường xuyên họ sử dụng chức năng này trong 3 năm. Thể hiện bằng tiền.

Có lẽ có những lợi ích kinh doanh khác có thể được thể hiện bằng tiền. Yêu thích của tôi luôn luôn là phòng chống "bóng ném". Nếu phần mềm của bạn có thể giúp giảm thiểu thảm họa hoặc tránh chúng hoàn toàn, thì hãy tìm một thảm họa gần đây và thể hiện nó bằng tiền. Sau đó nói với sếp của bạn: Nếu chúng tôi có điều này ngay bây giờ, chúng tôi sẽ tiết kiệm số tiền này.

Và nếu mánh khóe tiền bạc không hoạt động, thì có lẽ nên đến gặp anh ta và bảo anh ta ngừng quản lý nhóm vi mô. Mặc dù, theo kinh nghiệm của tôi, điều đó có nhiều khả năng khiến bạn bị sa thải hơn bất cứ điều gì khác.

Nơi đơn giản có thể là Tuyên ngôn về phát triển phần mềm linh hoạt .

Thông tin bạn tìm thấy ở nơi này là về các nguyên tắc cốt lõi của phát triển phần mềm nhanh được xác định bởi một nhóm các chuyên gia nổi tiếng.

Đó là

• Các cá nhân và tương tác qua các quy trình và công cụ
• Phần mềm làm việc trên tài liệu toàn diện
• Hợp tác khách hàng qua đàm phán hợp đồng
• Đáp ứng để thay đổi theo kế hoạch

Nhưng xin vui lòng xem chi tiết trang để có được ý định đầy đủ.

Tôi sẽ đề nghị cố gắng cho anh ấy thấy rằng bằng cách thực hiện "Tạo mẫu nhanh" (còn gọi là bắt đầu viết mã vài lần lặp đầu tiên), bạn có thể nhanh chóng xác định SDS của mình (nghĩa là làm lại ít hơn sau này) và bắt đầu cung cấp giá trị doanh nghiệp sớm hơn. Thực sự, rất có thể giá trị kinh doanh là tất cả những gì quan trọng đối với giám đốc này và ông đã quyết định rằng cách tốt nhất để đạt được nó là thông qua quá trình tuần tự này. Bạn cần cho anh ấy thấy điều đó tại sao cách tiếp cận của bạn tốt hơn.

Điều này có thể hữu ích - http://www.youtube.com/watch?v=4u5N00ApR_k

Trong bộ phim "Tôi muốn điều hành một dự án nhanh nhẹn", chúng tôi theo dõi kinh nghiệm của một người lãnh đạo dự án dũng cảm như vậy, khi anh ấy có nhiều cuộc gặp gỡ khác nhau trong toàn doanh nghiệp, làm việc để thiết lập và cung cấp dự án Agile của anh ấy.