Agile Software Development

I. Quy trình phát triển phần mềm Agile

1. Khái niệm

Agile là một cách tiếp cận lặp đi lặp lại và tăng dần để phát triển phần mềm được thực hiện một cách rất nhuần nhuyễn, có tính hợp tác cao giữa các đội dự án, có sự ưu tiên trong thực hiện nhu cầu sẽ giúp các giải pháp sản xuất có chất lượng cao với chi phí hiệu quả và kịp thời, đáp ứng các nhu cầu của các bên liên quan của nó.

Để xác định xem một team đang tham gia tiếp cận xử lý quy trình agile:

• Chất lượng: Kiểm thử theo mô hình phát triển hồi quy
• Sự tham gia của các bên liên quan: là các bên chủ chốt tham gia tích cực vào sự phát triển của dự án
• Các giải pháp tiêu thụ: là đội sản xuất chất lượng cao, đưa ra các giải pháp tiêu thụ 1 cách thường xuyên.
• Tự tổ chức: được đánh giá cao trong khả năng tự tổ chức, hợp tác trong khuôn khổ
• Cải thiện: có khả năng tự cải thiện trong suốt quá trình làm dự án

2. Vòng đời vận chuyển của Agile

Để thực sự hiểu các chiến lược kiểm thử và chất lượng của Agile bạn phải hiểu cách chúng phù hợp với vòng đời phát triển hệ thống Agile tổng thể (SDLC). Hình 1 mô tả 1 cái nhìn cao cấp về vòng đời phát triển Agile, cho thấy rằng các giai đoạn xây dựng dự án, Agile được tổ chức thành 1 seri các box thời gian được gọi là lặp lại (trong phương pháp Scrum họ gọi chúng là "Sprints" và một số người gọi chúng là chu kỳ). Mặc dù nhiều người nói rằng vòng đời của Agile là lặp đi lặp lại là không hoàn toàn đúng, có thể thấy vòng đời của nó nối tiếp trong lớn và lặp lại trong nhỏ. Về phía cạnh thứ tự thì ít nhất có vài thành phần trong vòng đời vận chuyển (ý tưởng, xây dựng và vận chuyển) có thể thay đổi. Điều này ám chỉ công việc validation/testing của bạn sẽ dựa trên việc bạn đang ở phase nào của vòng đời. Theo đó điều quan trọng cần hiểu rõ các thành phần của các hoạt động high level diễn ra trong vòng đời này:

• Ý tưởng (Inception): Mục tiêu của giai đoạn này là khởi động đội dự án. Bạn sẽ thực hiện hình dung yêu cầu ban đầu (requirements ), hình dung cấu trúc hệ thống, bắt đầu xác định và tổ chức đội ngũ phát triển đến việc thiết lập các mục tiêu ganh đua, sự hỗ trợ và tài trợ cho dự án. Hoạt động thử nghiệm / xác nhận bao gồm việc bắt đầu để thiết lập môi trường thử nghiệm và các công cụ cũng như khả năng xem xét các mô hình ban đầu, kế hoạch, tài liệu và các mục tiêu tầm nhìn hoặc các bên liên quan.

• Xây dựng lặp (Construction iterations): Mỗi lần xây dựng lặp lại (lặp lại từ 1 cho đến n lần như trong hình 1) mục tiêu là để việc sản xuất phần mềm hiệu quả hơn. Agile team sẽ thực hiện theo thứ tự ưu tiên: mỗi lần lặp họ sẽ thực hiện những yêu cầu quan trọng nhất từ danh sách hàng đợi (cái mà Scrum gọi là tồn đọng). Agile team sẽ tiếp cận tới toàn bộ đội ngũ, nơi mà kiểm thử được kết hợp xen kẽ với phát triển và xây dựng hệ thống. Trọng tâm của kiểm thử hiệu quả là họ sử dụng kiểm thử hồi quy và Test-Driven Development (TDD).

