Giới thiệu ScrumDay là một chuỗi hội thảo phi lợi nhuận chuyên sâu về phương pháp phát triển phần mềm Agile\Scrum, sự kiện này được diễn ra tại nhiều thành phố trên thế giới. Năm 2012, lần đầu tiên Cộng đồng Scrum tại Hà Nội đã tổ chức ScrumDay và đạt được nhiều thành công tốt đẹp. Đến 2013, ScrumDay với chủ đề “Transition” mong muốn tiếp tục là Ngày hội của cộng đồng Scrum Hà Nội với các mục đích: Giới thiệu và thúc đẩy sự phát triển Agile\Scrum Phát triển một cộng đồng Agile\Scrum lớn mạnh ở Việt Nam từ đó góp phần đổi mới và phát triển ngành phát triển phần mềm Việt Nam Chia sẻ kinh nghiệm triển khai từ những người thực hành và chuyên gia Hỗ trợ các Công ty\Tổ chức trong việc áp dụng và thực hành phương pháp Agile\Scrum Khác với ScrumDay 2012 nội dung đề cập tới hầu hết các khía cạnh căn bản trong Agile\Scrum, đối tượng trải rộng từ sinh viên\developer tới những nhà quản lý, hội nghị năm nay với chủ đề là “Transition” và hướng tới các đối tượng như sau: Giám đốc\Quản lý doanh nghiệp trong lĩnh vực phần mềm: những người mong muốn thấu hiểu khách hàng hơn, đáp ứng tốt hơn nguyện vọng của họ để phát triển kinh doanh. Các CTO: những người đang đau đầu với sự thay đổi quá nhanh của Công nghệ, muốn có một công cụ mạnh hơn cho chiến lược công nghệ tại công ty Team Leader: Những người mong muốn xây dựng một team mạnh Các Tech Startup founders: Những người luôn muốn tạo ra sản phẩm đột phá "disrupt the market" Salesperson\Marketer: Những người muốn áp dụng Agile\Scrum vào công việc của mình Những Nhà thực hành và nghiên cứu Agile\Scrum: những người đam mê và thực hành triết lý Agile, những người có đam mê chia sẻ hiểu biết để cùng nhau xây dựng một cộng đồng Agile mạnh tại Việt Nam, góp phần thúc đẩy sự phát triển của ngành.

1. Phương pháp luận
dự án phần mềm:
Truyền thống và Agile
Ngô Trung Việt
Giám đốc tri thức QNET
ntviet@gmail.com

2. Nội dung
● Mô hình vòng đời hệ thống
● Phương pháp luận
● Khuôn khổ qui trình phát triển phần mềm
● Khuôn khổ: truyền thống và Agile
● Agile
● XP
● Scrum

3. 1. Mô hình vòng đời hệ thống
● Mô hình vòng đời hệ thống nhấn mạnh
chủ yếu vào công việc phải làm khi phát
triển một sản phẩm (khía cạnh kĩ thuật):
● Những pha bắt buộc phải trải qua,
● Sản phẩm và tài liệu cần được tạo ra.

4. Mô hình
thác đổ
Waterfall
Quan niệm phần mềm
Yêu cầu
Phân tích
Thiết kế
Viết mã & gỡ lỗi
Kiểm thử hệ thống
Triển khai & bảo trì
•Quan niệm
•Thăm dò quan niệm
•Thăm dò hệ thống
•Phân tích yêu cầu
•Thiết kế kiến trúc
•Thiết kế chi tiết
•Thực hiện
•QA
•Sản xuất
•Vận hành

5. Thác đổ
● “Cụ tổ” của các mô hình
● Trình tự tuyến tính của các pha
● Mô hình “thuần”: không chờm lấp pha
● Dẫn lái theo tài liệu
● Mọi việc lập kế hoạch đều phải được làm
từ phía trước

6. Điểm mạnh của thác đổ
● Có tác dụng tốt cho các dự án với:
● Định nghĩa sản phẩm ổn định
● Công nghệ được hiểu rõ
● Ràng buộc chất lượng mạnh hơn chi phí &
lịch biểu
● Hỗ trợ cho cán bộ yếu về kĩ thuật
●Cung cấp cấu trúc
●Tốt cho các dự án hải ngoại

