Có thực hành tốt nhất nào liên quan đến việc bàn giao từ kiến ​​trúc đến phát triển không?

Chúng tôi đang xem xét cải tiến quy trình bàn giao các nhiệm vụ từ kiến ​​trúc đến phát triển.

Ở một đầu của quy mô, không có hướng dẫn kiến ​​trúc nào mà bạn có nguy cơ bị hỗn loạn, với mỗi nhà phát triển làm mọi thứ theo cách của mình.

Ở đầu kia của thang đo nơi mọi thứ được chỉ định, đặc tả sẽ mất nhiều thời gian hơn so với sự phát triển và bạn có nguy cơ gặp phải các nhiệm vụ phát triển rất nhàm chán.

Có ai tìm thấy một nền tảng trung gian tối ưu giữa các thái cực này? Những cổ vật nào bạn cung cấp để phát triển? Ví dụ: mô-đun, cấu trúc lớp hoặc sơ đồ tuần tự?

Tôi sẽ bắt đầu bằng cách nói rằng chính khái niệm về một nhóm "Kiến trúc" riêng biệt là một mối quan hệ với các thực tiễn phát triển phần mềm tốt. Các nhóm kiến ​​trúc trong môi trường doanh nghiệp có xu hướng trở thành đỉnh cao của những nghệ sĩ giả trí tuệ ngà tháp tồi tệ nhất * có thể được tìm thấy giữa nhóm các nhà phát triển.

Các tổ chức khác đối xử với các nhóm Kiến trúc như một phần thưởng chính trị và biện minh cho một mức lương khổng lồ cho các thành viên cao cấp nhất bất kể thành tích, kiến ​​thức hay kỹ năng. Hầu hết bao gồm cả hai loại.

Mỗi nhà phát triển có thể và nên là một kiến ​​trúc sư và nên tham gia vào các thiết kế cấp cao của một công ty. Người ta cho rằng một nhóm duy nhất có quyền kiểm soát độc tài hoàn toàn đối với mọi khía cạnh của thiết kế phần mềm và phải được trao cho các nhà phát triển không đóng góp cho thiết kế, không hiểu lý do đằng sau các lựa chọn thiết kế và có thể hiểu các lỗ hổng quan trọng trong thiết kế thoải mái hơn và gần hơn với việc triển khai thực tế và mã hiện có, thực sự hoàn toàn thiếu sót từ chính cốt lõi của nó, và sẽ luôn dẫn đến một trong ba kịch bản:

• Các nhà phát triển không hiểu thiết kế, hoặc từ chối hoàn toàn nó do thực tế của việc triển khai hiện tại và cuối cùng xác định thiết kế không có giấy tờ của riêng họ và thực hiện điều đó thay vào đó. Tình huống là các tài liệu thiết kế chính thức không phản ánh việc thực hiện phần mềm.

• Các nhà phát triển mù quáng tuân theo thiết kế có thể hoặc không thể xem xét các yêu cầu hiện tại hoặc các khía cạnh độc đáo của câu chuyện người dùng, dẫn đến việc triển khai lỗi và chất lượng kém.

• Các nhà phát triển thông minh, những người hiểu các tài liệu thiết kế và có thể thực hiện chúng, nhanh chóng cảm thấy nhàm chán khi không tham gia vào các cuộc thảo luận thiết kế. Họ có khả năng bị loại khỏi việc tham gia nhóm Kiến trúc do các vấn đề chính trị hoặc thâm niên, vì vậy họ trở nên thất vọng, buồn chán và rời khỏi đồng cỏ xanh hơn. Điều này ảnh hưởng tiêu cực đến dự án dẫn đến chảy máu chất xám khiến chu kỳ luẩn quẩn của chất lượng phần mềm kém tiếp tục.

Cách tốt nhất để giảm thiểu vấn đề này là THAY ĐỔI nhóm Kiến trúc và có thể đưa họ vào các vị trí lãnh đạo công nghệ. Vai trò của nhóm Kiến trúc nên ít nhiều là một "nhóm lãnh đạo công nghệ" nếu bạn muốn. Họ chỉ nên hiếm khi gặp nhau và chỉ thảo luận về các vấn đề định hướng kỹ thuật cấp cao nhất, vd. nghĩ rằng cuộc thảo luận chuyển từ Java sang Scala, từ bỏ Oracle cho MySQL, có thể viết các thư viện tiện ích phổ biến bắt buộc một LOẠI quy trình thiết kế nhất định khác, chuyển từ StarUML sang Altova UML.

