CHAPTER 3 AGILE METHODS

CHAPTER 3 AGILE METHODS 1

CHAPTER 3: AGILE METHODS

Phương pháp phát triển linh động - Agile

Methods

Agile Manifesto

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it These are our

values and principles.

https://agilemanifesto.org/

Individuals and interactions (Cá nhân hóa và sự tương tác): over processes

and tools (Hướng đến mỗi cá nhân và sự tương tác)

Working software (Phần mềm chạy được): over comprehensive

documentation (Viết mã nguồn hơn là tập trung vào các tài liệu)

Customer collaboration (Cộng tác giữa người dùng/khách hàng): over

contract negotiation (Cộng tác với khách hàng để lấy được sự tin tưởng của

khách hàng từ đó mới ký hợp đồng)

Responding to change (Sự đáp ứng thay đổi): over following a plan (Phản

hồi nhanh chóng với các sự thay đổi hơn là làm theo các kế hoạch)

⇒ Phương pháp này chú trọng những việc được đề ra ở bên trái nhiều hơn.

Ưu tiên hàng đầu của dự án phần mềm theo phương pháp agile là thỏa mãn

khách hàng thông qua việc phát triển và phân phối liên tục các phần mềm có

chất lượng

Chấp nhận những sự thay đổi cho dù đã qua quá trình phát triển

Giúp cho sản phẩm có thế mạnh hơn trong việc cạnh tranh

Chuyển giao những phần mềm hoạt động tốt một cách thường xuyên (hàng

tuần hoặc hàng tháng)

Xây dựng các môi trường khuyến khích những người có động lực cao phát

triển

Trao đổi trực tiếp mặt đối mặt (Thay vì thông qua tài liệu như phương pháp

truyền thống)

Các phần mềm hoạt động tốt là độ đo của tiến độ phần mềm

Đây là phương pháp giúp tăng mức độ phát triển bền vững của một dự án

Các nhà tài trợ, đội ngũ phát triển phần mềm và người dùng có thể duy trì phần mềm với một khoảng dài hạn

Tiếp tục tập trung vào kỹ thuật tốt và thiết kế đẹp

Simplicity - đơn giản hóa khối lượng độ công việc

Các kiến trúc tốt, yêu cầu và thiết kế đều được đưa ra bởi các nhóm tự tổ chức

(Self-organizing team)

Nhóm có thể tự kiểm điểm lại thường xuyên để điều chỉnh các thức làm việc của

mình

⇒ Agile là một tư tưởng và có rất nhiều phương pháp được sinh ra theo tư tưởng

này

Extreme Programming - Phương pháp lập trình cực

đoan

“Take known good practices and push them to extremes.”:

Cái gì làm tốt thì phải làm tốt hơn

The planning game: Cách lên kế hoạch như một trò chơi

Small Release: Chuyển giao phần mềm liên tục (Nhiều hơn cả phương pháp

agile)

Thiết kế đơn giản (Thiết kế những gì mình thấy trước mắt)

Refactoring (Thay đổi mã nguồn nhưng chức năng không thay đổi)

Lập trình song song

Liên tục hội nhập

Làm việc 40 tiếnng 1 tuần

On - site Customer

Coding standards

The 12 Practices

The planning game: cách lên kế hoạch như một trò chơi

Đưa những yêu cầu dưới dạng câu chuyện mang tính thực tế Đặt quyết định cho những người có kiến thức tốt nhất

Yêu cầu nghiệp vụ → KH Yêu cầu phần mềm → Developer Lên kế hoạch trong tầm hiểu biết của mình

Có một trò chơi là Planning Poker

Small Releases: chuyển giao sản phẩm nhỏ lẻ

Lấy phản hồi của người dùng nhanh

Có bao nhiêu stories hoàn thành trong một giai đoạn → biết được tiến độ của dự án

Metaphor: mượn hình ảnh thực tế

Thông qua thảo luận Cung cấp những cái nhìn Kết nối chương trình với bên ngoài để dễ hiểu hơn

Simple Design: thiết kế đơn giản

Không cần quá phức tạp về sau

Dễ chỉnh sửa, bảo trì và mô tả

Kiểm thử đơn vị: hàm, lớp, thành phần làm ra