7. Nhược điểm của thác đổ
● Không linh hoạt:
● Nước đi cứng nhắc từ bắt đầu -> kết thúc
● Tổ có thể theo đến cùng các kế hoạch lỗi thời
● Khó hoàn toàn xác định được các yêu cầu từ đầu.
● Có thể là quá tin tưởng vào qui trình.
● Có thể có các qui trình thực tế không được tuân theo.
● Có thể phí nhiều thời gian để tạo ra quá nhiều tài liệu.
● Ít dấu hiệu thấy được tiến độ cho tới cuối.
● Khách hàng/Người dùng chỉ thấy được sản phẩm ở
lúc cuối.

8. Mô hình thác đổ
Rấ t thường là khá ch hà ng không biết đı́ch xá c yêu cầ u
cho dự á n, và chắc chắn sẽ thay đổi khi dự á n tiến
triển. Người phá t triển có thể phải quay lại pha trước
để là m sá ng tỏ. Rấ t tốn thời gian là m lại việc.
Yêu cầu
Thiết kế
Viết mã
Kiểm thử
Tích hợp

9. Mô hình làm bản mẫu
● Mô hình làm bản mẫu có thể xây dựng phần
mềm nhanh chóng và không tốn kém để đánh
giá và trình diễn.
● Việc phát triển hệ thống không đầy đủ là để hiểu
hệ thống và tính đổi qui mô của vấn đề.
● Chẳng hạn:
● Bản mẫu – mô hình của sản phẩm, dịch vụ hay thệ
thống được đề nghị.
● Bản mẫu chứng minh khái niệm – được dùng để
chứng tỏ tính khả thi kĩ thuật của hệ thống.
● Bản mẫu bán – được dùng để thuyết phục mọi người
về giá trị của hệ thống được đề nghị

10. Mô hình bản mẫu
Lắng nghe & thu
lấy yêu cầu từ
khách hàng
Dựng/Sửa
bản thử
Khách hàng chạy
bản thử

11. Mô hình phát triển ứng dụng nhanh
Vài lần lặp được xây dựng để giúp đưa hệ thống vào vị trí.
Yêu cầu Thiết kế Viết mã Kiểm thử
Yêu cầu Thiết kế Viết mã Kiểm thử
Yêu cầu Thiết kế Viết mã Kiểm thử
Yêu cầu Thiết kế Viết mã Kiểm thử
Tích hợp

12. Mô hình gia tăng
● Vòng đời phát triển gia tăng là mô hình
phân giai đoạn trong đó các phần khác
nhau của hệ thống được phát triển ở
những lúc khác nhau và được tích hợp khi
chúng được hoàn thành.
● Phát triển lặp là chiến lược lập lịch làm
lại theo đó xét lại và cải tiến các phần của
hệ thống.
● Ý tưởng cơ bản là phát triển hệ thống
phần mềm tăng dần.

13. Mô hình gia tăng
Yêu cầu
Yêu cầu
Yêu cầu
Th. Kế Mã Kiểm Tích hợp Bảo trì
Đưa ra 1
Th. Kế Mã Kiểm Tích hợp Bảo trì
Đưa ra 2
Th. Kế Mã Kiểm Tích hợp Bảo trì
Đưa ra 3
Yêu cầu liên tục được phân tích rồi cấp phát
cho một loạt các đưa ra gia tăng.

14. Mô hình xoáy ốc
Xác định mục
tiêu, phương án
và ràng buộc
Đánh giá phương
án nhận diện và
giảm nhẹ rủi ro
Lập kế hoạch
Phát triển và trắc nghiệm
lần lặp sản phẩm tiếp
Phân tích
rủi ro
Phân tích
rủi ro
Phân tích
rủi ro
Bản mẫu 1 2 3
Lập kế hoạch
yêu cầu
Lập kế hoạch
phát triển
Thiết kế
Viết mã
Kiểm thử

15. Xoáy ốc
● Chuỗi các tiểu dự án, từng dự án nhỏ đề
cập tới một tập các “rủi ro”.
● Bắt đầu nhỏ, thám hiểm rủi ro, làm bản mẫu,
kế hoạch, lặp lại
● Nhấn mạnh vào phân tích & quản lí rủi ro
trong từng pha.
● Lặp sớm là “rẻ nhất”.
● Số xoáy ốc (lặp) là biến thiên.

