Quản lý quy trình phát triển phần mềm kiểu Agile

1. Phát triển lặp:

imageLà một kiểu phát triển phần mềm mà chu trình sống của phần mềm được chia thành các vòng lặp liên tiếp nhau.

Ví dụ: Giả sử sau khi nghiên cứu yêu cầu từ phía khách hàng, ta thống kê được phần mềm có tổng cộng 50 chức năng. Giả sử ta chọn 2 trong số 50 chức năng trên, ước lượng thời gian thực hiện 2 chức năng đó trong vòng khoảng 2 tuần chẳng hạn, để thực hiện hoàn chỉnh. Ta xây dựng phần mềm hoàn chỉnh phần mềm với chỉ 2 chức năng đó, rồi chuyển cho khách hàng sử dụng và đánh giá. Sau đó, khách hàng sẽ đưa ra đánh giá về 2 chức năng mà ta đã làm. Giả sử trong 2 chức năng đó, có 1 chức năng chưa hoàn chỉnh hoặc chưa đáp ứng đúng yêu cầu khách hàng, ta giữ lại chức năng đó cùng với những đánh giá của khách hàng. Tiếp theo, trong 48 chức năng còn lại, ta lại chọn ra 3 chức năng nữa, cộng với chức năng cũ là thành 4 chức năng và ước lượng thời gian hoàn thành trong vòng 2 tuần. Ta lại xây dựng phần mềm hoàn thiện với chỉ 4 chức năng đó. Sau khi xây dựng xong, ta lại đưa cho khách hàng chạy thử và xem phản hồi, đánh giá từ khách hàng. Tiếp tục ta lại chọn ra thêm 10 chức năng nữa để xây dựng, và ước lượng thời gian hoàn thành trong vòng cũng 2 tuần. Càng ngày ta có thể xây dựng phần mềm càng nhanh vì ta đã gần như nắm bắt được hệ thống, càng ngày càng có kinh nghiệm xây dựng các chức năng cho hệ thống đó. Theo đó, ta sẽ chọn thời gian cho mỗi vòng lặp là cứ 2 tuần. Hệ thống của chúng ta từ nhỏ, sẽ to dần to dần cho đến khi hoàn tất tất cả chức năng mà khách hàng yêu cầu.

Mục tiêu của mỗi vòng lặp là một hệ thống được xây dựng, kiểm thử cẩn thận, chạy ổn định và có thể đưa vào sử dụng.

image

Mỗi vòng lặp đều gồm các bước phân tích yêu cầu, thiết kế, phát triển, tích hợp (có thể ban đầu chúng ta chưa cần thực hiện bước này), kiểm thử và vận hành, chuyển giao cho khách hàng sử dụng và nhận phản hồi. Kết quả của mỗi vòng lặp là một release hoàn chỉnh, và release sau phải bao gồm cả release trước đó chứ không phải là release độc lập.

Điểm khác biệt so với những mô hình cổ điển (water fall, V model…)

Chẳng hạn ta có phần mềm phát triển trong vòng 2 năm

– Nếu phát triển theo water fall: ta có thể thực hiện việc phân tích yêu cầu trong vòng 3 tháng, thiết kế hệ thống trong vòng 3 tháng, phát triển trong vòng 1 năm và bảo trì trong vòng 6 tháng còn lại.

– Nếu phát triển theo phát triển lặp: 3 tuần đầu thực hiện phân tích yêu cầu của 2 chức năng, sau đó thiết kế hệ thống và phát triển hoàn thiện 2 chức năng đó, kiểm thử và chuyển cho khách hàng sử dụng và đánh giá. Trong 3 tuần tiếp theo, ta thực hiện phân tích yêu cầu của 5 chức năng khác, sau đó thiết kế hệ thống và phát triển 5 chức năng này, kiểm thử và lại chuyển giao cho khách hàng sử dụng và đánh giá. Quá trình này cứ lặp đi lặp lại, công việc trong mỗi vòng lặp tương tự nhau. 3 tuần đầu chúng ta vẫn có phần phân tích yêu cầu, 3 tuần kế tiếp vẫn có phần phân tích yêu cầu,… cho đến 3 tuần cuối cùng của 2 năm ta vẫn có phần phân tích yêu cầu. Đối với water fall, việc phân tích yêu cầu chỉ xảy ra ở 3 tháng đầu tiên, qua thời gian này là đã chuyển sang bước khác.

