Tư vấn trong một công ty không hiểu công nghệ! [đóng cửa]

Tôi nhận công việc là Tư vấn viên trong một công ty có 3 lập trình viên khác. Công việc của tôi là viết lại tất cả các hệ thống cũ trong Java, Spring, v.v. nhưng các lập trình viên nhân viên chỉ biết perl và người quản lý không biết lập trình nào.

Tôi đang cố gắng để họ hiểu rằng tôi có 6 dự án để viết lại ở đây nhưng không ai có tài liệu thiết kế hay thông số kỹ thuật. các lập trình viên nhân viên không bao giờ phải viết bất kỳ tài liệu. Thêm vào đó, tôi không thể khiến người quản lý hiểu được công nghệ java mới .. anh ta cứ hỏi một số nhân viên về quan điểm về mọi thứ nhưng nhân viên không biết hoặc hiểu nó.

Tôi sẽ đi đâu từ đây để làm cho người quản lý hiểu rằng các nhân viên lập trình hoặc ai đó phải viết một tài liệu thiết kế để tôi biết phải xây dựng cái gì. hoặc nếu tôi phải viết các tài liệu làm thế nào để tôi có được thông tin?

Có vẻ kỳ lạ là nhân viên không biết nền tảng mà bạn được yêu cầu viết lại tác phẩm của họ. Điều gì xảy ra sau khi bạn rời đi? Ai sẽ hỗ trợ công việc của bạn?

Vì vậy, bạn đã có một hệ thống phức tạp không có tài liệu phù hợp và bạn phải tạo lại hệ thống trong một nền tảng khác. Những gì tôi sẽ làm, ở vị trí của bạn, là xác định người duy nhất phải "đăng xuất" trên hệ thống mới. Từ đó, thực hiện một số cách đọc trên Câu chuyện của người dùng để xác định cách chia nhỏ các yêu cầu thành các đoạn có kích thước bit có thể được mô tả bằng tiếng Anh. Định dạng của chúng giống như "Là NGƯỜI DÙNG, trong HỆ THỐNG X, tôi muốn HÀNH ĐỘNG HÀNH ĐỘNG để GOAL IS MET.

Để giải thích thêm về Câu chuyện của người dùng, bạn thêm vào 'tiêu chí thành công' theo định dạng "Được đưa ra khi ĐIỀU KIỆN sau đó ra ngoài" để giải thích những gì xảy ra với các hành động khác nhau trong Câu chuyện người dùng gốc. Đây là một cách hay để chia nhỏ chức năng thành các phần có thể hiểu riêng lẻ và bạn có thể nhận trợ giúp viết các Câu chuyện khác nhau từ các nhóm khác nhau (chỉ cần đảm bảo rằng người cấp cao nhất đăng nhập vào tác phẩm vẫn giữ nguyên).

Vì vậy, hãy lấy tất cả các chức năng cũ của hệ thống được viết lại dưới dạng Câu chuyện của người dùng, sau đó hỏi chủ dự án nếu có bất kỳ chức năng MỚI nào họ muốn trong phiên bản Java. Thêm câu chuyện để thỏa mãn điều đó, nếu có, và sau đó bắt đầu viết mã.

Về cơ bản, bạn cần có khả năng phơi bày sự vô ích của các lập trình viên. Yêu cầu chủ sở hữu dự án yêu cầu họ cung cấp cho bạn Tiêu chí thành công cho một số Câu chuyện, để nếu họ cung cấp cho bạn đầu vào nhảm nhí, bạn có thể giữ điều đó theo yêu cầu chính thức của mình. Bất cứ điều gì họ bỏ đi sẽ là lỗi của họ, không phải của bạn.

Tôi đã tham gia vào một dự án trong đó toàn bộ hệ thống được viết bằng Oracle Forms, nhưng không có bất kỳ tài liệu nào. Công nghệ có thể dễ dàng có được Perl. Đây là kế hoạch tấn công để chuyển hệ thống sang Oracle ADF (nhưng cũng có thể dễ dàng trở thành bất kỳ nền tảng nào khác):

