Phương pháp luận agile và ứng dụng trong phát triển hệ thống thông tin hướng đối tượng

- Phát triển phần mềm linh hoạt agile software development – gọi tắt là Agile là một triết lí cùng với nhóm các phương pháp và phương pháp luận phát triển phần mềm dựa trên các nguyên tắ

hướng đối tượng

GV: TS Phạm Nguyễn Cương Nhóm học viên thực hiện:

Nguyễn Minh Đăng 10 12 006 Nguyễn Tấn Khánh 11 11 024

Lê Thanh Sang 11 11 042

TP.HCM - 12/2012

Agile methodology - 2 -

Mục lục

1 Tổng quan về Agile 3

1.1 Sự cần thiết của một mô hình phát triển phần mềm mới 3

1.2 Phương pháp Agile 6

1.3 So sánh Agile và các phương pháp hiện tại 17

2 Mô hình hóa với Agile 19

2.1 Các giá trị của mô hình hóa Agile 19

2.1 Các nguyên tắc cốt lõi của mô hình hóa agile 22

2.2 Các phương pháp thực hành của mô hình hóa agile 24

2.3 Phát triển phần mềm theo hướng mô hình hóa agile 26

2.4 Tài liệu hóa theo hướng agile 27

3 Quy trình Scrum 28

3.1 Tổng quan về Scrum 28

3.2 Scrum và Waterfall 28

4 Quy trình XP 31

4.1 Tổng quan về XP 31

4.1 Các đặc điểm của XP 32

5 Phát triển hướng vào tính năng (Feature Driven Development) 37

5.1 Quy trình 37

5.2 Các vai trò và trách nhiệm 40

5.3 Kiểm chứng thực tiễn (Practices) 43

5.4 Sự chấp nhận và kinh nghiệm 44

5.5 Phạm vi sử dụng 44

5.6 Nghiên cứu hiện tại 44

6 The Rational Unified Process 45

6.1 Quy trình 45

6.2 Các vai trò và trách nhiệm 48

6.3 Kiểm chứng thực tiễn 49

6.4 Sự chấp nhận và kinh nghiệm 49

6.5 Phạm vi sử dụng 50

6.6 Nghiên cứu hiện tại 51

7 Tài liệu tham khảo 51

Agile methodology - 3 -

1 Tổng quan về Agile

1.1 Sự cần thiết của một mô hình phát triển phần mềm mới

- Chúng ta đã viết phần mềm được 30 năm nhưng những gì chúng ta đã làm được còn rất ít Thành công của chúng ta được thúc đẩy bởi sự tưởng tượng, sáng tạo của con người Chúng ta càng viết ra nhiều phần mềm thì sự đòi hỏi, yêu cầu của con người càng nhiều Chính vì vậy, những nhà quản

lý và phát triển phần mềm tiếp tục tìm kiếm phương thức phát triển phần mềm tốt hơn

- So với 30 năm trước chúng ta đã có những chiếc máy tính rẻ hơn, nhanh hơn, nhiều ngôn ngữ lập trình mạnh mẽ ra đời, số lượng nhiều hơn cần thiết những công cụ hỗ trợ, sự đào tạo tốt hơn và có những hiểu biết sâu hơn về

lý thuyết phần mềm Internet đã thay đổi cách con người giao tiếp với nhau, thúc đẩy sự trao đổi thông tin và thay đổi một cách triệt để sự kỳ vọng của con người về cách thức phần mềm làm việc Chúng ta cũng có số lượng đáng kể những phương pháp khác nhau giúp xác định con đường phát triển phần mềm tốt nhất và đó chính là khía cạnh của việc phát triển phần mềm

mà chúng ta sẽ tập trung vào trong thời gian tới

1.1.1 Những hạn chế của mô hình phát triển phần mềm truyền thống

- Đã có rất nhiều mô hình phát triển phần mềm được tạo ra trong những năm qua Có thể kể đến như:

Agile methodology - 4 -

- Khi xây dựng các phương pháp truyền thống người ta đã cố gắng trang bị cho chúng khả năng dự đoán trước Với khả năng này ta có thể tạo ra một bản kế hoạch tại thời điểm đầu của dự án và xác định được thời gian hoàn thành dự án dựa theo bản kế hoạch này Và vấn đề cố hữu trong quá trình thực hiện dự án vẫn là “sự thay đổi yêu cầu của người dùng” Thông thường khách hàng không thay đổi yêu cầu của họ bởi vì họ biết rằng chi phí để thay đổi rất đắt Tuy nhiên phần mềm không phải là thứ hữu hình Khách hàng không chỉ khó để xác định một cách chính xác cái gì là cần thiết

mà cũng khó để hiểu tại sao việc thay đổi lại khó khăn như vậy Họ mong đợi một phần mềm phải có tính mềm dẻo Những phương pháp truyền thống đã đưa ra những thủ tục nhằm ngăn chặn sự thay đổi yêu cầu từ phía khách hàng Điều này giúp duy trì bản kế hoạch dự án đã xây dựng ban đầu nhưng lại không đảm bảo rằng kết quả cuối cùng là những gì mà khách hàng mong muốn Khả năng dự đoán trước có thể là điều ước ao nhưng ta chỉ có thể đạt được điều đó với giá phải trả là sự giảm sút chất lượng phần mềm không thỏa mãn được đòi hỏi của khách hàng

- Với những hạn chế như vậy của những phương pháp phát triển phần mềm truyền thống, ta thắc mắc rằng tại sao chúng lại được sử dụng và nếu chúng

đã được sử dụng trong quá khứ thì lại từ bỏ chúng bây giờ? Phải chăng một vài thứ đã thay đổi Trong suốt thập niên 80 những thay đổi cơ bản đã xảy ra và kết quả là hình thành nên “thế giới nhanh” – thế giới của sự toàn cầu hóa và “thế giới chậm” của những ai tự tách mình ra khỏi quá trình toàn cầu hóa Sự phát triển phần mềm diễn ra trong thế giới nhanh và sự thay đổi diễn ra đồng thời ở công nghệ, tài chính, thông tin và đi kèm với chúng là sự dỡ bỏ những hàng rào chính trị được duy trì suốt thời kỳ chiến tranh lạnh Mọi việc diễn ra nhanh hơn Những đối thủ xuất hiện, sự thành công hay thất bại chỉ là ranh giới mong manh Vòng đời của sản phẩm ngắn hơn và người dùng thì hay thay đổi Không có gì là ngạc nhiên khi những phương pháp phù hợp với thập niên 70 lại thất bại trong thập niên 80 và 90

1.1.2 Sự nổi lên của phương pháp Agile

- Trong thập kỉ 90 nhiều người đã nhận ra mọi thứ đã thay đổi bằng cách này hay cách khác Những người này đã quan tâm tới phương pháp phát triển

Agile methodology - 5 -

phần mềm linh hoạt hơn, phù hợp hơn với môi trường làm việc luôn luôn vận động Mặc dù chi tiết những phương pháp này là khác nhau nhưng chúng đều có chung một số nguyên tắc và trong một phạm vi nào đó những phương pháp này thường được nhóm lại với nhau dưới tên gọi “những phương pháp linh hoạt – agile methodologies”

