A brief introduction to agile by duong trong tan Giới thiệu ngắn gọn về Agile - Dương Trọng Tấn, Hà Nội 2014/06

1. Agile
nói chuyện
Dương Trọng Tấn
duongtrongtan@gmail.com
@Septeni HN/2014

2. Trích chéo
• Đã: FPT Aptech Hanoi, Khoa Quốc tế - ĐH
FPT, AgileVietnam.
• Khởi xướng HanoiScrum
• Hiện nay: nghỉ hưu non AgileVietnam, làm
RnD ở ĐH FPT và Cánh Buồm, công việc
chính: thí nghiệm.

3. Nội dung
Agile là gì?
Tại sao Agile?
Agile là gì?
Tại sao Agile?
Ví dụ
XP
Scrum
Lean
& Lean Startup
Ví dụ
XP
Scrum
Lean
& Lean Startup
Trở nên/dùng agile
cách nào ?
Tư duy
Kĩ thuật
Cộng tác
Công cụ
Trở nên/dùng agile
cách nào ?
Tư duy
Kĩ thuật
Cộng tác
Công cụ

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

5. 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)

6. 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

7. 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

8. 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 (JIT PLANNING)

9. 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

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

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

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

13. 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

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

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

16. Những Cách Khác
Scrum
XP Lean Software
Development
Crystal
DSDM
Agile
FDDAgileUP

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

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

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

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

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

22. Build-Measure-Learn

23. Minimum Viable Product
Gồm những tính năng
tối giản đủ để học từ
thực tiễn, 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ý
BuildBuild

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

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

26. 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).

27. 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.

28. Tuyên ngôn
Phát triển Phần mềm Linh hoạt
28
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ụ;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 đủ;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;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.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
Xem thêm: http://www.hanoiscrum.net/hnscrum/learning/145-agileprincipleandvalues

29. Tuần tự và Chồng lấp
Nguồn: “The New New Product Development Game” của Takeuchi và
Nonaka. Harvard Business Review, tháng Giêng 1986.
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.
29

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

31. 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

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

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

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

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

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

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

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

39. 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 …

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

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

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

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

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

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

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

47. 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 …)

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

49. THANK YOU!:-)

50. BACKUP SLIDES

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

52. Độ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.
Quy tắc Làm việc
52
Đã kýĐã ký

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

54. 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
54

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

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

57. 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.
57

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

59. 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
59

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

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

62. 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
sản phẩm sau khi hoàn
thành
• Khuyến khích sự tham gia
tích cực của người dùng và
nhà phát triển
• Tăng tốc độ phát triển hệ
thống
Xác định các
yêu cầu cơ bản
Phát triển bản
mẫu đầu
Xem xét
Kiểm tra và cải
tiến bản mẫu
62

63. 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ử
63

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

65. Cái giá của bug

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

67. 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
67
Yêu cầuYêu cầu
Kiểm thử
Chấp nhận Tự
động hóa
Kiểm thử
Chấp nhận Tự
động hóa TDDTDD
Định nghĩa
Hoàn thành
Định nghĩa
Hoàn thành

68. 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
68
Xác nhận
lại hành
vi
Phát
triển
Xác nhận
với mô
phỏng UI
Các mô
tả hành
vi

69. 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
69

70. 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
70