Tôi phải làm gì khi trưởng nhóm của tôi phá vỡ lược đồ cơ sở dữ liệu của tôi với một bản phát hành sắp tới?


21

Trưởng nhóm của tôi có thói quen ghê tởm với lược đồ cơ sở dữ liệu và thực hiện các thay đổi sẽ gây ra sự phá vỡ nghiêm trọng trên cơ sở mã (mà không thực sự tư vấn cho tôi về cách các thay đổi sẽ ảnh hưởng đến cơ sở mã).

Thông thường, tôi sẽ chỉ sống với nó, nhưng chúng tôi có thời hạn trong 2 tuần và điều này đã xảy ra kể từ khi tôi bắt đầu 1 tháng rưỡi trước. Tôi đã được đưa vào, để tăng tốc độ phát triển của dự án.

Do thời hạn cuối cùng, tôi đã đặt hơn 60 giờ một tuần và không thực sự còn năng lượng để giải quyết vấn đề này (tôi đã thử một số cách rồi). Chúng tôi chỉ là một nhóm 2 người, và bên cạnh việc thay đổi cơ sở dữ liệu hàng ngày, anh ấy đã không đóng góp nhiều trong ý nghĩa phát triển thực tế (mã hóa).

Hiện tại, tôi cảm thấy như mình đang làm tất cả công việc, cộng với việc phải 'sửa chữa' những gì anh ấy phá vỡ với những thay đổi của mình.

Làm thế nào để một người đối phó với điều này? Tôi đã nói chuyện với người quản lý của chúng tôi về sự thiếu nỗ lực của anh ấy trong bộ phận phát triển. Anh ta đã ở đó lâu hơn tôi 6 tháng, nhưng tôi đã viết 95% mã khi bạn loại trừ sự quái dị của cơ sở dữ liệu mẫu thông thường thứ 5 mà anh ta 'đóng góp'.

Bất kỳ đề xuất?

Hậu kỳ:

Vào thứ sáu, chúng tôi đã có một cuộc thảo luận với người quản lý, và tôi đã biết những lo lắng của mình. Điều này dẫn đến một chút đối đầu, nhưng nhìn chung tôi cảm thấy người quản lý đang đứng về phía tôi. Vì vậy, ít nhất chúng ta đã đóng băng dữ liệu của mình ngay bây giờ, hãy xem cách nó đi từ đây.


3
+1 cho thẻ 'quá nhanh nhẹn'! :-) Agile là một phương pháp tuyệt vời, nhưng một số người lầm tưởng rằng họ nhanh nhẹn, khi họ đơn giản là vô kỷ luật.
Bill Karwin

2
Một ví dụ điển hình của thử nghiệm tự động có giá trị muối của nó. Anh ta thay đổi một cái bàn và 15 phút sau tiếng chuông và còi bắt đầu cho bạn biết tất cả mã đó đã bị hỏng.

Câu trả lời:


15

"Hạn chót là trong hai tuần; chúng tôi cần đóng băng lược đồ nếu chúng tôi sẽ đạt được nó."


3
Ok, bước 1, đóng băng cơ sở dữ liệu, bước 3 lợi nhuận! :) Hãy xem mọi thứ diễn ra như thế nào ...