- Phát triển phần mềm linh hoạt (agile software development – gọi tắt là Agile)

là một triết lí cùng với nhóm các phương pháp và phương pháp luận phát triển phần mềm dựa trên các nguyên tắc phát triển phân đoạn lặp (iterative)

và tăng trưởng (incremental), theo đó nhu cầu và giải pháp tiến hóa thông qua sự hợp tác giữa các nhóm tự quản và liên chức năng Agile thường sử dụng cách lập kế hoạch thích ứng (adaptive planning), việc phát triển và chuyển giao theo hướng tiến hóa; sử dụng các khung thời gian ngắn và linh hoạt để dễ dàng phản hồi lại với các thay đổi trong quá trình phát triển Ngày nay, triết lí Agile đã vượt xa khỏi khu vực truyền thống của mình là phát triển phần mềm để đóng góp sự thay đổi trong cách thức làm việc, quản lí, sản xuất ở các ngành khác như sản xuất (manufacturing), dịch vụ, sales,

marketing, giáo dục v.v

- Thuật ngữ "Agile" chính thức được sử dụng rộng rãi theo cách thống nhất kể

từ khi “Tuyên ngôn Agile” được giới thiệu ra công chúng năm 2001 Nhờ tính linh hoạt, đa dạng và hiệu quả cao, các phương pháp Agile ngày càng trở thành sự lựa chọn hàng đầu của các khách hàng, nhà phát triển, các công ty phát triển phần mềm Theo khảo sát của hãng nghiên cứu thị trường

Forrester, mức độ phổ biến của Agile hiện đang ở mức cao nhất, và gấp nhiều lần so với các phương pháp truyền thống như thác nước hay CMMi (xem Hình 1) Hơn thế, một số phương pháp Agile có xuất xứ và được sử dụng hiệu quả ngoài phạm vi phát triển phần mềm

“phương pháp nhẹ”

- Vào tháng Hai năm 2001, mười bảy nhà phát triển phần mềm đã gặp gỡ nhau

ở Snowbird, Utah Resort để thảo luận về các phương pháp phát triển phần mềm gọn nhẹ và linh hoạt Họ đã cùng nhau công bố “Tuyên ngôn Phát triển phần mềm linh hoạt” (“Manifesto for Agile Software Development” – gọi tắt là

“Tuyên ngôn Agile”) để định nghĩa cách hiểu về Phát triển phần mềm linh

hoạt Đây là cột mốc quan trọng của agile Dù trước đó, các phương pháp agile như XP, Scrum, v.v đã được sử dụng thành công ở rất nhiều nơi,

nhưng phải tới khi có sự xuất hiện của “Tuyên ngôn Agile”, cùng với sự ra đời của các hiệp hội chuyên ngành agile như Agile Alliance hay Scrum Alliance, các phương pháp agile mới có một sự phát triển vượt bậc Văn bản này rất ngắn, dễ hiểu, và rất quan trọng vì nó đưa ra các giá trị cốt lõi nhất mà toàn bộ các nhà lý thuyết cũng như những người thực hành Agile tuân thủ; mặc dù các phương pháp họ đề xuất hoặc sử dụng trong thực tiễn có thể rất khác nhau

Agile methodology - 7 -

1.2.1 Tuyên ngôn Agile

- “Chúng tôi đã phát hiện ra cách phát triển phần mềm tốt hơn bằng cách thực hiện nó và giúp đỡ người khác thực hiện.”

Qua công việc này, các nhà sáng tạo Agile đã đi đến việc đánh giá cao:

- Cá nhân và sự tương tác hơn là quy trình và công cụ

- Phần mềm chạy tốt hơn là tài liệu đầy đủ:

- Cộng tác với khách hàng hơn là đàm phán hợp đồng:

- Phản hồi với các thay đổi hơn là bám sát kế hoạch:

- “Mặc dù các điều bên phải vẫn còn giá trị, nhưng chúng tôi đánh giá cao hơn

các mục ở bên trái.”

- Mười hai nguyên tắc phía sau tuyên ngôn Agile:

- “Chúng tôi tuân theo các nguyên tắc sau đây”

o Ưu tiên cao nhất của chúng tôi là thỏa mãn khách hàng thông qua việc chuyển giao sớm và liên tục các phần mềm có giá trị

o Chào đón việc thay đổi yêu cầu, thậm chí rất muộn trong quá trình phát triển Các quy trình linh hoạt tận dụng sự thay đổi cho các lợi thế cạnh tranh của khách hàng

o Thường xuyên chuyển giao phần mềm chạy tốt tới khách hàng, từ vài tuần đến vài tháng, ưu tiên cho các khoảng thời gian ngắn hơn

o Nhà kinh doanh và nhà phát triển phải làm việc cùng nhau hàng ngày trong suốt dự án

o Xây dựng các dự án xung quanh những cá nhân có động lực Cung cấp cho họ môi trường và sự hỗ trợ cần thiết, và tin tưởng họ để hoàn thành công việc

o Phương pháp hiệu quả nhất để truyền đạt thông tin tới nhóm phát triển

và trong nội bộ nhóm phát triển là hội thoại trực tiếp

o Phần mềm chạy tốt là thước đo chính của tiến độ

o Các quy trình linh hoạt thúc đẩy phát triển bền vững Các nhà tài trợ, nhà phát triển, và người dùng có thể duy trì một nhịp độ liên tục không giới hạn

o Liên tục quan tâm đến các kĩ thuật và thiết kế tốt để gia tăng sự linh hoạt

o Sự đơn giản – nghệ thuật tối đa hóa lượng công việc chưa xong – là căn bản

o Các kiến trúc tốt nhất, yêu cầu tốt nhất, và thiết kế tốt nhất sẽ được làm ra bởi các nhóm tự tổ chức

o Nhóm phát triển sẽ thường xuyên suy nghĩ về việc làm sao để trở nên hiệu quả hơn, sau đó họ sẽ điều chỉnh và thay đổi các hành vi của mình cho phù hợp

Agile methodology - 8 -

- Các nguyên lý này, cùng với năm điểm cốt lõi trong "Tuyên ngôn Agile" sẽ dẫn đường cho các nhà thực hành agile (agile practictioner) vận dụng tốt các phương pháp agile vào thực tiễn Các nguyên lí này được Jeff Sutherland diễn giải chi tiết như sau:

1.2.1.1 Cá nhân và Sự tương tác

- Cá nhân và sự tương tác giữa họ là cốt yếu để nhóm đạt được hiệu suất cao Các nghiên cứu về “bão hòa truyền thông” trong một dự án cho thấy rằng, khi không có vấn đề trong truyền thông, nhóm có thể thực hiện công việc tốt hơn 50 lần so với mức trung bình trong lĩnh vực của mình Để tạo điều kiện cho truyền thông, các phương pháp linh hoạt thường xuyên sử dụng chu trình thanh-tra-và-thích-nghi Chu trình này có thể diễn ra hằng phút với lập trình cặp (pair-programming), hằng giờ với tích hợp liên tục (continuos integration), hằng ngày với standup metting (đứng họp), hằng phân đoạn với các buổi họp sơ kết và cải tiến