Làm thường xuyên, liên tục → Phải kiểm thử tự động và tự động hoá càng nhiều càng tốt để giảm chi phí

Kiểm thử hệ thống → thực hiện bởi khách hàng → Kiểm tra lại yêu cầu

phần mềm (User stories)

Refactoring: thay đổi mã nguồn nhưng chức năng không đổi

Phải làm liên tục thường xuyên Thiết kế liên tục → Tiết kiệm chi phí

💡 Trong phương pháp truyền thống có Refactoring hay không?

Phương pháp nào thực hiện Refactoring nhiều hơn? Vì sao?

Phương pháp truyền thống là phải làm tuần tự, thiết kế đầy đủ, nhu cầu thay đổi không nhiều

Còn lại là xu hướng thay đổi nhiều do không có kế hoạch từ trước hoặc kế hoạch ngắn hạn, dẫn đến phải thay đổi nhiều

Pair Programming: lập trình đôi

Driver and navigator

Sau một thời gian đổi vai trò lại

Truyền đạt kinh nghiệm lẫn nhau giữa hai người

Chất lượng phần mềm tốt hơn, phát hiện lỗi tốt hơn

Giảm giai đoạn kiểm thử

Trong thực tế ít dùng pair programming

Collective Ownership: làm chủ tập thể

Mọi người đều sở hữu mã nguồn

Có thể thay đổi code ở bất kì đâu Không thiết lập modules cá nhân Giảm được rủi ro nếu một người bị ảnh hưởng, hỗ trợ công việc lẫn nhau

Continuous Integration: tích hợp liên tục

Tất cả đều chạy được liên tục

Có những bản releases thường xuyên và nhanh Giảm thiểu trường hợp đợi quá lâu và quá chênh lệch, dẫn đến lỗi (”big bang integration disasters”)

40-hour Week

Không làm việc liên tục → Chất lượng công việc giảm

On-site Customer: KH đến làm việc

Trao đổi trực tiếp với LTV LTV không biết mọi thứ

Coding Standards

Đảm bảo mã nguồn theo một tiêu chuẩn mã nguồn Mọi người có thể hiểu mã nguồn

The planning game

Mô tả phần mềm dưới dạng câu chuyện người dùng

Giao những công việc phù hợp cho những người có chuyên môn

Lên kế hoạch phù hợp với khả năng kiến thức của chúng ta

Small Release

Chuyển giao các phiên bản nhỏ để nhận được các phản hồi nhanh của khách hàng

Từ đó biết được tiến độ phát triển của dự án

Metaphor - Ẩn dụ

Mượn những hình ảnh trong thực tế để diễn đạt những gì trong dự án

Kết nối chương trình với tiến độ công việc

Simple Design

Thiết kế cho những yêu cầu đơn giản Những cái phức tạp sẽ được để lại về sau

⇒ Dễ dàng chỉnh sửa, duy trì

Testing - Kiểm thử đơn vị

Kiểm thự các hàm, lớp, thành phần được tạo ra để

Được thực hiện thường xuyên và liên tục (Kể cả với các chức năng đã được làm

rồi)

Việc kiểm thử này được thực hiện bởi khách hàng

Refactoring

Là một quá trình chỉnh sửa mã nguồn mà không đổi chức năng của mã nguồn (thay

đổi tên hàm, di chuyển qua các vị trí khác,…)

Được làm thường xuyên

Thiết kế là quan trọng được giữ vững trong suốt quá trình ⇒ giảm chi phí trong quá

trình phát triển

💡 Giữa phương pháp phát triển phần mềm truyền thống và phương

pháp hiện đại, phương pháp nào cần refactoring nhiều hơn?

Trong các phương pháp phát triển phần mềm truyền thống các thay đổi vạch ra chi tiết từ trước, khó thay đổi trong quá trình phát triển

Còn trong phương pháp này các thay đổi được đưa ra trong suốt quá trình phát triển phần mềm ⇒ Việc Refactoring nhiều hơn

Pair Programming

Giúp truyền đạt các kinh nghiệm lẫn nhau giữa 2 người

Làm cho chất lượng phần mềm tốt hơn ⇒ Tiết kiệm thời gian và chi phí

Về lâu dài tổng thời gian phát triển sẽ được giảm xuống

💡 Thực tế Pair Programming rất ít được dùng trong thực tế Bởi vì việc

