Giới thiệu

Trong bài viết trước (Lộ Trình Kỹ Thuật Chất lượng Toàn Diện), chúng tôi đã trình bày một lộ trình năm giai đoạn để xây dựng chất lượng cho phần mềm. Chúng tôi đã lập luận rằng bạn không thể kiểm tra để có một sản phẩm tuyệt vời, bởi vì chất lượng cần phải được xây dựng từ gốc. Bây giờ, chúng ta sẽ bắt đầu xây dựng nền tảng đó.

Bài viết này không chỉ là một cuộc thảo luận triết lý. Đây là một hướng dẫn thực tế cho Giai đoạn 1: Văn hóa, Vai trò và Tư duy. Chúng tôi sẽ phân tích từng nguyên tắc cơ bản và cung cấp cho bạn một khung rõ ràng về nó, tại sao nó là một phần không thể thương lượng của thành công, và cách bạn có thể thực hiện nó với đội ngũ của mình ngay hôm nay.

Định nghĩa chung về "Chất lượng"

• NÓ là gì: Một định nghĩa chung về chất lượng là một thỏa thuận rõ ràng, rõ ràng giữa toàn bộ đội ngũ (sản phẩm, thiết kế, phát triển và QA) về các thuộc tính cụ thể làm cho sản phẩm của bạn "tốt". Đây là một sự đồng thuận về mục tiêu mà tất cả các bạn đang hướng đến.

• TẠI SAO nó quan trọng: Nếu không có một định nghĩa chung, mọi người sẽ hoạt động dựa trên giả định. Một lập trình viên có thể định nghĩa chất lượng là "mã không có lỗi, hiệu suất tốt". Một quản lý sản phẩm có thể thấy nó như "giao hàng các tính năng đáp ứng mục tiêu kinh doanh". Khi những định nghĩa này va chạm, bạn sẽ có sự hỗn loạn và một sản phẩm không xuất sắc ở bất kỳ lĩnh vực nào. Một định nghĩa chung sẽ căn chỉnh nỗ lực của mọi người hướng tới cùng một kết quả.

• LÀM THẾ NÀO để tạo ra nó: Tổ chức một hội thảo "Định nghĩa Chất lượng". Tập hợp tất cả mọi người lại và đặt những câu hỏi sâu sắc:

  • Đối với khách hàng của chúng ta, chất lượng cảm giác như thế nào? Là tốc độ? Độ tin cậy? Độ dễ sử dụng? An ninh?
  • Ai là đối thủ cạnh tranh chính của chúng ta và tiêu chuẩn chất lượng của họ là gì? Chúng ta phải tốt hơn ở đâu?
  • Ghi lại kết quả. Liệt kê 3-5 thuộc tính hàng đầu mà sản phẩm của bạn phải có và đăng chúng một cách rõ ràng cho toàn bộ đội ngũ.

Chất lượng là Trách nhiệm Của Mọi Người

• NÓ là gì: Đây là nguyên tắc rằng chất lượng không phải là công việc của một bộ phận duy nhất ("đội QA"). Thay vào đó, nó là một năng lực cốt lõi và là trách nhiệm hàng ngày của từng người tham gia vào việc xây dựng sản phẩm.

• TẠI SAO nó quan trọng: Khi chất lượng chỉ nằm trong một bộ phận, nó trở thành một cánh cửa ở cuối quy trình. Điều này tạo ra một tâm lý "chúng ta chống lại họ", nơi mà các lập trình viên "ném mã qua tường" cho QA để "bắt lỗi". Điều này cực kỳ không hiệu quả, vì các vấn đề được phát hiện quá muộn. Trách nhiệm chung khiến chất lượng trở thành một hoạt động liên tục, không chỉ là một cuộc kiểm tra cuối cùng.

