Giới thiệu Agile tới sinh viên ĐH FPT tại Hòa Lạc. Tháng 1-2013.

1. Agile
đường vào
Dương Trọng Tấn
tandt@fpt.edu.vn
@FU HL/2013

2. Nội dung
Agile là gì? Trở nên agile?
Tại sao Agile? Tư duy
Các Phương pháp Kĩ thuật
XP
Cộng tác
Scrum
Lean & Lean Startup Công cụ
Kanban

3. NHÓM SCRUM TẠO RA
PHẦN MỀM NHƯ THẾ NÀO

4. Có vài người nghĩ là phải làm phần mềm gì đấy
để phục vụ việc gì đấy
Rồi đổ tiền vào
Giao nhiệm vụ cho (vài) người nào đấy
Rồi nghĩ ra vài chức năng cần phải có, được gọi là
YÊU CẦU
(REQUIREMENTS)

5. Công việc xây dựng phần mềm được quẳng cho
Đội sản xuất
Bọn này ngồi lại với nhau để
Lập kế hoạch
Tháng tới làm gì
Để có được (vài) chức năng nào đó hoàn
chỉnh
để “show hàng” vào cuối tháng

6. Kết quả của buổi họp lập kế hoạch
là một
Bản kế hoạch
Gồm mục tiêu
và
những việc cần làm trong tháng

7. Dựa trên Bản kế hoạch ấy
Đội sản xuất hì hụi
ai có việc người ấy làm
cộng tác chặt chẽ với nhau
Ngày nào cũng Họp 
15 phút mỗi ngày
Để đồng bộ hóa công việc của
nhau, nắm tiến độ và phát hiện
trở ngại

8. Nếu có việc gì phải làm thêm,
hoặc bớt đi vài việc không cần
làm nữa
Thì cập nhật luôn vào
Bản Kế hoạch

9. Cứ như thế
cho đến khi hết
Khung
thời gian

10. Phần
Mềm
Chạy
Tốt
Sẽ
Tòi
Ra

11. Chúng ta
có gì rồi?
DEMO
Phần mềm
Chạy tốt

12. Chưa xong, còn phải ngồi lại xem thời gian vừa rồi
làm việc có ỔN không, có thể làm tốt hơn không?
Cố tìm cho bằng được cái gì đó để CẢI TIẾN cho tháng tiếp theo

13. Rồi ta lại như thế …

14. Scrum
Framework
Đồ họa: Demer et al.

15. Những Cách Khác
Agile
XP Lean Software
Development
Scrum
Crystal
DSDM
AgileUP FDD

16. eXtreme Programming
Phát triển những phần mềm với chất Nguyên lý
lượng cao nhất, với chi phí thấp nhất, ít • Phản hồi nhanh (Rapid
lỗi nhất, siêu năng suất và tối đa hóa lợi Feedback)
nhuận đầu tư • Giả định Đơn giản
(Assume Simplicity)
Giá trị • Thay đổi tăng trưởng
• Giao tiếp (Incremental Change)
(Communication) • Sống chung với Thay
• Tính đơn giản
(Simplicity) đổi (Embracing Change)
• Phản hồi (Feedback) • Công việc chất lượng
• Tôn trọng (Respect)
• Can đảm (Courage) cao (Quality Work)
Đọc thêm: http://www.hanoiscrum.net/hnscrum/learning/167

17. Kĩ thuật XP
Xem thêm: http://www.slideshare.net/duongtrongtan/practices-of-an-agile-developer-16001474