• Vận chuyển (Transition): mục tiêu của giai đoạn này (màu xanh đậm trong hình 1) là: để triển khai thành công hệ thống vào sản xuất. Điều này có thể khá phức tạp trong thực tế, bao gồm đào tạo người dùng cuối, hỗ trợ người sử dụng, và các hoạt động sử dụng, truyền thông, tiếp thị sản phẩm, sao lưu phục hồi tiềm năng, thí điểm tổ chức triển khai hệ thống, hoàn thiện giao diện người dùng và tài liệu hướng dẫn. Trong suốt quá trình phát hành vẫn sử dụng kiểm thử để đảm bảo hệ thống sẵn sàng cho sản xuất.

                                            Hình 1
  

Hình 2: Mô tả sơ lược về Agile/ vòng đời cơ bản bằng Disciplined Agile Delivery (DAD). DAD không phải là quy tắc mà nó hỗ trợ 1 chu kỳ sống. Trong hình 2 là dựa trên DAD của Scrum, vòng đời vận chuyển Agile nhưng nó cũng hỗ trợ 1 vìa loại lean/Kaban của vòng đời vận chuyển liên tục rất tốt. Ý tưởng của nhóm bạn là cần phải thông qua vòng đời để làm tốt nhất những tình huống mà bạn cần đói mặt, với bài viết này tôi mặc định chấp nhận 1 cái gì đó tương tự như hình 2.

                                       Hình 2

3. Vòng đời phát triển hệ thống truyền thống

Hình 3 Mô tả cho mô hình phát triển phần mềm chữ V, cơ bản là 1 hình thức tinh vi của mô hình thác nước truyền thống. Với mô hình chữ V các công việc ở bên trái sơ đồ được xác nhận sau đó trong vòng đời các hoạt động được thông qua tương ứng (ví dụ yêu cầu được xác nhận thông qua kiểm thử chấp nhận, các cấu trúc được đi qua kiểm thử tích hợp, ...). Mặc dù phương pháp này tốt hơn so với không được test, nhưng nó được chứng minh là rất tốn kém trong thực tế vì một số vấn đề mang tính hệ thống:

• Cung cấp sai chức năng (Deliver the wrong functionality): Các mô hình chữ V thúc đẩy cách tiếp cận các yêu cầu được quy định chi tiết sớm trong dự án. Mặc dù đây có thể là phương pháp tốt, nhưng trogn thực tế nó lại chứng minh nó rất nghèo nàn để làm việc. Những yêu cầu lớn phía trước, BRUF, phương pháp tiếp cận nđó dẫn đến kết quả lãng phí đáng kể vì lúc tốt nhất các nhóm dự án sẽ xây dựng một cái gì đó cho đặc điểm kỹ thuật thay vì một cái mà các bên liên quan thực sự cần.

• Thiết kế mỏng manh (Build to a fragile design): Tương tự như trên mặc dù trên lý thuyết nó có thể là 1 ý tưởng tốt để thông qua suy nghĩ các chi tiết của kiến trúc/ thiết kế, nhưng trong thực tế các quyết định kỹ thuật là được đưa ra quá sớm khi bạn có ít thông tin có sẵn.

• Khó khăn trong việc chữa thiếu xót (Hand-offs inject defects): Mỗi lần có sự mâu thuẫn giữa 2 nhóm người sẽ dẫn đến sự cố sẽ được đưa vào các sản phẩm. Mặc dù vấn đề này có thể được giảm nhẹ một phần qua đánh giá.

• Sửa các khuyết điểm là tốn kém (Fixing defects is expensive): Mô hình chữ V thường kéo dài chu kỳ phản hồi, dẫn tới việc sửa chữa khuyết điểm bị kéo dài theo => tăng chi phí sửa chữa khuyết điểm.

• Tăng thời gian tới giá trị (Increased time to value): Các mô hình chữ V kéo dài khoảng thời gian, thông qua gia tăng sự quan liêu và thời gian chờ đợi sản xuất. Điều này sẽ làm giảm những lợi ích cơ hội và giá trị hiện tại ròng (NPV) do được release sớm.

                                  Hình 3

4. Agile khác biệt như thế nào?