16. Điểm mạnh điểm yếu của xoáy ốc
● Ưu điểm
● Có thể được tổ hợp với các mô hình khác
● Khi chi phí tăng, rủi ro giảm
● Xu hướng rủi ro cung cấp cảnh báo sớm
● Nhược điểm
● Phức tạp
● Yêu cầu cấp quản lí có ý thức, thông thái

17. V- mô hình kĩ nghệ hệ thống cổ điển
Xây
dựng
Kiểm thử
đơn vị
Yêu cầu
hệ thống
Kiểm thử
hệ thống
Yêu cầu
phần mềm
Kiểm thử
chấp nhận
Thiết kế
sơ bộ
Kiểm thử
tích hợp
Thiết kế
chi tiết
Kiểm thử
cấu phần
Kiểm thử
và tích hợp
Phân tích
và thiết kế

18. 2. Phương pháp luận
● Tuyển tập các chính sách
và thủ tục được làm tài liệu
bởi tổ phát triển hay tổ chức
để thực hành kĩ nghệ phần
mềm được gọi là phương
pháp luận phát triển phần
mềm - software
development methodology
(SDM))

19. Phương pháp luận (t.)
● Mọi SDLC đều có chung các qui trình, nhưng
chúng có thể thực hiện theo cách khác nhau
● Hiến chương dự án và hoàn cảnh doanh nghiệp
● Yêu cầu sản phẩm
● Kiến trúc mức đỉnh, cách tiếp cận kĩ thuật và thiết kế
hệ thống
● Cấu phần và đặc tả đơn vị và thiết kế
● Viết mã, lập kế hoạch kiểm thử đơn vị và kiểm thử
đơn vị
● Kiểm thử đơn vị và tích hợp
● Kiểm thử hệ thống
● Cài đặt, chuyển giao và chuyển dịch
● Đào tạo và hỗ trợ người dùng
● Nâng cấp hệ thống và bảo trình phần mềm thường lệ

20. Phương pháp luận (t.)
● Mọi SDLC đều dùng cùng các qui trình hỗ trợ
(kết cấu nền), nhưng chúng có thể thực hiện
khác nhau
● Kiểm soát mã nguồn
● Quản lí cấu hình
● Tích hợp liên tục
● Kiểm soát thay đổi
● Dõi vết lỗi
● Thu thập và phân tích các độ đo
● v.v.
● Tất cả những điều này đều cần thời gian và tài
nguyên để thực hiện và quản trị

21. Hai kiểu phương pháp luận
Truyền thống
Agile

22. Phương pháp luận truyền thống
● Giả định yêu cầu được biết lúc bắt đầu dự án.
● Chủ sản phẩm/người dùng tham gia cùng tổ
phát triển là tối thiểu sau khi yêu cầu được chấp
thuận.
● Lịch biểu, ngân sách, kiến trúc và thiết kế cho cả
dự án được tạo ra “từ đầu” theo yêu cầu đã cho.
● Thay đổi được quản lí một cách chính thức. Làm
lại là tốn kém và không được hỗ trợ.
● Nhiều tài liệu

23. Điểm mạnh của truyền thống
● Có tác dụng tốt cho các dự án mà:
● Định nghĩa sản phẩm ổn định
● Công nghệ được hiểu rõ
● Ràng buộc chất lượng mạnh hơn chi phí & lịch biểu
● Hỗ trợ cho cán bộ yếu về kĩ thuật
● Cung cấp cấu trúc
● Tốt cho các dự án ra nước ngoài
● Mô hình xoáy ốc là chuỗi các tiểu dự án, nơi
từng dự án đề cập tới một tập các rủi ro
● Bắt đầu nhỏ, thăm dò rủi ro, làm bản mẫu, lập kế
hoạch, lặp lại
● Từng lần lặp đều “rẻ nhất”

24. Điểm yếu của truyền thống
● Không linh hoạt
● Tổ có thể kiên trì theo kế hoạch lỗi thời
● Yêu cầu khó xác định từ đầu
● Người dùng có xu hướng xác định nhiều yêu
cầu như họ nghĩ tới
● Tin cậy vào qui trình (điều có thể không có tác
dụng tốt hay không được tuân theo)
● Có thể tạo ra quá nhiều tài liệu
● Ít dấu hiệu về tiến bộ mãi cho tới cuối

