Cong Nghe Phan Mem - Chuong10

Chương 10
Phát triển phần mềm Agile

10.1 Phát triển phần mềm nhanh
10.2 Phương pháp phát triển phần mềm Agile
10.3 SCRUM là gì
10.4 Các nhân sự SCRUM
10.5 Các buổi hợp SCRUM
10.6 Các artifacts SCRUM
10.7 Kết chương
Khoa Khoa học & Kỹ thuật Máy tính Môn : Công nghệ phần mềm
Trường ĐH Bách Khoa Tp.HCM Chương 10 : Phát triển phần mềm Agile
© 2010 Slide 1
10.1 Phát triển phần mềm nhanh

 Phát triển và phân phối nhanh hiện thời thường là yêu cầu quan
trọng nhất trong các hệ thống phần mềm.
• nghiệp vụ hoạt động theo yêu cầu thay đổi nhanh chóng.
• => thực tế khó có các yêu cầu phần mềm ổn định theo thời
gian.
• phần mềm phải tiến hóa nhanh để phản ánh các yêu cầu
nghiệp vụ thay đổi liên tục.
• việc phát triển dựa theo kế hoạch (mô hình thác nước, tích lũy
tang dần...) rất cần cho 1 vài loại phần mềm nhưng không
phù hợp với các yêu cầu nghiệp vụ thay đổi liên tục như trên.
© 2010 Slide 2
1
10.2 Phát triển phần mềm Agile
 xuất hiện vào cuối thập kỷ 1990 với mục đích giảm triệt để thời
gian phát triển và phân phối phần mềm.
 đặc tả, thiết kế và hiện thực sẽ được thực hiện xen kẻ.
 phần mềm = chuỗi các version/bản tăng tiến.
 các bên liên quan đều dính líu đến việc đặc tả và đánh giá
version.
 việc phân phối định kỳ các version mới để đánh giá chúng.
 tối thiểu hóa việc lập tài liệu - tập trung chủ yếu việc viết code.
 hỗ trợ tool rộng rãi (tool kiểm thử tự động) được dùng để hỗ
trợ việc phát triển phần mềm.
© 2010 Slide 3
Phát triển agile / phát triển theo kế hoạch
© 2010 Slide 4
2
Tuyên ngôn Agile
Individuals and
over Process and tools
interactions
Comprehensive
Working software over
documentation
Customer
over Contract negotiation
collaboration
Responding to
over Following a plan
change
© 2010 Slide 5
VL1 : cá nhân và giao tiếp hơn là qui trình và công cụ

 Strong players: cần nhưng nếu không làm việc cùng nhau thì có
thể thất bại.
 Strong player: không nhất thiết thiên tài có thể làm việc tốt với
những người khác.
• Liên hệ và tương tác quan trọng hơn tài năng thiên bẩm.
 Công cụ đúng là sống còn cho việc làm trơn hoạt động của
nhóm.
 Bắt đầu từ điều nhỏ nhất. Tìm tool miễn phí và dùng cho đến khi
có thể demo rằng bạn cần hơn nó. Đừng giả định cái lớn hơn là
tốt hơn. Bắt đầu từ zero, từ file thô trước khi tiến tới database lớn.
© 2010 Slide 6
3
VL1 : cá nhân và giao tiếp hơn là qui trình và công cụ
 Xây dựng 1 nhóm quan trọng hơn là xây dựng môi trường.
• 1 số manager xây dựng môi trường trước và hy vọng nhóm sẽ
làm việc tốt với nhau trong môi trường đó.
• không làm việc.
• hãy để nhóm tự xây dựng môi trường làm việc dựa trên yêu
cầu của họ.
© 2010 Slide 7
VL2 : tập trung coding hơn là lập tài liệu

 Code : không phải là phương tiện lý tưởng cho việc liên lạc và cấu
trúc hệ thống.
• nhóm cần tạo tài liệu dễ đọc bởi con người để diễn tả phần
mềm và lý do cơ sở cho quyết định thiết kế.
 lập tài liệu quá nhiều sẽ tệ hơn là quá ít.
• tốn thời gian, nhiều hơn nữa để đồng bộ nó với code; còn nếu
không đồng bộ được thì tài liệu lạc lối với code và vô dụng.
 tài liệu cấu trúc và lý do cơ sở ngắn gọn.
• giữ tài liệu đồng bộ với code, chỉ cấu trúc cấp cao nhất trong
hệ thống được giữ.
• điểm yếu chết người : lo lập tài liệu thay vì viết phần mềm:
• qui luật : không tạo tài liệu trừ phi có yêu cầu ngay và quan
trọng.
© 2010 Slide 8
4
VL3 : cộng tác với khách hàng hơn là thương lượng
hợp đồng
 không thể miêu tả yêu cầu phần mềm trước rồi để đó trừ phi để