Khái niệm “time-boxed” trong phát triển lặp: có nghĩa là chúng ta cố định thời gian kết thúc 1 vòng lặp.

image

Khái niệm trên nghe có vẻ đơn giản nhưng các bạn nên lưu ý như thế này. Quay trở lại “tam giác chất lượng”, ta có 4 thành phần ảnh hưởng đến dự án, đó là yêu cầu của khách hàng, thứ 2 là chất lượng của dự án, thứ 3 là nguồn lực mà chúng ta có, và cuối cùng là thời gian. Vậy “time-boxed” ở đây có ý nghĩa gì? Ở đây, nó có nghĩa rằng chúng ta cố định phần thời gian thực hiện (chẳng hạn như 5 ngày, sau 5 ngày yêu cầu phải cho ra 1 hệ thống nhỏ), ta có thể thay đổi các yếu tố khác. Chẳng hạn, trong 5 ngày yêu cầu thực hiện 20 tính năng của phần mềm, nhưng vào thời điểm đó, các yếu tố khác không đủ để đáp ứng yêu cầu này, và ta phải giảm 1 đỉnh của tam giác lại, chẳng hạn ta đề xuất giảm xuống còn 10 tính năng để làm sao sau 5 ngày cho ra được hệ thống. Hoặc là với 20 tính năng đó, với nguồn nhân lực hiện tại không đủ đáp ứng được, có thể đề xuất thêm người vào làm để đảm bảo sau 5 ngày cho ra được hệ thống. 3 cạnh của tam giác có thể thay đổi nhưng đỉnh thời gian không thay đổi, cố định.

Khái niệm phát triển tiến hóa và thích nghi trong phát triển lặp:

image

Chẳng hạn ta chia dự án ra thành 10 vòng lặp, mỗi vòng lặp 3 tuần, yêu cầu khách hàng đưa ra là 100 chức năng. Ở vòng lặp đầu tiên, giả sử ta hiểu được 20% yêu cầu và phát triển được hệ thống hoàn thiện đáp ứng 20% yêu cầu đó với 2 chức năng. Đến vòng lặp tiếp theo, giả sử ta hiểu được thêm 10% yêu cầu và phát triển được thêm 3 chức năng (cộng với 2 chức năng đã làm ở vòng lặp trước nữa là thành 5 chức năng, tức 5%). Đến vòng lặp sau, ta hiểu được thêm 20% yêu cầu và phát triển được thêm 3 chức năng nữa. Đến vòng lặp thứ 4, giả sử ta hiểu được thêm 40% yêu cầu và làm được thêm 2 chức năng nữa. Sang vòng lặp thứ 5, ta dừng việc phân tích yêu cầu, mặc dù còn 10% yêu cầu ta chưa hiểu nó ra sao, ta tập trung phát triển thêm 10 chức năng nữa cho hệ thống. Khi đó, hệ thống hiện tại có 20 chức năng. Sau đó, giả sử ở vòng lặp thứ 6, ta không phát triển hệ thống nữa mà tập trung phân tích 10% yêu cầu còn lại của khách hàng, khi đó ta đã hiểu hết các yêu cầu mà khách hàng đưa ra. Sang những vòng lặp tiếp theo, ta cứ việc phát triển hệ thống để hoàn thiện các chức năng còn lại.

* Điểm đặc trưng của phát triển lặp:

– Ban đầu yêu cầu cùa khách hàng không phải lúc nào cũng rõ ràng, khó mà xác định “đúng” được. Thay vì bỏ ra 1 khoảng thời gian để xác định hết yêu cầu của khách hàng, chúng ta có thể phát triển dần dần, từ từ hiểu yêu cầu của khách hàng. Khi áp dụng phát triển lặp, đối với khách hàng đó là điều tốt vì nó làm tăng độ tin cậy của khách hàng đối với sản phẩm (sau mỗi vòng lặp, sản phẩm đưa ra đó là hệ thống, phần mềm hoàn chỉnh cho dù chức năng còn ít và khách hàng có thể biết được sản phầm của mình nó như thế nào).