• LÀM THẾ NÀO để thực hiện nó:

  • Tích hợp chất lượng vào các nghi thức. Trong quá trình lập kế hoạch sprint, hãy hỏi "Làm thế nào chúng ta có thể đảm bảo rằng câu chuyện này có chất lượng cao?" không chỉ là "Mất bao lâu?"
  • Loại bỏ cột "Sẵn sàng cho QA". Đối xử với chất lượng như một cuộc trò chuyện liên tục nơi mà lập trình viên và QA hợp tác trong suốt quá trình phát triển một tính năng.
  • Chia sẻ các chỉ số chất lượng với tất cả mọi người. Làm cho số lượng lỗi, dữ liệu hiệu suất và thời gian hoạt động trở nên rõ ràng cho toàn bộ đội ngũ. Những gì được đo lường và nhìn thấy sẽ được cải thiện.

An toàn Tâm lý

• NÓ là gì: An toàn tâm lý là một niềm tin chung rằng các thành viên trong đội có thể thực hiện những rủi ro giao tiếp mà không sợ bị trừng phạt hoặc xấu hổ. Đó là sự tự tin để nói lên, đặt câu hỏi, thừa nhận sai lầm, hoặc thách thức tình trạng hiện tại.

• TẠI SAO nó quan trọng: Đây là nền tảng của một văn hóa lành mạnh. Nếu không có nó, bạn chỉ đang đánh cược. Các thành viên trong đội sẽ giấu diếm sai lầm và giữ im lặng về những rủi ro. Sự im lặng này là nơi mà các lỗi, lỗ hổng bảo mật và các quyết định kiến trúc kém xuất hiện. An toàn tâm lý biến sự im lặng thành thông tin quý giá.

• LÀM THẾ NÀO để xây dựng nó: Đây chủ yếu là trách nhiệm của người lãnh đạo.

  • Mô phỏng sự dễ bị tổn thương. Thừa nhận những sai lầm của bản thân. "Tôi đã sai về giả định đó" là một trong những điều mạnh mẽ nhất mà một người lãnh đạo có thể nói.
  • Đối xử với các câu hỏi như một món quà. Khi ai đó đặt câu hỏi "ngớ ngẩn", hãy cảm ơn họ. Có thể những người khác cũng có cùng câu hỏi nhưng sợ hỏi.
  • Tập trung vào quy trình, không phải con người. Khi một sai lầm xảy ra, hãy hỏi "Làm thế nào chúng ta có thể ngăn chặn điều này trong tương lai?" không phải "Tại sao bạn lại làm điều đó?"

Sự Chấp thuận của Lãnh đạo Hiện Hữu

• NÓ là gì: Đây là bằng chứng cụ thể, nhất quán từ lãnh đạo rằng chất lượng là một ưu tiên hàng đầu của doanh nghiệp, không chỉ là một câu nói. Nó là hành động, không chỉ là lời nói.

• TẠI SAO nó quan trọng: Các đội lấy tín hiệu từ lãnh đạo. Nếu một lãnh đạo nói rằng chất lượng là quan trọng nhưng sau đó liên tục thúc giục đội cắt bớt để đáp ứng thời hạn, thông điệp là rõ ràng - tốc độ quan trọng hơn. Sự chấp thuận rõ ràng sẽ trao quyền cho các đội làm điều đúng đắn.

• LÀM THẾ NÀO để phát hiện (và thực hiện):

  • Ngân sách: Các lãnh đạo sẽ phân bổ thời gian và tiền để giải quyết nợ kỹ thuật. Họ phê duyệt việc mua sắm các công cụ và đào tạo tốt hơn.
  • Ưu tiên: Khi một lỗi nghiêm trọng được phát hiện, họ ưu tiên sửa chữa nó hơn là bắt đầu tính năng mới.
  • Tăng cường: Họ công khai khen ngợi các đội vì một bản phát hành mượt mà, chất lượng cao, không chỉ vì giao hàng một tính năng nhanh chóng. Họ hỗ trợ quyết định của QA khi một rủi ro nghiêm trọng được phát hiện.

Cuộc họp Cải tiến Không Tố cáo