18. Lean Software Development
Sử dụng Tư duy Tinh gọn (Lean Thinking) 7 Nguyên lý
cho lĩnh vực phát triển phần mềm 1. Loại bỏ lãng phí
2. Khuếch trương việc học
22 Công cụ
3. Quyết định càng muộn
11. Lý thuyết Hàng đợi
12. Giá của Trì hoãn càng tốt
1. Nhìn ra Lãng phí
13. Tự-Xác-định
2. Ánh xạ Dòng Giá trị 4. Chuyển giao càng
14. Động viên
3. Phản hồi
15. Lãnh đạo
4. Phân đoạn nhanh càng tốt
16. Chuyên môn
5. Đồng bộ hóa
17. Toàn vẹn Nhận thức 5. Trao quyền cho nhóm
6. Phát triển theo lô
18. Toàn vẹn Khái niệm
7. Tư duy Lựa chọn 6. Tạo ra tính toàn vẹn tự
19. Tái cấu trúc
8. Trách nhiệm Phút cuối
20. Kiểm thử
9. Ra quyết định thân
21. Đo lường
10. Hệ thống kéo
22. Hợp đồng 7. Thấy toàn cảnh
Đọc thêm: http://www.hanoiscrum.net/hnscrum/learning/168-agilemethod3-lean-software-development

19. Kanban
Phương pháp luận Cải tiến
Quy trình theo cách thức 5 Đặc điểm
tiến hóa và tăng trưởng 1. Trực quan hóa Luồng công việc
2. Giới hạn Việc-đang-làm
‘Complex Adaptive System for Lean’
3. Đo lường và Quản lí Luồng
4. Công khai Chính sách Quy
trình
Không cần Phân đoạn? Bỏ luôn!
5. Dùng Mô hình để nhận biết
Không cần Ước lượng? Bỏ luôn! các cơ hội Cải tiến

20. Lean Startup | Khởi nghiệp Tinh gọn
Vấn đề: chưa rõ Giả định, thử nghiệm
Giải pháp: chưa rõ Dữ liệu, phản hồi

21. Build-Measure-Learn

22. Minimum Viable Product
Gồm những tính năng
tối giản đủ để học từ
Build
sớm nhất có thể
• Tránh làm ra chức
năng không ai dùng
• Mỗi đồng bỏ ra đều
thu được bài học quý

23. Chung | Riêng
Ảnh: Hendrik Kniberg

24. PHÍA SAU CÁNH GÀ ...

25. Agile | Agility | Linh hoạt
• Ken Schwaber:
1. flexibility, the capacity and
capability of rapidly and
efficiently adapting to
change.
2. ability to take advantage
of opportunities while
controlling risk.
Wiki:
Agile Software Development: một họ các phương pháp phát triển phần mềm
dựa trên các nguyên lí tăng trưởng (incremental) và lặp (iterative), trong đó
các yêu cầu và giải pháp tiến hóa thông qua sự cộng tác giữa các nhóm liên
chức năng (cross-functional) tự tổ chức (self-organizing).

26. Triết lí Agile
• Định nghĩa các giá trị cốt
lõi
• Định hướng các phương
pháp Agile
• Mô tả trong Tuyên ngôn
Agile (Manifesto) và 12
Nguyên lí Agile.

27. Tuyên ngôn
Phát triển Phần mềm Linh hoạt
Chúng tôi đã phát hiện ra cách tốt hơn để phát triển phần
mềm thông qua việc thực hiện nó và giúp đỡ người khác thực hiện.
Qua công việc này, chúng tôi đã đi đến việc đánh giá cao:
Cá nhân và 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ácvới khách hàng hơn là đàm phán hợp đồng;
Phản hồi với thay đổi hơn là bám sát kế hoạch.
Mặc dù các thứ bên phải vẫn còn giá trị, chúng tôi đánh giá cao hơn
các mục ở bên trái.
Dịch từ: AgileManifesto.org
27
Xem thêm: http://www.hanoiscrum.net/hnscrum/learning/145-agileprincipleandvalues

28. Tuần tự và Chồng lấp
Phát triển tuần tự
Nhóm Scrum làm mỗi thứ một ít ở mọi thời điểm, tập trung đưa ra
các chức năng [chạy tốt] sớm nhất.
Nguồn: “The New New Product Development Game” của Takeuchi và
Nonaka. Harvard Business Review, tháng Giêng 1986. 28

29. Chồng lấp: cùng làm, từng tí một
Nguồn: Mike Kohn

