Thiết kế trong một nhóm, mã hóa trong một nhóm khác

Tôi sẽ tham gia vào một dự án trong đó tất cả các thiết kế phần mềm được thực hiện bởi một nhóm địa phương và những thiết kế này được gửi đến một nhóm ngoài khơi để mã hóa.

Đây là lần đầu tiên tôi phải đối mặt với một dự án có đặc điểm này và đối với tôi cảm giác thật kỳ quặc: Các nhà quản lý hy vọng chúng tôi sẽ tạo ra các tài liệu thiết kế rất chi tiết để không có chỗ cho lỗi cho đội ngoài khơi; từ quan điểm của tôi, họ đang làm cho chúng ta viết mã trên giấy trong khi chúng ta có thể làm điều đó trong một IDE.

Vì vậy, câu hỏi của tôi là cách tiếp cận này là tốt, hoặc đã được chứng minh phải không? Những cân nhắc chính mà quy trình phần mềm của chúng tôi phải có để thành công trong dự án của chúng tôi là gì?

Quan điểm của tôi:

Nếu tất cả những gì bạn sẽ cung cấp cho người nước ngoài là tài liệu và sơ đồ, bạn sẽ có rất nhiều thông tin sai lệch và thất vọng .

Đề nghị của tôi

• Đừng cung cấp cho họ quá nhiều tài liệu, mà thay vào đó là các giao diện và các lớp trừu tượng để sắp xếp chúng vào các mục tiêu thiết kế của bạn .

• Yêu cầu họ sử dụng một tiêu chuẩn đặt tên đã biết.

• Yêu cầu họ sử dụng các bài kiểm tra đơn vị.

• Gửi một trong những nhà thiết kế / kiến ​​trúc sư của bạn ra nước ngoài đến cơ sở của họ để giám sát quá trình, nó sẽ vẫn rẻ hơn so với mã hóa trong nhà, nhưng bạn sẽ nhận được kết quả tốt hơn.

Nó được gọi là Big Design Up Front, hay còn gọi là Thác nước. Nó không được coi là một phương pháp rất thành công. Nhưng tôi đã thấy nó hoạt động, và khi nó hoạt động, nó hoạt động rất tốt. Nó rất tốn kém để làm đúng.

Đó cũng là những gì nhà tuyển dụng của bạn đã yêu cầu bạn làm.

Các đội ngoài khơi không làm việc theo cách các đội trên bờ làm. Bạn phải rất, rất cụ thể về chính xác những gì bạn muốn, nếu không bạn sẽ không có được những gì bạn muốn.

Dự án cuối cùng tôi là nhà thiết kế phần mềm. Tất cả sự phát triển là ngoài khơi. Chúng tôi đã thành công. Vì vậy, quá trình này có thể làm việc.

Tôi đã tạo ra rất nhiều tài liệu nhưng không có nghĩa là toàn diện và không có nghĩa là hướng dẫn từng bước hoặc chi tiết đến tên lớp, tên hàm, v.v. sơ đồ, cũng như một tài liệu thiết kế chi tiết hơn khi cần thiết.

Nó thực sự phụ thuộc vào mức độ bạn tin tưởng phát triển ra nước ngoài. Tôi tin tưởng đội ngũ nước ngoài của tôi là nhà phát triển có thẩm quyền. Điều đó nói rằng, tôi đã cung cấp hướng tổng thể nhưng đã cho họ mất thời gian để thực hiện mà đội ngoài khơi thấy hài lòng. Trong quá khứ họ được quản lý vi mô nhiều hơn. Trong một số tình huống, tôi sẽ hướng dẫn họ sử dụng các mẫu thiết kế khi cần thiết. Tôi cũng thường xuyên thực hiện đánh giá và phân tích mã về mã họ đã viết và sẽ tư vấn tái cấu trúc hoặc làm sạch các nỗ lực. Ngoài ra, vì một số người trong nhóm gặp tai nạn với các phương tiện giải trí, tôi đã kết thúc việc mã hóa một số câu chuyện trong khi thực hiện vì cuối cùng chúng tôi bị thiếu một số tài nguyên.