1
Tôi đã chịu trách nhiệm mà không chịu trách nhiệm, bây giờ chúng tôi có một thành viên khác trong nhóm. Lời khuyên của bạn là câu trả lời cuối cùng cho thời gian. Chúng tôi vẫn nhìn chằm chằm vào đầu người hâm mộ trên ... :(

4

Nói chuyện với người quản lý VÀ nhà phát triển tại cùng một cuộc họp:

"Thay đổi cơ sở dữ liệu và mã cần xuất hiện đồng thời. Nếu bạn thay đổi cơ sở dữ liệu, bạn cũng phải thay đổi và kiểm tra cơ sở mã. Nếu không, bạn đang gửi các cam kết bị hỏng, không thể chấp nhận nếu chúng tôi đáp ứng thời hạn. Tôi sẽ không sửa mã nữa. bị phá vỡ bởi các cam kết của bạn, tôi chỉ đơn giản là sao lưu các thay đổi và để lại cho bạn một lưu ý email vì tôi không thể điều tra và khắc phục các sự cố bên ngoài công việc tôi được giao và vẫn mong đợi đáp ứng thời hạn. "

Khó hơn nhiều nếu bạn không có kế hoạch kiểm tra ...


Kế hoạch kiểm tra? Chúng tôi thậm chí không có một kế hoạch friggen! Chỉ là thông số kỹ thuật yêu cầu khách hàng thông thường, được viết bằng ngôn ngữ của khách hàng ... Và vâng, thật buồn khi bạn phải thực hiện một ghi chú đăng ký có nội dung: BUILD IS BROKEN.

2

Bạn sẽ phải mạnh mẽ hơn và đảm bảo rằng sớm (như ngày hôm qua, ngày hôm kia, hoặc tháng trước) bạn giải quyết một lược đồ và tiến về phía trước. Không có cách nào hợp lý để bạn có thể tiếp tục phát triển một ứng dụng với cơ sở dữ liệu là mục tiêu di động.


1

Bạn cần phải đối đầu với anh ta và giải thích cho anh ta về những thay đổi của anh ta đang ảnh hưởng đến cơ sở mã và do đó các dòng thời gian của dự án. Hãy thuyết phục anh ta rằng anh ta cần xem xét tác động của những thay đổi trước khi thực hiện chúng. Đồng thời khiến anh ấy đồng ý với sự có mặt của người quản lý của bạn với thực tế rằng anh ấy sẽ chịu trách nhiệm cho bất kỳ sự chậm trễ nào mà anh ấy gây ra bởi hành vi này


1

Nếu trưởng nhóm không phải là người hợp lý (và anh ấy / cô ấy không có vẻ hợp lý từ mô tả hành vi của anh ấy), hãy nói chuyện với người quản lý của bạn và giải thích với anh ấy rằng bạn sẽ không đáp ứng được thời hạn. Yêu cầu anh ta đứng lên và đảm bảo trưởng nhóm của bạn nhận thức được điều này bằng cách tổ chức một cuộc họp nơi người quản lý đặt kỳ vọng.

Bạn cũng nên thúc đẩy trường hợp của bạn liên quan đến việc thiếu trưởng nhóm của bạn để đóng góp cho sự phát triển. Cả hai vấn đề phải được giải quyết để làm cho dự án thành công.


Chúng tôi đã trải qua một cái gì đó như thế này, nhưng có vẻ như anh ấy không hiểu ... anh ấy nói anh ấy sẽ đóng góp, nhưng tôi đã không thấy gì cho đến nay, ngoại trừ thay đổi lược đồ. Tôi tự hỏi nếu anh ta thậm chí có thể viết mã, và không chỉ là "thiết kế".

Tại sao người quản lý để cho trưởng nhóm thoát khỏi điều này? Ai đã làm cho nhóm trưởng nhóm trưởng? Người quản lý của bạn không có tiếng nói trong việc này sao?

Tôi đoán người quản lý đang cố gắng giữ thể diện. Ít nhất tôi đã cảnh báo anh ta sớm, và hy vọng họ sẽ không đổ lỗi cho tôi vì sự chậm trễ.

1

Bạn sẽ phải thực thi một số hạn chế đối với đội của bạn, nhưng điều đó có thể là khó khăn để chơi ở vị trí của bạn trong đó.

Một cách hữu ích để giải quyết vấn đề này có thể được áp dụng kiểm soát thay đổi được ghi chép chặt chẽ hơn. Bạn có thể chơi điều này bằng cách nhấn mạnh rằng tại thời điểm các thay đổi đột xuất đang có nguy cơ khả năng quản lý các bản cập nhật hệ thống theo cách không lường trước được và hậu quả đe dọa đến hạn chót (đó là sự thật). Vì vậy, nhấn mạnh rằng tất cả các thay đổi phải đi kèm với tài liệu cho thấy sự thay đổi được đề xuất và các tác động của nó đối với tất cả các mã và cấu trúc khác. Bạn sẽ ngạc nhiên về mức độ sẽ làm giảm khối lượng thay đổi đi qua :-)


Một trong những người hỗ trợ CNTT khác đã khuyến nghị rằng :)

Hehe, đó là vì đó là sự thật - Tôi đã ở đó. Hầu hết các câu trả lời khác ở đây là các giải pháp kỹ thuật cho một lỗi hệ thống logic nhận thức. Trên thực tế những gì bạn có vấn đề về hành vi, vì vậy bạn cần thực hiện một hệ thống trừng phạt / khen thưởng để sửa đổi hành vi đó

1

Bạn đã tổ chức một hồi tưởng với nhóm? Nếu không, giữ một cái. Khi bạn thực hiện, xác định các thay đổi ngoài dự kiến ​​(mucking với) cho cơ sở dữ liệu là một vấn đề. Chỉ định chi phí cho bạn và những người khác về rủi ro và chất lượng cuộc sống công việc. Làm việc liên tục 60 giờ một tuần là không bền vững. Nếu bạn không thể duy trì tốc độ phát triển của mình, bạn không làm việc nhanh nhẹn.

Ngoài ra, bạn đang thực hiện TDD (phát triển theo hướng kiểm tra) hay kiểm tra chức năng / hồi quy tự động? Nếu vậy, thay đổi cơ sở dữ liệu sẽ dẫn đến các bài kiểm tra bị hỏng. Điều này sẽ giúp giải quyết tác động và xác định mã cần được cập nhật.

Trong trường hợp này, trưởng nhóm của bạn không " quá nhanh nhẹn ", trưởng nhóm của bạn là một " cao bồi nhanh nhẹn ". Giữ một hồi tưởng, xác định những gì đã sai. Ưu tiên nó cao, sau đó giải quyết nó trong lần lặp tiếp theo. Điều đó nên dây trong cao bồi nhanh nhẹn của bạn !!!


Tôi đã cố gắng và cố gắng. Tôi nghĩ rằng anh ấy hoàn toàn là một cao bồi BS'ng. Dù sao, tôi đang sống với nó.

0

Có một vấn đề tương tự với bạn khoảng một năm trước? ' Trưởng nhóm của tôi nói A.Property = A.Property; vẫn ổn '. Có vẻ như việc đốt cháy đã bị cấm vì tôi không thấy nó trong lịch sử bình luận của mình. Dù sao, vấn đề là:

Nếu bạn cảm thấy tất cả các nhà lãnh đạo nhóm của bạn đang làm phiền bạn chỉ có một nửa kinh nghiệm của bạn, có lẽ bạn sẽ tìm được một công việc không có ai . Tôi sẽ đề nghị dùng thử và trở thành người dẫn đầu như một lựa chọn khác, nếu bạn vẫn có khả năng, bạn đã được đề nghị làm như vậy.

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.