phát triển nó ngay trong phạm vi chi phí xác định.
 khách hàng không thể đưa ra yêu cầu rồi rời đi.
 dự án thành công đòi hỏi sự hồi tiếp từ khách hàng đều đặn
thường xuyên, và không phụ thuộc vào hợp đồng hay SOW
(Statement Of Work).
© 2010 Slide 9
VL3 : cộng tác với khách hàng hơn là thương lượng

 hợp
hợpđồng
đồng tốt nhất không phải là hợp đồng có đặc tả các yêu cầu,
lịch biểu và chi phí cụ thể -> vì nó nhanh chóng không còn ý nghĩa.
 tốt hơn là có hợp đồng mà kiểm quản lý cách thức mà nhóm phát
triển và khách hàng sẽ làm việc với nhau.
 vấn đề chính là sự cộng tác mạnh với khách hàng và 1 hợp đồng
mà sự cộng tác được cai quản hơn là chi tiết về phạm vi và lịch
biểu.
• lý tưởng là chi tiết không được đặc tả trong hợp đồng.
• thay vì vậy, hợp đồng có thể được thanh toán khi 1 phân hệ
(block, deliverable) được thông qua bởi kiểm thử độ chấp thuận
bởi khách hàng.
• với các phân hệ được phát hành thường xuyên và sự hồi tiếp,
các kiểm thử độ chấp thuận bởi người dùng không còn là vấn
đề nữa.
© 2010 Slide 10
5
VL4 : đáp ứng với thay đổi hơn là theo sát kế hoạch
 kế hoạch của chúng ta và khả năng đáp ứng với thay đổi là sống
còn.
 dĩ nhiên 1 dự án không thể được tiên đoán xa trong tương lai.
• quá nhiều biến, không có cách tốt để ước lượng chi phí.
• khi nhà phát triển thu được kiến thức về hệ thống và khi
khách hàng thu được kiến thức về yêu cầu của họ, 1 vài tác vụ
sẽ trở nên không cần thiết.
© 2010 Slide 11
VL4 : đáp ứng với thay đổi hơn là theo sát kế hoạch
 Chiến lược lập kế hoạch tốt hơn : lập kế hoạch chi tiết cho 1 vài
tuần tới, chút ít cho vài tháng tới và rất thô cho thời gian sau đó.
 nhu cầu biết cái gì chúng ta sẽ làm trong vài tuần tới, phỏng
chừng cái gì làm trong vài tháng tới, mơ hồ về cái gì sẽ làm sau 1
năm.
 chỉ đầu tư vào kế hoạch chi tiết cho các tác vụ trước mắt; 1 khi kế
hoạch được làm thì khó thay đổi do động lượng và cam kết.
 những phần chưa chi tiết của kế hoạch có thể được thay đổi
tương đối dễ dàng.
© 2010 Slide 12
6
10.3 SCRUM là gì ?
 Scrum là một quy trình phát triển phần mềm theo phương pháp
Agile. Chính vì thế, Scrum tuân thủ các nguyên tắc của bản tuyên
ngôn Agile.
 Do đó, Agile và Scrum không phải là một. Hãy nhớ lại, Agile là
một phương pháp, bao gồm những giá trị cốt lõi và nguyên tắc
nhất định còn Scrum là quy trình “hiện thực hoá” những giá trị và
nguyên tắc của Agile.
© 2010 Slide 13
SCRUM được dùng bởi

 ?
•Nielsen Media
•First American Real Estate
•BMC Software
•Ipswitch
•John Deere
•Lexis Nexis
•Sabre
•Salesforce.com
•Time Warner
•Turner Broadcasting
•Oce
•…
© 2010 Slide 14
7
SCRUM được dùng cho
 Commercial software  Video game development
 In-house development  FDA-approved, life-critical
 Contract development systems
 Fixed-price projects  Satellite-control software
 Financial applications  Websites
 ISO 9001-certified applications  Handheld software
 Embedded systems  Mobile phones
 24x7 systems with 99.999%  Network switching applications
uptime requirements  ISV applications
© 2010 Slide 15
Cách SCRUM hoạt động
© 2010 Slide 16
8
Framework SCRUM
Roles Ceremonies
•Product owner •Sprint planning
•ScrumMaster •Sprint review
•Team •Sprint retrospective
•Daily scrum meeting
Artifacts
•Product backlog
•Sprint backlog
•Burndown charts
© 2010 Slide 17
10.4 Các nhân sự SCRUM

 chủ nhân sản phẩm (Product owner)
 ScrumMaster
 nhóm (team)