30. Sprint | Iteration | Phân đoạn
Vòng đời phản hồi ngắn
Khuyến khích việc học
Gia tăng Visibility
Thích ứng với thay đổi

31. Thực nghiệm | Empiricism
Chim di cư bay hàng chục nghìn km mỗi năm

32. Just-in-time | Tức thì Cập nhật
Hằng ngày
Kế hoạch động,
thích ứng liên tục
Daily Standup

33. Nhóm Tự tổ chức
Self-organized Team

34. Hướng đến Mục tiêu chung
• Tập trung vào Mục tiêu, công phải Task
• Giới hạn việc-đang-làm
34

35. Nhóm liên chức năng
Cross-functional Team
Ảnh: suitcaseorchestra.com

36. Retrospective | Kaizen
Cải tiến liên tục
Image: Rachel Davies & Liz Sedley

37. Độ trực quan Khả năng thay đổi
Giá trị mang lại Rủi ro
Tại sao Agile? Nguồn: Ken Schwaber

38. Công cụ hỗ trợ
• Index Card, Miếng giấy dán (sticky notes)
• Planning Poker
• Task Board|Kanban Board|Scrum Board| Các loại bảng
• Công cụ giao tiếp (Skype, Hangout,Yammer …)
• Các công cụ soạn thảo cộng tác: wiki, online office
suites, mindmapping …
• Các hệ ALM( Application Lifecycle Management) của
MS, IBM, HP, Rally, CollabNet, VersionOne, Atlassian,
Redmine ...
• Các phần mềm tự động hóa: CI (continuous
integration), các test automation framework (xUnit,
Cucumber, FitNess, Robots …)
• Và nhiều nữa …

39. User Story
& Backlogs
Image: iqupi.wordpress.com mountaingoatsoftware.com agilemodeling.com agilistapm.com

40. Sprint Burndown
Release
Release Burndown
Ảnh: mountaingoat.com

41. Ảnh: pages.kiva.org | Atlassian | Quang NB

42. Học và hành
Học thông qua … Thực hành
• Ghép cặp (Pairing) • Thực học là để làm, làm
• Cộng đồng thực hành được mới được coi là học
(Coding Dojo, Interest được
Group …) • Pilot project
• Hội thảo chuyên ngành • Các bài tập lớn (assignment)
(AgileTour, ScrumDay …) • Các Dự án|Đồ án (Project)
• Đọc sách • Quản lí công việc cá nhân
• Các tài nguyên online (Personal Kanban, Personal
(video) Scrum, Lean …)
• Thuyết trình|Dạy lại người
khác

43. Học tập cũng cần chiến lược
SHU HA RI
Bám sát Quy tắc Nghĩ lại về Quy tắc Quên đi Quy tắc
Tìm kiếm ngoại lệ,
Phá vỡ Quy tắc
43

44. Expert
Competent
Proficient
Tới Bruce Lee - bậc thầy Kungfu
Advanced
Beginner
Novice
10.000
Giờ leo núi
Cậu bé bắt đầu học Vịnh Xuân
Image: http://goo.gl/1RzEE
44

45. Đọc thêm nữa
45

46. Tài nguyên online
• HanoiScrum.net
• AgileAtlas.org
• ScrumAlliance.org
• AgileAlliance.org
• InfoQ.com/process-practices/
• Các hội thảo Agile Conference, Scrum
Gathering, Agile Tour, ScrumDay …
• Tool Vendors (MSDN, IBM, VersionOne …)

47. Cộng đồng
HanoiScrum.net
AgileVietnam.org

48. :-)
THANK YOU!

49. BACKUP SLIDES

50. Độ phức tạp của dự án
Scrum
Nguồn: Ken Schwaber

51. Quy tắc Làm việc
Đội Y
*************
1. Thời gian Daily Scrum: 9:00
2. Phạt đến muộn: 2 $
3. Mọi người đều tích hợp liên tục
4. Tái cấu trúc lại mã bẩn
5. Hỏi nếu không rõ
6. Sử dụng Lập trình cặp và TDD
7. Thực hiện đúng chuẩn viết mã
8. Kiểm tra lại Định nghĩa Hoàn thành
trước khi commit.
Đã ký
51