- Tuy nhiên, chỉ tăng tần suất phản hồi và giao tiếp là không đủ để loại bỏ các vấn đề về truyền thông Chu kỳ thanh-tra-và-thích-nghi làm việc tốt chỉ khi các thành viên trong nhóm thể hiện những hành vi quan trọng sau:

- Tôn trọng giá trị của mỗi cá nhân

- Trung thực trong truyền thông

- Minh bạch về dữ liệu, hoạt động, và quyết định

- Tin tưởng vào sự hỗ trợ của mỗi cá nhân với nhóm

- Cam kết với nhóm và các mục tiêu của nhóm

- Để thúc đẩy các hành vi này, nhà quản lý linh hoạt phải cung cấp một môi trường hỗ trợ, các nhà huấn luyện phải tạo điều kiện thuận lợi, và các thành viên của nhóm phải thể hiện chúng Chỉ khi đó nhóm mới có thể phát huy được hết tiềm năng của mình

- Đạt tới các hành vi đó khó khăn hơn rất nhiều so với việc hình thành chúng Hầu hết các nhóm tránh lé sự thật, sự minh bạch, và tin tưởng vào các chuẩn mực văn hóa hoặc có những kinh nghiệm tiêu cực từ các xung đột xuất phát từ truyền thông trung thực trước đây Để chống lại những khuynh hướng này, ban lãnh đạo và thành viên nhóm phải tạo điều kiện cho những xung đột tích cực Làm như vậy không chỉ giúp tạo ra hành vi sinh lợi mà còn đem lại các lợi ích khác:

Agile methodology - 9 -

- Cải tiến quy trình phụ thuộc vào nhóm trong việc tạo ra danh sách các trở ngại hoặc vấn đề trong tổ chức, đối mặt với chúng một cách trung thực, và sau đó loại bỏ chúng một cách có hệ thống tùy theo độ ưu tiên

- Đổi mới chỉ xảy ra với việc tự do trao đổi các ý tưởng mâu thuẫn lẫn nhau, một hiện tượng được nghiên cứu và viết thành tài liệu bởi Takeuchi và Nonaka, những người cha đỡ đầu của Scrum

- Việc hướng các nhóm tới mục tiêu chung đòi hỏi nhóm phải đối mặt và giải quyết các vấn đề về xung đột

- Cam kết làm việc cùng nhau sẽ xảy ra chỉ khi mọi người đồng ý với mục tiêu chung và sau đó đấu tranh cho sự tiến bộ của bản thân cũng như nhóm

- Ý cuối cùng ở trên nói về cam kết là đặc biệt quan trọng Đó là khi mà các

cá nhân và các nhóm được cam kết mà họ cảm thấy có trách nhiệm với việc cung cấp các giá trị cao, đó là điểm mấu chốt đối với các nhóm phát triển phần mềm Các phương pháp linh hoạt tạo điều kiện cho việc cam kết bằng cách khuyến khích các nhóm đưa ra một danh sách các công việc được ưu tiên hóa, để họ tự quản lý công việc của mình, và tập trung vào cải tiến về cách thực hiện các công việc đó Thực hành là nền tảng của tự-tổ-chức (self-organization), đó là động lực để đạt được kết quả trong một nhóm agile

- Để tạo ra các nhóm có hiệu suất cao, các phương pháp linh hoạt coi trọng

cá nhân và sự tương tác hơn là quy trình và công cụ Thực tế cho thấy rằng, tất cả các phương pháp linh hoạt tìm kiếm sự gia tăng trong truyền thông và cộng tác thông qua việc kiểm tra thường xuyên các chu trình thanh-tra-và-thích-nghi Tuy nhiên, các chu trình đó chỉ thực sự làm việc tốt khi mà các nhà lãnh đạo agile khuyến khích các cuộc xung đột tích cực, thứ cần thiết để xây dựng một nền tảng vững chắc cho sự trung thực, tính minh bạch, lòng tin, sự tôn trọng, và cam kết từ các nhóm agile của họ

1.2.1.2 Phần mềm Chạy tốt hơn là Tài liệu Đầy đủ

- Phần mềm chạy tốt là một trong những khác biệt lớn mà phát triển linh hoạt mang lại Tất cả các phương pháp linh hoạt thể hiện Tuyên ngôn Agile bằng cách nhấn mạnh việc cung cấp một phần nhỏ của phần mềm chạy tốt tới khách hàng sau một khoảng thời gian nhất định

Agile methodology - 10 -

- Tất cả các nhóm agile phải xác lập những gì họ muốn nói là “phần mềm chạy tốt”, cái thường được biết như là định nghĩa hoàn thành Ở mức độ cao, một phần của chức năng hoàn thành chỉ khi các tính năng của chúng vượt qua tất cả các kiểm thử và có thể được vận hành bởi người dùng cuối Ở mức thấp nhất, các nhóm phải vượt qua được kiểm thử đơn vị (unit test) và kiểm thử hệ thống Các nhóm tốt nhất còn bao gồm việc kiểm thử tích hợp, kiểm thử hiệu năng, và kiểm thử chấp nhận của khách hàng trong định nghĩa hoàn thành đối với một phần chức năng Thông qua nguồn dữ liệu phong phú từ các dự án, một công ty CMMI Cấp độ 5 cho thấy việc xác định kiểm thử chấp nhận cùng với các tính năng, triển khai một loạt các tính năng và theo độ ưu tiên, ngay lập tức chạy các kiểm thử chấp nhận với mỗi tính năng, và sửa bất cứ một lỗi nào có độ ưu tiên cao nhất sẽ tăng gấp đôi tốc độ sản xuất và giảm các sai sót đến 40% Điều này có được từ một công ty có tỷ lệ sai sót thấp nhất thế giới

- Tuyên ngôn Agile khuyến nghị các nhóm cung cấp phần mềm chạy tốt sau một khoảng thời gian nhất định Đồng thuận với định nghĩa hoàn thành là một trong những cách thực tế để nhóm agile mang lại hiệu suất và chất lượng cao, cái cần thiết để hoàn thành mục tiêu này

1.2.1.3 Cộng tác với Khách hàng hơn là Thương thảo Hợp đồng

- Trong hai thập kỷ qua, tỉ lệ thành công của các dự án tăng hơn hai lần trên toàn thế giới Điều này được cho là vì các dự án nhỏ hơn và mức độ

chuyển giao thường xuyên đã cho phép khách hàng cung cấp các thông tin phản hồi về phần mềm hoạt động một cách đều đặn hơn Các tác giả của bản Tuyên ngôn đã làm sáng tỏ điều này khi họ nhấn mạnh rằng việc để khách hàng tham gia vào quá trình phát triển phần mềm là hết sức cần thiết

để dẫn tới thành công