© 2010 Slide 18
9
Chủ nhân sản phẩm
 Định nghĩa các tính chất nổi bật của sản phẩm.
 quyết định ngày/nội dung phát hành.
 chịu trách nhiệm về khả năng sinh lợi của sản phẩm (ROI)
 lập thứ tự ưu tiên các tính chất của sản phẩm theo giá trị thị
trường.
 điều chỉnh các tính chất và quyền ưu tiên cho mỗi bước lặp nếu
cần thiết.
 chấp thuận hay hủy kết quả làm việc.
© 2010 Slide 19
ScrumMaster
 quản lý dự án.
 chịu trách nhiệm cho việc đề ra các giá trị và thực tiển Scrum.
 loại bỏ các trở ngại.
 đảm bảo nhóm hoạt động và hiệu quả.
 có thể đóng sự cộng tác giữa tất cả nhân sự và chức năng.
 Bao bọc nhóm từ các quấy nhiễu từ bên ngoài.
© 2010 Slide 20
10
Nhóm làm việc
 thường từ 5-9 người
 chức năng : lập trình viên, kiểm thử viên, người thiết kế có kinh
nghiệm,...
 các thành viên nên làm việc toàn thời gian.
• có thể có ngoại lệ (td. quản lý viên database)
 nhóm tự tổ chức lấy.
• lý tưởng là không có chức danh nhưng hiếm khi như vậy.
 sự thay đổi nhân sự chỉ khi xong sprint hiện hành.
© 2010 Slide 21
10.5 Các cuộc họp SCRUM

 Sprint planning
 Sprint review
 Sprint retrospective
 Daily scrum meeting
© 2010 Slide 22
11
Lập kế hoạch Sprint
 quyết định cách thức để đạt được mục tiêu Sprint (thiết kế)
 Nhóm chọn các phần tử từ product backlog mà sprint có thể
hoàn thành.
 tạo ra sprint backlog (tasks) từ các phần tử product backlog đã
chọn cho sprint (user story/tính chất)
 Ước lượng sprint backlog ra giờ. Các task được ước lượng (1-16
giờ).
 phải cộng tác chứ ScrumMastter không được làm 1 mình.
As a vacation planner, I want to Code the middle tier (8 hours)

see photos of the hotels. Code the user interface (4)
Write test fixtures (4)
Code the foo class (6)
Update performance tests (4)
© 2010 Slide 23
Cuộc họp SCRUM hằng ngày (hằng tuần)

 hằng ngày, 15 phút, đứng
 không phải để giải quyết vấn đề
 được điều phối bởi Scrum master
 có 3 câu hỏi :
• Hôm này bạn đã làm gì?
• Hôm này bạn sẽ làm gì?
• Mọi thứ theo tính toán của bạn ?
© 2010 Slide 24
12
Các cuộc họp đánh giá Sprint
 nhóm trình bày những gì đã làm xong
trong suốt sprint
 thường dưới dạng demo 1 vài tính chất mới
hay kiến trúc cơ sở.
 không chính thức
• qui luật 2 giờ chuẩn bị
• không cần slide
 toàn bộ thành viên nhóm đều tham gia
 mời mọi người.
© 2010 Slide 25
Các cuộc họp nhìn lại Sprint

 Định kỳ xem cái gì làm việc và cái gì không làm việc.
 điển hình khoảng 15-30 phút
 được thực hiện sau mỗi sprint
 toàn bộ thành viên nhóm đều tham gia
 được điều phối bởi Scrum Master.
 mỗi thành viên được yêu cầu nhận dạng những điều đặc biệt mà
nhóm sẽ :
• bắt đầu làm
• ngừng làm
• tiếp tục làm.
© 2010 Slide 26
13
Bài tập trong lớp
 suy ngẫm về các tool, sự cộng tác, công việc của nhóm, các cuộc
họp,... mà bạn đã làm cho Delivery 2. Thực hiện cuộc nhìn lại nội
trong nhóm của mình :
 một thành viên hoạt động như ScrumMaster
• scrumMaster hỏi mỗi thành viên về cài gì mà anh/chị ấy sẽ:
• bắt đầu làm
• ngừng làm
• tiếp tục làm
© 2010 Slide 27
10.6 Các artifacts SCRUM

 Product backlog
 Sprint backlog
 Burndown charts
© 2010 Slide 28
14
Product Backlog vs Sprint backlog
© 2010 Slide 29
User story
 sự miêu tả không chính thức bằng ngôn ngữ tự nhiên của 1 hay
nhiều tính chất của hệ thống phần mềm.
 được viết từ góc nhìn của người dùng cuối.
 Khuôn mẫu thường dùng :