Thiết kế phần mềm thực tế và thực tế sẽ là một quy trình cộng đồng liên quan đến TẤT CẢ các nhà phát triển phần mềm, được đặt ra theo định hướng cực kỳ cao của nhóm Kiến trúc.

Luôn có vấn đề trong cách thông tin được truyền từ kiến ​​trúc đến kiểm tra và vận hành phát triển. Cách giải quyết những vấn đề này imho phụ thuộc vào một số yếu tố như:

• kích thước của phần mềm
• phức tạp
• văn hóa trong tổ chức của bạn
• sự tin tưởng.

Đối với các kết hợp nhất định của các yếu tố này, một cách tiếp cận nhanh nhẹn thuần túy các nhóm chức năng chéo với thiết kế nổi dần là phù hợp. Các luồng thông tin bằng cách làm việc cùng nhau. Các kỷ luật tài liệu những gì họ cần.

Đối với các kết hợp khác của các yếu tố này, một nhóm nhỏ kiến ​​trúc sư, người thử nghiệm, chuyên gia vận hành và nhà phát triển chính có thể bắt đầu với các bước lặp kiến ​​trúc từ từ xây dựng kiến ​​trúc, ghi lại tài liệu và nhận phản hồi ngay lập tức về các quyết định kiến ​​trúc của họ. Dần dần nhiều nhà phát triển triển khai các tính năng có thể được thêm vào nhóm và nhóm cốt lõi ban đầu có thể được làm nhỏ hơn.

Chủ yếu là cho các dự án chính phủ và tài chính, yêu cầu nhiều tài liệu hơn được viết trước và có thể mất nhiều thời gian mà không có phản hồi trong thế giới thực về lựa chọn của bạn. Trong tâm trí tôi, lý do lớn nhất khiến nhiều dự án này thất bại. Tuy nhiên, nếu đây là tình huống của bạn, tôi sẽ làm cho tài liệu phù hợp với yêu cầu Và hơn là sử dụng tùy chọn 1 hoặc 2 để thực sự xây dựng phần mềm và tinh chỉnh / điều chỉnh tài liệu.

Hi vọng điêu nay co ich.

Tôi biết điều này sẽ không phổ biến lắm nhưng bình luận bạn đã đưa ra

Ở đầu kia của thang đo nếu mọi thứ được chỉ định, đặc tả sẽ mất nhiều thời gian hơn so với sự phát triển. Và bạn có nguy cơ có những nhiệm vụ phát triển rất nhàm chán.

thực sự là một cái gì đó bạn nên phấn đấu. Nếu thiết kế và đặc tả đủ vững chắc để các nhiệm vụ phát triển nhàm chán, thì chi phí phát triển sẽ giảm xuống. Nó ít tốn kém hơn nhiều để sửa một đặc tả so với sửa mã, và chi phí lớn nhất của các dự án phần mềm không phải là bản dựng, nó là hỗ trợ dài hạn. Và mã hỗ trợ dựa trên một thông số kỹ thuật rắn sẽ ít tốn kém hơn nhiều.

Tôi không hoàn toàn đồng ý với câu trả lời của maple_shaft, nhưng không có đủ chỗ trong bình luận để nói toàn bộ ý kiến ​​của tôi! ;-)

Tôi đồng ý rằng mọi nhà phát triển đều có thể và nên là một kiến ​​trúc sư, nhưng điều đó không có nghĩa là mọi nhà phát triển phải chịu trách nhiệm về kiến ​​trúc của toàn bộ sản phẩm hoặc hệ thống. Hơn nữa, tôi không nghĩ bạn có thể vẽ mọi nhóm kiến ​​trúc bằng cùng một bàn chải rộng và khi thực hiện đúng, các nhóm kiến ​​trúc có thể mang lại giá trị lớn cho quá trình phát triển sản phẩm tổng thể. Quan niệm sai lầm là các kiến ​​trúc sư nên ra lệnh cho mọi khía cạnh của thiết kế hệ thống. Thay vào đó, họ nên tập trung vào thiết kế cấp cao hơn và để lại chi tiết triển khai cho các nhóm phát triển của họ. Tuy nhiên, điều đó không có nghĩa là các nhà phát triển không nên tham gia vào quá trình lập kế hoạch và thiết kế ngay từ đầu.