• NÓ là gì: Một cuộc họp có cấu trúc sau một sự cố (như một sự cố sản xuất) nơi toàn bộ sự chú ý tập trung vào việc hiểu nguyên nhân hệ thống và cải thiện quy trình. Tố cáo không bao giờ là mục tiêu.

• TẠI SAO nó quan trọng: Một văn hóa tố cáo kích thích việc giấu diếm sự thật. Nếu mọi người sợ bị trừng phạt, họ sẽ không bao giờ hoàn toàn minh bạch về những gì đã xảy ra. Sự không tố cáo tạo ra một môi trường mà đội có thể phân tích một thất bại một cách trung thực để tìm ra nguyên nhân gốc rễ và đảm bảo rằng nó không xảy ra lần nữa.

• LÀM THẾ NÀO để tổ chức nó:

  • Có một người điều phối trung lập. Công việc của người này là giữ cho cuộc trò chuyện tập trung vào quy trình.
  • Hãy hỏi "làm thế nào", không phải "ai". Câu hỏi hướng dẫn luôn là, "Quy trình của chúng ta đã cho phép điều này xảy ra như thế nào?"
  • Tập trung vào cải tiến hệ thống có thể thực hiện. Đầu ra nên là những thứ như "Thêm một kiểm tra CI mới" hoặc "Cải thiện hướng dẫn triển khai của chúng ta", không phải "Dave cần cẩn thận hơn".

Định nghĩa Vai trò của QA: Từ Cửa ngăn đến Huấn luyện viên

• NÓ là gì: Sự tiến hóa của một chuyên gia Đảm bảo Chất lượng từ một "người tìm lỗi" ở cuối quy trình đến một "huấn luyện viên chất lượng" và người ủng hộ được nhúng trong đội từ rất sớm.

• TẠI SAO nó quan trọng: Tìm lỗi muộn là tốn kém. Mô hình cửa ngăn tạo ra các nút thắt và một mối quan hệ cạnh tranh. Mô hình huấn luyện ngăn chặn toàn bộ các loại lỗi không bao giờ được viết bằng cách làm rõ yêu cầu và xác định rủi ro ngay từ đầu. Nó là chủ động, không phải phản ứng.

• LÀM THẾ NÀO để chuyển đổi:

  • Đưa QA vào phòng ngay từ đầu. QA phải tham gia vào lập kế hoạch ban đầu và các buổi "Ba Người Bạn" để đặt ra những câu hỏi sâu sắc trước khi một dòng mã được viết.
  • Tập trung vào việc tạo điều kiện. Công việc của QA là giúp lập trình viên kiểm tra tốt hơn bằng cách ủng hộ các thực hành tốt nhất, duy trì cơ sở hạ tầng kiểm tra và hợp tác với họ.
  • Thay đổi các chỉ số. Thành công không phải là "lỗi được tìm thấy." Mà là "ngăn chặn lỗi" và "tăng cường sự tự tin của đội trong việc phát hành".

Định nghĩa Vai trò của Lập trình viên: Quyền sở hữu thực sự

• NÓ là gì: Đây là nguyên tắc rằng lập trình viên là những người sở hữu chính chất lượng của mã của họ. Vai trò của QA là một sự hợp tác, không phải là một mạng lưới an toàn cho công việc kém.

• TẠI SAO nó quan trọng: Người viết mã có nhiều bối cảnh nhất để xây dựng chất lượng từ đầu. Dựa vào một kiểm tra bên ngoài tạo ra sự phân tán trách nhiệm. Khi các lập trình viên sở hữu chất lượng, họ viết mã bền vững, dễ bảo trì và được kiểm tra tốt hơn.