- Các phương pháp phát triển linh hoạt đã thúc đẩy giá trị này bằng cách đưa vào một đồng minh tích cực của khách hàng làm việc sát cánh với đội phát triển Lấy một ví dụ, một nhóm Scrum đầu tiên có hàng ngàn khách hàng

Sẽ là không khả thi nếu cho phép tất cả khách hàng tham gia vào quá trình phát triển sản phẩm, vì vậy họ chọn ra một vị đại sứ của khách hàng, được gọi là Product Owner (chủ sản phẩm), để đại diện cho không chỉ tất cả khách hàng trong trường hợp này mà còn bao gồm cả quản lý, dịch vụ

Agile methodology - 11 -

khách hàng, và các bên liên quan khác Chủ sản phẩm có trách nhiệm cập nhật danh sách yêu cầu về sản phẩm sau mỗi bốn tuần thời điểm mà nhóm Scrum phát hành phiên bản sản phẩm chạy tốt, có tính đến yếu tố thực tế cùng phản hồi của khách hàng và các bên liên quan Điều này cho phép khách hàng có thể giúp định hình sản phẩm phần mềm đang được tạo ra

- Một nhóm XP đầu tiên đã bắt đầu với một dự án CNTT nội bộ Họ có thể có sẵn người sử dụng đầu cuối của công ty trong nhóm làm việc với họ hàng ngày Khoảng 10% thời gian, các tư vấn viên và nhóm nội bộ có thể tìm được một người dùng cuối có thể làm việc với nhóm từng ngày 90% thời gian còn lại, họ phải cử ra người đại diện cho khách hàng Người này, được nhóm XP gọi là Customer (khách hàng), làm việc trực tiếp với người dùng cuối để cung cấp một danh sách các tính năng rõ ràng cùng độ ưu tiên cho phép đội phát triển có thể thực hiện

- Cộng tác với khách hàng (hoặc đại diện của khách hàng) trên cơ sở hàng ngày là một trong những lý do lý giải tại sao các dữ liệu trong ngành công nghiệp cho thấy rằng các dự án linh hoạt có tỉ lệ thành công cao hơn gấp đôi so với các dự án truyền thống tính trung bình trên toàn thế giới Các phương pháp phát triển linh hoạt đã nhận ra điều đó, và do vậy, chúng đã tạo ra một vị trí đặc biệt trong đội hình phát triển để dành riêng cho vị khách hàng đại diện này

1.2.1.4 Phản hồi với Thay đổi hơn là Bám sát Kế hoạch

- Phản hồi với thay đổi là điều cần thiết cho việc tạo ra một sản phẩm làm hài lòng khách hàng cũng như mang lại những giá trị kinh doanh Dữ liệu

ngành công nghiệp cho thấy hơn 60% các yêu cầu về sản phẩm hay dự án

bị thay đổi suốt quá trình phát triển phần mềm Ngay cả khi các dự án truyền thống kết thúc đúng thời gian, đúng kinh phí, với tất cả các tính năng theo kế hoạch, nhưng khách hàng thường không hài lòng vì những gì họ thấy không thật sự đúng như những gì họ muốn Luật Humphrey nói rằng khách hàng không bao giờ biết những gì họ muốn cho đến khi họ thấy phần mềm hoạt động Nếu khách hàng không nhìn thấy phần mềm hoạt động cho đến khi kết thúc dự án, sẽ là quá muộn cho việc kết hợp các thông tin phản hồi của họ ở thời điểm này Các phương pháp phát triển linh hoạt tìm

đó, để thành công hơn chúng phải có kế hoạch để thay đổi Đó là lý do tại sao chúng thiết lập các quy trình, chẳng hạn như Sơ kết và Cải tiến, được thiết kế đặc biệt để thay đổi các ưu tiên thường xuyên dựa trên thông tin phản hồi của khách hàng và giá trị kinh doanh

1.2.1.5 Nền tảng Agile

- Phát triển linh hoạt bản thân nó không phải là một phương pháp Nó là một thuật ngữ chung mô tả rất nhiều các phương pháp linh hoạt Tại thời điểm

ký kết Tuyên ngôn Agile năm 2001, những phương pháp này bao gồm:

Scrum, XP, Crystal, FDD, và DSDM Kể từ thời điểm đó, Lean cũng đã nổi lên như là một phương pháp linh hoạt có giá trị do vậy cũng được đưa vào trong chiếc ô của các phương pháp Agile trong hình minh họa dưới đây

Hình 2: Agile là chiếc ô – Các phương pháp được triển khai dưới chiếc ô này

- Mỗi phương pháp phát triển linh hoạt có một cách tiếp cận hơi khác nhau

để thực hiện các giá trị cốt lõi trong tuyên ngôn Agile, cũng giống như các ngôn ngữ máy tính có các biểu hiện tính năng cốt lõi trong lập trình hướng

Agile methodology - 13 -

đối tượng theo những cách khác nhau Một cuộc khảo sát gần đây cho thấy rằng, khoảng 50% học viên theo học phương pháp phát triển linh hoạt nói rằng đội của họ đang làm Scrum, 20% khác nói rằng họ đang làm Scrum với các thành phần của XP Khoảng 12% nói rằng họ chỉ áp dụng XP Do

có hơn 80% áp dụng phát triển linh hoạt trên toàn thế giới là sử dụng

Scrum và XP, nên bản MSF cho phát triển phần mềm linh hoạt phiên bản 5.0 tập trung vào quy trình cốt lõi và thực tiễn áp dụng của Scrum và XP

- Scrum là một khung làm việc (framework) cho các quy trình phát triển linh hoạt Nó không bao gồm các vấn đề thực hành, kỹ thuật cụ thể Ngược lại,

XP lại tập trung vào các kỹ thuật thực hành cụ thể nhưng không có một bộ khung làm việc tổng thể cho quá trình phát triển Điều đó không có nghĩa rằng Scrum khuyên bạn không nên áp dụng các phương pháp thực hành

cụ thể hay là XP thì không có quy trình Ví dụ, ban đầu Scrum áp dụng tất

cả các phương pháp thực hành mà bây giờ được biết đến như là XP Tuy nhiên, khung làm việc Scrum cho việc phát triển phần mềm được thiết kế

để có được một nhóm nghiên cứu bắt đầu trong hai ba ngày, trong khi thực hành kỹ thuật phải mất nhiều tháng để thực hiện Vì vậy, nó để lại câu hỏi khi nào (hay không) để thực hiện các thực hành cụ thể đối với mỗi đội Hai đồng tác giả của Scrum là Jeff Sutherland và Ken Schwaber khuyến nghị rằng Nhóm Scrum bắt đầu ngay lập tức và tạo ra danh sách các trở ngại và

kế hoạch cải tiến quy trình Khi việc thực hành về kỹ thuật được xác định là trở ngại, nhóm nên xem xét các phương pháp thực hành của XP như là một cách để cải tiến Các nhóm tốt nhất sử dụng Scrum bổ sung với thực hành XP Scrum giúp XP về mặt quy mô, XP giúp Scrum làm việc tốt hơn