1. Tạo một tập hợp các loại mã cho các yêu cầu nghiệp vụ (chức năng, lỗi, xác nhận, ui, v.v.).
2. Tạo một tập hợp các danh mục cho màn hình (nhóm chúng theo chức năng tương tự).
3. Tạo một danh sách tất cả các màn hình cho toàn bộ ứng dụng và liệt kê chúng trong bảng tính.
4. Chỉ định mỗi màn hình một danh mục mã và loại mã (ví dụ: quy tắc kinh doanh, yêu cầu hệ thống, kỹ thuật).
5. Kỹ sư đảo ngược mã để trích xuất các yêu cầu nghiệp vụ, tạo một mô tả một câu cho mỗi yêu cầu.

Tại thời điểm này, bạn sẽ có tài liệu về các quy tắc kinh doanh cho ứng dụng. Điều này một mình sẽ là vàng cho bất cứ ai tiếp theo phải duy trì hệ thống. Hơn nữa, nó sẽ cho bạn cơ hội để xem những phần nào của hệ thống đã được sao chép. (Trong trường hợp của tôi, chúng tôi đã phát hiện ra rằng hơn 60% cơ sở mã đã được sao chép.)

Từ đây, bạn có thể sắp xếp thông qua các yêu cầu kinh doanh với quản lý. Điều này có thể đòi hỏi phải tạo ra các câu chuyện người dùng, ví dụ. Điều này cũng sẽ tiết lộ chức năng trùng lặp cấp cao và đưa ra các cơ hội để đơn giản hóa và nâng cao hệ thống trong quá trình di chuyển. Tôi đã bao gồm một ảnh chụp màn hình của bảng tính để chỉ ra một cách để theo dõi và ghi lại các yêu cầu.

Bạn có thể phải đánh lên Perl của bạn. ;-)

Khi bạn đã thiết kế ngược lại dự án, bạn có thể sử dụng một bộ công cụ để giúp bạn thực hiện vòng đời phát triển phần mềm. (Chúng tôi đang sử dụng JIRA , nhưng có nhiều bộ phần mềm khác sẽ hoạt động.) Bạn có thể phải chiến đấu, nhưng một khi bạn có yêu cầu, bạn sẽ muốn chuyển sang các môi trường sau:

• Tạo một môi trường tài liệu (ví dụ, wiki).
• Tạo môi trường phát triển (DEV). Máy chủ web, máy chủ cơ sở dữ liệu, kho lưu trữ nguồn, v.v.
• Tạo một môi trường thử nghiệm (TEST) phản ánh sự phát triển.
• Tạo một môi trường tiền sản xuất (PREPROD) phản ánh chính xác quá trình sản xuất và có thể đóng vai trò là sự thất bại cho hệ thống sản xuất.
• Tạo môi trường sản xuất (SẢN XUẤT).

Hãy suy nghĩ về việc sử dụng một dịch vụ hướng đến cộng đồng để giải quyết yêu cầu của tài liệu người dùng cuối. Một gói phần mềm tuyệt vời tương tự như bộ StackExchange là OSQA . Hãy để người dùng xây dựng hệ thống trợ giúp (đó là một chiến lược khá thông minh).

SDLC trở thành:

1. Các nhà phát triển thực hiện và kiểm tra các thay đổi ứng dụng trong DEV (sử dụng kho lưu trữ ).
2. Các công cụ hệ thống tự động triển khai các bản dựng thường xuyên vào TEST.
3. Khi người kiểm tra hài lòng với ứng dụng, ứng dụng sẽ được triển khai vào PREPROD. Điều này cho phép quá trình triển khai cũng được kiểm tra. Thử nghiệm nhiều hơn xảy ra trong PREPROD.
4. Sau khi người kiểm tra hài lòng với PREPROD, ứng dụng cuối cùng được đưa vào SẢN XUẤT.

Tôi thấy đây là một cách tiếp cận có tổ chức cao, hoạt động tốt với các phương pháp phát triển khác nhau. Vượt qua đầu tiên, mà tôi đã mô tả ở đây, nên được coi là "nét vẽ rộng" - bạn không muốn nhận quá chi tiết (sa lầy) với các chi tiết kỹ thuật tại thời điểm này. (Ví dụ: yêu cầu giao diện người dùng được ghi lại bởi mỗi màn hình. Miễn là bạn đã liệt kê các màn hình, bạn không cần lặp lại từng trường nhập - chỉ cần liên kết đến ảnh chụp màn hình hoặc URL hoạt động.)

