Sprinting làm chậm phát triển phần mềm - Cách tốt hơn để xây dựng sản phẩm

Sprinting làm chậm phát triển phần mềm: Cách tốt hơn để xây dựng sản phẩm

Các sprint phần mềm đã trở thành chuẩn mực trong ngành công nghệ. Trong những ngành cạnh tranh, các công ty cảm thấy áp lực lớn phải ra mắt sản phẩm và tính năng trước đối thủ. Hạn chót hai tuần là phổ biến, với đội ngũ lập trình viên chia công việc theo kiểu dây chuyền và chạy đua theo ngày ra mắt cố định.

Nhưng liệu đây có phải là cách tốt nhất để phát triển sản phẩm?

Tôi đã điều hành một công ty phần mềm 12 năm qua, trước đó học kỹ thuật phần mềm và nhận bằng Tiến sĩ Khoa học Máy tính về Hệ thống Lập trình. Mặc dù sprint, scrum và các phương pháp hiện đại có giá trị, chúng không phải là cách chúng tôi xây dựng phần mềm tại Everlaw ngày nay.

Sprint hứa hẹn tăng tốc phát triển nhưng thực tế thường ngược lại. Áp lực liên tục và bản chất không thỏa mãn của sprint khiến lập trình viên kiệt sức và nghỉ việc. Dù kinh tế không ổn định, chưa đến một nửa lập trình viên nói họ hài lòng với công việc hiện tại.

Phương pháp chúng tôi sử dụng cho phép kỹ sư xây dựng chức năng đúng cách, mà không áp đặt hạn chót. Nó ưu tiên các nhóm nhỏ có quyền tự chủ thiết kế toàn bộ tính năng, không chỉ một phần. Đồng thời, quan trọng là không hứa hẹn ngày phát hành phần mềm mới cho khách hàng. Kết quả cuối cùng là năng suất cao hơn: nhiều tính năng được ra mắt trên cùng đơn vị thời gian.

Tôi khuyến khích bạn xem xét cách tiếp cận này thay vì mặc định theo chuẩn mực ngành có thể dẫn đến nợ kỹ thuật cao và tỷ lệ lập trình viên nghỉ việc lớn.

Sprinting làm bạn chậm lại

Hạn chót ảnh hưởng khác với phát triển phần mềm so với các lĩnh vực khác. Sprint có thể gây hậu quả tiêu cực lâu dài, khiến lập trình viên viết code chất lượng kém, tầm nhìn hạn chế để kịp tiến độ. Điều này dẫn đến code kém, quyết định kỹ thuật tốn kém sửa sau này, và lập trình viên thất vọng.

Mặc dù lúc nào cũng tưởng sprint giúp hoàn thành nhanh, thực tế sprint khiến phần mềm mới được phát triển ít hơn theo thời gian do tác động tiêu cực tích lũy.

Sprint tưởng như di chuyển nhanh nhất, nhưng trong phát triển phần mềm, bạn thường zig-zag giữa các vấn đề ưu tiên cao, sửa lỗi trước đó do áp lực hạn chót.

Nếu đi thẳng, bạn có thể đạt được nhiều hơn và bớt mệt mỏi.

Hạn chót phần mềm ưu tiên tốc độ hơn chất lượng

Nhiều lãnh đạo nhìn phần mềm như các bộ phận khác, với nhịp điệu hoạt động dựa trên hạn chót. Giống như marketing phải ra chiến dịch trước ngày 31/10, kế toán phải đóng sổ, đội kỹ sư phải ra sản phẩm mới đúng hạn.

Nhưng phát triển phần mềm khác biệt cơ bản, hạn chót thường không phù hợp. Ba lý do chính:

1. Công việc trong codebase lớn, phức tạp.
2. Tiêu chuẩn chính xác (correctness) cao hơn nhiều lĩnh vực khác.
3. Hậu quả của quyết định tốt hay xấu cộng dồn theo thời gian.

Codebase phức tạp

Khó dự đoán thời gian thực hiện chức năng mới vì hiếm khi làm việc độc lập. Tính năng mới được thêm vào codebase hiện có, các chi tiết về bảo mật, hiệu năng và bảo trì thường chỉ lộ ra khi viết code.