Ngoài ra, tôi nghĩ rằng quá trình này thực sự chỉ thành công nhờ vào sức mạnh của (các) lãnh đạo kỹ thuật của bạn đối với dự án và sự giao tiếp giữa doanh nghiệp, nhà thiết kế, khách hàng tiềm năng và nhà phát triển. Chúng tôi đã dành rất nhiều thời gian để xem qua từng tính năng và câu chuyện và đảm bảo rằng các khách hàng tiềm năng / tài nguyên ở nước ngoài đã thành thạo với những yêu cầu đó. Nếu họ không đặt câu hỏi trong quá trình đánh giá tính năng / câu chuyện thì mong đợi một số vấn đề. Ngoài ra công việc không được coi là hoàn thành cho đến khi có tín hiệu kinh doanh. Vì vậy, điều đó khiến mọi người phải chịu trách nhiệm vì mọi thứ đều được theo dõi trong một công cụ quản lý sự phát triển nhanh.

Như một trong những câu trả lời khác đã được đề cập, quy trình phát triển bao gồm các tiêu chuẩn đặt tên (quy tắc chia sẻ lại được xây dựng), phạm vi kiểm tra trường hợp (nó sử dụng TDD, Mocking, v.v.) vì vậy nếu có quy trình và quy trình mã hóa tốt, nó sẽ tăng lên cơ hội của bạn cho một dự án thành công.

Chi phí chính của sự phát triển ra nước ngoài là truyền thông. Tài liệu là một cách giao tiếp, tuy nhiên, tài liệu không thể bao gồm tất cả các chi tiết và thay đổi tiềm năng thường.

Không chắc chắn dự án của bạn lớn như thế nào. Tôi cho rằng nó lớn nếu không nó không có giá trị để sử dụng nhóm phát triển ngoài khơi. Vì vậy, kinh nghiệm của tôi là

1. Xác định mã bộ xương, giao diện công cộng, giao diện dịch vụ, v.v. và cùng nhau xem xét
2. Xác định các bài kiểm tra chấp nhận với phía bên kia
3. Chia tài liệu lớn thành những câu chuyện nhỏ, làm việc dựa trên những câu chuyện nhỏ. Tài liệu lớn chỉ là một bức tranh lớn của toàn bộ hệ thống
4. Thiết lập các điểm kiểm tra của câu chuyện, một tuần hoặc hai tuần

1 và 2 thực sự là về sự phát triển, để đảm bảo phía bên kia hiểu rõ yêu cầu và cả hai bên đều sử dụng cùng một mô hình. 3 và 4 là một phần của phương pháp phát triển nhanh, nhưng đối với sự phát triển ngoài khơi, thật khó để sử dụng quy trình nhanh hoàn toàn.

Tôi nghĩ ở một mức độ nào đó tất cả chúng ta làm việc như vậy. Ai đó ở đâu đó thiết kế một cái gì đó và chúng tôi mã hóa một cái gì đó là một phần hoặc làm việc với hệ thống. Ví dụ đang xây dựng các ứng dụng dựa trên khung, giống như các ứng dụng không phải trò chơi trên thiết bị di động. Rất nhiều quyết định UI đã được đưa ra bởi đội ngũ thiết kế của những người xây dựng khung. Họ kiểm soát mọi thứ từ học viết một ứng dụng đến bán ứng dụng của bạn. Nếu bạn muốn xem tại sao mô hình này thành công, chỉ cần nhìn vào số lượng tài liệu và công cụ được cung cấp bởi một số nhà cung cấp.

Một ví dụ khác là các ứng dụng web có rất nhiều trong số chúng đang cố gắng thực hiện kiểu REST. Điều này không thực sự cho biết làm thế nào để thực hiện một cái gì đó, mặc dù khi có các thông số kỹ thuật về cách sử dụng HTTP. Dù sao, có thông số kỹ thuật và nguyên tắc hướng dẫn để làm theo. Nếu bạn thấy số lượng thảo luận về việc triển khai REST trên stackexchange hoặc tại nơi làm việc, thì giống như có một kiến ​​trúc sư bảo mọi người thực hiện một cái gì đó theo những cách nhất định. Tôi nghĩ đó vẫn là một mô hình thành công, với rất nhiều người theo phong cách này.

Từ hai ví dụ này, bạn có thể thấy cách thiết kế được truyền bá, một số như thông số kỹ thuật giấy, một số khác đi kèm với sách, công cụ và ví dụ. Bạn có thể thấy cách mọi người hỏi (về khối lượng), cố gắng hiểu đúng với các mức độ khác nhau tùy thuộc vào tiêu chuẩn / thiết kế nào họ đang cố gắng tuân theo. Chỉ cần vào stackoverflow và xem;)

Nếu bạn cho tôi đặc điểm kỹ thuật của bạn, tôi sẽ hỏi. Nếu bạn cho tôi kiểm tra đơn vị, tôi sẽ mã và kiểm tra.