Sản phẩm càng lớn và nhiều mô-đun và cuối cùng càng phức tạp, bạn càng có nhiều khả năng tìm thấy các bộ phận khác nhau của sản phẩm được xử lý bởi các nhóm phát triển khác nhau. Các nhóm như vậy không cần phải hiểu toàn bộ hệ thống với điều kiện họ có sự hiểu biết đầy đủ về các bộ phận của hệ thống mà họ chịu trách nhiệm. Thông thường, các nhóm bổ sung này được đưa vào làm nhà thầu phụ cho mục đích cụ thể là phát triển mô-đun trong một lĩnh vực công nghệ cụ thể mà các kiến ​​trúc sư hoặc các nhóm khác có thể không có chuyên môn. Tài năng đặc biệt của tôi nằm ở việc phát triển API và tôi vẫn chưa thấy API bao gồm nhiều yếu tố được phát triển hoàn toàn hữu cơ mà không phải là một mớ hỗn độn về khả năng sử dụng, hoặc điều đó không yêu cầu ai đó phải nổi bật như người đảm bảo có mức độ đồng nhất giữa các khía cạnh khác nhau của API. Tôi có thể tiếp tục liệt kê nhiều ví dụ và lý do, nhưng tôi không nghĩ rằng những tình huống này là tháp ngà BS mà nhiều người có thể nghĩ rằng chúng là như vậy. Thật không may, có nhiều nơi, đặc biệt là trong các lĩnh vực quốc phòng, y tế và các lĩnh vực tài chính mà sự hoang tưởng của công ty dẫn đến việc phát triển sản phẩm được quản lý kém và thậm chí còn kém hơn mà tôi chắc chắn rằng maple_shaft quan tâm nhất. Đây là những điều mà tôi tin rằng cung cấp cho các kiến ​​trúc sư một chút của một tên xấu kém xứng đáng (nói chung). Thật không may, có nhiều nơi, đặc biệt là trong các lĩnh vực quốc phòng, y tế và các lĩnh vực tài chính mà sự hoang tưởng của công ty dẫn đến việc phát triển sản phẩm được quản lý kém và thậm chí còn kém hơn mà tôi chắc chắn rằng maple_shaft quan tâm nhất. Đây là những điều mà tôi tin rằng cung cấp cho các kiến ​​trúc sư một chút của một tên xấu kém xứng đáng (nói chung). Thật không may, có nhiều nơi, đặc biệt là trong các lĩnh vực quốc phòng, y tế và các lĩnh vực tài chính mà sự hoang tưởng của công ty dẫn đến việc phát triển sản phẩm được quản lý kém và thậm chí còn kém hơn mà tôi chắc chắn rằng maple_shaft quan tâm nhất. Đây là những điều mà tôi tin rằng cung cấp cho các kiến ​​trúc sư một chút của một tên xấu kém xứng đáng (nói chung).

Vậy đâu là nền tảng trung gian mà OP đang tìm kiếm? Câu trả lời là tất cả để làm với việc mở các kênh truyền thông. Các kiến ​​trúc sư cần phải bàn giao các thông số kỹ thuật mô tả thiết kế của họ đủ chi tiết để đảm bảo các nhóm phát triển sẽ hiểu được ranh giới ở đâu. Câu chuyện và kịch bản tính năng theo nghĩa rộng nhất, nơi mọi thứ được coi là hộp đen. Sau đó, các kiến ​​trúc sư cần đảm bảo rằng các đội có quyền truy cập vào thời gian của kiến ​​trúc sư để xác nhận bất kỳ giả định nào và để có bất kỳ câu hỏi nào được trả lời về các thông số kỹ thuật có vẻ quá rộng hoặc không rõ ràng. Sau đó, thực sự là về việc đảm bảo rằng các đội riêng lẻ nhận thức được những gì các đội khác đang làm việc và họ biết ai sẽ liên lạc với các đội khác để đảm bảo mỗi phần của hệ thống sẽ chơi tốt với các phần khác. Các đội gặp nhau trực tiếp. Khi hệ thống đã được thiết kế ở cấp độ rộng nhất, các kiến ​​trúc sư thực sự chỉ nên là người mà các đội quay sang khi họ cần kiểm tra vệ sinh và để đảm bảo rằng "tầm nhìn" của sản phẩm được duy trì. Họ cũng nên tham gia bất kỳ quy trình tích hợp nào cần thiết và cung cấp "không khí" rất cần thiết cho các nhóm phát triển từ các nhà quản lý, khách hàng và bất kỳ bên liên quan nào khác, trong khi vẫn đảm bảo những người khác nhau có thể cùng nhau giải quyết họ làm việc như thế nào