– Khách hàng có thể thay đổi yêu cầu bất cứ lúc nào, và phát triển lặp được đưa ra để đáp ứng việc này Smile.

– Trở ngại lớn nhất của phát triển lặp đó là việc ước lượng, định giá cho dự án, bởi vì chúng ta sẽ không có yêu cầu từ đầu, do đó cũng sẽ không có thiết kế ngay từ đầu. Ở những vòng lập đầu tiên, việc ước lượng có thể cho sai số gấp 3 lần bình thường Confused smile. Nhưng càng về sau, sai số sẽ ngày càng nhỏ đi.

 

2. Agile Development:

Agile là một mô hình phát triển phần mềm kế thừa từ phát triển lặp.

Khái niệm: là phương pháp phát triển lặp cố định thời gian của từng vòng lặp, đưa ra các sản phẩm (release) theo hướng tiến hóa dần, có kế hoạch thích hợp (không phải cố định), sẵn sàng cho mọi sự thay đổi nếu có xảy ra.

(P/S: phát triển lặp có thể không cần cố định về thời gian.)

image

* 4 khái niệm (đặc điểm) quan trọng trong phát triển Agile:

– Con người và sự tương tác giữa người với người đặt lên trên quy trình và công cụ sử dụng: có nghĩa là quy trình hiện tại là như vậy, nhưng ta hoàn toàn có thể thay đổi nó một chút (thêm phần này, bớt phần kia).

– Phần mềm làm việc thay cho tài liệu phức tạp: trọng tâm của phát triển Agile đó là sản phẩm đưa ra (có thể nhảy vào coding vẫn được, miễn là code đúng, code chạy; không cần thiết kế vẫn được).

– Việc tương tác với khách hàng đặt lên trên các hợp đồng, thương thảo: như đã nói ở phần trên, thì sau mỗi vòng lặp chúng ta sẽ chuyển giao cho khách hàng sản phẩm để nhận phản hồi, đánh giá từ khách hàng.

– Sẵn sàng cho sự thay đổi thay vì theo như kế hoạch nhất định.

* Quá trình vận hành Agile:

Đầu tiên là phải xác định vấn đề phải giải quyết cho phần mềm, sau đó đưa ra các khái niệm, ý tưởng để giải quyết vấn đề đó. Tiếp theo, chúng ta đưa ra chứng minh cho khách hàng xem là ta có thể thực hiện được (proof of concept) – không nên thiên về kỹ thuật, nên hướng về phần nghiệp vụ nhiều hơn. Đây là bước quan trọng, bắt buộc khi phát triển theo Agile. Sau khi 2 bên đã đồng ý và ký kết hợp đồng xong, chúng ta sẽ bắt đầu đi vào quy trình phát triển phần mềm. Quy trình phát triển phần mềm trong Agile tương tự như khi phát triển lặp, nhưng không hoàn toàn là phát triển lặp.

Như đã trình bày ở trên thì Agile không tập trung vào các yêu cầu, tài liệu. Vậy làm sao chúng ta biết và nắm yêu cầu của khách hàng? Trong Agile có 1 khái niệm đó là Story.

image

Một dự án bao gồm rất nhiều story được xếp theo thứ tự mức độ ưu tiên. Khi phát triển phần mềm, chúng ta phải lấy theo thứ tự độ ưu tiên giảm dần.

5 thoughts on “Quản lý quy trình phát triển phần mềm kiểu Agile

  1. Pingback: Quản lý quy trình phát triển phần mềm kiểu Agile « Shining
  2. Pingback: Checklist | Joe Thinh
  3. Huy nè, tôi có đọc bài viết của bạn về phát triển phần mềm theo kiểu Agile và Scrum. Nhưng thực sự tôi vẫn chưa phân biệt được hai kiểu phát triển phần mềm này. Ban phân biệt giúp tôi dc k ?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s