Agile software development (Phần 2)

I. Whole-team approach (Phương pháp tiếp cận toàn đội)

Agile software development được xây dựng bởi đội gồm những người với nhiều mảng khác nhau. Thường bao gồm programming, testing, analysis, database và infrastructure cùng các thành phần khác. Tất cả lĩnh vực này là cần thiết để hoàn thiện sản phẩm trong các dự án Agile nhờ phương pháp tiếp cận toàn đội.

Một vấn đề trong các development lifecycle truyền thống là trách nhiệm, các action quan trọng thường xảy ra quá muộn hoặc quyền sở hữu các hoạt động này là không rõ ràng. Phương pháp tiếp cận toàn đội có thể giúp giải quyết vấn đề này. Sau đây là những lợi thế của cách tiếp cận này:

1. Ưu điểm 1: Làm cho chất lượng của dự án trở thành trách nhiệm chung của mọi người

Theo phương pháp phát triển phần mềm tuần tự truyền thống, vai trò của team được phân định rất rõ ràng. Thường hình thành ranh giới giữa các vai trò khác nhau trong đội. Điều này dẫn đến sản phẩm thường chuyển giao từ team này sang team khác, ví dụ như từ developer sang tester. Với điều này việc bàn giao sản phẩm cũng là bàn giao trách nhiệm. Vì vậy, trong trường hợp này, khi code được developer chuyển cho tester, giờ đây nó trở thành trách nhiệm của tester chứ không phải của developer. Khi tester tìm thấy lỗi trong phần mềm, sản phẩm được giao lại cho developer để được sửa chữa. Vì vậy, code một lần nữa bây giờ là trách nhiệm của developer

Tất cả hoạt động qua lại này có thể dễ dàng tạo ra sự phân chia trong đội phát triển phần mềm. Tester thường được coi là 'cảnh sát giám sát chất lượng'.

Agile Development tiếp cận việc tạo ra phần mềm theo cách khác. Nhanh chóng, kịp thời giao sản phẩm là trách nhiệm của cả team phát triển. Team Agile bao gồm tất cả các kỹ thuật cần thiết của các team phát triển phần mềm truyền thống. Tuy nhiên, bằng cách tạo ra một team có trách nhiệm chung về chất lượng và phân phối, những "bức tường" có thể phân chia các vai trò khác nhau được chia nhỏ và sự cộng tác trở thành một điều cần thiết. Do đó, các team Agile được cho là team 'đa chức năng' với nhiều vai trò khác nhau và các kỹ thuật chuyên ngành kết hợp với nhau trong một team duy nhất. Kết hợp tất cả các kỹ thuật cần thiết cùng nhau trong một team chức năng có nghĩa là dự án được hưởng lợi từ việc khai thác chuyên môn này. Trong Agile, toàn bộ team thực sự có thể to lớn hơn là từng các bộ phận.

2. Ưu điểm 2: Tăng cường giao tiếp và cộng tác trong team

Khi một team tham gia vào một dự án Agile, sự hợp tác là chìa khóa để thành công và là một thành phần cơ bản của phương pháp tiếp cận toàn đội. Hỗ trợ hợp tác chặt chẽ, các team Agile thường được đặt cùng vị trí. Mọi người chia sẻ cùng một không gian làm việc giúp cho việc tiếp xúc không chính thức trở nên đơn giản. Điều này được nâng cao khi khách hàng, hoặc đại diện khách hàng, cũng có mặt tại chỗ.

Các cuộc họp chính thức và tài liệu được giảm thiểu trong một dự án Agile, vì vậy tester, developer và các thành viên khác trong team phải giao tiếp liên tục. Một trong số các cách trong dự án Agile là stand-up meeting. Nó diễn ra hàng ngày, cuộc họp này có sự tham gia của cả team và để báo cáo trạng thái của công việc. Bằng cách sử dụng phương pháp đơn giản này, mỗi thành viên trong team được cập nhật về những gì những người khác đang làm. Tuy nhiên, daily meeting không loại trừ nhu cầu giao tiếp 1-1 của các thành viên trong team. Giao tiếp 1-1 giúp loại bỏ những trở ngại được nêu trong cuộc họp trực tiếp và đảm bảo đà dự án được duy trì.

Tuy nhiên, tester vẫn cần phải nói chuyện với đại diện khách hàng; và những người phân tích business có thể nói chuyện với các chuyên gia về trải nghiệm người dùng; các chuyên gia mạng có thể cần nói chuyện với các developer. Các kênh giao tiếp rất nhiều và đa dạng. Tất cả các cách giao tiếp này không chỉ giúp chia sẻ hiểu biết mà còn giúp chia sẻ trách nhiệm với sản phẩm đó. Các dự án Agile được hưởng lợi rất nhiều từ giao tiếp và cộng tác này.