- Bảng sau cho thấy những thuật ngữ quan trọng tương ứng giữa Scrum và

XP

Scrum XP

Chủ sản phẩm (Product Owner) Khách hàng (Customer)

Scrum Master Huấn luyện viên XP (XP coach)

Nhóm Nhóm

Họp Kế hoạch Sprint (Sprint

Planning) Trò chơi lập kế hoạch (Planning Game)

Agile methodology - 14 -

1.2.2 Đặc trưng của Agile

- Có rất nhiều phương pháp agile với các hướng tiếp cận rất khác nhau Bên cạnh các cách thức tổ chức công việc, thiết lập quy trình, các phương pháp agile còn nghiên cứu và đưa vào sử dụng các công cụ và kĩ thuật đặc thù như công cụ tích hợp liên tục (continuous integration), kiểm thử đơn vị, mẫu thiết kế, tái cấu trúc, phát triển hướng kiểm thử (TDD), phát triển hướng hành vi (BDD), hay lập trình theo cặp v.v để đảm bảo và gia tăng tính linh hoạt Tuy vậy các phương pháp này chia sẻ nhiều đặc trưng giống nhau cộng tác nhóm chặt chẽ, tổ chức các nhóm tự quản, liên chức năng, tính đáp ứng cao trong suốt vòng đời của dự án

1.2.2.1 Tính lặp (Iterative)

- Dự án sẽ được thực hiện trong các phân đoạn lặp đi lặp lại Các phân đoạn (được gọi là Iteration hoặc Sprint) này thường có khung thời gian ngắn (từ một đến bốn tuần) Trong mỗi phân đoạn này, nhóm phát triển thực hiện đầy đủ các công việc cần thiết như lập kế hoạch, phân tích yêu cầu, thiết

kế, triển khai, kiểm thử (với các mức độ khác nhau) để cho ra các phần nhỏ của sản phẩm Các phương pháp agile thường phân rã mục tiêu thành các phần nhỏ với quá trình lập kế hoạch đơn giản và gọn nhẹ nhất có thể, và không thực hiện việc lập kế hoạch dài hạn Có phương pháp như Scrum thậm chí sử dụng phương pháp lập kế hoạch just-in-time trong quá trình phát triển Khi đó, thậm chí công việc lập kế hoạch, làm mịn kế hoạch được thực hiện liên tục trong suốt quá trình làm việc

Hình 3: Các phân đoạn lặp đi lặp lại trong agile

1.2.2.2 Tính tiệm tiến (Incremental) và tiến hóa (Evolutionary)

- Cuối các phân đoạn, nhóm phát triển thường cho ra các phần nhỏ của sản phẩm cuối cùng Các phần nhỏ này thường là đầy đủ, có khả năng chạy tốt, được kiểm thử cẩn thận và có thể sử dụng ngay (gọi là potentially shippable product increment of functionality) Theo thời gian, phân đoạn này tiếp nối phân đoạn kia, các phần chạy được này sẽ được tích lũy, lớn

Agile methodology - 15 -

dần lên cho tới khi toàn bộ yêu cầu của khách hàng được thỏa mãn Khác với mô hình phát triển Thác nước – vốn chỉ cho phép nhìn thấy toàn bộ các chức năng tại thời điểm kết thúc dự án, sản phẩm trong các dự án agile lớn dần lên theo thời gian, tiến hóa cho tới khi đạt được trạng thái đủ để phát hành

1.2.2.3 Tính thích ứng (hay thích nghi – adaptive)

- Do các phân đoạn chỉ kéo dài trong một khoảng thời gian ngắn, và việc lập

kế hoạch cũng được điều chỉnh liên tục, nên các thay đổi trong quá trình phát triển (yêu cầu thay đổi, thay đổi công nghệ, thay đổi định hướng về mục tiêu v.v.) đều có thể được đáp ứng theo cách thích hợp Ví dụ, trong Scrum – phương pháp phổ biến nhất hiện nay – trong khi nhóm phát triển sản xuất ra các gói phần mềm, khách hàng có thể đưa thêm các yêu cầu mới, chủ sản phẩm (Product Owner) có thể đánh giá các yêu cầu này và có thể đưa vào làm việc trong phân đoạn (được gọi là Sprint trong Scrum) tiếp theo Theo đó, các quy trình agile thường thích ứng rất tốt với các thay đổi

1.2.2.4 Nhóm tự tổ chức và liên chức năng

- Cấu trúc nhóm agile thường là liên chức năng(cross-functionality) và tự tổ

công công việc mà không dựa trên các mô tả cứng về chức danh (title) hay làm việc dựa trên một sự phân cấp rõ ràng trong tổ chức Các nhóm này cộng tác với nhau để ra quyết định, theo dõi tiến độ, giải quyết các vấn đề

mà không chờ mệnh lệnh của các cấp quản lý Họ không làm việc theo cơ chế “mệnh lệnh và kiểm soát” (command and control) Nhóm tự tổ chức có nghĩa là nó đã đủ các kĩ năng (competency) cần thiết cho việc phát triển phần mềm, do vậy nó có thể được trao quyền để tự ra quyết định, tự quản

lí và tổ chức lấy công việc của chính mình để đạt được hiệu quả cao nhất

1.2.2.5 Quản lý tiến trình thực nghiệm (Empirical Process Control)

- Các nhóm agile ra các quyết định dựa trên các dữ liệu thực tiễn thay vì tính toán lý thuyết hay các tiền giả định (prescription) Việc phân nhỏ dự án thành các phân đoạn ngắn góp phần gia tăng các điểm mốc để nhóm phát triển thu thập dữ kiện cho phép điều chỉnh các chiến lược phát triển của mình Nói cách khác, Agile rút ngắn vòng đời phản hồi (short feedback life cycle) để dễ dàng thích nghi và gia tăng tính linh hoạt Theo thời gian, các

Agile methodology - 16 -

chiến lược này sẽ tiến gần đến trạng thái tối ưu, nhờ đó nhóm có thể kiểm soát được tiến trình, và nâng cao năng suất lao động

1.2.2.6 Giao tiếp trực diện(face-to-face communication)

- Một số mô hình phát triển phần mềm dựa rất nhiều vào công việc giấy tờ,

từ việc thu thập yêu cầu người dùng, viết đặc tả hệ thống, các thiết kế hệ thống v.v Agile không phản đối công dụng của công việc tài liệu hóa,

nhưng đánh giá cao hơn việc giao tiếp trực diện thay vì gián tiếp thông qua giấy tờ Về yêu cầu của khách hàng, agile khuyến khích nhóm phát triển trực tiếp nói chuyện với khách hàng để hiểu rõ hơn về cái khách hàng thực

sự cần, thay vì phụ thuộc nhiều vào các loại văn bản Trong giao tiếp giữa nội bộ nhóm phát triển với nhau, thay vì một lập trình viên (thực hiện việc

mã hóa) và một kĩ sư (thực hiện việc thiết kế) giao tiếp với nhau thông qua bản thiết kế, agile khuyến khích hai người này trực tiếp trao đổi và thống nhất với nhau về thiết kế của hệ thống và cùng nhau triển khai thành các chức năng theo yêu cầu

