A team that can’t ship, can’t learn

Có hai câu hỏi cần làm rõ khi xem xét quy trình làm phần mềm:

–      Liệu phần mềm có thể xuất bản?, và

–      Chúng ta có nên xuất bản chưa?

Câu hỏi đầu tiên liên quan đến việc ra quyết định. Liệu có thực sự ý nghĩa đưa ra các tính năng phần mềm mới nhất.

Người quản lý sản phẩm (Product Manager) sẽ là người ra quyết định. Tuy nhiên, thực tế câu hỏi trên lại mang tính kỹ thuật nhiều hơn. Có thể diễn đạt câu hỏi theo một cách khác là: Liệu phần mềm đã hoạt động ổn định để có thể sẵn sàng cung cấp cho người dùng.

Chúng ta có luôn đủ tự tin rằng phần mềm hoạt động ổn đinh mà không phát sinh bất kỳ vấn đề trong môi trường Production? Mục tiêu của đội ngũ kỹ thuật đó là đảm bảo câu trả lời “YES” cho vấn đề này. Có một câu nói là: “A team that can’t ship, can’t learn”, áp dụng vào quy trình làm phần mềm thì tạm hiểu là đội ngũ hay còn gọi là một team làm phần mềm không tạo ra được sản phẩm, thì không thể học hỏi được. Lẽ tất nhiên khi bạn không học, bạn không có nhiều kiến thức dẫn đến rủi ro trong việc mất thời gian cho những tiếp cận không tối ưu hoặc không đúng đắn.

Sự kết hợp dưới đây khả dĩ để đội ngũ kỹ thuật luôn có câu trả lời “YES” cho câu hỏi đề cập:

–      Ngữ cảnh

–      Tích hợp liên tục

Vậy ngữ cảnh là gì? Nó là đặc tả về việc người dùng tương tác với hệ thống. Là phần nhỏ nhất truyền tải thông điệp và giá trị đến người dùng. Nên biết rằng các tính năng mô tả ở đây phải có giá trị đối với người dùng. Nó không phải là phần mêm demo hay thử nghiệm. Đấy là hệ phần mềm hoạt động thực tế.

Lượng không quá quan trọng, đủ mà chất lượng mới là thứ yếu 

Bạn có nghĩ rằng phần mềm tốt nhất được xây dựng thông qua một quá trình tìm hiểu và học tập, đòi hỏi việc liên tục đưa sản phẩm đến người dùng để họ trải nghiệm và phản hổi, từ đó hoàn thiện sản phẩm.

Hãy xem xét hai đồ thị dưới đây, giả sử mỗi đồ thị là biểu diễn cho hoạt động của 1 team, bạn sẽ chọn team nào trong số 2 team dưới đây:

Dễ thấy rằng đồ thị đầu biểu thị rằng team đi rất nhanh về lúc đầu nhưng càng về sau tốc độ chậm lại và gần như duy trì ở mức rất thấp, ở đồ thị thứ hai tốc độ tăng đều theo chiều đi lên – đương nhiên đây là biểu thị tốt. Có nhiều vấn đề với đồ thị đầu tiên, nhưng điều tối quan trọng nhất đó là: Bad Code.

Ở mọi thời điểm bạn có thể kiểm thử nếu đoạn code chạy – hoặc các tính năng của sản phẩm hoạt động đúng như mong đợi.

Với team lớn, với nhiều tasks quản lý song song việc đồng bộ là một bài toán khó.

Đấy là lý do phải có CI hay con gọi là Liên tục Tích hợp: từng thành viên có thể commit code, hệ thống CI sẽ tự động lấy code, và build. Các lỗi hoặc cảnh báo trong toàn bộ quá trình sẽ được thông báo đến cả team.

Quá trình hoạt tất không có vấn đề, bạn tin rằng đã sẵn sàn để xuất bản phần mềm. Đây là thời điểm PM phải đưa ra quyết định là việc xuất bản là khả thi hay chưa.

Một số PM thậm chí tự động hóa việc ra quyết định trong quy trình của CI luôn. Câu trả lời mặc định có thể là: “Ship on green”, nghĩa là có thể xuất bản khi không có lỗi.

Sâu hơn nữa, chúng ta có thể tự động phần triển khai code vào hệ thống Production khi CI đang có trạng thái “green”. Hay còn gọi là CD – Continous Deployment – Tự động Triển khai. Tất nhiên trên thực tế, việc xuất bản luôn luôn mang trách nhiệm sống còn đối với doanh nghiệp.

Cái gọi là “Ship on green” không thể áp dụng một cách đại trà, cũng không phủ nh

ận trách nhiệm và quyền quyết định của team kỹ thuật.

Trên hết PM phải có trách nhiệm và hiểu biết về các tính năng trên hệ thống thực tế cũng như phản ứng của người dùng. Từ đó đưa ra thứ tự ưu tiên những tasks có thể thực hiện tự động trong quy trình CI/CD. Chúng ta sẽ thấy được ý nghĩa của CI/CA cũng như vai trò chính của quy trình.