Code phụ thuộc lẫn nhau, thêm chức năng mới thường cần viết lại code khác. Hạn chót tạo áp lực: kỹ sư phải viết spaghetti code, code giòn, dù biết cách đúng.

Tiêu chuẩn cao về correctness

Khác với marketing, trong code, bất kỳ sai lệch nào đều là defect. Deadline đẩy nhiều bug vào production, tốn nhiều thời gian sửa và ít thời gian xây dựng chức năng mới.

Quyết định tồi cộng dồn

Hậu quả của quyết định kỹ thuật tồi tích lũy theo thời gian. Code mới phụ thuộc code cũ, kiến trúc kém sẽ làm khó thêm tính năng mới sau này. Sprint hôm nay có thể giúp ra tính năng nhanh, nhưng làm chậm phát triển về lâu dài.

Nhóm lớn, vấn đề lớn

Khi deadline, thường giao nhiều kỹ sư. Nhưng nhóm lớn gặp hai vấn đề: giao tiếp nhiều và code phân tán. Mỗi kỹ sư làm phần riêng, mất nhiều thời gian phối hợp, chất lượng giảm. Code tốt cần tối ưu toàn cục, điều khó với nhóm lớn.

Giải pháp: Bỏ hạn chót, thu nhỏ nhóm

1. Bỏ hạn chót: Kỹ sư quyết định khi nào tính năng sẵn sàng. Họ đưa ra quyết định kỹ thuật nguyên tắc, code tốt hơn.
2. Nhóm nhỏ: Nhóm nhỏ (thường 1 người) sở hữu toàn bộ tính năng từ back-end đến front-end. Không cần daily standup, giảm giao tiếp thừa. Code toàn diện, quyết định kỹ thuật nguyên tắc, triển khai đồng bộ.

Kết quả: mặc dù mỗi dự án mất nhiều thời gian hơn, năng suất tổng thể cao hơn: nhiều dự án song song, ít bug, ít nợ kỹ thuật, code chất lượng cao.

Kỹ sư hạnh phúc hơn: không phải chữa lỗi do deadline, hợp tác tự do, học hỏi liên tục.

Giữ khách hàng hài lòng

• Kỹ sư thích ship code, sở hữu tính năng nên động lực cao.
• Họ hiểu việc ra phần mềm chất lượng là lợi thế cạnh tranh, thưởng cho người làm tốt.
• Lãnh đạo kiểm tra tiến độ hàng tuần, không áp hạn chót, bảo vệ chất lượng.

Chúng tôi không cam kết giao tính năng vào ngày cố định. Khách hài lòng vì phần mềm chất lượng, nhiều tính năng ra mắt hơn đối thủ. Chia sẻ roadmap để khách góp ý, nhưng nếu khách yêu cầu hạn chót cứng, chúng tôi từ chối để bảo vệ chất lượng.

Chiến lược dài hạn thắng cuộc

Mô hình tập trung kết quả dài hạn, không phù hợp mọi doanh nghiệp. Startup giai đoạn đầu cần thử nghiệm nhanh để tìm product-market fit. Khi đạt fit, mục tiêu chuyển từ thử nghiệm sang thực thi: xây dựng nhanh và hiệu quả. Mô hình này phù hợp với họ.

Bộ ba vàng phát triển phần mềm: kỹ sư hạnh phúc, code chất lượng, nhiều tính năng hữu ích. Kiểm soát chất lượng thúc đẩy throughput, lợi ích cho doanh nghiệp và người dùng.

Khám phá thêm

Nếu bạn thấy bài viết này hữu ích, bạn có thể tham khảo thêm các dịch vụ và nền tảng của chúng tôi:

• MyTeam: đội lập trình freelancer chuyên nghiệp, sẵn sàng hỗ trợ các dự án công nghệ của bạn từ A-Z.
• Hệ thống tiếp thị liên kết: nền tảng giúp bạn tạo thu nhập thụ động từ marketing liên kết dễ dàng và hiệu quả.