13

Trong Agile, mọi câu chuyện của người dùng phải được xác định rõ ràng về Tiêu chí hoàn thành hoặc chấp nhận. Có hai phần quan trọng trong khi xác định các tiêu chí Hoàn thành; một cái có chức năng và một cái khác là phi chức năng. Trong hầu hết các trường hợp, mọi người sẽ xác định các tiêu chí chấp nhận chức năng rất tốt và không quan trọng lắm đối với danh sách kiểm tra việc thực hiện phi chức năng.

Để đảm bảo chất lượng phần mềm ở mọi khía cạnh, tiêu chí hoàn thành cần đạt được từ cả khía cạnh chức năng và phi chức năng. Để đảm bảo các tiêu chí về việc hoàn thành phi chức năng cũng được quan tâm, chúng ta phải xác định danh sách kiểm tra và đảm bảo nó được tuân thủ cho tất cả các câu chuyện của người dùng.

Để đạt đến đỉnh cao của bạn cần rất nhiều kỷ luật. Nó không đến dễ dàng. Đạt được chất lượng phần mềm liên tục một lần nữa đi kèm với rất nhiều sự cống hiến và kỷ luật. Để có được kết quả mong muốn về chất lượng phần mềm mọi lúc, chúng ta phải tuân theo các quy trình một cách tôn giáo, xem xét lại và cải tiến liên tục.

Một trong những quy trình như vậy đã giúp chúng tôi là “danh sách kiểm tra Mức độ hoàn thành”. Chủ yếu là danh sách các phương pháp hay nhất mà chúng tôi đã học được và đồng ý tuân theo cho mọi câu chuyện của người dùng trong một bản phát hành.

Về cơ bản, nó chứa danh sách các mục bên dưới cho mỗi câu chuyện của người dùng và chúng tôi hy vọng chủ sở hữu câu chuyện của người dùng sẽ bắt buộc đăng xuất tất cả chúng.

  • Phân tích Yêu cầu - Hoàn thiện các tiêu chí chấp nhận
  • Thiết kế và đánh giá kỹ thuật
  • Đánh giá mã
  • Xem xét mối quan tâm xuyên suốt –caching, giao dịch, bảo mật
  • Thiết kế và đánh giá cơ sở dữ liệu
  • Đánh giá hiệu suất
  • Đánh giá bảo mật - xác thực XSS
  • Tập lệnh dữ liệu ban đầu / nâng cấp
  • Kiểm tra khả năng tiếp cận
  • Kiểm tra trình duyệt
  • Cập nhật số bản dựng

Tôi muốn xem xét các mục trong danh sách kiểm tra này là các yếu tố vệ sinh của thực tiễn phát triển phần mềm và chúng phải được tuân thủ mà không thất bại. Để đảm bảo chúng được theo dõi, tôi đề xuất hai phương pháp:

  • Tạo những thứ này làm nhiệm vụ cho mỗi câu chuyện của người dùng
  • Tạo tài liệu danh sách kiểm tra và đăng ký từ chủ sở hữu câu chuyện người dùng

Chúng tôi làm theo cả hai lựa chọn. Một số điều cơ bản, chẳng hạn như đánh giá, được tạo như một phần của danh sách nhiệm vụ của câu chuyện người dùng. Bằng cách này, chủ sở hữu câu chuyện người dùng phải hoàn thành các tác vụ này như một phần của câu chuyện người dùng. Truyện sẽ chỉ được chấp nhận nếu các nhiệm vụ này được hoàn thành.

Mặc dù nghe có vẻ có quá nhiều nhiệm vụ cho mỗi câu chuyện của người dùng, nhưng một danh sách kiểm tra rất hữu ích sẽ đảm bảo chất lượng của mỗi câu chuyện của người dùng.

Một số lợi ích với danh sách kiểm tra mức độ hoàn thành này như sau

Chất lượng mã

Đánh giá thiết kế

Chất lượng mã được đảm bảo bằng cách đảm bảo có thiết kế phù hợp cho mọi câu chuyện của người dùng. Trong Agile, một số người nghĩ rằng không cần tài liệu, nhưng đó chỉ là một huyền thoại. Chúng tôi phải thiết kế gia tăng cho mọi câu chuyện của người dùng và đảm bảo tạo sơ đồ nhanh cho họ. Nó không thực sự bắt buộc phải tạo một tài liệu thiết kế cấp thấp rất chi tiết. Nó có thể là một thiết kế bảng trắng động não được chụp lại và tải lên câu chuyện của người dùng. Điều này đạt được thông qua danh sách kiểm tra đánh giá thiết kế trong quy trình của chúng tôi. Mỗi câu chuyện của người dùng trong sprint sẽ chứa một nhiệm vụ đánh giá thiết kế.