tương tác giữa 2 người có nhiều trục trặc (bất đồng quan điểm, cái tôi lớn,

…)

Collective Ownership - Làm chủ tập thể

Mỗi người đều có thể sở hữu mã nguồn của nhóm mình Có thể cập nhật bởi bất cứ

người nào trong team

Làm giảm thiểu rủi ro khi một người sở hữu và người đó ròi nhóm hay nghỉ việc →

những người khác không thể truy cập được

💡 Mọi người có thể hiểu được tổng thể mã nguồn và chia sẻ công việc với

nhau

Continuous Intergration

Hệ thống được hoạt động liên tục để bảo bảo mã nguồn luôn chạy và không có lỗi

Mỗi người phải up lên Github và đảm bảo mã nguồn của mình chạy được trước khi

rời văn phòng

40-hour week

Không làm việc liên tục → Chất lượng công việc sẽ bị giảm

On-site Customer

Những người có kiến thức về nghiệp vụ, về khách hàng sẽ làm việc trực tiếp với lập

trình viên để chia sẻ về kinh nghiệm và quy tắc cần trong môi trường làm việc

Coding Standards

Phải đảm bảo mã nguồn theo một tiêu chuẩn được đề ra ⇒ Dễ dàng cho việc chỉnh

sửa và bảo trì

Tùy theo từng ngôn ngữ sẽ có những tiêu chuẩn khác nhau

Là một quy tắc trong phương pháp Agile sử dụng một tập hợp các quy tắc và thực

hành đơn giản để từng bước phát triển phần mềm

Một số khái niệm của Scrum:

Daily Scrum: Một cuộc họp ngắn (ít hơn 30 phút) giúp nhóm có thể giám sát

các trạng thái và trao đổi về các vấn đề phát sinh

Sprint: chu kỳ phát triển phần mềm (thường là 30 ngày).

Backlog:

Product backlog: danh sách ưu tiên của các sản phẩm được yêu cầu.

Sprint backlog: danh sách ưu tiên của các yêu cầu được phân bổ cho quá

trình sprint

Impediments backlog: danh sách các vấn đề phát sinh.

Burndown chart: biểu đồ biểu diễn tiến độ.

Artifacts

Product backlog

Overall product requirements (Yêu cầu tổng thể về sản phẩm) Items are estimated and prioritized (Các mục được ước tính và ưu tiên)

Sprint backlog

Requirement items allocated for one sprint (Các mục yêu cầu được phân bổ cho một sprint)

Items are estimated prioritized (Các mục được ước tính ưu tiên)

Scrum Roles

Scrum master:

Facilitate Scum practices

Enforce Scrum principles

Team:

Estimate product backlog

Create sprint backlog

Implement backlog items

Product Owner:

Create vision and requirements

Contact point

Create releases plan

Manager:

Ensure resources available

Resources management

Team building

Activities

Release planning: Ưu tiên và phân bổ các tính năng cho các bản release

Sprint planning:

Đưa ra các mục tiêu và phân bổ các hạng mục tồn đọng cho quá trình Sprint

Daily Scrum: Có 3 câu hỏi cần được đặt ra bởi các thành viên trong team

What had been done since the last meeting?

What will be done by the next meeting?

What issue we have now?

⇒ Giúp mọi người trong nhóm có thể tập trung hơn cho dự án

Sprint review:

Tổ chức cuối mỗi sprint

Xem lại những chức năng đã hoàn thiện

Quyết định những hướng đi đúng và chưa đúng

Where Agile Methods Work Best?

Nhóm nhỏ (2-20 người)

Quá trình lặp lại ngắn (1-2 tuần)

Những hệ thống không yêu cầu cao về độ an toàn

Strengths and Weaknesses of Agile Methods

Thế mạnh:

Phù hợp với những môi trường linh động Thay đổi nhanh chóng, hỗ trợ tốt với những yêu cầu khẩn cấp

Tránh các chi phí về tài liệu (tốn thời gian và nhân lực soạn tài liệu)

Trao quyền/khuyến khích mọi người làm việc

Điểm yếu:

Đòi hỏi trình độ và động lực cá nhân cao

Khó thực hiện đối với những hệ thống quan trọng về độ an toàn

Thường sẽ gặp sự cố khi áp dụng với những dự án lớn