Cắt xén ngăn xếp phát triển - theo đường chéo?


11

Chúng tôi đã có một dự án mới đang diễn ra và hiện tại các nhà phát triển đã được chia thành hai nhóm, nhóm A và nhóm B. Dự án này có 2 phần để yêu cầu phát triển trong toàn bộ quá trình phát triển. Mẫu rất đơn giản của ngăn xếp của chúng tôi được hiển thị dưới đây:

nhập mô tả hình ảnh ở đây

Mỗi phần của dự án đòi hỏi sự phát triển trên toàn bộ ngăn xếp, vì vậy tôi thường mong đợi một cách tiếp cận nhà phát triển ngăn xếp đầy đủ, đó là cách chúng tôi đã chia nhỏ công việc của mình trong nhóm B, thiết kế và xử lý các tương tác giữa các phần khác nhau.

nhập mô tả hình ảnh ở đây

Tuy nhiên, gần đây tôi đã biết rằng nhóm A muốn phụ trách một số phần nhất định của ngăn xếp và họ đang đề xuất sự phân chia giữa hai nhóm, trong đó Lớp Trừu tượng dữ liệu (và đưa nội dung vào lớp Dữ liệu) được xử lý bởi bản thân họ không có sự phát triển nào từ Đội B. Sự phân chia sẽ trông giống như điều này:

nhập mô tả hình ảnh ở đây

Đối với tôi điều này cảm thấy rất không tự nhiên. Mỗi đội có các mục tiêu và thời gian khác nhau để đạt được những mục tiêu này, nhưng Đội B sẽ có sự phụ thuộc vào Đội A để thực hiện các tính năng. Giải pháp đề xuất là các giao diện phổ biến được xác định từ trước (có thể có thời gian 2 năm trong dự án để chúng có thể có rất nhiều). Đội A sau đó sẽ sớm phát triển các bit cần thiết cho các giao diện này mặc dù đã có mục tiêu riêng, trong khi Đội B vẫn loại bỏ tất cả các cuộc gọi trong thời gian ngắn để chúng có thể tiến triển.

Tôi lo ngại về phương pháp này liên quan đến:

  • Các giao diện có thể thay đổi và Đội A có thể không có băng thông hoặc thời gian để đáp ứng các yêu cầu thay đổi.
  • Lỗi trong mã của Đội A có thể ngăn chặn tiến trình của Đội B và một lần nữa, chúng có thể không phải là ưu tiên để khắc phục những điều này do Đội A có hàng đợi ưu tiên khác.
  • Thiếu kiến ​​thức trải rộng trên các đội - Đội B có thể không hiểu đầy đủ những gì diễn ra dưới mui xe và có thể đưa ra quyết định thiết kế kém vì điều này.

Có ý kiến ​​cho rằng nhiều công ty trong ngành có các nhóm phụ và phải có khả năng xử lý việc này. Theo hiểu biết của tôi, thông thường các đội sẽ phân chia cách tôi dự kiến ​​ban đầu (Full Stack) hoặc bằng cách phá vỡ ngăn xếp công nghệ như dưới đây:

nhập mô tả hình ảnh ở đây

Vì vậy, tôi quan tâm đến việc biết phần còn lại của ngành công nghiệp đang làm gì. Có phải hầu hết các phân chia dọc / ngang? Liệu một đường chéo chia có ý nghĩa? Nếu xảy ra sự phân chia đường chéo, mối quan tâm của tôi có vẻ hợp lệ và có điều gì khác mà Đội B nên quan tâm không? Lưu ý rằng có lẽ tôi sẽ chịu trách nhiệm cho sự thành công hay thất bại của Đội B.


10
"Phần còn lại của ngành công nghiệp" có lẽ đang thực hiện mọi sự kết hợp chia tách mà bạn có thể nghĩ ra. Nhưng thành thật mà nói, bạn đã không cho chúng tôi biết lý do tại sao đội A muốn chịu trách nhiệm. Và nó làm cho một sự khác biệt lớn như thế nào các đội của bạn lớn, và nếu họ có trình độ như nhau.
Doc Brown

Trong hình minh họa thứ ba của bạn, công việc của Đội A và Đội B có được phân tách bằng một API riêng biệt không? Có một ranh giới rõ ràng, hợp lý được áp đặt bởi đường phân chia đó? Phân công lao động không hẳn là một điều mới; Stack Exchange có nhà thiết kế riêng của họ, ví dụ.
Robert Harvey

@DocBrown Tôi tin rằng Đội A muốn chịu trách nhiệm vì họ cảm thấy như 'quá nhiều đầu bếp làm hỏng nước dùng' sau thất bại dự án trước đó với một đội lớn hơn - nhưng tôi thực sự không biết chắc chắn. Mỗi đội có khoảng 5 Dev, và có kỹ năng tương đương nhau.
Ian