25. Phương pháp luận Agile
● Giả định rằng yêu cầu sẽ nổi lên khi người chủ
sản phẩm/người dùng làm việc cùng tổ phát
triển trên cơ sở hàng ngày.
● Lịch biểu, ngân sách, kiến trúc và thiết kế cho
dự án tiến hoá khi yêu cầu nổi lên
● Thay đổi được quản lí không chính thức
● Sản phẩm được xây dựng nên bạn bao giờ cũng
hệ thống làm việc và có thể “đưa ra” vào mọi lúc.
● Làm lại (cải biên lại) là tốt

26. Scrum

27. Agile
● Yêu cầu được làm tài liệu như “câu chuyện
người dùng” (tồn dư tính năng sản phẩm)
● Thực hiện xuất hiện trong các đợt nước rút
‘sprints’ ngắn.
● Lập kế hoạch tiền và hậu sprint và các hoạt
động chấp nhận.
● Tổ tự quản.
● Họp đứng ngắn (<30 phút) hàng ngày để
trao đổi về tình trạng & vấn đề

28. Điểm mạnh của Agile
● Đảm bảo đáp ứng nhu cầu của khách hàng (người
chủ sản phẩm xác định câu chuyện người dùng để
thực hiện trong từng sprint)
● Yêu cầu không quan trọng không được phát triển
● Tài liệu tối thiểu. Ví dụ:
● Yêu cầu được xác định như câu chuyện người
dùng
● Tổ phát triển là được tin cậy
● Từng sprint tạo ra sản phẩm giao được tiềm năng.

29. Nhược điểm của Agile
● Thiếu yêu cầu miền dài nghĩa là lập kế
hoạch miền dài tối thiểu
● Việc nổi lên yêu cầu đòi hỏi quản lí yêu
cầu phải uỷ quyền thẩm quyền ra quyết
định cho tổ Scrum.
● Yêu cầu nhiều người phát triển cấp cao.
● Một số công nhân không thoải mái với
việc tạo khả năng chịu trách nhiệm Scrum

30. 3. Khuôn khổ qui trình
● Các qui trình phần mềm của tổ chức bắt
đầu đi liền với việc quản lí các tổ chức tri
thức và việc nâng cao chất lượng quản lí
toàn bộ tổ chức.
● Nói riêng Quản lí dự án theo khuôn khổ
qui trình nhằm đạt mục tiêu của tổ
chức chứ không chỉ mục tiêu sản
phẩm.

31. Khuôn khổ qui trình
phát triển phần mềm
● Khuôn khổ qui trình phát triển phần mềm
là qui định chung trong toàn tổ chức mà
● dựa trên các mô hình vòng đời phần mềm
tổng quát,
● Nêu rõ các vai trò, trách nhiệm, vật phẩm, thủ
tục, phương pháp, … phải được mọi người và
dự án tuân thủ.
● Khuôn khổ qui trình phần mềm đề cập tới
con người làm việc dựa trên kĩ thuật,
nhấn mạnh vào qui trình phối hợp, khía
cạnh chất lượng và tổ chức.

32. Tại sao cần qui trình phần mềm?
● Bằng việc hội tụ chỉ vào sản phẩm phần mềm,
bạn không thể giải quyết được vấn đề kích cỡ
và độ phức tạp (tính đổi qui mô) và không có tri
thức về cách làm nó tốt hơn.
● Bằng việc hội tụ vào qui trình phần mềm và hiểu
mọi bước trên con đường phát triển, bạn có thể
dự đoán chất lượng của sản phẩm, xu hướng
dự án, và có khả năng lặp lại điều bạn đã làm
trong công việc tương lai.

33. Yếu tố qui trình
● Qui trình được xác định của tổ chức bao gồm vài
“Yếu tố qui trình” cho các hoạt động như:
● Ước lượng phần mềm, lập kế hoạch phần mềm
● Kiến trúc, thiết kế, làm mô hình, luồng phần mềm
● Viết mã, kiểm thử và kiểm soát thay đổi
● Kiểm điểm, giám định
● Đào tạo và làm tài liệu
● Các yếu tố qui trình được mô tả dưới dạng chuẩn,
thủ tục, hướng dẫn, khuôn mẫu, trừu tượng. v.v
● “Qui trình được xác định” của tổ chức hỗ trợ cho các
mô hình vòng đời như Thác đổ, Xoáy ốc, Dựng gia
tăng, Bản mẫu v.v