Những tester chuyên nguyệp khi chuyển sang phong cách phát triển agile có thể nhận thấy 1 số đặc điểm phát triển rất khác biệt so với gì họ đã từng làm:

• Hợp tác tốt hơn (Greater collaboration): Nhân viên phát triển Agile làm việc chặt chẽ với nhau, ưu giao tiếp trực tiếp thông qua các tài liệu trao đổi qua lại với nhau. Họ nhận ra tài liệu là cách thức hiệu quả nhất của giao tiếp giữa con người.

• Chu kỳ làm việc ngắn hơn (Shorter work cycle): Thời gian xác định giữa một yêu cầu cụ thể và xác nhận yêu cầu hiện thời là vào thứ tự của phút, không phải vài tháng hoặc nhiều năm, do áp dụng các thử nghiệm điều khiển phát triển (TDD), phương pháp tiếp cận, hợp tác tốt hơn, và ít phụ thuộc hơn vào tài liệu hướng dẫn tạm thời.

• Agilists nắm lấy thay đổi (Agilists embrace change): Quy trình phát triển Agile lựa chọn để sửa chữa các yêu cầu như một chồng ưu tiên được phép thay đổi trong suốt vòng đời. Một yêu cầu thay đổi là một lợi thế cạnh tranh nếu bạn có thể thực hiện nó.

• Linh hoạt hơn (Greater flexibility): Sau mỗi giai đoạn phát triển phần mềm được đưa ra để test luôn, mỗi cuối ngày độ dự án Agile lại họp lại nhằm trao đổi công việc dẫn đến việc yêu cầu luôn được cập nhật liên tục, các bugs được phát hiện sớm và fix sớm.

• Kỷ luật hơn là yêu cầu của CNTT (Greater discipline is required of IT): Rất dễ dàng để nói rằng bạn sẽ làm việc chặt chẽ với các bên liên quan của bạn, tôn trọng quyết định của mình, sản xuất phần mềm có khả năng thay đổi một cách thường xuyên, cần viết một test script đơn giản trước khi viết 1 test script đầy đủ, nhưng khó khăn hơn rất nhiều để thực sự làm được chúng. Phát triển agile đòi hỏi có tính kỷ luật hơn nhiều so với phát triển truyền thống.

• Tăng cường trách nhiệm giữa các bên liên quan (Greater accountability is required of stakeholders): Agile yêu cầu các bên liên quan cần liên hệ chặt chẽ với nhau hơn và để đảm bảo cho việc sản xuất phần mềm các bên tham gia cần có trách nhiệm hơn với những yêu cầu, quyết định mà họ đưa ra.

• Nhiều hơn các kỹ năng được yêu cầu (Greater range of skills are required): Không chỉ là 1 tester, hay chỉ là một lập trình viên, hay chỉ là một nhà phân tích, hay chỉ là một ... nữa. Agilists tách ra khỏi các phương pháp tiếp cận phát triển truyền thống cái mà thúc đẩy mọi người trở nên chuyên nghiệp hơn và thay vào đó là chuyển hướng tới một cách tiếp cận phản ứng cao và liên kết chặt chẽ hơn.

5. So sánh phương pháp tiếp cận Agile và phương pháp truyền thống

Cách tiếp Agile cung cấp nhiều lợi ích hơn các mô hình chữ V truyền thống:

• Có thể mở rộng yêu cầu chức năng hơn (Greater ability to deliver required functionality): Agile teams làm việc chặt chẽ với các bên liên quan của họ, ý tưởng được đưa ra ngay sau sự tha gia tích cực của các bên liên quan. Trên thực tế, do có sự hợp tác, trao đổi liên tục giữa các bên nên các yêu cầu chức năng luôn được mở rộng và cập nhật liên tục.

• Chất lượng cao hơn (Greater quality): Điều tra cho thấy áp dụng agile vào phát triển mang lại chất lượng cao hơn so với phát triển thông thường, lý do ở đây là sự kết hợp trong team, sự phản hồi sớm hơn và test thường xuyên trong các giai đoạn.