Cuối cùng, để xem lại mã nguồn, chúng tôi đã tự động tạo một loạt các trang web (một trang web trên mỗi "màn hình" chức năng). Điều này hoạt động tốt vì mã PL / SQL có thể được tách thành các tệp riêng biệt và tự động được chuyển đổi sang HTML với tính năng tô sáng cú pháp. Với Perl, điều này có thể không hoạt động tốt cho bạn. Mặc dù vậy, ý tưởng là bạn có thể tạo các liên kết neo trong bảng tính quay lại phần mã thực thi yêu cầu nghiệp vụ. (Bên cạnh đó, điều này cũng sẽ cho phép nhiều nhà phát triển thiết kế song song các yêu cầu hệ thống vì mỗi nhà phát triển có thể giải quyết các màn hình khác nhau cùng một lúc.)

Một đoạn mã nguồn ví dụ (+ là một liên kết neo):

Bạn có thể khuyên bạn nên thuê một vài bậc thầy về Perl để giúp thực hiện nhiệm vụ phân tích.

Tôi không nghĩ rằng sẽ rất hữu ích khi chỉ ra rằng những người khác đang làm "công việc nhảm nhí"; thay vào đó, bạn nên tìm cách cải tiến sản phẩm và cho mọi người cơ hội giúp đỡ với mục tiêu này (và có lẽ học cách cải thiện kỹ năng của họ trong quy trình). Đó là, bạn không biết những gì các nhà phát triển khác biết, bạn cũng không ở đó khi họ phát triển hệ thống. Cách tiếp cận này làm cho toàn bộ quá trình mở và dễ thấy, theo đó mọi người đều có thể đóng góp.

Thành thật mà nói, các nhà quản lý sẽ nhìn thấy chính họ là người thực sự hữu ích và ai muốn cải thiện.

Họ không có tài liệu và mã của họ rất kém nên họ đã thuê người khác viết lại bằng ngôn ngữ khác. Bắt đầu thu thập các yêu cầu từ nguồn. Bạn sẽ tìm thấy rất nhiều tính năng và chức năng không còn được sử dụng hoặc có thể không hoạt động đúng. Điều quan trọng không kém là phải biết những gì không xây dựng.

Khi bạn đã tìm thấy những gì người dùng cần, hãy xác định những gì đã có trong ứng dụng hiện tại và những gì phải được xây dựng từ đầu. Các mảnh hiện có là nơi bạn có thể nhìn vào mã và nói chuyện với các nhà phát triển.

Bất cứ ai tuyên bố họ cần mọi thứ không bao giờ bận tâm để kiểm tra. Có một lập luận để không bao giờ viết lại một ứng dụng, nhưng điều đó giả định rằng mọi thứ hoạt động theo cách người dùng muốn và điều đó không phải lúc nào cũng đúng. Họ sử dụng nó vì không có sự thay thế. Cung cấp cho họ một sự thay thế tốt hơn.

Tôi sẽ bắt đầu bằng cách nói chuyện với người quản lý của bạn và chấp nhận trách nhiệm thu thập các yêu cầu và xác định thông số kỹ thuật. Bạn sẽ cần phải thuyết phục anh ấy về sự cần thiết của những tài liệu này và những gì họ sẽ cung cấp. Tôi có thể sẽ tìm thấy một ví dụ trực tuyến. Sau đó, bạn phụ trách lắp ráp các yêu cầu và thông số kỹ thuật cho hệ thống. Sau đó gặp lại người quản lý của bạn để xem lại tài liệu. Khi bạn đã cho họ xem tài liệu đầu tiên, bạn có thể nhận được một số trợ giúp trong việc tạo tài liệu khác 5. Thông minh khác nếu nó hiệu quả thì có lẽ bạn cũng sẽ chịu trách nhiệm thu thập những yêu cầu đó nhưng ít nhất sẽ có người thực hiện nó.