Giới thiệu chung Phát triển phần mềm linh hoạt agile software development – gọi tắt làagile là một nhóm các phương pháp và phương pháp luận phát triển phần mềmdựa trên các nguyên tắc phá
Trang 1Tổng quan về Agile 0.1 Agile giới thiệu chung
0.1.1 Giới thiệu chung
Phát triển phần mềm linh hoạt (agile software development – gọi tắt làagile) là một nhóm các phương pháp và phương pháp luận phát triển phần mềmdự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ữacá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ạchthích ứng (adaptive planning), việc phát triển và chuyển giao theo hướng tiếnhó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ớicác thay đổi trong quá trình phát triển
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 bởi mộtnhóm gồm các nhà sáng tạo Scrum, Extreme Programming (XP), DynamicSystems Development Method (DSDM - Phương pháp Phát triển Hệ thống Linhđộng), và Crystal; đại diện của phát triển hướng-tính-năng (feature-driven); vàmột vài nhà lãnh đạo khác trong lĩnh vực công nghiệp phần mềm Nhờ tính linhhoạ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ựachọ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ầnmềm Theo khảo sát của hãng nghiên cứu thị trường Forrester, mức độ phổ biếncủ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áptruyền thống như thác nước hay CMMi (xem Hình 1.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áttriển phần mềm
Trang 2Có 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êncạ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 agilecò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ấutrúc, phát triển hướng kiểm thử (TDD), phát triển hướng hành vi (BDD), hay lậptrình theo cặp v.v để đảm bảo và gia tăng tính linh hoạt Tuy vậy các phươngpháp này chia sẻ nhiều đặc trưng giống nhau cộng tác nhóm chặt chẽ, tổ chứccá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.
Trang 30.1.2 Vì sao cần Agile
Theo quan niệm truyền thống, một dự án phần mềm được coi là thànhcông khi sản phẩm được giao đúng hạn, trong ngân sách cho phép và làm đúngyêu cầu của khách hàng Trên thực tế, nhiều dự án thỏa mãn tất cả các tiêu chínày nhưng rút cuộc vẫn bị coi là thất bại bởi phần mềm làm ra không đượcngười dùng ưa thích, hoặc không mang lại nhiều lợi ích cho các cá nhân, tổ chức
sử dụng chúng
Ngoài các yếu tố truyền thống nói trên, một dự án phần mềm chỉ được coi
là thành công khi thỏa mãn ba tiêu chí: Thành công ở mức cá nhân, thành công
về mặt kĩ thuật và thành công ở mức công ty Thành công ở mức cá nhân giúpkích thích các thành viên trong nhóm Thành công về kĩ thuật đảm bảo khả năngbảo trì và tiến hóa của sản phẩm Vị trí của nhóm sẽ được bảo đảm nhờ cácthành công mà nhóm mang lại cho công ty Các phương pháp Agile giúp cho dự
án phần mềm đạt được ba thành công này
1) Thành công ở mức công ty
Agile nhắm đến việc tạo ra giá trị cho công ty trong khi làm giảm chi phí.Đồng thời, Agile giúp sớm xác định các kì vọng đối với sản phẩm đang đượcphát triển Nhờ đó, những dự án không mang lại giá trị như mong đợi sẽ đượcphát hiện sớm, tiết kiệm chi phí cho công ty
Theo phương pháp Agile, các chuyên gia về nghiệp vụ (business) sẽ làmviệc trực tiếp cùng với đội dự án Các chức năng quan trọng nhất của sản phẩmđược tập trung phát triển trước và được đưa vào vận hành sớm nhất có thể Cácphiên bản mới với các tính năng mới sẽ lần lượt được đưa thêm vào
Agile giúp tăng cường khả năng giao tiếp giữa các thành viên trong nhóm.Chất lượng mã nguồn được cải tiến liên tục Tiến độ dự án cũng được xem xét
và đánh giá một cách thường xuyên
2) Thành công về mặt kĩ thuật
Trong Extreme Programming, một phương pháp tuân theo triết lí Agile,
Trang 4các lập trình viên làm việc cùng nhau Nhờ vậy, các chi tiết quan trọng sẽ không
bị bỏ sót, mỗi đoạn code sẽ được kiểm tra bởi ít nhất hai người Các lập trìnhviên liên tục tích hợp những đoạn code vừa viết vào hệ thống, cho phép mộtphiên bản mới của phần mềm được “ra lò” bất cứ khi nào nó góp thêm một giátrị đáng kể Hơn nữa, toàn bộ đội dự án tập trung hoàn thành một chức năngtrước khi chuyển sang chức năng tiếp theo Bởi vậy, tiến độ công việc đượckiểm soát tốt hơn và dự án có thể dễ dàng “chuyển hướng” khi có những thayđổi từ phía khách hàng
Ngoài ra, Extreme Programming cũng đề xuất những quy tắc giúp tạo racác thiết kế và các đoạn mã tốt Chẳng hạn, quy tắc “phát triển dựa trên kiểmthử” (test-driven development) trợ giúp lập trình viên viết các chương trình thựchiện đúng chức năng mong muốn
kế hoạch Quyền tự chủ của đội dự án cũng được tăng cường
Các tester nhận thấy họ có ảnh hưởng lớn đến chất lượng sản phẩm, đồngthời giảm được các công việc lặp lại một cách nhàm chán
Nhà quản lí dự án hài lòng vì kiểm soát được tiến độ công việc, dự ánthực hiện đúng các cam kết và làm thỏa mãn khách hàng
Khách hàng, người sử dụng, các chuyên gia nghiệp vụ cảm thấy hài lòng
vì điều kiển được hướng đi của dự án và các ý kiến được lắng nghe
Các nhà lãnh đạo cao cấp sẽ cảm thấy hài lòng vì dự án mang lại lợinhuận lớn cho công ty
0.2 Đặc trưng Agile
Trang 5Đặc trưng của Agile được biểu hiện qua một số thuộc tính sau:
- Danh sách hạng mục yêu cầu ưu tiên
- Perioritied ‘to do’
list
Sản phẩm phần mềm (và các tài liệu liên quan)
Giai đoạn (thường: 2 tuần)
- Danh sách công việc cho giai đoạn
Phân tích Phát triển Kiểm thử Tích hợp
=> Phân tích
=> Xem xét, đánh giá
=> Xây dựng kế hoạch chi giai đoạn tiếp
=> Đánh giá các công việc
Thông tin trao đổi trong nhóm
Thông tin trao đổi ngoài nhóm
Trình bày
Tất cả các thành viên liên quan đến phần mềm nắm được
Mọi công việc phải hoàn thành
Hạng mục công việc có độ ưu tiên Xử lý các hạng
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ạchdà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
Trang 6Hình 2: Các phân đoạn lặp đi lặp lại trong agile
0.2.2 Tính tiệp 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ảnphẩm cuối cùng Các phần nhỏ này thường là đầy đủ, có khả năng chạy tốt, đượckiểm thử cẩn thận và có thể sử dụng ngay Theo thời gian, phân đoạn này tiếpnối phân đoạn kia, các phần chạy được này sẽ được tích lũy, lớn dần lên cho tớikhi 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ểnThá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ếtthú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óacho tới khi đạt được trạng thái đủ để phát hành
0.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ệclậ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áttriển (yêu cầu thay đổi, thay đổi công nghệ, thay đổi định hướng về mục tiêuv.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ácgó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ệctrong phân đoạn (được gọi là Sprint trong Scrum) tiếp theo Theo đó, các quytrình agile thường thích ứng rất tốt với các thay đổi
0.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 và tự tổ chức Theo đó, cácnhóm này tự thực hiện lấy việc phân 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
Trang 7quyế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àmviệc theo cơ chế “mệnh lệnh và kiểm soát” (command and control).
0.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 giả định Việc phân nhỏ dự án thành các phân đoạnngắ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 chophép điều chỉnh các chiến lược phát triển của mình Theo thời gian, các chiếnlượ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 đượctiến trình, và nâng cao năng suất lao động
0.2.6 Giao tiếp trực diện
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ốngv.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ầucủ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ớikhách hàng để hiểu rõ hơn về cái khách hàng thực sự cần, thay vì phụ thuộcnhiề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ớinhau, 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ệnviệc thiết kế) giao tiếp với nhau thông qua bản thiết kế, agile khuyến khích haingườ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) để đơn giảnhó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ốndùng agile thường phải phân thành nhóm nhỏ đồng thời làm việc với nhauhướ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 trao đổi trực diện mộtcá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 trunghằng ngày (daily meeting) Tại đây, tất cả các thành viên được yêu cầu nói rõ
Trang 8cho 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ặpphả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ệuquả, 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 độngthí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.
0.2.7 Phát triển dựa trên giá trị (value-base)
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ấyrằ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ầnphá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ảnphẩ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úngchiế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ácphâ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àiliệ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ườnglà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áchhà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, manglại giá trị hơn cho dự án Nhờ đó các dự án agile thường giúp khách hàng tối ưuhó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
0.3 Các thuật ngữ Agile
Để cung cấp cho các bạn đầy đủ các thuật ngữ của agile bằng tiếng Việt,chúng tôi đã thống nhất và đưa ra các thuật ngữ và giải thích chúng dưới đây.Hanoi Scrum rất mong nhận được sự đóng góp ý kiến và những thắc mắc củacác bạn về các thuật ngữ này
4) Agile software Development – Phát triển phần mềm linh hoạt
Một họ các phương pháp phát triển phần mềm dựa theo các giá trị và
Trang 9nguyên tắc được định nghĩa bởi AgileAlliance.org.
5) Burndown Chart – Biểu đồ Burndown
Là biểu đồ thể hiện xu hướng của công việc còn lại theo thời gian trongmột Sprint, một bản phát hành (Release), hoặc sản phẩm Dữ liệu cho Biểu đồBurndown được lấy từ Sprint Backlog và Product Backlog, với công việc còn lạiđược theo dõi trên trục tung và khoảng thời gian (các ngày trong một Sprint,hoặc nhiều Sprint) theo dõi trên trục hoành Biểu đồ Burndown được dùng choBản phát hành (khi đó gọi là Release Burndown) hoặc cho Sprint (gọi là SprintBurndown)
6) Chicken – Gà
Một người nào đó quan tâm đến dự án nhưng không có trách nhiệm trong
dự án (không giữ các vai trò Nhóm Phát triển, Product Owner hay ScrumMaster)
7) Daily Scrum – Buổi họp hàng ngày (hay Họp Scrum hàng ngày)
Một cuộc họp ngắn được tổ chức hàng ngày của mỗi Nhóm Phát triển,trong thời gian đó các thành viên của nhóm kiểm tra công việc của họ, đồng bộhóa công việc và tiến độ của mình và báo cáo các vấn đề để giải quyết Nhóm vàScrum Master có thể phải tiến hành các hoạt động tiếp theo Daily Scrum đểthích ứng với công việc sắp tới và tối tưu hóa Sprint
Với Scrum, để giải quyết các mâu thuẫn kể trên, đồng thời để đảm bảotiến độ của các đội, Scrum đưa ra ý tưởng về Daily Scrum Daily Scrum là mộtbuổi họp nhằm điều hướng công việc của nhóm lập trình và là buỗi họp diễn ramỗi ngày Để giữ cho buổi họp diễn ra nhanh chóng, các lập trình viên chỉ trả lờiđối với ba câu hỏi sau:
a) Bạn đã làm gì ngày hôm qua?
b) Bạn định làm gì hôm nay?
c) Có gì cản bước bạn không?
Trong suốt cuộc họp Daily Scrum, các lập tình viên không được phép nói
Trang 10chuyện về các vấn đề không liên quan, trình diễn cái họ đã làm, hay nói vềnhững kinh nghiệm khi giải quyết các vấn đề lập trình Buổi họp phải diễn ranhanh gọn, thường là trong 15 phút Các vấn đề được nêu ra trong Daily Scrum
sẽ được thảo luận kỹ hơn trong các cuộc meeting khác, và lúc đó không cần thiếtphải có sự có mặt của toàn đội
8) Done - Hoàn thành
Định nghĩa về sự hoàn thành (Done Definition - Định nghĩa Hoàn thành)được đồng thuận giữa tất cả các bên và phù hợp với tiêu chuẩn, quy ước của tổchức cũng như các chỉ dẫn khác Khi một công việc được ghi nhận là "Done"tại cuộc họp Sơ kết Sprint , nó phải phù hợp với định nghĩa về sự hoàn thànhnày
9) Estimated Work Remaining – Công việc ước tính còn lại
Số giờ mà một thành viên của nhóm ước lượng để thực hiện một côngviệc nào đó Ước lượng này được cập nhật hằng ngày khi thành viên đó thựchiện công việc trong Sprint Backlog Đây là con số ước tính tổng số giờ còn lại
để hoàn thành công việc, không kể đến số lượng người thực hiện công việc hay
số giờ đã bỏ ra cho công việc ấy trong quá khứ
10) Empirical Process Control – Quản lý tiến trình thực nghiệm
Đây là phương pháp quản lý các tiến trình (process) không dựa trên giảđịnh và tính toán lý thuyết (Predictive management) mà dựa trên các khảo sát kĩlưỡng và thích nghi với các biến động trên thực tiễn
11) Increment – Tăng trưởng
Là phần tăng trưởng của sản phẩm được phát triển bởi Nhóm Phát triểntrong mỗi Sprint Đôi khi increment được dịch gần đúng là “gói phần mềm”, hayđơn giản là gói
12) Increment of Potentially Shippable Product Functionality
Một phần nhỏ nhưng hoàn chỉnh của sản phẩm tổng thể hoặc hệ thống cóthể được sử dụng bởi chủ sở hữu sản phẩm hoặc các bên liên quan
Trang 1113) Iteration – Phân đoạn
Trong các phương pháp phát triển linh hoạt, iteration chỉ một phân đoạnvới khoảng thời gian ngắn nhằm phát triển một phần nhỏ của hệ thống Một dự
án sẽ gồm nhiều phân đoạn lặp đi lặp lại
14) Sprint – Phân đoạn nước rút trong scrum
Một phân đoạn (iteration), là một chu kỳ lặp đi lặp lại công việc tương tựnhằm tạo ra các phần tăng trưởng (increment) cho hệ thống Sprint thường kéodài từ một tuần tới một tháng.Trong suốt dự án, thời gian cho một Sprint là cốđịnh Từ “sprint” có nghĩa là giai đoạn nước rút, ám chỉ sự gấp gáp và tập trungcao độ trong khoảng thời gian ngắn để làm việc
15) Pig – Lợn
Một người nào đó thực hiện một trong ba vai trò của Scrum (Team,Product Owner hoặc Scrum Master), người đã có những cam kết và có quyền đểthực hiện cam kết của mình
16) Product Backlog
Một danh sách ưu tiên của các yêu cầu với thời gian ước tính để biếnchúng thành các tính năng hoàn chỉnh của sản phẩm Các hạng mục được ưutiên hơn trong Product Backlog được ước lượng cẩn thận hơn, và thường chínhxác hơn các phần khác Danh sách này có thể thay đổi khi có sự thay đổi trongđiều kiện kinh doanh hoặc công nghệ Trong tiếng Anh, 'backlog' có nghĩa làphần việc tồn đọng, cần phải giải quyết
17) Product Backlog Item – Hạng mục Product Backlog
Một yêu cầu chức năng hay phi chức năng, và các vấn đề được sắp độ ưutiên Độ chính xác của ước lượng phụ thuộc vào tầm quan trọng và độ chi tiếtcủa hạng mục đó Phần có độ ưu tiên cao nhất sẽ được chọn trong Sprint tiếptheo để làm việc
18) Product Owner – Chủ sản phẩm
Người chịu trách nhiệm quản lý Product Backlog để tối đa hóa giá trị của
dự án Chủ sở hữu sản phẩm có trách nhiệm đại diện cho lợi ích của tất cả mọi