• Cải thiện designs: Kiến trúc agile và chiến thuật design agile là 1 cải thiện vượt bậc, và điều này kết hợp với sự hợp tác bởi agile team, mang lại design tốt hơn so với phát triển thường. Kiến trúc và design rất quan trọng với team agile, họ thực hiện điều này trong suốt quá trình phát triển, không chỉ giai đoạn đầu.

• Cải thiện kinh tế: Điều tra những trường hợp thành công cho thấy đội agile mang lại thu nhập cao hơn so với team thường, lý do vì thời gian feedback ngắn hơn khiến cho chi phí thấp hơn. Hơn nữa, vì agile team làm việc thông minh hơn, không phải làm nhiều hơn (OT liên tiếp...), những chức năng họ mang lại nhanh hơn và từ đó có thu nhập cao hơn...

         Hình 4:  Yếu tố thành công của mô hình (Scale là từ -10 đến 10).

II. Yêu cầu chiến lược của Agile (Agile Requirements Strategies)

                                  Hình 5: Agile Model

1. Sự tích cực tham gia của các bên liên quan

Sự tham gia của các bên liên quan là vô cùng quan trọng với mô hình Agile, khi các bên liên quan liên hệ chặt chẽ với nhau nó làm tăng cơ hội thành công của dự án bằng cách tăng:

• Các developers có thể hiểu được thực tế nhu cầu của các bên liên quan
• Chất lượng của dự án tăng vì có sự tham gia kiểm thử chấp nhận (acception testing) của nhiều bên liên quan
• Các bên liên quan có thể chỉ đạo, thay đổi chiến lược, yêu cầu ngay trong lúc cùng làm việc với đội phát triển

2. Quản lý yêu cầu chức năng

• Nền tảng của mô hình Agile là ưu tiên theo mô hình stack (hàng đợi),như trong hình 6, những yêu cầu được thực hiện theo thứ tự ưu tiên và để cho các bên liên quan phát triển các yêu cầu của họ trong suốt quá trình phát triển dự án . Biểu đồ cũng chỉ ra 1 só khái niệm cao cấp của Agile.
• Ở mức độ ưu tiên cao, các yêu cầu chức năng và sự lặp lại công việc cũng được đưa ra chi tiết hơn so với các yêu cầu có mức độ ưu tiên trung bình và thấp.

         Hình 6: Agile requirements có thể thay đổi theo chức năng quản lý

3. Hình dung yêu cầu ban đầu

            Hình 7: Mô tả vòng đời phát triển Agile Model Driven (AMDD)

Tùy thuộc vào các vấn đề logic và khả năng tổ chức của bạn để đưa ra quyết định trong một khoảng thời gian hợp lý, ý tưởng có thể kéo dài 1 vài ngày đến vài tháng.Tuy nhiên, mô hình hóa yêu cầu ban đầu chỉ cần mất mấy ngày mà thôi. Ở hình 7, ý tưởng được đưa ra nhanh hơn, dựa trên việc rút ngắn và sắp xếp độ ưu tiên cho ý tưởng.

III. Kết luận

Những dự án áp dụng mô hình Agile thường là những dự án có requirements cần thay đổi và cập nhật liên tục, đòi hỏi một sự nắm bắt nhanh và kịp thời cả kiến thức và xu hướng công nghệ. Bên cạnh đó nhờ sự phát triển và sản xuất theo hướng tập trung ưu tiên nên Agile sẽ được áp dụng cho các dự án phát triển theo nhiều giai đoạn, nhiều thành phần.

Phát triển phần mềm Agile là một nhóm phương pháp phát triển phần mềm, trong đó yêu cầu và các giải pháp phát triển được tiến hành thông qua sự hợp tác giữa các tổ chức, các nhóm chức năng. Nó thúc đẩy sự thích ứng, phát triển tiến hóa, bàn giao sản phẩm sớm hơn, cải tiến liên tục, và khuyến khích quá trình phản ứng nhanh và linh hoạt để thay đổi.