Các dự án Agile cố tình khuyến khích cộng tác thông qua việc sử dụng các User Story, là những mô tả rất ngắn gọn về các tính năng của hệ thống. User story chỉ cung cấp đủ thông tin để cho phép lập kế hoạch và ước tính khối lượng công việc cần thực hiện nhưng không đủ để tính năng được phát triển và thử nghiệm. Để làm được điều này, cần phải nói chuyện với người từ phía doanh nghiệp, người đang đề xuất đặc tính. Chỉ họ, với tư cách là khách hàng hoặc đại diện khách hàng, biết chính xác cách tính năng sẽ hoạt động như thế nào, vì vậy cộng tác chặt chẽ với chúng sẽ hỗ trợ rất nhiều cho việc hiểu yêu cầu.

3. Ưu điểm 3: Cho phép các bộ kỹ thuật khác nhau trong team được tận dụng để mang lại lợi ích của dự án

Tester trong team Agile làm việc với đại diện khách hàng để làm acceptance test. Chỉ có đại diện của doanh nghiệp mới biết họ mong muốn chính xác hệ thống hoạt động như thế nào. Làm việc cùng với nhà tài trợ business, tester có thể hỗ trợ trong việc tạo các acceptance test để giúp team xác định khi nào một tính năng hệ thống hoàn thành hoặc done. Trong các dự án Agile, nhiều acceptance test được tự động hóa, vì vậy tester có trách nhiệm rất lớn là đảm bảo các yêu cầu tính năng từ đại diện khách hàng có thể kiểm tra được nhiều nhất có thể và có thể dễ dàng viết thành công cụ.

Là một phần trong vai trò của họ trong phương pháp tiếp cận toàn đội, tester cũng sẽ làm việc chặt chẽ với các developer. Tester có thể giúp các developer tạo các unit test tự động, nhưng đóng một vai trò lớn hơn nữa khi sử dụng tích hợp liên tục (CI) (xem Phần 1.2). Hàng ngày, hoặc thường xuyên hơn với các bản demo phần mềm được yêu cầu regression test. Đối với CI để có hiệu quả, các regression test phải được tự động hóa. Làm việc cùng nhau, các developer và tester có thể sử dụng các kỹ thuật của họ để tạo ra một bộ regression test tự động được sử dụng mỗi khi một bản demo hệ thống mới được tạo. Ngoài ra, bộ test phải có khả năng dễ dàng được sửa đổi và thêm vào khi chức năng mới được tích hợp và các test case mới tương ứng được yêu cầu.

Thông qua cộng tác với đại diện khách hàng, developer và tester có thể giúp chia sẻ kiến thức về test. Làm việc giữa các team làm tăng chia sẻ kiến ​​thức và tất cả các thành viên trong team hiểu rõ hơn về công việc của nhau. Một trong những hạn chế với các dự án phát triển phần mềm truyền thống là các developer và tester thường không có bất kỳ tương tác nào với khách hàng. Nhiều thông tin sản phẩm họ nhận được thông qua các tài liệu dự án hoặc từ các cuộc trò chuyện với các thành viên team phát triển khác, chẳng hạn như các nhà phân tích business. Khuyến khích tester và developer cộng tác trực tiếp với khách hàng hoặc đại diện khách hàng có nghĩa là các tính năng của hệ thống được hiểu rõ hơn nhiều so với trường hợp khác.

Crispin và Gregory đã đề xuất sử dụng 'Power of Three' cho các tương tác team như vậy. Bất kỳ cuộc họp hoặc cuộc thảo luận nào về tính năng phải có sự tham gia của đại diện khách hàng, developer và một tester. Sự hiện diện của cả ba vai trò trong các cuộc thảo luận mang lại sự chia sẻ, sự rõ ràng và hiểu biết về các tính năng hệ thống trong team.

II. Phản hồi sớm và thường xuyên

Trong các dự án phát triển tuần tự, chu kỳ phát triển có thể dài và khách hàng tham gia vào quá trình có thể bị hạn chế, hầu hết các phản hồi đến muộn trong quá trình. Agile Development được hưởng lợi từ phản hồi sớm và thường xuyên từ khách hàng.

1. Lợi ích 1: Tránh hiểu nhầm các yêu cầu mà có thể chưa được phát hiện cho đến cuối chu kỳ phát triển khi chúng nên sẽ tốn kém hơn để sửa chữa.