As a <role> I can/ want <capability>, so that <receive benefit>
© 2010 Slide 30
15
User story trong Sprint backlog/Product backlog
© 2010 Slide 31
Ước lượng nỗ lực

 lúc bắt đầu mỗi Sprint, ta sẽ nói tốn bao lâu/giá nào để hoàn
thành từng user story ABC mà sprint cần thực hiện.
• “tôi nghĩ sẽ tốn 5 ngày toàn thời gian để hoàn thành user
story ABC”
• “tuần này tôi có bài kiểm tra giữa kỳ, do đó tốn 7 ngày ...”
• “user story ABC có thể cần 3000 LOC để hiện thực...”
• “user Story ABC sẽ có 3 giao diện người dùng…”
• “tôi cho điểm 5/10 về mức độ nỗ lực cần thiết để thực hiện
user story ABC.”
 Có nhiều cách tiếp cận khác nhau để ước lượng.
 Không có ước lượng nào hoàn hảo.
 Cái quan trọng là có sự hiểu biết nhất quán về nỗ lực/độ phức tạp
của công việc/user story xuyên suốt toàn bộ nhóm.
© 2010 Slide 32
16
kế hoạch poker
© 2010 Slide 33
Kế hoạch poker
 Với mỗi user story, 1 thành viên có thể gán 1 số trong tập
{0,1,2,3,5,8, 13, 21}. 1 story được ước lượng là 2 sẽ khó bằng 1/4
story nhận số 8, 0 là đơn giản nhất, 21 là khó nhất.
 Điều phối viên sẽ hỏi mỗi thành viên : đọc to số của mình
 Thành viên gán số nhỏ nhất và lớn nhất sẽ giải thích tại sao mình
chọn số ấy.
 thảo luận cho đến khi mọi người nhất trí trên 1 số nào đó.
© 2010 Slide 34
17
Biểu đồ BURNDOWN
Tasks Mon Tues Wed Thur Fri
Code the user interface 8 4 8
Code the middle tier 16 12 10 7
Test the middle tier 8 16 16 11 8
Write online help 12
50
40
30
20
10
Hours
0
Khoa Khoa học & Kỹ thuật Máy tính Mon Tue Wed Thu Fri
Môn : Công nghệ phần mềm
© 2010 Slide 35
Các lợi ít của SCRUM

 Phần mềm được phân ra thành 1 tập các phần nhỏ dễ hiểu và dễ
quản lý.
 Các yêu cầu chưa ổn định không trì hoãn qui trình phát triển
phần mềm.
 Toàn bộ nhóm có tầm nhìn về mọi điều, kết quả là việc liên lạc
với nhau trong nhóm sẽ được cải tiến.
 Khách hàng thấy sự phát hành kịp thời các bản tăng tiến, nhờ vậy
họ phản hồi nhanh về cách phần mềm hoạt động.
 Sự tin tưởng giữa khách hàng và nhà phát triển được thiết lập và
văn hóa tích cực được tạo ra ở đó mọi người hy vọng dự án sẽ
thành công.
© 2010 Slide 36
18
Lập trình cực nhanh
 Lập trình cực nhanh (XP - Extreme programming) dùng cách tiếp
cận "thái cực" về việc lặp lại việc phát triển phần mềm.
 version mới có thể được tạo ra nhiều lần trong ngày.
 các bản tăng tiến được phân phối tới khách hàng 2 tuần 1 lần.
 tất cả test case phải được thực hiện cho mỗi build và build chỉ
được chấp thuận nếu các test case chạy thành công trên nó.
© 2010 Slide 37
10.7 Kết chương

 ?
© 2010 Slide 38
19

Cong Nghe Phan Mem - Chuong10

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cong Nghe Phan Mem - Chuong10

Uploaded by

Copyright:

Available Formats

Chương 10

Phát triển phần mềm Agile

10.1 Phát triển phần mềm nhanh

Phát triển agile / phát triển theo kế hoạch

VL1 : cá nhân và giao tiếp hơn là qui trình và công cụ

VL2 : tập trung coding hơn là lập tài liệu

VL3 : cộng tác với khách hàng hơn là thương lượng

SCRUM được dùng bởi

Cách SCRUM hoạt động

10.4 Các nhân sự SCRUM

10.5 Các cuộc họp SCRUM

As a vacation planner, I want to Code the middle tier (8 hours)

Cuộc họp SCRUM hằng ngày (hằng tuần)

Các cuộc họp nhìn lại Sprint

10.6 Các artifacts SCRUM

Ước lượng nỗ lực

Các lợi ít của SCRUM

10.7 Kết chương

You might also like