52. Một tình huống phát triển
$ $
Collaboration:
PO DevTeam PO
UI Mocking Design Draft Code the Refactoring
Steps: Requirement Coding in Build the
• Customer • Design Discussion skeleton to and
Analysis team increment
discussion test the design Refinement
Interface IDo{
//TODO …
A Interface IDo{ }
//TODO … Class A{
IDo } method1(){
As a super user,
Class A{ //Mr. A codes here
Artifacts:
I want to …
//TODO … }
}
B }
Class B:IDo{ Class B:IDo{
//TODO … method1(){
} //Mrs. B codes here
}
}
Note: Class C{
TDD|BDD|AMDD can be used or not } 52

53. User Story
• User story là các yêu cầu linh hoạt (agile requirement)
• Đảm bảo sự cân bằng của các bên tham gia phát triển
sản phẩm: khách hàng, người dùng và nhà phát triển
– Thể hiện bằng một ngôn ngữ hướng-người-dùng và các nhà
phát triển có thể hiểu được
• Hướng tới người dùng và nghiệp vụ, không chứa các đặc
tính về hệ thống
53

54. INVEST – các tiêu chuẩn cho một user
story tốt
Independent – Độc lập
Negotiable – Đàm phán được
Valuable – Đáng giá
Estimatable – Ước tính được
Sized appropriately – Kích thước phù hợp
Testable – Kiểm thử được
54

55. Tập hợp các user story
Chuẩn bị các
Quan sát
câu hỏi
Phỏng vấn
Viết user story
người dùng
55

56. Họp xây dựng user story
• Người tham gia: nhà phát triển, người dùng, khách
hàng, thành phần khác (được gọi là những “chú
lợn”)
• Thảo luận để đưa ra các story
• Mục tiêu là viết được càng nhiều story càng tốt
– Một số sẽ “sẵn sàng triển khai”
– Một số khác sẽ là “epic”
• Không xác định độ ưu tiên trong buổi hội thảo này
• Product Owner và những người có liên quan
được tham gia nhưng không bắt buộc.
56

57. Lập trình cặp
Pair-Programming
• Có 2 vai trò: Ngườilái
• Hai LTV cùng chia sẻ một vấn
đề, với một máy tính, một (Driver) và Hoa tiêu
bàn phím và với mục tiêu: (Navigator):
giải quyết vấn đề đó. – Người lái không quan tâm tới bức
tranh toàn cảnh
• Sử dụng sự ĐỒNG THUẬN,
– Người lái nên “rời bàn phím
nhưng thông qua TRANH trong giây lát”
LUẬN! – Hoa tiêu có xu hướng sử dụng tư
• Một ví dụ về “luồng một sản duy mẫu trong giải quyết vấn đề
phẩm”
• Chậm hơn nhưng hiệu quả
hơn & chất lượng hơn
57

58. Tích hợp Liên tục
• Tích hợp Liên tục (Continuous integration - CI)
triển khai liên tục các tiến trình để đảm bảo việc
quản lý chất lượng — từng phần nhỏ hiệu quả, áp
dụng thường xuyên.
• Được hỗ trợ bởi một hệ thống CI với rất nhiều các
kiểm thử tự động, build và các thành phần khác.
• Lợi ích:
– Tăng cường sự minh bạch
– Tăng cường sự hợp tác và truyền thông
– Cho phép mọi người cùng làm việc trên một mã
nguồn
58

59. Hệ thống Tích hợp liên tục
CI Systems
59

60. Thiết kế tiến hóa
Incremental Design
Thiết kế Luôn có Nhiều phức tạp
những thứ những thứ hơn mức cần
phức tạp có thay đổi bất thiết. Khó khăn
khả năng linh ngờ trong việc bảo
hoạt trên trì
giấy hoặc
công cụ Dễ dàng thích
Luôn có nghi. ID thay
những thứ đổi dễ dàng.
Thiết kế tiến Giảm bớt phức
hóa thay đổi bất
ngờ tạp
60

