abriefintroductiontoagile duongtrongtan2014-06-140611232528-phpapp01
TRANSCRIPT
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.
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ụ
NHÓM SCRUM TẠO RA
PHẦN MỀM NHƯ THẾ NÀO
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)
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
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
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)
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
Cứ như thế
cho đến khi hết
Khung
thời gian
Phần
Mềm
Chạy
Tốt
Sẽ
Tòi
Ra
DEMO
Phần mềm
Chạy tốt
Chúng ta
có gì rồi?
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
Rồi ta lại như thế …
Scrum Framework
Đồ họa: Demer et al.
Những Cách Khác
Scrum
XP Lean Software
Development
CrystalDSDM
Agile
FDDAgileUP
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ư
Kĩ thuật XP
Xem thêm: http://www.slideshare.net/duongtrongtan/practices-of-an-agile-developer-16001474
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
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
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õ
Build-Measure-Learn
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
Chung | Riêng
Ảnh: Hendrik Kniberg
PHÍA SAU CÁNH GÀ ...
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).
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.
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
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
Chồng lấp: cùng làm, từng tí một
Nguồn: Mike Kohn
Sprint | Iteration | Phân đoạnVò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
Thực nghiệm | Empiricism
Chim di cư bay hàng chục nghìn km mỗi năm
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
Nhóm Tự tổ chức
Self-organized Team
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
Nhóm liên chức năng
Cross-functional Team
Ảnh: suitcaseorchestra.com
Retrospective | Kaizen
Cải tiến liên tục
Image: Rachel Davies & Liz Sedley
Độ trực quan Khả năng thay đổi
Giá trị mang lại Rủi ro
Tại sao Agile?Nguồn: Ken Schwaber
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ủaMS, 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 …
User Story
& Backlogs
User Story
& Backlogs
Image: iqupi.wordpress.com mountaingoatsoftware.com agilemodeling.com agilistapm.com
Release Burndown
Sprint Burndown
Release
Ảnh: mountaingoat.com
Ảnh: pages.kiva.org | Atlassian | Quang NB
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 …)
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
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.000Giờ leo núi
Đọc thêm nữa
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 …)
Cộng đồng
HanoiScrum.net
AgileVietnam.org
THANK YOU!
:-)
BACKUP SLIDES
Độ phức tạp của dự án
Scrum
Nguồn: Ken Schwaber
Độ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ý
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
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
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
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ỏiQuan sátQuan sát
Phỏng vấn
người dùng
Phỏng vấn
người dùngViết user storyViết user story
56
Họp xây dựng user story
• Người tham gia: nhà phát triển, người dùng, kháchhà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
Lập trình cặpPair-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
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ệcquản lý chất lượng — từng phần nhỏ hiệu quả, ápdụng thường xuyên.
• Được hỗ trợ bởi một hệ thống CI với rất nhiều cáckiể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
Hệ thống Tích hợp liên tụcCI Systems
60
Thiết kế tiến hóa
Incremental DesignThiết kếnhững thứphức tạp cókhả năng linhhoạt trêngiấy hoặccông cụ
Thiết kế tiếnhóa
61
Luôn cónhững thứthay đổi bấtngờ
Luôn cónhững thứthay đổi bấtngờ
Nhiều phức tạphơn mức cầnthiết. Khó khăntrong việc bảotrì
Dễ dàng thíchnghi. ID thayđổi dễ dàng. Giảm bớt phứctạp
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
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ểmthử đã đượ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ấtbạ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
Các bước trong TDD
Nguồn ảnh: Excirial (http://upload.wikimedia.org/wikipedia/en/9/9c/Test-driven_development.PNG)
Cái giá của bug
Ba nhân tố RGB
66
Thất bạiThất bại
Thành
công
Thành
côngCải tiếnCải tiến
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ầuKiể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
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
Tái cấu trúcRefactoring
• 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ủahệ 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
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