- Bản thân các nhóm agile thường nhỏ (ít hơn mười hai người, một nhóm lớn thường được phân nhỏ với cơ chế hợp tác đặc thù để luôn luôn có thông lượng giao tiếp tối đa) để đơn giản hóa quá trình giao tiếp, thúc đẩy việc cộng tác hiệu quả Các dự án lớn muốn dùng agile thường phải phân thành nhóm nhỏ đồng thời làm việc với nhau hướng đến một mục tiêu chung Việc này có thể đòi hỏi một số nỗ lực đáng kể trong việc điều phối các mức

ưu tiên giữa các nhóm

- Các nhóm phát triển thường tạo ra các thói quen và cơ chế trao đổi trực diện một cách thường xuyên Một trong các cơ chế thường thấy là các cuộc họp tập trung hằng ngày (daily meeting, Daily Scrum, standup

meeting) Tại đây, tất cả các thành viên được yêu cầu nói rõ cho nhóm của mình biết mình đã làm gì, đang làm gì, sắp làm gì và đang gặp phải khó khăn nào trong quá trình làm việc Khi cơ chế này được thực hiện hiệu quả, nhóm luôn luôn nắm được tình hình công việc của mình, có các hành động thích hợp để vượt qua các trở lực để thực hiện thành công mục tiêu của dự

án

Agile methodology - 17 -

1.2.2.7 Phát triển dựa trên giá trị (value-based development)

- Một trong các nguyên tắc cơ bản của agile là “phần mềm chạy tốt chính là thước đo của tiến độ” Nguyên tắc này giúp nhóm dám loại bỏ đi các công việc dư thừa không trực tiếp mang lại giá trị cho sản phẩm Ví dụ, một nhóm thấy rằng có thể không cần phải viết ra tất cả các thiết kế của hệ thống, mà họ chỉ cần phác thảo các thiết kế này lên bảng, rồi cùng nhau triển khai các chức năng của hệ thống Nhưng nếu như chủ sản phẩm quyết định rằng, khi chuyển giao sản phẩm, nhóm phát triển phải kèm theo thiết kế chi tiết của hệ thống vì chúng chiếm 20% giá trị của dự án theo yêu cầu của khách hàng, và vì khách hàng cần nó để chứng minh tính đúng đắn của các chức năng, và để phát triển tiếp các phân hệ tiếp theo của sản phẩm; thì nhóm phát triển sẽ phải thực hiện việc tài liệu hóa đầy đủ

- Để vận hành được cơ chế “làm việc dựa trên giá trị”, nhóm agile thường làm việc trực tiếp và thường xuyên với khách hàng (hay đại diện của khách hàng), cộng tác trực tiếp với họ để biết yêu cầu nào có độ ưu tiên cao hơn, mang lại giá trị hơn sớm nhất có thể cho dự án Nhờ đó các dự án agile thường giúp khách hàng tối ưu hóa được giá trị của dự án Một cách gần như trực tiếp, agile gia tăng đáng kể độ hài lòng của khách hàng

1.3 So sánh Agile và các phương pháp hiện tại

- Phương pháp phát triển linh hoạt đôi khi bị đánh giá là thiểu tính kỉ luật Những nhận xét như vậy gây ra sự hiểu lầm Để hiểu vấn đề một cách đúng đắn, ta có thể hình dung rằng những phương pháp phát triển phần mềm hiện

có nằm trên một trục đi từ “khả năng thích ứng” tới “khả năng dự đoán trước” thì phương pháp phát triển linh hoạt nằm về phía “khả năng thích ứng”

- Những phương pháp nằm về phía “khả năng thích ứng” có thể thích nghi nhanh chóng với những thay đổi của thực tế Khi mà những yêu cầu của dự án thay đổi, nhóm thực hiện cần phải có những điều chỉnh thích hợp

Họ sẽ gặp khó khăn để mô tả chính xác những gì sẽ xảy ra trong tương lai Tương lai càng xa thì sự khó khăn đó càng lớn Nhóm thực hiện có thể báo cáo chính xác công việc sẽ được tiến hành trong tuần tới nhưng chỉ có thể báo cáo những tính năng nào sẽ được xây dựng trong tháng tới Và khi được hỏi về phiên bản phần mềm trong 6 tháng tiếp theo thì họ chỉ có thể đưa ra được những tính năng chung nhất hoặc đưa ra kinh phí dự kiến

Agile methodology - 18 -

- Trong khi đó những phương pháp nằm về phía “khả năng dự báo trước” trong hợp đồng với khách hàng, tập trung vào xây dựng một kế hoạch chi tiết cho tương lai Nhóm thực hiện dự án có thể báo cáo chính xác những tính năng và công việc cần thực hiện trong toàn bộ quy trình phát triển phần mềm Bản kế hoạch được tối ưu hoá cho những mục tiêu đã đặt ra lúc đầu và sự thay đổi có thể khiến cho công việc đã hoàn thành trở nên vô nghĩa Nhóm phát triển dự án sẽ xây dựng một bảng kiểm soát những thay đổi để đảm bảo rằng chỉ những thay đổi có giá trị mới được xem xét đến

1.3.1 Phân biệt với mô hình thác nước

- Phương pháp phát triển linh hoạt có vài điểm chung nhỏ với mô hình thác nước Hiện nay mô hình thác nước vẫn được sử dụng phổ biến Nó được lên kế hoạch trước và được tiến hành lần lượt qua các bước nắm bắt yêu cầu, phân tích, thiết kế, viết code và kiểm thử một cách nghiêm ngặt Vấn đề của mô hình thác nước là sự phân chia cứng nhắc dự án thành các giai đoạn riêng biệt và do đó rất khó khăn khi muốn thay đổi yêu cầu Chi phí để thực hiện lại rất đắt Điều đó có nghĩa là mô hình thác nước không thích hợp khi mà không thể xác định chính xác, rõ ràng yêu cầu của khách hàng hoặc những yêu cầu có thể thay đổi trong quá trình tiến hành dự

án Phương pháp phát triển linh hoạt, trong hợp đồng, sẽ nhanh chóng đưa ra sản phẩm hoạt động ổn định với những tính năng cơ bản giúp khách hàng sớm được sử dụng sản phẩm phục vụ mục đích của họ Sau đó nhóm phát triển tiếp tục nâng cấp sản phầm trong suốt thời gian tiến hành

dự án, hàng tuần hoặc tháng sẽ bổ sung những tính năng được được phát triển và kiểm thử toàn diện

- Theo khía cạnh này, những người chỉ trích phương pháp linh hoạt có thể quả quyết rằng những tính năng này không được xem xét trong quy mô toàn

dự án Nếu người tài trợ dự án lo ngại về thời gian hoàn thành toàn bộ dự