61. Làm Bản mẫu
• Bản mẫu có sớm sẽ giúp
người dùng dễ hình dung ra Xác định các
yêu cầu cơ bản
sản phẩm sau khi hoàn
thành Phát triển bản
mẫu đầu
• Khuyến khích sự tham gia
tích cực của người dùng và
nhà phát triển Xem xét
• Tăng tốc độ phát triển hệ
thống Kiểm tra và cải
tiến bản mẫu
61

62. Phát triển Hướng-Kiểm-thử
Test-Driven Development
• Không viết mã nguồn cho tới khi các kiểm
thử đã được thiết kế hoàn chỉnh!
• Chiến lược
– Làm cho Thất bại
• Không có mã nguồn nào mà không có kiểm thử thất
bại
– Làm cho Thành công
• Đơn giản nhất có thể
– Làm cho Tốt hơn
• Cải tiến (mã nguồn, thiết kế, kiểm thử, tài liệu)
– Tin tưởng vào việc kiểm thử
62

63. Các bước trong TDD
Nguồn ảnh: Excirial (http://upload.wikimedia.org/wikipedia/en/9/9c/Test-driven_development.PNG)
63

64. Cái giá của bug

65. Ba nhân tố RGB
Thất bại
Thành
Cải tiến
công
65

66. Phát triển Hướng Kiểm thử
Chấp nhận (ATDD)
• Một kỹ thuật dành cho tự động kiểm thử chấp nhận
• Chiến lược 3D
– Thảo luận (Discuss) trong hội thảo về xác định yêu cầu
• Để xây dựng các thư viện kiểm thử
– Phát triển (Develop) với sự đồng thuận
• Để tạo ra nhiều tính năng đạt kiểm thử hơn
– Cung cấp (Deliver) các chấp nhận
• Để đạt được định nghĩa hoàn thành, cần sự chấp nhận của người
dùng
Kiểm thử Định nghĩa
Yêu cầu Chấp nhận Tự Hoàn thành
động hóa TDD
66

67. Phát triển Hướng-Hành-vi
Behavior-Driven Development
• Phát triển phần mềm được chỉ dẫn trực tiếp bởi các mô
tả hành vi và các tính năng (và mô phỏng).
• Hơi giống với ATDD, nhưng khác về tư duy
• Chất lượng phần mềm cao hơn, tính tự tổ chức tốt hơn
Các mô Xác nhận Xác nhận
Phát
tả hành với mô lại hành
triển
vi phỏng UI vi
67

68. Tái cấu trúc
Refactoring
• Bạn thực hành “viết mã một ít, sửa lỗi một ít”
=> kết quả là code bẩn và thiết kế tồi.
• Tái cấu trúc để code tốt hơn, có thiết kế
tốt hơn, vẫn giữ nguyên chức năng của
hệ thống
• Giữ cho mã nguồn:
– Dễ bảo trì
– Dễ mở rộng
– Tính gắn kết cao (High Cohesion)
– Ít phụ thuộc (Low Coupling)
– Loại bỏ trùng lặp
• Database cũng cần được tái cấu trúc cho phù hợp
68

69. Các kỹ thuật tái cấu trúc
• Trừu tượng hóa (Abstraction)
– Bao gói các trường
– Dùng kiểu khái quát (generic)
– Thay thế mã kiểm tra (check) với State/Strategy
– Thay thế các điều kiện bằng đa hình
• Phân tách mã
– Tạo mới phương thức, thay thế một phần lớn mã trong một
phương thức bằng phương thức khác
– Tạo thêm lớp mới
• Chuẩn hóa mã
– Chuyển phương thức hoặc trường
– Đổi tên phương thức, trường
– Đẩy lên lớp cấp trên hoặc lớp cha
– Đẩy xuống lớp cấp dưới hoặc lớp con
69