Tại sao chúng ta không thể làm gì?

Tôi làm việc trong một nhóm nhỏ, trong một công ty cỡ trung bình, hầu hết không tham gia phát triển phần mềm. Tôi là nhà phát triển mới nhất và ít kinh nghiệm nhất và không có kiến ​​thức chuyên môn hoặc học thuật về phần mềm trước khi bắt đầu, nhưng tôi khá hài lòng với sự tôn trọng đầu vào của tôi và rất biết ơn vì đã nghiêm túc trong giai đoạn đầu của sự nghiệp.

Tuy nhiên, tôi cảm thấy mình nên làm nhiều hơn với lượng thời gian phát sóng hào phóng này. Là một nhóm, chúng tôi dường như gặp khó khăn trong việc hoàn thành công việc. Tôi muốn có thể đề xuất một cái gì đó để cải thiện tình hình và tôi nghĩ rằng tôi sẽ được lắng nghe nếu đó là một ý tưởng tốt, nhưng tôi không biết phải đề xuất gì.

Những điều tôi có thể xác định là vấn đề bao gồm:

• Đặc điểm kỹ thuật của các nhiệm vụ trong tay là thưa thớt. Điều này một phần vì quản lý là một nút cổ chai và chúng tôi không có tiền hoặc mọi người cam kết thực hiện các yêu cầu chi tiết nhiều như chúng tôi muốn. Điều đó cũng một phần vì phần mềm chúng tôi đang phát triển là nghiên cứu và phương pháp chính xác không rõ ràng cho đến khi phần mềm được trình diễn và sử dụng để xác định tính hiệu quả của nó.
• Trưởng nhóm Dev rất thích cái mà anh ta gọi là 'nguyên mẫu' đến mức gần đây anh ta bắt đầu khăng khăng rằng mọi thứ đều là 'nguyên mẫu', mà phần còn lại của chúng tôi trông giống như viết mã xấu và đưa nó cho người điều hành để chơi. Không rõ những gì anh ấy mong đợi từ bài tập này trong nhiều trường hợp. Việc thực hiện 'thực tế' sau đó bị ảnh hưởng bởi vì ông nhấn mạnh rằng thực hành tốt mất quá nhiều thời gian từ việc tạo mẫu. Tôi thậm chí chưa bắt đầu có thể gỡ rối logic xoắn này và tôi không chắc mình muốn thử.
• Các nhà điều hành dự kiến ​​sẽ cho chúng tôi biết tất cả mọi thứ về phương pháp mong muốn một cách chi tiết chính xác, và người ta tin tưởng tuyệt đối rằng những gì họ đưa ra là hoàn hảo về mặt lý thuyết. Điều này hầu như không bao giờ đúng, nhưng không có hành động nào được thực hiện để khắc phục tình trạng này. Không ai ở phía người mẫu nêu lên bất kỳ mối quan tâm nào theo cách có cấu trúc có khả năng được hành động, họ cũng không tìm kiếm hướng dẫn trong việc áp dụng các thực tiễn tốt nhất. Không có gì được thực hiện về sự thụ động của họ.
• Tôi đã cố gắng thúc đẩy TDD trong đội trước đây, nhưng cảm thấy khó khăn vì nó mới đối với tôi và trong khi những người giám sát công việc của tôi sẵn sàng chịu đựng điều đó, không có sự nhiệt tình nào được đưa ra từ bất kỳ ai khác. Tôi không thể biện minh cho lượng thời gian tôi dành cho việc đắm mình và không hoàn thiện các tính năng, vì vậy ý ​​tưởng này - hiện tại - đã bị từ bỏ. Tôi lo ngại nó sẽ không được chọn lại, bởi vì không ai thích được nói về cách thực hiện công việc của họ.
• Bây giờ chúng tôi có một máy chủ tích hợp liên tục, nhưng nó hầu như chỉ được sử dụng để chạy thử nghiệm hồi quy nhiều giờ. Nó đã bị bỏ ngỏ rằng nó cũng nên chạy các bài kiểm tra đơn vị và tích hợp toàn diện, nhưng hiện tại không ai viết chúng.
• Mỗi lần tôi nêu vấn đề về chất lượng với nhà phát triển chính, tôi nhận được câu trả lời về tác dụng của 'Tính năng kiểm tra A rất đơn giản, tính năng B quan trọng hơn nhiều đối với người dùng nhưng quá khó để kiểm tra, do đó chúng tôi không nên kiểm tra tính năng A '. Một lần nữa, tôi đã không cố gắng gỡ rối logic này.

.... phew. Khi tôi nói nó như thế, nó trông tệ hơn tôi nghĩ. Tôi cho rằng, hóa ra, đây là tiếng kêu cứu.

Hãy để tôi chơi người ủng hộ của quỷ trong giây lát:

Đặc điểm kỹ thuật của các nhiệm vụ trong tay còn thưa thớt ... Người dẫn đầu rất thích những gì anh ta gọi là 'nguyên mẫu'

Các nhà phát triển chì rất thích tạo mẫu vì thông số kỹ thuật còn thưa thớt. Đây có lẽ là một điều tốt; đây là cách các cửa hàng lặp đi lặp lại làm việc

Các nhà điều hành dự kiến ​​sẽ cho chúng tôi biết mọi thứ về phương pháp mong muốn một cách chi tiết

Điều này sẽ không làm việc trong một cửa hàng lặp đi lặp lại. Bản chất của phát triển lặp là các yêu cầu thường không đầy đủ. Lặp đi lặp lại là những gì cần thiết để đưa ra các yêu cầu.

Tôi đã cố gắng đẩy TDD trong đội trước đây, nhưng cảm thấy khó khăn vì nó mới đối với tôi

Điều này cũng không hoạt động; bạn cần hiểu công nghệ trước khi bạn có thể truyền giáo nó. Hơn nữa, trong một cửa hàng lặp đi lặp lại với các yêu cầu ít ỏi, TDD có thể quá nhiều chi phí. Tốt hơn là khuyến khích bảo hiểm thử nghiệm đơn vị đầy đủ.

Bây giờ chúng tôi có một máy chủ tích hợp liên tục, nhưng nó hầu như chỉ được sử dụng để chạy thử nghiệm hồi quy nhiều giờ.

Điều đó có thể thích hợp trong một cửa hàng nhỏ, lặp đi lặp lại.

Mỗi lần tôi nêu vấn đề về chất lượng với nhà phát triển chính, tôi nhận được câu trả lời về tác dụng của 'Tính năng kiểm tra A rất đơn giản, tính năng B quan trọng hơn nhiều đối với người dùng nhưng quá khó để kiểm tra, do đó chúng tôi không nên kiểm tra tính năng Một '

Có vẻ như cửa hàng của bạn có một số hạn chế thời gian khá chặt chẽ; Dù muốn hay không, bạn bị ràng buộc bởi những ràng buộc đó.

Có vẻ như bạn đến từ một phần của ngành công nghiệp phần mềm, coi trọng việc thực hiện "đúng cách" hơn là đưa mọi thứ ra thị trường trước. Không có gì sai với điều đó (thực tế là đáng ngưỡng mộ), ngoại trừ việc người đầu tiên đưa ra thị trường với một phần mềm lỗi thường là người chiến thắng. Thật không công bằng, nhưng đó là như thế.

Tôi sẽ tập trung vào việc tạo mẫu ở đây

vấn đề chính với các nguyên mẫu là chúng có nghĩa là bằng chứng của khái niệm

tuy nhiên nếu bạn không thể xây dựng thêm trên nguyên mẫu và cần xây dựng lại sản phẩm cuối cùng từ đầu, bạn có thể không xây dựng nguyên mẫu và bạn đã lãng phí thời gian để xây dựng nó

Lời khuyên của tôi cho nhóm của bạn là có được một số chất lượng và tính linh hoạt trong các nguyên mẫu đó. Tôi biết lần đầu tiên không thể tạo ra những thứ hoàn hảo nhưng cố gắng duy trì khả năng mở rộng cho các yêu cầu trong tương lai

Đây là những câu trả lời tốt. Tôi chỉ có thể thêm rằng "cố gắng giao tiếp" tốt nhất là một đề xuất của iffy. Những thay đổi trong cách tổ chức hoạt động không diễn ra nhanh chóng. Khi nó xảy ra, nó thường giống như thủy triều, nơi động lượng xây dựng từ bên dưới và từ bên trên. Vì vậy, bạn sẽ hạnh phúc hơn nếu bạn giữ kỳ vọng của mình ở mức thấp và chờ cơ hội để nói mọi thứ sẽ được thực hiện như thế nào hoặc mong muốn được làm việc với một tổ chức khác.

Bạn đã xác định được ai đó ở công ty "hiểu rồi" nếu vậy, hãy bám lấy anh chàng này và học hỏi càng nhiều càng tốt từ anh ta. Nếu không, hãy dành thời gian của bạn, bắt đầu tự học và phát triển (tham gia dự án Nguồn mở hoặc bắt đầu dự án của riêng bạn) và tìm một nơi có thể thúc đẩy sự phát triển của bạn.

Điều tồi tệ nhất có thể xảy ra là bạn ở lại đó và học cách làm mọi thứ sai cách. Vâng, cần phải có một số chủ nghĩa thực dụng, nhưng một đội ngũ thực sự có kỹ năng có thể làm mọi thứ đúng cách và vẫn đúng giờ với một sản phẩm chất lượng. Có vẻ như nhóm hiện tại của bạn không có những gì nó cần và bạn nên bắt đầu tìm kiếm một nhóm mới.