1
Nếu bạn không thành công trong việc thuyết phục họ phân chia theo chiều dọc, bạn có thể muốn Nhóm A cam kết xử lý các yêu cầu của Đội B với mức độ ưu tiên cao hơn như các yêu cầu của riêng họ. Điều này có thể ngăn chặn và máu xấu, và có vẻ như một cái giá phải trả.
Hans-Peter Störr

1
@hstoerr: Điều thú vị là đây chính xác là những gì liên minh scrum đề xuất Một nhóm thành phần tiêu thụ (nhóm thành phần sử dụng hoặc "tiêu thụ" các sản phẩm của các nhóm thành phần khác) đóng vai trò là chủ sở hữu sản phẩm của nhóm sản xuất. lấy từ scrumalliance.org/community/articles/2012/september/ trộm
Ian

Câu trả lời:


12

Mối quan tâm của bạn là vô cùng hợp lệ. Đặc biệt là hai điểm đầu tiên về Đội A không có thời gian để thêm các tính năng hoặc sửa các lỗi ảnh hưởng đến Đội B. Tôi đã thấy điều này xảy ra trong công việc của mình khá nhiều lần.

Đây có thể là một ý tưởng tốt nếu:

  • Được biết, Đội A sẽ làm việc với các dự án yêu cầu các tính năng mới trong cơ sở dữ liệu, trong khi mục tiêu của Đội B về cơ bản là thực hiện các tính năng "chỉ có lối vào". Chẳng hạn, nếu Đội B đang viết ứng dụng iPhone mới của công ty bạn, có khả năng họ sẽ không thêm các trường cơ sở dữ liệu mới trong một thời gian, vì họ cần chuyển / thực hiện lại tất cả các tính năng của phiên bản máy tính để bàn.

  • "Ngăn xếp đầy đủ" đã trở nên đủ phức tạp để không một nhà phát triển (hoặc nhóm phát triển) nào có thể "sở hữu" toàn bộ mọi thứ một cách hiệu quả. Bằng cách "sở hữu" tôi có nghĩa là không chỉ thêm các tính năng và sửa lỗi, mà còn hiểu và quan tâm đến toàn bộ hệ thống đến mức họ có thể tránh thêm nợ kỹ thuật cho nó theo thời gian. Trong trường hợp này, phân chia "đường chéo" là bước đi hợp lý nếu Nhóm A sở hữu API UI / Web cực kỳ đơn giản hoặc không thể tránh khỏi được kết hợp chặt chẽ với triển khai cơ sở dữ liệu DAL / (có lẽ là một số công cụ chẩn đoán nội bộ?), Trong khi Đội B thực hiện tất cả các công cụ frontend phức tạp đối mặt với người dùng.

  • Ban quản lý hiểu nguy cơ Đội A trở thành nút cổ chai và sẽ sẵn sàng hủy bỏ mọi thứ nếu hoặc khi rủi ro này biến thành vấn đề thực sự.

Tôi không thể nói với những gì phổ biến hơn hoặc ít hơn trong ngành, nhưng ít nhất là nơi tôi làm việc, có một nhu cầu rõ ràng cho tất cả các nhà phát triển ứng dụng là "toàn bộ". Những gì chúng tôi có là các nhóm "cơ sở hạ tầng" phát triển / duy trì cơ sở dữ liệu nội bộ, khung dịch vụ web và khung UI của chúng tôi (tôi có đề cập đến công ty của tôi rất lớn không?), Để tất cả hàng trăm ứng dụng của chúng tôi có thể có đầy đủ Các nhà phát triển trong khi toàn bộ công ty vẫn có thể cung cấp hiệu suất và giao diện người dùng nhất quán cho tất cả các dịch vụ của chúng tôi.

Gần đây, công ty chúng tôi đã tạo ra một khung UI hoàn toàn mới, vì vậy đã có một khoảng thời gian một số ứng dụng mới của chúng tôi bị chặn khá nặng về các lỗi và thiếu các tính năng trong khung mới. Đây không còn là vấn đề nữa, chủ yếu là do một số người trong chúng tôi đã được phép gửi yêu cầu kéo cho nhóm sở hữu khung (không hoàn toàn "khử chéo", nhưng bạn hiểu ý).


2
Về điểm thứ hai của bạn, điều này có vẻ đúng với bất kỳ ứng dụng kinh doanh có quy mô hợp lý nào. Các thư viện có API được xác định rõ dường như là ranh giới logic, miễn là chúng không quá lớn.
Robert Harvey
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.