34. Các góc nhìn cải tiến qui trình
● Việc cải tiến qui trình truyền thống được
nhìn theo các góc độ khác nhau: chất
lượng sản phẩm, qui trình, cách tổ chức
● Các mô hình vòng đời thác đổ,
● TQM: cải tiến chất lượng toàn bộ,
● CMMI: mô hình trưởng thành năng lực
● ISO 9000: tổ chức quản lí
● Six Sigma: quản lí chất lượng

35. TQM

36. Cải tiến chất lượng toàn bộ TQM
● Mọi người phát triển đều là người chịu
trách nhiệm cho chất lượng việc mình làm
● Đảm bảo chất lượng ở mọi khâu
● Đảm bảo tuân thủ qui trình qua việc tiến
hành hoạt động QA, QC
● Người chịu trách nhiệm QA phải là những
người quản lí giầu kinh nghiệm.

37. CMMI

38. Mô hình tăng trưởng năng lực tích hợp (CMMI)
● Mô hình khái niệm để giúp tổ chức:
● Đặc trưng hoá sự trưởng thành về qui trình của họ (nó
vậy)
● Thiết lập mục đích cho cải tiến qui trình (sẽ vậy)
● Đặt ưu tiên cho hành động ngay (chuyển tiếp)
● Quản lí và duy trì thay đổi trong tổ chức (ổn định hoá)
● Đưa vào thay đổi dần để tránh ngắt quãng qui trình hiện
thời.
● Mức độ trưởng thành là tập các “chuẩn văn hoá kĩ nghệ
phần mềm” được thiết lập vững chắc – dựa trên các
thực hành tốt nhất trong công nghiệp.
● Từng mức trưởng thành bao gồm vài Khu vực qui trình
(PA) để hướng dẫn tổ chức hướng tới “các chuẩn văn
hoá kĩ nghệ phần mềm” này.

39. CMMI và mục đích doanh nghiệp
Kế hoạch cải tiến
qui trình phần mềm
Mục đích kinh doanh của tổ chức
CMMI Trưởng thành
năng lực hiện thời
Nhiệm
vụ
Đào tạo
Kiểm điểm
Thực hiện
Thực hiệnNhiệm vụ cải tiến
CMMI chỉ là hướng dẫn
Mục đích doanh
nghiệp là dẫn lái chính
Kế hoạch dựa trên kết
quả đánh giá
Dữliệuđượcdùngđểthẩmtrakếtquảcảitiến

40. Six Sigma

41. Six Sigma
● Là phương pháp luận quản lí
● Khách hàng được hội tụ
● Quyết định đưa ra theo dữ liệu
● Thu được hiệu năng đột phá
● Kết quả tuyến đáy được kiểm nghiệm

42. Khuôn khổ nặng cân và nhẹ cân
● Khuôn khổ truyền thống: chia pha và làm
tài liệu nhiều được coi là nặng cân.
● Khuôn khổ Agile: tập trung vào lập trình,
bớt yêu cầu tài liệu nhưng tăng tương tác
với khách hàng, được coi là nhẹ cân.
● Ví dụ về phương pháp Agile
●RAD
●XP
●Scrum

43. 4. Khuôn khổ truyền thống và Agile
● Phương pháp luận theo kế hoạch khẳng
định nhu cầu cần kỉ luật qui trình mạnh và
thực hành nghiêm túc.
● Sản phẩm chất lượng tới từ qui trình chất
lượng.
● Giả định các yêu cầu được biết vào lúc bắt
đầu.
● “Đây là lịch biểu & ngân sách được cho theo
các yêu cầu này.”
● Thay đổi được quản lí chính thức.
● Làm lại việc là tồi tệ.

44. Phương pháp luận theo kế hoạch
so với Agile
● Phương pháp luận Agile dùng cho các mô thức
nhẹ, dễ thích nghi.
● Sản phẩm được dựng để bao giờ cũng có hệ thống
làm việc và có thể "đưa ra" vào bất kì lúc nào.
● Chỉnh sửa là tốt.
● Cương lĩnh Agile nói rằng chúng ta đi tới đánh
giá:
● Cá nhân & tương tác qua qui trình & công cụ.
● Phần mềm làm việc qua tài liệu thấu đáo.
● Cộng tác của khách hàng qua thương lượng hợp
đồng.
● Đáp ứng với thay đổi qua việc tuân theo kế hoạch.

