Đường vào agile - 2013

Agile
đường vào

Dương Trọng Tấn
tandt@fpt.edu.vn
@FU HL/2013

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

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

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

Chúng ta

có gì rồi?

DEMO
Phần mềm

Chạy tốt

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

Scrum
Framework

Đồ họa: Demer et al.

Những Cách Khác

Agile
XP Lean Software
Development
Scrum
Crystal
DSDM
AgileUP FDD

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

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

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

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

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ý

Chung | Riêng

Ảnh: Hendrik Kniberg

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

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

Chồng lấp: cùng làm, từng tí một

Nguồn: Mike Kohn

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

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

Kế hoạch động,
thích ứng liên tục

Daily Standup

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

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

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ủ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 …

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

Sprint Burndown

Release

Release Burndown

Ảnh: mountaingoat.com

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

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

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

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

Đọc thêm nữa

45

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

Độ phức tạp của dự án

Scrum

Nguồn: Ken Schwaber

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

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

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

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

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

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

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

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

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

59

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

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

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

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

Ba nhân tố RGB

Thất bại

Thành
Cải tiến
công

65

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

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

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

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

Đường vào agile - 2013

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Đường vào agile - 2013

Similar a Đường vào agile - 2013 (20)

Más de DUONG Trong Tan

Más de DUONG Trong Tan (20)

Último

Último (20)

Đường vào agile - 2013