Gần đây tôi đã suy nghĩ rất nhiều về cách xây dựng một nhóm phát triển tinh gọn. Cuối cùng, tôi muốn mở ra ngôi nhà phần mềm nhỏ của riêng mình với một số ít người có cùng chí hướng. Mục tiêu sẽ không trở nên giàu có, mà là có một môi trường làm việc lành mạnh.
Cho đến nay, tôi đang xác định một nhóm nạc như sau:
- Nhỏ;
- Tự tổ chức;
- Tất cả các thành viên phải có QA trong tâm trí;
- Thành viên phải có khả năng thực hiện nhiều vai trò
Điểm cuối cùng là nơi tôi lo lắng một chút bởi vì, khi câu thần chú diễn ra ...
Các nhà phát triển làm cho người kiểm tra xấu.
Mặc dù tôi hiểu rằng, thông thường, các nhà phát triển "quá gần" với mã của họ hoặc mã của đồng nghiệp của họ để đưa ra các đánh giá chất lượng cao hơn, tôi không tin rằng họ là những người kiểm tra thực tế tồi. Ngược lại, tôi cho rằng phẩm chất của một nhà phát triển giỏi trùng lặp rất lớn với phẩm chất của một người thử nghiệm giỏi.
Giả sử điều này là chính xác, tôi đã nghĩ đến nhiều cách khác nhau để giải quyết vấn đề dev / người kiểm tra và tôi tin rằng tôi đã đưa ra một mô hình khả thi.
Mô hình của tôi yêu cầu:
- Một ngôi nhà phần mềm nhỏ với hơn 2 dự án
- Một cách tiếp cận Agile (lặp đi lặp lại) để phát triển và phân phối
- 1 đội mỗi dự án
- Tất cả các thành viên trong nhóm sẽ là Nhà phát triển phần mềm
- Mô tả công việc của họ sẽ nêu rõ trách nhiệm Phát triển , Đảm bảo Chất lượng , Thử nghiệm và Giao hàng là trách nhiệm
Nếu tất cả các điều kiện tiên quyết đã được đáp ứng, thì các dự án có thể được tổ chức theo kiểu sau (ví dụ này sẽ đề cập đến hai dự án, A và B ):
- Mỗi thành viên trong nhóm sẽ luân phiên giữa vai trò Nhà phát triển và vai trò Người kiểm tra
- Nếu một thành viên trong nhóm là Nhà phát triển của dự án A , họ sẽ là Người kiểm tra dự án B
- Các thành viên sẽ chỉ làm việc trên 1 dự án tại một thời điểm và do đó được dự kiến sẽ đóng vai trò là Dev hoặc Tester.
- Một chu kỳ vai trò bao gồm 3 lần lặp là Dev và 2 lần lặp là Người kiểm tra (một lần nữa, trên hai dự án khác nhau)
- Các nhóm dự án sẽ có 3 Dev và 2 Testers mọi lúc.
- Chu kỳ vai trò thành viên nên lệch pha 1 lần lặp.
- Điều này giảm thiểu sự đột ngột của những thay đổi của đội. Đối với mỗi lần lặp, 2 Dev và 1 Tester sẽ giữ nguyên như lần lặp trước.
Đưa ra những điều trên, tôi thấy những ưu và nhược điểm sau:
Ưu
- Phân phối kiến thức dự án trong toàn công ty.
- Đảm bảo các thành viên trong nhóm không kiểm tra mã họ đã viết.
- Chu kỳ vai trò ngoài pha có nghĩa là không có dự án nào có chuyển đổi thành viên 100%.
- Vai trò xen kẽ phá vỡ sự đơn điệu của các dự án nhàm chán.
Nhược điểm
- Lặp đi lặp lại của cả hai dự án được liên kết chặt chẽ. Nếu một dự án hủy bỏ một nửa vòng lặp và bắt đầu lại, thì hai dự án sẽ không đồng bộ. Điều này sẽ làm cho chu kỳ vai trò khó quản lý.
- Bản lề về việc tuyển dụng Các nhà phát triển mở làm việc như Người thử nghiệm.
Tôi đã nhận được nhiều ý kiến trái chiều khi thảo luận về phương pháp này với bạn bè và đồng nghiệp. Một số người tin rằng rất ít nhà phát triển muốn thay thế vai trò như thế này, trong khi những người khác nói với tôi rằng cá nhân họ rất thích thử nó.
Vì vậy, câu hỏi của tôi là: một mô hình như vậy có thể làm việc trong thực tế? Nếu không, nó có thể được điều chỉnh thành một mô hình làm việc không?
Lưu ý: Vì lợi ích của sự ngắn gọn, tôi chỉ tập trung vào vai trò Dev và Tester. Tôi sẽ mở rộng vai trò khác nếu cần.