45. Phương pháp luận theo kế hoạch
so với Agile (t.)
● Cách nào tốt nhất? Còn tuỳ theo thuộc
tính và môi trường của dự án.
● Yêu cầu nổi lên hay đã biết?
● Văn hoá của dự án và tổ chức.
● Tri thức chuyên gia của tổ.
● Tính sẵn có của khách hàng.
● Bản chất của mối quan hệ với khách hàng.
● Độ phức tạp của khách hàng.

46. Đo truyền thống so với Agile
● Chúng ta có xây dựng sản phẩm đúng không?
● Truyền thống: Quản lí yêu cầu
● Agile: Chấp nhận của khách hàng sau từng sprint
● Dự án mất bao lâu?
● Truyền thống: Kế hoạch lớn từ đầu & giá trị thu được
● Agile: Gia tốc & Sơ đồ Burn Down
● Dự án tốn bao nhiêu tiền?
● Truyền thống: Kế hoạch lớn từ đầu & giá trị thu được
● Agile: Người phát triển được phân 100% cho dự án,
cho nên chi phí dự án là # số người phát triển * # số
sprints

47. Đo truyền thống so với Agile
● Thay đổi sản phẩm
● Truyền thống: Cần được quản lí
● Agile: Phần tự nhiên của cuộc họp về nhu cầu khách
hàng. Chỉ cần đo số câu chuyện
● Làm lại và cải biên
● Truyền thống: Làm lại là dở, phải dẹp
● Agile: Cải biên là phần tự nhiên của đáp ứng nhu cầu
khách hàng. Không cần đo
● Chất lượng
● Truyền thống: chất lượng qui trình & sản phẩm
● Agile: Nhấn mạnh vào chất lượng sản phẩm

48. 5. Khuôn khổ dự án Agile

49. Qui trình Agile điển hình

50. Yếu tố Agile thành công
● Người lãnh đạo là người quản lí dự án
giỏi: “Là người quản lí dự án, bạn có sẵn
lòng thay đổi để trở thành người lãnh đạo
giỏi hơn không?”
● Tổ có kinh nghiệm và có kỉ luật: “Là thành
viên tổ, bạn có đủ kinh nghiệm và kỉ luật
để áp dụng phương pháp agile vào công
việc của bạn không?”
● Liên hệ chặt chẽ với khách hàng

51. Yêu cầu của Agile
● Tổ phát triển phải toàn những cá nhân tài năng,
người sẵn lòng và có khả năng thuộc vào loại
những nhà tổng quát, có thể làm việc xuyên qua
miền rộng các bước của vòng đời truyền thống.
● Agile yêu cầu các cá nhân đa kĩ năng, người có
động cơ cá nhân, biết nghiên cứu, có tính phân
tích, sáng tạo, và có các kĩ năng liên con người
rất cao để hiểu vấn đề của khách hàng.
● Tổ Agile có kết hợp chặt chẽ với khách hàng

52. Nhược điểm của Agile
● Được thiết kế để làm việc trong môi trường rất
nhỏ, không then chốt (trang Web, trạm web) nơi
mọi sự phải xảy ra rất nhanh chóng và nếu mọi
thứ không làm việc thì bắt đầu lại toàn bộ.
● Đòi hỏi sự hợp tác chặt chẽ của khách hàng
ngay bên cạnh trong quá trình làm sản phẩm.
● Cần rất thận trọng về dùng Agile trong các dự án
lớn nơi kỉ luật là quan trọng và tài liệu là then
chốt. Nói riêng, nó không nên được dùng trong
các dự án lớn và trong môi trường nghiệp vụ
điển hình.