Trong các dự án phần mềm sử dụng các phương pháp truyền thống, khách hàng tham gia rất nhiều vào giai đoạn đầu của quá trình trong quá trình nắm bắt và xác định các yêu cầu. Một khi khách hàng đã ký tên vào tài liệu yêu cầu, đầu vào chính tiếp theo mà họ có thể có ở giai đoạn sau của quá trình thử nghiệm sản phẩm khi đã quá muộn để khắc phục những hiểu lầm hoặc hiểu sai về yêu cầu. Nó cũng rất tốn kém để thay đổi ở giai đoạn này, vì số lượng công việc làm lại có thể là đáng kể. Khách hàng liên tục tham gia dẫn đến phản hồi sớm và thường xuyên giúp loại bỏ các yêu cầu mơ hồ.

2. Lợi ích 2: Làm rõ các yêu cầu về tính năng của khách hàng và cung cấp chúng cho khách hàng sử dụng sớm. Bằng cách này, sản phẩm phản ánh tốt hơn những gì khách hàng muốn.

Các dự án Agile sử dụng các vòng lặp ngắn trong chu kỳ phát triển. Trong chu trình ngắn, tìm hiểu các tính năng, thiết kế, code và testing sẽ diễn ra. Vào cuối chu kỳ, team sẽ tạo ra một "sản phẩm khả thi tối thiểu" (minimum viable product - MVP). Sản phầm chứa một phần các tính năng hệ thống được đề xuất, nhưng đủ để cho phép phản hồi có ý nghĩa được thu thập từ những người dùng ban đầu của sản phẩm. Mỗi lần lặp lại phát triển tiếp theo sau đó thêm vào sản phẩm cho đến khi, cuối cùng, toàn bộ hệ thống đã hoàn tất. Các đại diện business trong dự án hỗ trợ ưu tiên tính năng, dẫn đến các tính năng quan trọng nhất, những tính năng có giá trị business cao nhất, được phát triển trước tiên. Điều này cũng làm giảm rủi ro hệ thống, như chúng ta luôn biết rằng làm việc trên các phần của hệ thống có giá trị khách hàng lớn nhất.

3. Lợi ích 3: Tìm ra, tách biệt và giải quyết sớm vấn đề về chất lượng.

Những dự án sử dụng các phương pháp tiếp cận phát triển phần mềm tuần tự thực hiện tích hợp test vào cuối vòng đời phát triển. Bất kỳ vấn đề tích hợp nào, hoặc các vấn đề về giao diện hệ thống, chỉ trở nên rõ ràng vào cuối quá trình và có thể là một vấn đề chính đau đầu để sửa chữa. Sử dụng CI, các dự án Agile được hưởng lợi từ thực tế là bất kỳ vấn đề tích hợp nào được đánh dấu ngay lập tức, các mô-đun liên quan có thể được tách ra trong khi chờ sửa chữa và hệ thống có thể được quay trở lại phiên bản làm việc trước đó. Khi sửa chữa được thực hiện, mô-đun sau đó có thể được tích hợp lại vào hệ thống và kiểm tra lại. Vấn đề chất lượng được khắc phục sớm trước khi có thêm các lỗi hệ thống.

4. Lợi ích 4: Cung cấp thông tin cho team Agile về năng suất và khả năng release.

Phản hồi sớm và thường xuyên từ khách hàng cung cấp hiểu biết cho team Agile về năng suất của nó. Mỗi tính năng được ước tính và ưu tiên trước khi phát triển và sau đó được xây dựng trong vòng lặp phát triển. Khi tính năng vượt qua các acceptance test, nó có thể được phân loại là "done". Quá trình này cho phép team Agile đo lường mức độ sản phẩm nó có thể release mỗi lần lặp lại. Quy trình như vậy cho phép Agile team của đo năng suất hoặc 'tốc độ' và hỗ trợ rất nhiều cho việc ước tính và phát hành sau đó lập kế hoạch.

Ngoài ra, team Agile có thể thấy điều gì đang cản trở năng suất và tiến độ của họ, cho phép họ thực hiện hành động khắc phục hậu quả.

5. Lợi ích 5: Thúc đẩy đà phát triển của dự án.

Tinh thần của team dự án được cải thiện nhờ khả năng hiển thị của tiến độ. Đi sớm và thường xuyên phản hồi từ khách hàng làm cho tất cả các bên gắn kết hơn. Làm hài lòng khách hàng là phần thưởng to lớn cho team Agile.

Nguồn tham khảo:

• https://devqa.io/whole-team-approach-agile-testing/