• LÀM THẾ NÀO để thúc đẩy nó:

  • Vượt qua các bài kiểm tra đơn vị. Quyền sở hữu bao gồm việc viết nhật ký tốt, xem xét các trường hợp biên và đảm bảo mã sạch và dễ bảo trì.
  • Triển khai Kiểm tra Cặp. Để một lập trình viên và QA cùng kiểm tra một tính năng. Điều này xây dựng sự đồng cảm và tạo ra một phản hồi tức thì mạnh mẽ.
  • Làm cho chất lượng trở thành một phần của các bài đánh giá mã. Các bài đánh giá nên kiểm tra nhiều hơn chỉ là phong cách. Chúng nên đặt câu hỏi "Chức năng này có bền vững không? Có được kiểm tra tốt không?"

Hiểu Biết Sâu về Tình huống

• NÓ là gì: Điều này có nghĩa là QA không chỉ là một chuyên gia trong các kỹ thuật kiểm tra, mà còn là một chuyên gia sâu trong lĩnh vực kinh doanh, các tính năng của sản phẩm, và các vấn đề của khách hàng. Họ là "keo" giữa kinh doanh và công nghệ.

• TẠI SAO nó quan trọng: Bạn không thể kiểm tra những gì bạn không hiểu. Kiến thức sâu về miền cho phép QA xác định các rủi ro mà các lập trình viên hoặc chủ sở hữu sản phẩm có thể bỏ lỡ. Họ có thể thiết kế các bài kiểm tra mô phỏng việc sử dụng thực tế, không chỉ là độ chính xác kỹ thuật.

• LÀM THẾ NÀO để phát triển nó:

  • Luôn luôn tò mò. Nghiên cứu các điểm đau lớn nhất của người dùng cho các sản phẩm tương tự.
  • Đặt câu hỏi "tại sao" năm lần. Hiểu nhu cầu kinh doanh gốc đằng sau mỗi tính năng.
  • Trở thành người dùng. Sử dụng sản phẩm của bạn thường xuyên, cố gắng đạt được cùng một mục tiêu mà khách hàng của bạn đang thực hiện.

Thiết lập Quyền Lực Bình Đẳng

• NÓ là gì: Điều này có nghĩa là tiếng nói và phán đoán chuyên nghiệp của QA về các vấn đề rủi ro chất lượng mang cùng trọng lượng như tiếng nói của lập trình viên về việc thực hiện kỹ thuật. Đây là một sự hợp tác bình đẳng.

• TẠI SAO nó quan trọng: Nếu có sự mất cân bằng quyền lực, các mối quan tâm về chất lượng sẽ luôn bị áp đảo bởi áp lực giao hàng. QA trở thành "em trai nhỏ" mà những cảnh báo của họ bị phớt lờ. Điều này dẫn đến một văn hóa nơi mà các rủi ro đã biết được chấp nhận và giao hàng. Quyền lực bình đẳng đảm bảo một quy trình ra quyết định cân bằng.

• LÀM THẾ NÀO để đạt được nó:

  • Về mặt cấu trúc: QA nên báo cáo qua cùng một chuỗi quản lý như phát triển, không phải như một chức năng phụ thuộc.
  • Trong thực tiễn: Trong các cuộc họp, các lãnh đạo phải công khai dành thời gian và trọng số nói chuyện cho quan điểm của QA. Một lập trình viên không nên có thể hợp nhất mã nếu QA đã nêu lên một mối quan tâm hợp lệ và chưa được giải quyết.

Kết luận: Nền Tảng Đã Được Thiết Lập

Kỹ thuật Chất lượng là một tư duy, không phải là một vai trò. Bằng cách thiết lập nền tảng văn hóa này, bạn không còn coi chất lượng là một tai nạn mà bắt đầu xây dựng nó theo thiết kế.

Với nền tảng văn hóa vững chắc này, bạn không còn đoán về chất lượng - bạn đã sẵn sàng để thiết kế nó. Bước tiếp theo là thực hiện "Các Chiến lược Chủ động cho Thành công Trước Phát triển - Yêu cầu, Câu chuyện & Lập kế hoạch" để ngăn chặn lỗi trước khi một dòng mã được viết.