Danh sách kiểm tra này sẽ đảm bảo tập trung vào thiết kế gia tăng cho từng câu chuyện của người dùng và cuối cùng là cho bản phát hành đầy đủ.

Đánh giá mã

Để đạt được chất lượng mã, điều quan trọng là phải thực hiện đánh giá mã nhóm kỹ thuật cho từng câu chuyện của người dùng. Trong bài đánh giá này, các mục dưới đây được xác nhận:

  1. Tiêu chuẩn mã hóa
  2. Các phương pháp hay nhất về bảo mật
  3. Thiết kế mạnh mẽ và được thực hiện theo thiết kế ban đầu
  4. Tất cả các quy tắc kinh doanh được thực hiện để đáp ứng các tiêu chí chấp nhận.
  5. Các trường hợp kiểm thử thích hợp được viết dựa trên mã do nhà phát triển viết

Có nhiều lợi ích khi thực hiện việc xem xét mã nhóm

  1. Chất lượng mã được cải thiện khi chúng tôi nhận được các quan điểm / ý tưởng khác nhau từ những người cấp cao đến cấp dưới trong nhóm.
  2. Thụ phấn chéo - Kiến thức về lĩnh vực và kiến ​​thức kỹ thuật được thụ phấn chéo giữa tất cả các thành viên trong nhóm. Đây là một quá trình rất quan trọng nếu nhóm đang làm việc về phát triển sản phẩm, vì nó giúp chia sẻ kiến ​​thức miền giữa các nhóm.
  3. QA sẽ có cơ hội xác thực các trường hợp thử nghiệm của họ dựa trên mã đã viết. Nó là một loại thảo luận thử nghiệm hộp trắng
  4. Không có nợ kỹ thuật

Điều quan trọng là phải xác thực một số mối quan tâm xuyên suốt như bộ nhớ đệm, bảo mật và Giao dịch được yêu cầu hay không như một phần của quá trình xem xét mã.

Đánh giá cơ sở dữ liệu

Là một phần của việc này, chúng tôi phải kiểm tra kỹ lưỡng các mục dưới đây

  • Lược đồ
  • Các phương pháp hay nhất về mã hóa cho thủ tục SQL Stored

Tập lệnh ban đầu / nâng cấp

Khi một tính năng được phát triển thì điều quan trọng là chúng ta cũng phải coi trọng dữ liệu. Dữ liệu được yêu cầu ban đầu trong bảng được gọi là tập lệnh dữ liệu ban đầu. Nếu tính năng đã được sản xuất và thay đổi tính năng mới yêu cầu thay đổi dữ liệu thì nó được gọi là tập lệnh dữ liệu nâng cấp.

Nếu những điều này không được chú ý trong quá trình phát triển và thử nghiệm, khả năng cao chúng tôi sẽ nhận được vé sản xuất.

Tất cả các môi trường thử nghiệm của chúng tôi phải tuân theo cùng một quy trình được sử dụng để triển khai sản xuất. Bằng cách này, các tập lệnh dữ liệu ban đầu / nâng cấp này cũng được kiểm tra kỹ lưỡng trong môi trường thử nghiệm của chúng tôi.

Cập nhật số bản dựng

Đây không phải là gì khác ngoài việc lập phiên bản. Điều quan trọng là đảm bảo thực hiện phiên bản phù hợp cho tất cả các tệp phía máy khách như tệp Javascript và CSS. Việc tạo phiên bản sẽ đảm bảo các tệp mới được tải xuống máy khách sau khi triển khai. Nếu không có phiên bản phù hợp, có khả năng các tệp đã lưu trong bộ nhớ cache cũ sẽ được phân phối cho khách hàng và kết thúc với các sự cố sản xuất. Đó là một trong những phương pháp hay được thực hiện như một phần của câu chuyện người dùng.

Tóm lại, danh sách kiểm tra Doneness rất hữu ích để xây dựng quy trình luôn đảm bảo chất lượng phần mềm. Đó là một lợi ích cho các nhóm phần mềm, đặc biệt là đối với phần mềm cấp doanh nghiệp và các nhóm lớn.

|