Các kiến ​​trúc sư của IMHO trước hết nên là người hướng dẫn & truyền thông, và người thiết kế thứ hai. Như mức độ đặc điểm kỹ thuật? Tôi nghĩ rằng các kiến ​​trúc sư giỏi nhất là những người hỏi các đội của họ về mức độ chi tiết mà một nhóm muốn và giữa họ tìm thấy sự cân bằng hoạt động. Các đội khác nhau có thể có các yêu cầu khác nhau về số lượng tài liệu hoặc hướng yêu cầu. Các nhóm cao cấp có thể tìm thấy một sơ đồ được vẽ thô sơ và một cuộc trò chuyện nhanh có thể đủ để bắt đầu, trong khi các nhóm chứa đầy các nhà phát triển tương đối cơ sở có thể cần thêm một chút để họ đi. Trên hết, kiến ​​trúc sư cần khuyến khích các nhà phát triển thực hiện tài năng thiết kế của riêng họ để có được kết quả cuối cùng tốt nhất từ ​​mỗi nhóm.

Vì bạn cố gắng cải thiện một cái gì đó, nên bạn đã cảm nhận được một vấn đề trong quy trình của mình. Nguyên nhân sâu xa cho tình huống cụ thể có thể là do: Các nhà phát triển không thể xác định chính họ với kiến ​​trúc, bởi vì nó được áp đặt lên họ bởi một ai đó bên ngoài. Bàn giao kiến ​​trúc cho sự phát triển sẽ rất có thể không giải quyết được nguyên nhân gốc rễ này.

Làm cho kiến ​​trúc là một phần của nhóm phát triển. Xé xuống biên giới giữa kiến ​​trúc sư và nhà phát triển. Điều này đảm bảo rằng thông tin sẽ chảy. Nếu nhóm phát triển tham gia vào việc định hình kiến ​​trúc, họ sẽ không coi đó là một thứ gì đó xa lạ. Truyền kiến ​​thức về kiến ​​trúc vào đội. Dạy họ các yếu tố thúc đẩy đằng sau kiến ​​trúc công ty để tránh sự hỗn loạn mà bạn đề cập. Thu hút các nhà phát triển khi các quyết định kiến ​​trúc phải được đưa ra để tránh sự nhàm chán mà bạn đề cập. Việc bàn giao sau đó không còn cần thiết nữa và bạn đã hoàn thành vai trò là một kiến ​​trúc sư trong một nhóm phát triển.

Bạn cần cung cấp càng nhiều thông tin càng tốt cho nhóm tương lai để duy trì mã. Nếu bạn không có sơ đồ trình tự chẳng hạn, nhà phát triển buộc phải theo dõi mã từng bước, do đó sẽ lãng phí thời gian.

Ngoài ra còn có chỗ cho đội mới đưa ra các giả định không hợp lệ.

Nói chung nên có một tài liệu về dự án là gì, các thông số kỹ thuật, trường hợp kiểm thử đơn vị và sơ đồ trình tự / lớp.

Tôi muốn nói rằng các khung nhìn biểu đồ Class tạo ra một mô hình cũng như mã là một giải pháp. Biểu đồ lớp đại diện cho chế độ xem tĩnh của kiến ​​trúc dự án của bạn. Ý tôi là bạn có các gói> lớp, không gian, enum> thuộc tính, mehtods, v.v ...> vv .. Nếu bạn nhìn tốt thì siêu mô hình UML2 có cấu trúc chính xác như dự án java hoặc dotnet.

Những gì chúng ta sử dụng trong các dự án của chúng ta chỉ đơn giản là các sơ đồ lớp được lưu vào một mô hình duy nhất. Chúng tôi tạo các khung nhìn của mô hình nếu trình phân loại đã tồn tại hoặc tạo một mô hình mới tại đồ họa nếu nó là mới. Các nhà phát triển có thể xem sơ đồ và mô hình của chúng tôi vì được lưu tại thư mục gốc của thư mục dự án bên trong CVS. Điều tôi thích là nhà phát triển cũng có thể lập mô hình vì nếu có gì đó được thay đổi ở cấp mã thì mô hình sẽ tự động được cập nhật trên CVS cho toàn đội.

Nó hoạt động thực sự tốt và không cần thực sự biết UML vì sơ đồ lớp thực sự đơn giản và kỹ thuật đảo ngược sẽ thực hiện công việc và tạo chế độ xem đồ họa của mã. Điều hướng đơn giản, chế độ xem nâng cao và chi tiết trong đó có thể thêm nhiều bình luận với sơ đồ luôn cập nhật và hiển thị trực tiếp trên CVS trong dự án. Sơ đồ lớp UML của tôi bây giờ là Magic :-)