53. Đào tạo về dùng Agile
● Phần lớn đào tạo về quản lí dự án hội tụ vào dự
án lớn tập trung theo cách tiếp cận "vòng đời
thác đổ."
● Khi công ti dùng phương pháp agile, người quản
lí dự án phải được đào tạo lại
● giữ các nhiệm vụ dự án nhỏ (8 tới 20 giờ),.
● Mọi nhiệm vụ đều có định nghĩa về "làm xong."
● Phương pháp Agile hội tụ nhiều vào công việc tổ,
hội tụ nhiều vào chức năng hơn vào kiến trúc
● Cả tổ tham gia lập lịch và ước lượng, cần người
quản lí cấu hình và phiên bản
● Vai trò người quản lí là lãnh đạo và thầy kèm chứ
không giám sát và kiểm soát.

54. 6. Lập trình cực đoan XP

55. Lập trình cực đoan – qui trình

56. XP
● Dựa trên bốn giá trị:
● Trao đổi: Tiến hành trao đổi tích cực.
● Tính đơn giản: Thủ tục đơn giản nhất đáp ứng nhu
cầu khách hàng.
● Phản hồi: Thu và đánh giá phản hồi từ khách hàng, hệ
thống.
● Dũng cảm: Được chuẩn bị để ra quyết định cứng rắn.
● Tổ nhỏ.
● Khách hàng liên tục hiện diện tại chỗ.
● Lặp ngắn (không quá 3 tuần).
● Cách tiếp cận kiểm thử trước.
● Dựng và tích hợp liên tục.

57. XP

58. Điểm mạnh của XP
● Phương pháp Agile được thừa nhận rộng
rãi nhất.
● Giữ kỉ lục thành công lớn với các ứng
dụng nhỏ.
● Trao đổi và tham gia rất mạnh cùng khách
hàng làm giảm nhẹ rủi ro của việc nổi lên
yêu cầu.
● Thực hành XP lập trình cặp đôi tại http:
//www.agileventures.org/projects

59. Nhược điểm của XP
● Đổi qui mô là vấn đề
● Ít kinh nghiệm với tổ lớn hơn
● Có xu hướng cần phương pháp quản lí có kỉ
luật hơn để tổ lớn hơn làm việc
● Một số rào chắn sử dụng:
● Tổ không được xếp cùng chỗ
● Chu kì phản hồi dài (khách hàng không sẵn
có vào đúng lúc)

60. 7. Scrum

61. Scrum (t.)
● Dựa trên quan niệm là phát triển phần mềm
không phải là quá trình được xác định, mà thay
vì thế là quá trình kinh nghiệm mà có thể hay
không thể lặp lại được dựa trên hoàn cảnh.
● Tổ tự tổ chức.
● Có nhấn mạnh vào quản lí dự án xác định.
● Được quản lí bởi Người chủ Scrum
● Dựa trên tồn việc về nâng cao sản phẩm
● 'nước rút' 30-ngày
● Các hoạt động tiền và hậu nước rút
● Các cuộc họp Scrum hàng ngày ngắn (<30 phút) để
giám sát tình trạnh & trao đổi vấn đề

62. Sprint trong Scrum

63. Điểm mạnh của Scrum
● Một trong số ít các phương pháp mau lẹ đã cố
đổi qui mô cho các dự án lớn hơn bằng việc có
scrums của các thầy scrum.
● Không có thực hành kĩ nghệ đặc biệt nào được qui
định, nhưng nhiều tổ Scrum đang chấp nhận XP.
● Scrum cung cấp các phương tiện được kiểm
soát để đưa các phương pháp Agile vào môi
thường theo kế hoạch truyền thống.
● Không thay đổi nào được phép có trong một đợt
nước rút!
● Từng đợt nước rút đều tạo ra việc tăng sản
phẩm chuyển đi được về tiềm năng.

64. Qui
trình
dự
án
Scrum

65. Nhược điểm của Scrum
● Yêu cầu quản lí liền tay, nhưng không vi quản lí.
● Cấp quản lí phải sẵn lòng làm thay đổi để giúp cho tổ
Scrum thành công.
● Scrum yêu cầu giám sát thường xuyên cả về số
lượng và chất lượng.
● Yêu cầu cấp quản lí uỷ quyền ra quyết định cho
tổ Scrum.
● Người quản lí phải để tổ Scrum ra quyết định
riêng của họ, thậm chí cho phép họ thất bại nếu
cần.
● Một số công nhân không thoải mái với tính trách
nhiệm mà Scrum tạo ra khả năng.

66. Trao đổi và thảo luận