án đã được định trước hay ngân sách đầu tư cho dự án thì phương pháp linh hoạt có thể không thích hợp Tuy nhiên lời chỉ trích này gặp phải sự phản đối của cộng đồng phát triển phần mềm linh hoạt Họ cho rằng với SCUM (một phương pháp phát triển linh hoạt sẽ được tìm hiểu kĩ hơn ở phần sau), nhóm phát triển có thể đấy nhanh tiến độ thực hiện và liên tục cải thiện kế hoạch chiến lược

Agile methodology - 19 -

- Vài nhóm phát triển phần mềm linh hoạt sử dụng mô hình thác nước với quy mô nhỏ trong các giai đoạn của dự án

1.3.2 Phân biệt với “Cowboy coding”

- Khi những thành viên trong nhóm làm bất cứ điều gì họ cho là đúng, không tuân thủ kỷ luật, nguyên tắc thì người ta gọi đó là “Cowboy coding”

Sự thường xuyên đánh giá lại các kế hoạch của phương pháp phát triển linh hoạt, sự chú trọng vào giao tiếp mặt đối mặt trực tiếp và vấn đề tài liệu

hướng dẫn đi kèm khá ít đôi khi khiến cho người dùng lầm tưởng nó với

“cowboy coding” Tuy nhiên thực tế là nhóm phát triển phần mềm linh hoạt luôn làm việc theo một quy trình đã được vạch rõ ( và thường rất kỷ luật và nghiêm ngặt)

- Giống như tất cả các phương pháp phát triển phần mềm, kỹ năng và kinh nghiệm của người sử dụng quyết định để mức độ thành công hoặc thất bại của sản phẩm Càng có nhiều hệ thống kiểm soát khắt khe được nhúng vào trong quy trình phát triển thì trách nhiệm của người sử dụng càng được nâng cao

2 Mô hình hóa với Agile

2.1 Các giá trị của mô hình hóa Agile

2.1.1 Trao đổi thông tin

- Việc trao đổi thông tin một cách hiệu quả đóng một vài trò cực kì quan trọng đối với nhóm phát triển cũng như đối với các bên liên quan

Agile methodology - 21 -

Hình 5: Cách mô hình hóa UI cho một ứng dụng bằng các thẻ và bảng trắng

2.1.3 Sự phản hồi

- Cần thu nhận các phản hồi thường xuyên và sớm nhất có thể

Hình 6: Các thức phản hồi trong một Sprint của Scrum

2.1.4 Tính can đảm

- Nhóm phát triển cần can đảm áp dụng tất cả các kỹ thuật mới nhất trong việc

đưa ra quyết định cho một giải pháp

Agile methodology - 22 -

2.1.5 Tính khiêm tốn

- Mỗi thành viên trong nhóm phát triển cần khiêm tốn và chấp nhận rằng một

cá nhân không thể nắm bắt tất cả mọi thứ Vì vậy mỗi thành viên trong nhóm đều có một giá trị quan trọng trong việc phát triển dự án

Hình 7: Mô hình các nhóm liên chức năng

2.1 Các nguyên tắc cốt lõi của mô hình hóa agile

2.1.1 Mô hình hóa có mục đích

- Sẽ là không cần thiết nếu tạo một mô hình mà mô hình đó không thể xác

định được lý do cần tạo và đối tượng sử dụng

2.1.2 Sử dụng vốn đầu tư của các bên liên quan với hiệu quả cao nhất

- Các bên liên quan cần có sản phẩm phần mềm phù hợp với nhu cầu của họ bởi họ là đối tượng đã đầu tư tài nguyên (thời gian, tiền bạc, công cụ, v.v )

và dự án Chính vì vậy họ đáng được hưởng một sản phẩm tốt dựa trên

nguyên tắc sử dụng hợp lý, hiệu quả tài nguyên và tránh việc phung phí tài nguyên

2.1.3 Sẵn sàng đối mặt với các thay đổi

- Sẽ là hoàn toàn bình thường nếu như nhóm phát triển nhận được một yêu cầu mới Nhóm phát triển sẽ xem điều đó như một bước tiến hóa của hệ thống và xem xét đến độ ưu tiên cho các thay đổi

2.1.4 Thay đổi theo hướng tiếp cận tăng trưởng

- Trong việc đối mặt với các thay đổi, cần chia công việc ra thành từng phần nhỏ, đánh giá độ ưu tiên và sắp xếp trong các khoảng thời gian hợp lý thay

vì dồn hết tất cả lại trong một lần bàn giao sản phẩm

2.1.5 Áp dụng đa mô hình

- Mỗi mô hình có điểm mạnh và điểm yếu riêng của nó và sẽ phù hợp với một hoàn cảnh nhất định Các phần mềm hiện nay có cúc trúc rất phức tạp

Agile methodology - 23 -

và không một công cụ mô hình hóa nào có thể đáp ứng được cho tất cả các trường hợp mô hình hóa Chính vì vậy để việc mô hình hóa được hiệu quả chúng ta cần sử dụng kết hợp nhiều mô hình để mô hình hóa các hệ thống phần mềm Mỗi mô hình sẽ đóng một vai trò trong việc diễn tả một khía cạnh của hệ thống

2.1.7 Phần mềm chạy tốt là mục tiêu chính

- Coi phần mềm chạy được là mục tiêu chính là một nguyên tắc cốt lõi là bởi

vì mục tiêu chính của toàn bộ quá trình phát triển phần mềm chính là sản xuất ra những phần mềm chất lượng cao phù hợp với yêu cầu của các bên liên quan theo một cách thức hiệu quả nhất Chính vì vậy việc mô hình hóa cần bám sát mục tiêu này Bất kì hoạt động mô hình hóa nào không trực tiếp đóng góp vào thành quả nhằm sản xuất ra các sản phẩm có chất lượng cần được cân nhắc loại bỏ ra khỏi quá trình phát triển

2.1.8 Mục tiêu thứ hai là sẵn sàng nguồn lực cho các giai đoạn kế tiếp

- Một sự án có thể đi đến bờ vực thất bại thậm chí nhóm phát triển đã bàn giao một hệ thống hoạt động ổn định cho người dùng, thỏa tất cả các yêu cầu mà các bên liên quan đặt ra

- Lý do chính của sự thất bại là hệ thống không đủ mạnh để đáp ứng được

sự nâng cấp lặp đi lặp lại theo thời gian Chính vì vậy cần chuẩn bị đầy đủ các mô hình, tài liệu cho việc sẵn sàng phát triển hệ thống trong những chu

kỳ tiếp theo

2.1.9 Chất lượng trong công việc

- Sự luộm thuộm trong công việc sẽ dẫn đến việc khó khăn trong nâng cấp ứng dụng cũng như sự không hài lòng từ phía khách hàng bởi vì hệ thống

có khả năng dễ sụp đổ Chính vì vậy việc tạo ra các mô hình, tài liệu có chất lượng, độ ổn định cao đóng một vài trò hết sức quan trọng

2.1.10 Sự phản hồi nhanh chóng

Agile methodology - 24 -

