Agile đường vào

Dương Trọng Tấn tandt@fpt.edu.vn

@FU HL/2013

Nội dung

Agile là gì?

Tại sao Agile?

Các Phương pháp XP

Scrum

Lean & Lean Startup

Kanban

Trở nên agile?

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

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

Crystal DSDM

Agile

FDD AgileUP

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)

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ư

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

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

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’

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

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ừ

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ý

Build

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

27

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

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.

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

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

34

• Tập trung vào Mục tiêu, cô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ủ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

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

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

43

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

44

10.000

Giờ leo núi

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

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

51

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

$

DevTeam PO

Collaboration:

Steps:

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

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

54

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

Tập hợp các user story

Chuẩn bị các

câu hỏi Quan sát

Phỏng vấn

người dùng Viết user story

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 • 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 đề

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

60

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

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

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

63

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

65

Thất bại

Thành

công Cả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

66

Yêu cầu Kiểm thử

Chấp nhận Tự

động hóa TDD

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

67

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