- Cần có sự liên kết chặt chẽ với khách hàng nhằm nắm bắt sự phản hồi liên tục từ phía khách hàng Sự phản hồi nhanh chóng sẽ giúp phát hiện ra nhiều vấn đề trước lúc nó trở nên nghiêm trọng hơn

- Trong việc mô hình hóa, cùng làm việc với khách hàng sử dụng các kĩ thuật

"mô hình hóa chia sẻ" như bảng trắng, thẻ CRC, thẻ ghi chú sẽ giúp hỗ trợ việc ghi nhận các phản hồi một cách nhanh chóng

2.2 Các phương pháp thực hành của mô hình hóa agile

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

- Một dự án thành công cần sự hỗ trợ ở mức cao bởi các bên liên quan Sự quản lý cấp cao yêu cầu hỗ trỡ cả trong lẫn ngoài đối với dự án, các nhân viên hỗ trợ và vận hành hệ thống cần làm việc một cách chủ động với nhóm phát triển để làm cho môi trường vận hành sản phẩm thực có thể sẵn sàng

để cài đặt sản phẩm trên nó, các nhóm phát triển các hệ thống khác cần nỗ lực trong việc hỗ trợ tích hợp, các nhà phát triển chuyên nâng cấp, bảo dưỡng cần phải thông thạo công nghệ và kĩ thuật được dùng trong dự án

2.2.2 Dùng các công cụ đơn giản nhất

- Rất nhiều mô hình có thể được vẽ trên bảng, trên giấy Bất cứ khi nào chúng

ta muốn lưu trữ một lược đồ, chỉ cần chụp lại lược đồ với một máy ảnh số hay vẽ trên giấy

- Giá trị của một lược đồ là để làm rõ một vấn đề nào đó, và một khi vấn đề đã được giải quyết, lược đồ sẽ không cần nhiều giá trị nữa Chính vì vậy không nên áp dụng nhiều công cụ mô hình hóa phức tạp

2.2.3 Cộng tác trong việc mô hình hóa

- Mục tiêu của mô hình hóa là làm rõ một vấn đề hoặc để diễn đạt các ý tưởng cho những người khách trong nhóm Vì vậy hóm phát triển cần làm việc cùng nhau để tạo một bộ các mô hình cơ bản cho dự án

2.2.4 Chứng minh mô hình bằng mã nguồn

- Mô hình là một thực thể trừu tượng và nên phản ánh chính xác một khía cạnh của sản phẩm thực Vì vậy để biết được mô hình có thực sự hoạt động hay không, cần kiểm nghiệm đó với chính các mã lệnh được viết ra từ nó

2.2.5 Sử dụng các artifact một cách thích hợp

- Artifact là các sản phẩm phụ được tạo ra trong quá trình phát triển phần mềm

Agile methodology - 25 -

- Mỗi artifact chẳng hạn như sơ đồ trạng thái của UML, ca sử dụng "use

case", mã nguồn, lược đồ luồng DFD có điểm mạnh và điểm yếu riêng của

nó Chính vì vậy mỗi artifact chỉ thích hợp trong một ngữ cảnh cụ thể nào đó

2.2.6 Tạo nhiều mô hình song song

- Không có một mô hình đơn lẽ nào có thể phù hợp với tất cả các yêu cầu mô hình hóa vì mỗi mô hình có điểm mạnh và điểm yếu riêng Cần tạo song song nhiều mô hình để các mô hình có thể có sự hỗ trợ lẫn nhau trong việc làm rõ vấn đề và hơn nữa là một mô hình có thể được dùng để tạo nên một

mô hình khác

2.2.7 Lặp lại việc thiết kế với artifact khác

- Bất kì khi nào gặp khó khăn trong việc diễn đạt ý tưởng thông qua một mô hình, cần chuyển qua sử dụng một mô hình khác và lặp lại liên tục như vậy cho đến khi tìm ra giải pháp Bằng cách thay đổi góc nhìn, chúng ta có thể thấy được nguyên nhân chúng ta gặp khó khăn trong việc tạo những mô hình phía trước

2.2.8 Mô hình hóa theo hướng tiếp cận tăng trưởng với độ tăng trưởng nhỏ

- Việc mô hình hóa từng phần nhỏ giúp chúng ta có thể bàn giao sản phẩm đến tay khách hàng nhanh hơn và vì thế có thể nhận được phản hồi từ phía khách hàng nhanh hơn

- Việc mô hình hóa được đặt trong nguyên tắc chung là mô hình hóa một phần nhỏ, viết mã một phần nhỏ, kiểm thử mộts phẩn nhỏ, và bàn giao một phần nhỏ Sẽ không có một thiết kế lớn ngay từ đầu, cụ thể hơn là sẽ không có một giai đoạn mô hình hóa nào kéo dài tới vài tuần hay vài tháng

2.2.9 Sự sở hữu tập thể

- Tất cả mọi người trong nhóm phát triển đều có thể làm việc với bất kỳ mô hình nào được tạo ra bởi nhóm Điều này giúp tạo ra sự hiệu quả trong việc truyền tải ý tưởng giữa các thành viên trong nhóm và cũng giúp phát hiện sớm những sai sót trong quá trình mô hình hóa

2.2.10 Tạo mô hình với nội dung đơn giản

- Cần tạo mô hình với nội dung đơn giản, giữ lại những nội dung thực sự cần thiết mà vẫn đảm bảo mô hình được tạo mô tả đầy đủ các yêu cầu của các bên liên quan

2.2.11 Trình bày mô hình một cách đơn giản

Agile methodology - 26 -

- Cần xem xét việc tạo mô hình tươngs ứng với các đặc tính chủ chốt của sản phẩm Chúng ta có thể mô hình hóa tất cả mọi thứ liên quan tới sản phẩm nhưng điều này không đem lại nhiều giá trị

2.2.12 Trình bày công khai mô hình

- Tạo điều kiện cho các bên liên quan có thể dễ dàng sử dụng các mô hình đã được tạo Việc này nhằm mục đích cho các bên liên quan biết được công việc phát triển sản phẩm đang đi đúng hướng và mang lại nhiều giá trị

2.2.13 Xem xét đến khả năng kiểm thử

- Khi tạo một mô hình cần phải tự đặt ra câu hỏi "Mô hình này có thể được kiểm chứng như thế nào?" Nếu ta xây dựng một mô hình không thể có khả năng được kiểm chứng, mô hình đó không nên được tạo ra

2.3 Phát triển phần mềm theo hướng mô hình hóa agile

- Phát triển phần mềm theo hướng tiếp cận mô hình agile (AMDD) là một phiên bản của phát triển phần mềm theo hướng tiếp cận mô hình(MDD) MDD là hướng tiếp cận theo hướng các mô hình được tạo ra trước khi mã nguồn được viết ra

- Điểm khác biệt của AMDD so với phương pháp truyền thống là thay vì tạo một số lượng lớn các mô hình trước khi viết mã nguồn, chúng ta sẽ tiến hành tạo một số lượng nhỏ hơn các mô hìn sh một cách linh hoạt để vừa đủ đáp ứng cho một chu kỳ phát triển lặp trong Agile