Xây dựng mô hình đánh giá dự án phát triển phần mềm theo phương thức agile

TÓM TẮT LUẬN VĂN Mục tiêu chính của luận văn là tìm ra đáp án cho câu hỏi các phương thức đo lường phần mềm có thể được kết hợp trong quá trình phát triển phần mềm theo phương thức Agile

ĐẠI HỌC QUỐC GIA TP HỒ CHÍ MINH TRƯỜNG ĐẠI HỌC BÁCH KHOA -

TRẦN NGUYỄN PHƯƠNG THẢO

XÂY DỰNG MÔ HÌNH ĐÁNH GIÁ DỰ ÁN PHÁT TRIỂN

PHẦN MỀM THEO PHƯƠNG THỨC AGILE

Chuyên ngành : HỆ THỐNG THÔNG TIN QUẢN LÝ

Mã số: 60.34.04.05

LUẬN VĂN THẠC SĨ

TP HỒ CHÍ MINH – tháng 12 năm 2016

ĐẠI HỌC QUỐC GIA TP HỒ CHÍ MINH TRƯỜNG ĐẠI HỌC BÁCH KHOA -

TRẦN NGUYỄN PHƯƠNG THẢO

XÂY DỰNG MÔ HÌNH ĐÁNH GIÁ DỰ ÁN PHÁT TRIỂN

PHẦN MỀM THEO PHƯƠNG THỨC AGILE

Chuyên ngành : HỆ THỐNG THÔNG TIN QUẢN LÝ

Mã số: 60.34.04.05

LUẬN VĂN THẠC SĨ

TP HỒ CHÍ MINH – tháng 12 năm 2016

CÔNG TRÌNH ĐƯỢC HOÀN THÀNH TẠI TRƯỜNG ĐẠI HỌC BÁCH KHOA –ĐHQG -HCM

Cán bộ hướng dẫn khoa học: PGS.TS Đặng Trần Khánh

Cán bộ chấm nhận xét 1

Cán bộ chấm nhận xét 2

Luận văn thạc sĩ được bảo vệ tại Trường Đại học Bách Khoa, ĐHQG Tp HCM ngày 28 tháng 12 năm 2016

Thành phần Hội đồng đánh giá luận văn thạc sĩ gồm:

(Ghi rõ họ, tên, học hàm, học vị của Hội đồng chấm bảo vệ luận văn thạc sĩ)

1

2

3

4

5

Xác nhận của Chủ tịch Hội đồng đánh giá LV và Trưởng Khoa quản lý chuyên ngành sau khi luận văn đã được sửa chữa (nếu có)

ĐẠI HỌC QUỐC GIA TP.HCM

TRƯỜNG ĐẠI HỌC BÁCH KHOA

CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM

Độc lập - Tự do - Hạnh phúc

NHIỆM VỤ LUẬN VĂN THẠC SĨ

Họ tên học viên: Trần Nguyễn Phương Thảo MSHV:7141177

Ngày, tháng, năm sinh: 23/11/1992 Nơi sinh: Đồng Nai

Chuyên ngành: Hệ thống thông tin quản lý Mã số : 60 34 04 05

I TÊN ĐỀ TÀI: XÂY DỰNG MÔ HÌNH ĐÁNH GIÁ DỰ ÁN PHÁT TRIỂN

PHẦN MỀM THEO PHƯƠNG THỨC AGILE

III NHIỆM VỤ VÀ NỘI DUNG:

Nghiên cứu phương thức xây dựng thang đo đánh giá, nghiên cứu lý thuyết về tiêu

chuẩn đo lường và đặc điểm của phương pháp phát triển phần mềm linh hoạt Agile

Xây dựng mô hình đánh giá dự án phát triển phần mềm theo phương thức Agile

Ứng dụng mô hình đo lường vào dự án thực tế

II NGÀY GIAO NHIỆM VỤ : 04/7/2016

III NGÀY HOÀN THÀNH NHIỆM VỤ: 04/12/2016

LỜI CẢM ƠN

Tôi xin chân thành cám ơn khoa Khoa học và Kỹ thuật máy tính, trường Đại học Bách Khoa thành phố Hồ Chí Minh đã tạo điều kiện cho tôi thực hiện luận văn này Xin cám ơn thầy Đặng Trần Khánh người đã tận tình hướng dẫn, chỉ bảo tôi trong suốt thời gian thực hiện đề tài Trong thời gian làm việc với thầy, tôi không những học hỏi thêm nhiều kiến thức bổ ích mà còn học được tinh thần làm việc, thái độ nghiên cứu khoa học nghiêm túc của thầy

Xin gửi lời cám ơn chân thành đến gia đình và bạn bè, đồng nghiệp đã luôn hỗ trợ, giúp đỡ hết sức nhiệt tình để tôi có thể vượt qua những khó khăn trong suốt quá trình làm việc

Mặc dù đã cố gắng hoàn thành luận văn trong phạm vi và khả năng cho phép nhưng chắc chắn không tránh khỏi những thiếu sót Vì vậy kính mong nhận được sự thông cảm và chỉ bảo của quý Thầy (Cô) và các bạn

Tác giả Trần Nguyễn Phương Thảo

TÓM TẮT LUẬN VĂN

Mục tiêu chính của luận văn là tìm ra đáp án cho câu hỏi các phương thức đo lường phần mềm có thể được kết hợp trong quá trình phát triển phần mềm theo phương thức Agile để hỗ trở cải tiến liên tục ra sao Với mục đích trên, luận văn đã nghiên cứu phương pháp có thể được dùng để xác định mô hình đo lường từ đó sử dụng nó

để xác định mô hình đo lường cho dự án phát triển phần mềm theo phương thức Agile Mô hình này được áp dụng trong dự án thực tiễn để chứng minh tính hữu ích của đề tài nghiên cứu

ABSTRACT

The main objective of the thesis was to find out the answer of the question “How software measurement methods can be combined in the development process Agile software methods to support continuous improvement?” For this purpose, the thesis had researched method can be used to determine the measurement model which uses it to determine the measurement model for software development projects according to Agile methods This model has been applied in practical projects to demonstrate the usefulness of research topics

LỜI CAM ĐOAN

Tôi cam đoan rằng đề cương luận văn thạc sĩ của tôi dưới sự hướng dẫn của Phó Giáo Sư Tiến Sĩ Đặng Trần Khánh là do tôi thực hiện, ngoại trừ các kết quả, tham khảo được tham khảo từ các công trình khác Các tham khảo này đều được ghi rõ trong phần Tài liệu tham khảo

Ngày 5 tháng 12 năm 2016

Trần Nguyễn Phương Thảo

MỤC LỤC

DANH MỤC CÁC CHỮ VIẾT TẮT 11

DANH MỤC HÌNH ẢNH 12

DANH MỤC BẢNG BIỂU 13

CHƯƠNG 1: TỔNG QUAN ĐỀ TÀI 14

1.1 Lý do hình thành đề tài 14

1.2 Đối tượng, phạm vi nghiên cứu 15

1.3 Mục đích nghiên cứu 15

1.4 Phương pháp nghiên cứu 15

1.5 Ý nghĩa khoa học và thực tiễn 16

1.6 Cấu trúc đề tài 16

CHƯƠNG 2: CƠ SỞ LÝ THUYẾT 17

2.1Lợi ích của đo lường phần mềm 17

2.2Tổng quan ISO 9126 18

2.3Tổng quan Agile và Scrum 21

CHƯƠNG 3: PHƯƠNG THỨC XÂY DỰNG MÔ HÌNH ĐO LƯỜNG PHẦN MỀM 36

3.1 Điều kiện tiên quyết của thang đo phần mềm 36

3.2 Phương pháp tiếp cận để xác định một mô hình đo lường phần mềm 37

3.3 Kết nối giữa mục tiêu kinh doanh với mục tiêu đo lường 39

CHƯƠNG 4: MÔ HÌNH CHẤT LƯỢNG PHẦN MỀM TRONG MÔI TRƯỜNG AGILE 44

4.1 Xác định mô hình 44

4.2 Các câu hỏi được xây dựng dựa trên tiếp cận mô hình GQM 47

4.3 Xây dựng thang đo 52

CHƯƠNG 5: ỨNG DỤNG MÔ HÌNH ĐO LƯỜNG VÀO DỰ ÁN THỰC TẾ 59

5.1 Tổng quan về ứng dụng 59

5.2 Các nội dung báo cáo chính 60

CHƯƠNG 6: KẾT QUẢ ĐẠT ĐƯỢC VÀ HƯỚNG PHÁT TRIỂN 65

6.1 Kết quả đạt được 65

6.2 Hướng phát triển 65

DANH MỤC CÁC TÀI LIỆU THAM KHẢO 66

DANH MỤC CÁC CHỮ VIẾT TẮT

Danh mục từ viết tắt và giải thích các thuật ngữ tiếng Anh

Agile Agile Software Development Phát triển phần mềm linh hoạt

BDD Behavior Driven

Development

Phát triển theo hướng hành vi

ITS Issue Tracking System Hệ thống ghi lỗi

TDD Test Driven Development Phát triển theo hướng kiểm thử

Adaptive planing Lập kế hoạch thích ứng Continous Intergration Công cụ tích hớp liên tục Code Đoạn mã lệnh trong lập trình Defect/Bug Lỗi xảy ra trong quá trình thực

hiện chức năng của phần mềm Daily meeting Họp tập trung hàng ngày Interative Phân đoạn lặp

Incremental Phân đoạn tăng trưởng Release Bàn giao chức năng đến khách

hàng Scrum Phương pháp Agile được dùng

phổ biến Sprint Chu trình phát triển sản phẩm

trong Scrum User Stories Yêu cầu người dùng

DANH MỤC HÌNH ẢNH

Hình 2.1 Mức độ phổ biến của các phương pháp phát triển phần mềm 22

Hình 2.2 Hình Cynefin Framework 23

Hình 2.3 Các phân đoạn lặp đi lặp lại trong Agile 26

Hình 2.4 Các phương pháp Agile được dùng 29

Hình 2.5 Tóm tắt Scrum 30

Hình 2.6 Ví dụ về Product Backlog 33

Hình 2.7 Sprint Backlog 34

Hình 2.8 Burndown Chart 34

Hình 3.1 Goal Question Metric Approach ( GQM) 39

Hình 3.2 Tam giác Agile (Highsmith 2010) 43

Hình 4.1 Ứng dụng của phương thức GQM để định nghĩa mô hình đo lường chất lượng phần mềm 45

Hình 4.2: Mô hình chất lượng sản phẩm (ISO/IEC 25010) 46

Hình 4.3 : Ánh xạ thuộc tính con tới thuộc tính mã nguồn 57

Hình 5.1 Defect Escape Report 60

Hình 5.2 High/Critical Defect Escape Report 61

Hình 5.3 Escape Production by Durable Team 62

Hình 5.4 Escape Staging by Durable Team 63

Hình 5.5 Defect Ratio 64

Hình 5.6 Defect Detection Efficiency 64

DANH MỤC BẢNG BIỂU

Bảng 2.1 Nhận biết và ra quyết định phù hợp với độ phức tạp, theo Snowden

và Boone 25Bảng 3.1 Các yếu tố ảnh hưởng đến chất lượng phần mềm (Chappell) 41

CHƯƠNG 1: TỔNG QUAN ĐỀ TÀI

1.1 Lý do hình thành đề tài

Ngày nay, công nghệ phần mềm đang phải đối mặt với sự thay đổi nhanh chóng về yêu cầu người dùng cũng như công nghệ Để đối phó với sự thay đổi nhanh chóng trong môi trường kinh doanh, quá trình phát triển phần mềm phải được đánh giá và điều chỉnh thường xuyên Các phương pháp truyền thống như phương pháp thác nước, không phù hợp cho môi trường với sự thay đổi nhanh chóng như trên vì chúng có xu hướng lên kế hoạch cho một phần lớn của quá trình phần mềm quãng thời gian dài một cách chi tiết và mọi thứ hoạt động ổn định cho đến khi xảy ra thay đổi vì vậy, bản chất của các phương pháp truyền thống là để chống lại sự thay đổi Phương pháp Agile tiến hóa để thúc đẩy cải tiến liên tục Scrum thuộc về phương pháp Agile và lặp lại các phản hồi thường xuyên để cải thiện Cải tiến liên tục là một yếu tố then chốt của Scrum và các phương pháp Agile khác và vấn đề mà các nhà phát triển phần mềm đang đối mặt là xác định tiềm năng cải tiến Sự nhận dạng tiềm năng cải tiến nên thực hiện một cách khách quan hơn chủ quan Một loạt các

số liệu phần mềm tồn tại cung cấp thông tin về các nguồn lực, các quy trình và các sản phẩm liên quan đến phát triển phần mềm Số liệu phần mềm cung cấp thông tin thực tế và định lượng

Sự giới thiệu riêng lẻ số liệu phần mềm là không đủ Nhiều mô hình đo lường phần mềm đã thất bại vì chúng không tôn trọng các yếu tố thành công quan trọng Do đó, một mô hình đo phải phản ánh cụ thể được vấn đề tổ chức hoặc các mục tiêu để cung cấp dữ liệu mà có thể được sử dụng để tìm ra giải pháp để khắc phục các vấn

đề có liên quan đến các mục tiêu của tổ chức Nói cách khác, các mô hình đo lường

sẽ chỉ có thể cung cấp thông tin có liên quan nếu một liên kết giữa các mục tiêu kinh doanh và các phép đo hiệu năng được thành lập Nhưng ngay cả khi mô hình

đo lường phản ánh các mục tiêu của tổ chức, rất khó để phân loại các kết quả đo Liệu một giá trị số liệu cụ thể là dấu hiệu của sự cải thiện hay xấu đi đối với một mục tiêu nhất định

Tất cả những vấn đề này cần phải được giải quyết để xây dựng thành công một mô hình đánh giá dự án phát triển phần mềm Mục đích của luận văn là để giải quyết vấn đề nêu trên của việc đo lường một dự án phát triển phần mềm Nghiên cứu này nghiên cứu trong môi trường Agile với phương thức Scrum

1.2 Đối tượng, phạm vi nghiên cứu

- Các tiêu chuẩn đo lường chất lượng phần mềm

- Các đặc trưng của phương thức phát triển phần mềm Aglie

- Các mô hình cơ bản trong việc xây dựng thang đo

- Số liệu thực tế từ dự án

1.3 Mục đích nghiên cứu

Mục đích chính của đề tài là nghiên cứu phương thức xây dựng thang đo đánh giá, nghiên cứu lý thuyết về tiêu chuẩn đo lường và đặc điểm của phương pháp phát triển phần mềm linh hoạt Agile để từ đó xây dựng mô hình đánh giá dự án phát triển phần mềm theo phương thức Agile và ứng dụng mô hình đo lường vào dự án thực

tế

1.4 Phương pháp nghiên cứu

Phương pháp nghiên cứu lý thuyết: Nghiên cứu tài liệu liên quan đến các đối tượng nghiên cứu được trình bày ở mục 1.1, lựa chọn các thuộc tính phù hợp để xây dựng thang đo cũng như mô hình tổng quan

Phương pháp chuyên gia: Tham khảo ý kiến các chuyên gia trong lĩnh vực phát triển phần mềm để có những hướng dẫn kịp thời, chuyên sâu trong quá trình thực hiện đề tài

Phương pháp thiết kế: Dùng trong ví dụ mô tả, phân tích yêu cầu của dự án, thiết kế mẫu báo cáo, tìm kiếm dữ liệu phù hợp để hoàn thiện báo cáo

Phương pháp dùng câu hỏi nghiên cứu

1.5 Ý nghĩa khoa học và thực tiễn

Về mặt lý thuyết, luận văn nghiên cứu về phương thức cơ bản để xây dựng mô hình đánh giá, phân tích, lựa chọn các tiêu chuẩn dùng để đánh giá chất lượng phần mềm

để hoàn thành mô hình đánh giá chất lượng phần mềm tổng quan

Về mặt thực tiễn: Ứng dụng kết quả nghiên cứu vào dự án thực tế và đạt được những lợi ích nhất định cho dự án

1.6 Cấu trúc đề tài

Nội dung chính của đề tài gồm 6 chương:

Chương 1: Giới thiệu tổng quan đề tài - Giới thiệu khái quát về lý do lựa chọn đề tài, mục tiêu, ý nghĩa, đối tượng và phạm vi nghiên cứu, cũng như các phương pháp

sẽ áp dụng để hiện thực hóa đề tài

Chương 2: Cơ sở lý thuyết – Cung cấp kiến thức tổng quan về lợi ích của đo lường phần mềm, chuẩn ISO 9126 dùng trong đánh giá chất lượng phần mềm và các kiến thức cơ bản về phát triển phần mềm linh hoạt

Chương 3: Xây dựng mô hình đo lường phần mềm – Đề xuất và nghiên cứu phương thức GQM trong việc xây dựng mô hình đo lường

Chương 4: Mô hình đo lường chất lượng phần mềm trong môi trường Agile – Xây dựng mô hình đánh giá chất lượng phần mềm dựa trên phương thức đã nghiên cứu Chương 5: Ứng dụng mô hình đo lường vào dự án thực tế

Chương 6: Kết quả đạt được và hướng phát triển

CHƯƠNG 2: CƠ SỞ LÝ THUYẾT

2.1 Lợi ích của đo lường phần mềm

Sự đo lường được giới thiệu bởi các tổ chức công nghệ thông tin để hiểu rõ hơn, đánh giá, kiểm soát và dự đoán việc ra quyết định và quy trình phần mềm Có nhiều công dụng thiết thực của thang đo phần mềm Bốn trong số chúng gồm:

Dự toán dự án và theo dõi tiến độ:

Hiện tại, có rất nhiều công việc dự toán, với thành công hạn chế Ngày nay, ngành công nghiệp phần mềm nhận biết rằng có rất nhiều khía cạnh của phát triển phần mềm ảnh hưởng đến sự dự toán Nhấn mạnh về cải tiến quy trình cho chúng ta một

số điểm cần quan tâm ở đây, các ước lượng không chính xác là kết quả của thời gian chu trình phát triển dài và sự biến đổi của quy trình Điều đó không bất thường đối với các dự án yêu cầu phải thay đổi sau khi ra đời Các nhà quản lý phải có trách nhiệm đặt hệ thống thích hợp đúng nơi để đo lường tiến độ dự án Họ cần phải sử dụng dữ liệu từ các dự án trước đó để ước lượng dự án và hiệu quả xử lý một cách tiến độ quá trình và yêu cầu thay đổi

Đánh giá hoạt động của sản phẩm:

Phân tích code là vùng lớn nhất của nghiên cứu số liệu phần mềm Mọi sự phát triển phần mềm kết quả cuối cùng có bước tiến của code Code được thể hiện bằng một ngôn ngữ chuẩn trong lập trình có thể được xử lý tự động Mỗi ngôn ngữ cũng được xác định, và code là hình thức hoàn toàn của các kết quả mong muốn Điều này làm cho các sản phẩm cuối cùng - code - một phương tiện thuận lợi để áp dụng số liệu phần mềm

Quá trình cải thiện thông qua phân tích chất lượng phần mềm:

Chất lượng phần mềm là một trong những hứa hẹn và mở rộng nhất trong quá trình phát triển phần mềm ngày nay Phân tích defect, theo dõi và loại bỏ cung cấp một tiềm năng lớn cho các công ty phải cắt giảm chi phí phát triển và chi phí bảo trì của

họ Chất lượng phần mềm bao gồm một loạt các thuộc tính: tính toàn vẹn, tính

tương hợp, linh hoạt, bảo trì, tính di động, tính mở rộng, tái sử dụng, khả năng đàn hồi và khả năng sử dụng Những thuộc tính này nên được lưu ý khi thiết kế và thực hiện các quy trình phát triển phần mềm Sau đó, thành tích đạt được có thể được xác nhận sử dụng số liệu phân tích lỗi và kiểm tra đảm bảo chất lượng

Xác nhận kinh nghiệm của các mẫu tốt nhất trong phát triển phần mềm Công nghệ phần mềm là một lĩnh vực thay đổi nhanh chóng Điều đó rất quan trọng cho các công ty để tiếp tục sử dụng số liệu đo lường để kiểm tra các yêu cầu đôi khi không thực tế được thực hiện cho các phương pháp phát triển phần mềm mới và các công cụ trong công nghệ phần mềm

Tính chức năng: Khả năng của phần mềm cung cấp các chức năng đáp ứng được nhu cầu sử dụng khi phần mềm làm việc trong điều kiện cụ thể

 Sự phù hợp: là khả năng của một phần mềm có thể cung cấp một tập các chức năng thích hợp cho công việc cụ thể phục vụ mục đích của người sử dụng

 Độ chính xác: là khả năng của phần mềm có thể cung cấp các kết quả hay hiệu quả đúng đắn hoặc chấp nhận được với độ chính xác cần thiết

 Khả năng tương tác: với một hoặc một vài hệ thống cụ thể của phần mềm

 Tính an toàn: khả năng bảo vệ thông tin và dữ liệu của sản phẩm phần mềm,sao cho những người, hệ thống không được phép thì không thể truy cập, đọc hay chỉnh sửa chúng

 Tính tuân thủ chức năng: các phần mềm theo các chuẩn, quy ước, quy định

Tính tin cậy: Là khả năng của phần mềm có thể hoạt động ổn định trong những điều kiện cụ thể

 Tính chính xác: khả năng tránh các kết quả sai

 Khả năng chịu lỗi: khả năng của phần mềm hoạt động ổn định tại một mức độ cả trong trường hợp có lỗi xảy ra ở phần mềm hoặc có những vi phạm trong giao diện

 Khả năng phục hồi: khả năng của phần mềm có thể tái thiết lại hoạt động tại một mức xác định và khôi phục lại những dữ liệu có liên quan trực tiếp đến lỗi

 Tính tuân thủ tin cậy: phần mềm thoả mãn các chuẩn, quy ước, quy định Tính khả dụng: Là khả năng của phần mềm có thể hiểu được, học được, sử dụng được và hấp dẫn người sử dụng trong từng trường hợp sử dụng cụ thể

 Có thể hiểu được: người sử dụng có thể hiểu được xem phần mềm có hợp với họ không và và sử dụng chúng thế nào cho những công việc cụ thể

 Có thể học được: người sử dụng có thể học các ứng dụng của phần mềm

 Có thể sử dụng được: khả năng của phần mềm cho phép người sử dụng

sử dụng và điều khiển nó

 Tính hấp dẫn: khả năng hấp dẫn người sử dụng của phần mềm

 Tính tuân thủ khả dụng: phần mềm thoả mãn các chuẩn, quy ước, quy định

Tính hiệu quả: Khả năng của phần mềm có thể hoạt động một cách hợp lý, tương ứng với lượng tài nguyên nó sử dụng, trong điều kiện cụ thể

 Đáp ứng thời gian: khả năng của phần mềm có thể đưa ra trả lời, thời gian

xử lý và một tốc độ thông lượng hợp lý khi thực hiện công việc của mình, dưới điều kiện làm việc xác định

 Tận dụng tài nguyên: khả năng của phần mềm có thể sử dụng một số lượng, một loại tài nguyên hợp lý để thực hiện công việc trong những điều kiện cụ thể

 Tính tuân thủ hiệu quả: thoả mãn các chuẩn, quy ước, quy định

Khả năng bảo hành, bảo trì: Khả năng của phần mềm có thể chỉnh sửa Việc chỉnh sửa bao gồm: sửa lại cho đúng, cải tiến và làm phần mềm thích nghi được với những thay đổi của môi trường, của yêu cầu và của chức năng xác định

 Có thể phân tích được: phần mềm có thể được chẩn đoán để tìm những thiếu sót hay những nguyên nhân gây lỗi hoặc để xác định những phần cần sửa

 Có thể thay đổi được: phần mềm có thể chấp nhận một số thay đổi cụ thể trong quá trình triển khai

 Tính bền vững: khả năng tránh những tác động không mong muốn khi chỉnh sửa phần mềm

 Có thể kiểm tra được: khả năng cho phép phần mềm chỉnh sửa có thể được đánh giá

 Khả năng tuân thủ bảo trì: thoả mãn các chuẩn, quy ước, quy định

Tính khả chuyển: Là khả năng của phần mềm cho phép nó có thể được chuyển từ môi trường này sang môi trường khác

 Khả năng thích nghi: khả năng của phần mềm có thể thích nghi với nhiều môi trường khác nhau mà không cần phải thay đổi

 Có thể cài đặt được: phần mềm có thể cài đặt được trên những môi trường cụ thể

 Khả năng cùng tồn tại: phần mềm có thể cùng tồn tại với những phần mềm độc lập khác trong một môi trường chung, cùng chia sẻ những tài nguyên chung

 Khả năng thay thế: phần mềm có thể dùng thay thế cho một phần mềm khác,với cùng mục đích và trong cùng môi trường

 Tính tuân thủ khả chuyển: thoả mãn các chuẩn, quy ước, quy định

Mỗi chất lượng phụ đặc trưng (như khả năng thích ứng) có thể được chia thành các thuộc tính sản phẩm cụ thể hơn Thuộc tính là một tài sản có thể được xác định hay

đo lường trong các sản phẩm phần mềm Các thuộc tính không được định nghĩa trong tiêu chuẩnvì có sự khác nhau lớn giữa các sản phẩm phần mềm Thách thức đối với đo lường phần mềm là để mô tả các thuộc tính chất lượng của tiêu chuẩn ISO 9126 với các thang đo dùng cho phần mềm

2.3 Tổng quan Agile và Scrum

2.3.1.Tổng quan Agile

Agile là một nhóm các phương pháp và phương pháp luận phát triển phần mềm dựa trên các nguyên tắc phát triển phân đoạn lặp và tăng trưởng, theo đó nhu cầu và giải pháp tiến hóa thông qua sự hợp tác giữa các nhóm tự quản và liên chức năng Agile thường sử dụng cách lập kế hoạch thích ứng, việc phát triển và chuyển giao theo hướng tiến hóa; sử dụng các khung thời gian ngắn và linh hoạt để dễ dàng phản hồi lại với các thay đổi trong quá trình phát triển

Nhờ tính linh hoạt, đa dạng và hiệu quả cao, các phương pháp Agile ngày càng trở thành sự lựa chọn hàng đầu của các khách hàng, nhà phát triển, các công ty phát triển phần mềm Theo khảo sát của hãng nghiên cứu thị trường Forrester, mức độ phổ biến của Agile hiện đang ở mức cao nhất, và gấp nhiều lần so với các phương pháp truyền thống như thác nước hay CMMI

Hình 2.1 Mức độ phổ biến của các phương pháp phát triển phần mềm

(Nguồn: Forrester Research) Khi nào sử dụng Agile:

Trong bài báo “Embrace Agile” đăng trên HBR[23], đồng tác giả Scrum, ông Jeff Sutherland cùng với giáo sư Takeuchi ở Đại học Harvard và Darrell K Rigby đã cung cấp một số lời khuyên hữu ích Các tác giả cho rằng Agile phù hợp khi:

- Nhu cầu khách hàng và yêu cầu về giải pháp thay đổi thường xuyên

- Cần cộng tác chặt chẽ với khách hàng và có thể cung cấp các phản hồi nhanh, khách hàng nắm rõ hơn về những gì họ mong muốn

- Vấn đề rất phức tạp, giải pháp không rõ từ đầu và phạm vi cũng không được xác định rõ

- Đặc tả sản phẩm có thể thay đổi, và những sáng tạo đột phá luôn được ưu tiên

- Việc phát triển tăng trưởng mang lại giá trị, và khách hàng có thể sử dụng ngay những giá trị này

- Công việc có thể bẻ nhỏ thành từng phần và có thể được thực thi trong những phân đoạn lặp ngắn

- Những thay đổi ở phút chót có thể quản lí được

- Những sai sót có thể mang lại những bài học chứ không mang đến những thảm họa

Agile có thể không phù hợp trong những điều kiện ngược lại:

- Điều kiện thị trường ổn định và có thể tiên lượng

- Yêu cầu rất rõ ràng và luôn ổn định

- Khách hàng không thể cộng tác thường xuyên

- Công việc tương tự những gì đã làm trước đó, và giải pháp là rất rõ ràng Đặc

tả chi tiết có thể làm ra với sự dự đoán rõ ràng và chính xác Vấn đề có thể giải quyết tuần tự qua từng bộ phận chức năng mà không gặp trở ngại nào

- Khách hàng không thể bắt đầu kiểm thử các phần sản phẩm cho tới khi sản phẩm hoàn chỉnh

- Thay đổi phút chót rất tốn kém, hoặc không thể

- Sai sót trong thực thi có thể dẫn đến thảm họa không thể cứu vãn được Trong bài báo “A Leader’s Framework for Decision Making”[24] trên HBR số Tháng 11 năm 2007, các tác giả Snowden và Boone trình bày một mô hình phân loại thế giới trong các vùng với các đặc điểm tương đối khác nhau với độ phức tạp tăng dần: Hiển nhiên (Obvious), Rắm rối (Complicated), Phức hợp (Complex) và Hỗn độn (Chaotic)

Hình 2.2 Hình Cynefin Framework

Tình huống Đặc điểm nhận dạng Vai trò người ra quyết định Hiển nhiên Các khuôn mẫu và sự kiện

lặp đi lặp lại Nhìn rõ mối quan hệ nhân-quả

Có một câu trả lời đúng đắn Mọi người biết rõ những cái

đã biết Quản lí theo thực tế

Phán đoán trước, phân loại sau, rồi phản hồi

Rắm rối Cần chuyên gia phân tích

Có thể nhận biết quan hệ nhân-quả nhưng không hiển nhiên đối với mọi người

Có nhiều hơn một câu trả lời Mọi người biết là có những thứ chưa biết đến

Phức hợp Thay đổi liên tục và không

thể tiên lượng Không có câu trả lời đúng đắn

Mọi người không biết những điều chưa biết

Rất nhiều ý tưởng đối nghịch nhau

Cần những tiếp cận sáng tạo Lãnh đạo dựa-trên-khuôn-mẫu (pattern-based leadership)

Thử nghiệm trước, phán đoán sau, rồi phản hồi

Tạo môi trường thử nghiệm cho phép các khuôn mẫu xuất hiện

Tăng mức độ tương tác và giao tiếp hai chiều

Dùng các phương pháp để tạo lập thật nhiều ý tưởng: thảo luận mở; tạo lập biên; khuyến khích các nhân tố thu hút; khuyến khích sự bất đồng quan điểm và sự đa dạng; quản lí các điều kiện ban đầu

và giám sát để hình thành các khuôn mẫu

Hỗn độn Nhiễu loạn cao độ

Không rõ quan hệ nhân- quả, thậm chí không có điểm nào

để tìm kiếm manh mối Không thể biết được điều gì Phải ra nhiều quyết định cấp tập mà không có thời gian để suy nghĩ

Lãnh đạo mẫu (pattern-based leadership)

dựa-trên-khuôn-Hành động trước, phán đoán sau, rồi phản hồi

Quan sát xem cái nào hiệu quả thay vì tìm kiếm câu hỏi đúng đắn

Hành động tắp lự để vãn hồi trật tự (mệnh lệnh và kiểm soát)

Truyền đạt rõ ràng, trực tiếp

Bảng 2.1 Nhận biết và ra quyết định phù hợp với độ phức tạp, theo Snowden và Boone

Như chúng ta thấy, Agile phù hợp hơn ở vùng Phức hợp, nơi có thể vận dụng cách thức thí nghiệm - phán đoán - phản hồi để ra quyết định, trao quyền tự quản cho nhóm, thiết lập các điều kiện ban đầu và luôn tìm kiếm các khuôn mẫu thích ứng có tính tối ưu nổi lên trong quá trình nhóm làm việc tự tổ chức Ở một mức độ nhất định, Agile có thể phù hợp ở vùng Rắm rối, nhưng nói chung, vùng Phức hợp là vùng dễ thấy tính tương thích nhiều nhất

Dựa trên Cynefin, chúng ta có cái nhìn rõ ràng hơn trong trường hợp nào thì Agile

sẽ hiệu quả Tuy vậy, Cynefin vẫn chỉ là một công cụ mang tính kĩ thuật Và những lời khuyên ở bên trên cũng mang tính kĩ thuật Nó động đến câu hỏi “phải làm sao” khi ra quyết định Agile hay không Agile Nhưng việc ra các quyết định trong thực

tế lại đòi hỏi chúng ta phải hỏi “tại sao”, “để làm gì” nhiều hơn Agile để làm gì? Tức là hỏi cái mục đích của việc sử dụng Agile Xa hơn nữa, là hỏi cái triết lí kinh doanh của nhà lãnh đạo là gì

Đặc trưng của Agile:

Có rất nhiều phương pháp Agile với các hướng tiếp cận rất khác nhau Bên cạnh các cách thức tổ chức công việc, thiết lập quy trình, các phương pháp Agile còn nghiên cứu và đưa vào sử dụng các công cụ và kĩ thuật đặc thù như công cụ tích hợp liên tục, kiểm thử đơn vị, mẫu thiết kế, tái cấu trúc, phát triển hướng kiểm thử (TDD), phát triển hướng hành vi (BDD), hay lập trình theo cặp v.v… để đảm bảo và gia tăng tính linh hoạt Tuy vậy các phương pháp này chia sẻ nhiều đặc trưng giống nhau như cộng tác nhóm chặt chẽ, tổ chức các nhóm tự quản, liên chức năng, tính đáp ứng cao trong suốt vòng đời của dự án

- Tính lặp:

Dự án sẽ được thực hiện trong các phân đoạn lặp đi lặp lại Các phân đoạn (được gọi là Iteration hoặc Sprint) này thường có khung thời gian ngắn (từ một đến bốn tuần) Trong mỗi phân đoạn này, nhóm phát triển thực hiện đầy đủ các công việc cần thiết như lập kế hoạch, phân tích yêu cầu, thiết kế, triển khai, kiểm thử (với các mức độ khác nhau) để cho ra các phần nhỏ của sản phẩm Các phương pháp Agile

thường phân rã mục tiêu thành các phần nhỏ với quá trình lập kế hoạch đơn giản và gọn nhẹ nhất có thể, và không thực hiện việc lập kế hoạch dài hạn Có phương pháp như Scrum thậm chí sử dụng phương pháp lập kế hoạch “just-in-time” trong quá trình phát triển Khi đó, thậm chí công việc lập kế hoạch, làm mịn kế hoạch được thực hiện liên tục trong suốt quá trình làm việc

Hình 2.3 Các phân đoạn lặp đi lặp lại trong Agile

- Tính tăng trưởng:

Cuối các phân đoạn, nhóm phát triển thường cho ra các phần nhỏ của sản phẩm cuối cùng Các phần nhỏ này thường là đầy đủ, có khả năng chạy tốt, được kiểm thử cẩn thận và có thể sử dụng ngay Theo thời gian, phân đoạn này tiếp nối phân đoạn kia, các phần chạy được này sẽ được tích lũy, lớn dần lên cho tới khi toàn bộ yêu cầu của khách hàng được thỏa mãn Khác với mô hình phát triển Thác nước – vốn chỉ cho phép nhìn thấy toàn bộ các chức năng tại thời điểm kết thúc dự án, sản phẩm trong các dự án Agile lớn dần lên theo thời gian, tiến hóa cho tới khi đạt được trạng thái đủ để phát hành

- Tính thích ứng:

Do các phân đoạn chỉ kéo dài trong một khoảng thời gian ngắn, và việc lập kế hoạch cũng được điều chỉnh liên tục, nên các thay đổi trong quá trình phát triển (yêu cầu thay đổi, thay đổi công nghệ, thay đổi định hướng về mục tiêu v.v.) đều có thể được đáp ứng theo cách thích hợp Ví dụ, trong Scrum – phương pháp phổ biến nhất hiện nay – trong khi nhóm phát triển sản xuất ra các gói phần mềm, khách hàng có thể đưa thêm các yêu cầu mới, chủ sản phẩm (Product Owner) có thể đánh giá các yêu cầu này và có thể đưa vào làm việc trong phân đoạn (được gọi là Sprint trong Scrum) tiếp theo Theo đó, các quy trình Agile thường thích ứng rất tốt với các thay đổi

- Nhóm tự tổ chức và liên chức năng:

Cấu trúc nhóm Agile thường là liên chức năng và tự tổ chức Theo đó, các nhóm này tự thực hiện lấy việc phân công công việc mà không dựa trên các mô tả cứng về chức danh hay làm việc dựa trên một sự phân cấp rõ ràng trong tổ chức Các nhóm này cộng tác với nhau để ra quyết định, theo dõi tiến độ, giải quyết các vấn đề mà không chờ mệnh lệnh của các cấp quản lý Họ không làm việc theo cơ chế “mệnh lệnh và kiểm soát” (command and control)

- Quản lý tiến trình thực nghiệm:

Các nhóm Agile ra các quyết định dựa trên các dữ liệu thực tiễn thay vì tính toán lý thuyết hay các giả định Việc phân nhỏ dự án thành các phân đoạn ngắn góp phần gia tăng các điểm mốc để nhóm phát triển thu thập dữ kiện cho phép điều chỉnh các chiến lược phát triển của mình Theo thời gian, các chiến lược này sẽ tiến gần đến trạng thái tối ưu, nhờ đó nhóm có thể kiểm soát được tiến trình, và nâng cao năng suất lao động

- Giao tiếp trực diện:

Một số mô hình phát triển phần mềm dựa rất nhiều vào công việc giấy tờ, từ việc thu thập yêu cầu người dùng, viết đặc tả hệ thống, các thiết kế hệ thống v.v Agile không phản đối công dụng của công việc tài liệu hóa, nhưng đánh giá cao hơn việc giao tiếp trực diện thay vì gián tiếp thông qua giấy tờ Về yêu cầu của khách hàng, Agile khuyến khích nhóm phát triển trực tiếp nói chuyện với khách hàng để hiểu rõ hơn về cái khách hàng thực sự cần, thay vì phụ thuộc nhiều vào các loại văn bản Trong giao tiếp giữa nội bộ nhóm phát triển với nhau, thay vì một lập trình viên (thực hiện việc mã hóa) và một kĩ sư (thực hiện việc thiết kế) giao tiếp với nhau thông qua bản thiết kế, Agile khuyến khích hai người này trực tiếp trao đổi và thống nhất với nhau về thiết kế của hệ thống và cùng nhau triển khai thành các chức năng theo yêu cầu

Bản thân các nhóm Agile thường nhỏ (ít hơn mười hai người) để đơn giản hóa quá trình giao tiếp, thúc đẩy việc cộng tác hiệu quả Các dự án lớn muốn dùng Agile thường phải phân thành nhóm nhỏ đồng thời làm việc với nhau hướng đến một mục tiêu chung Việc này có thể đòi hỏi một số nỗ lực đáng kể trong việc điều phối các mức ưu tiên giữa các nhóm

Các nhóm phát triển thường tạo ra các thói quen trao đổi trực diện một cách thường xuyên Một trong các cơ chế thường thấy là các cuộc họp tập trung hằng ngày (daily meeting) Tại đây, tất cả các thành viên được yêu cầu nói rõ cho nhóm của mình biết mình đã làm gì, đang làm gì, sắp làm gì và đang gặp phải khó khăn nào trong quá trình làm việc Khi cơ chế này được thực hiện hiệu quả, nhóm luôn luôn nắm được tình hình công việc của mình, có các hành động thích hợp để vượt qua các trở lực để thực hiện thành công mục tiêu của dự án

- Phát triển dựa trên giá trị:

Một trong các nguyên tắc cơ bản của Agile là “phần mềm chạy tốt chính là thước đo của tiến độ” Nguyên tắc này giúp nhóm dám loại bỏ đi các công việc dư thừa không trực tiếp mang lại giá trị cho sản phẩm

Để vận hành được cơ chế “làm việc dựa trên giá trị”, nhóm Agile thường làm việc trực tiếp và thường xuyên với khách hàng (hay đại diện của khách hàng), cộng tác trực tiếp với họ để biết yêu cầu nào có độ ưu tiên cao hơn, mang lại giá trị hơn cho

dự án Nhờ đó các dự án Agile thường giúp khách hàng tối ưu hóa được giá trị của

dự án Một cách gần như trực tiếp, Agile gia tăng đáng kể độ hài lòng của khách hàng

Các tuyên ngôn của Agile:

 “Cá nhân và sự tương hỗ quan trọng hơn quy trình và công cụ”

 “Sản phẩm xài được quan trọng hơn tài liệu về sản phẩm”

 “Cộng tác với khách hàng quan trọng hơn đàm phán hợp đồng”

 “Phản hồi với sự thay đổi quan trọng hơn bám theo kế hoạch”

Những nguyên tắc của Agile

 Thỏa mãn yêu cầu của khách hàng thông qua việc giao hàng sớm và liên tục

 Chào đón việc thay đổi yêu cầu, thậm chí là những thay đổi yêu cầu muộn

 Giao phần mềm chạy được cho khách hàng một cách thường xuyên (giao hàng tuần hơn là hàng tháng)

 Nhà kinh doanh và kỹ sư lập trình phải làm việc cùng nhau hàng ngày trong suốt dự án

 Các dự án được xây dựng xung quanh những cá nhân có động lực Cung cấp cho họ môi trường và sự hỗ trợ cần thiết, và tin tưởng họ để hoàn thành công việc

 Trao đổi trực tiếp mặt đối mặt là phương pháp hiệu quả nhất để truyền đạt thông tin

 Phần mềm chạy được là thước đo chính của tiến độ

 Phát triển bền vững và duy trì được nhịp độ phát triển liên tục

2.3.2 Tổng quan Scrum:

Scrum là một quy trình phát triển phần mềm theo mô hình Agile, cơ bản là bộ khung làm việc (framework) hay có thể hiểu nôm na là cách thức làm việc để trở nên “linh hoạt” trong phát triển phần mềm Theo thống kê của Vesion One về các phương pháp Agile được sử dụng, Srum là phương pháp chiếm tỷ lệ cao nhất

Hình 2.4 Các phương pháp Agile được dùng

Nguồn: Version One

Scrum chia phần mềm thành các phần nhỏ để phát triển (các phần nhỏ này phải đô ̣c

lập và release được), lấy ý kiến khách hàng và thay đổi cho phù hợp ngay trong quá trình phát triển để đảm bảo sản phẩm release đáp ứng những gì khách hàng mong

muốn Đơn vị của Scum là Sprint Mỗi Sprint sẽ bao gồm mô ̣t số các thành phần requirement, design, code, integration, test, deploy đủ để làm trong mô ̣t khoảng thời gian cố đi ̣nh Từ Sprint đầu tiên, nhóm phát triển cố gắng đưa ra mô ̣t sản phẩm

dù ng được với các chức năng cơ bản nhất và triển khai cho khách hàng Mô ̣t Sprint

có thời ha ̣n từ 2 đến 4 tuần

Hình 2.5 Tóm tắt Scrum Nguồn : gurtejpsingh.wordpress.com/tag/scrum-lifecycle/

Các đặc điểm của Scrum

- Là một khuôn khổ quy trình nhẹ phù hợp với sự phát triển nhanh

- Cho phép các tổ chức dễ điều chỉnh khi có sự thay đổi yêu cầu nhanh chóng,

và sản xuất ra một sản phẩm đáp ứng mục tiêu kinh doanh phát triển

Ưu điểm:

 Một người có thể làm nhiều việc ví dụ như lập trình viên có thể thực hiện kiểm thử

 Phát hiện lỗi sớm hơn rất nhiều so với các phương pháp truyền thống

 Khách hàng nhanh chóng thấy được sản phẩm qua đó đưa ra phản hồi sớm

 Có khả năng áp dụng được cho những dự án mà yêu cầu khách hàng không rõ ràng ngay từ đầu

Nhược điểm:

 Trình độ của nhóm là có một kỹ năng nhất định

 Phải có sự hiểu biết về mô hình Aglie

 Khó khăn trong việc xác định ngân sách và thời gian

 Luôn nghe ý kiến phản hồi từ khách hàng và thay đổi theo nên thời gian

sẽ kéo dài khi có quá nhiều yêu cầu thay đổi từ khách hàng

Vai trò trong Scrum

Trong Scrum có 3 vai trò: Chủ sản phẩm (Product Owner), Nhóm phát triển, và Scrum Master Trong Scrum sẽ không có vai trò Quản lý dự án (Project manager) hay Trưởng nhóm kỹ thuật (Technical lead)

Chủ sản phẩm: Là người chịu trách nhiệm cao nhất đối với sản phẩm và nhóm phát triển Chủ sản phẩm có trách nhiệm làm việc với chủ đầu tư để hiểu yêu cầu về sản phẩm, quản lý những yêu cầu đó, tạo ra những “câu chuyện người dùng” đối với sản phẩm và truyền đạt những thông tin đó đến đội phát triển Cơ bản là nếu nhóm gặp những vấn đề hay thắc mắc gì liên quan đến sản phẩm, hãy tìm gặp Chủ sản phẩm Nhóm phát triển: Là một tập hợp những kỹ sư “liên chức năng”- nghĩa là công việc của họ không cố định ở lập trình, kiểm thử, phân tích hay thiết kế Tùy theo yêu cầu công việc mà họ sẽ đảm nhận những vai trò tương ứng Nhóm phát triển được quyền chủ động tổ chức công việc, ước lượng khối lượng công việc và cam kết hoàn thành công việc đã cam kết Trong Sprint, nhóm phát triển có tiếng nói lớn nhất và những bộ phận khác có nhiệm vụ hỗ trợ những điều kiện tốt nhất để nhóm làm việc hiệu quả

Scrum Master: Nhiệm vụ của Scrum Master là giúp mọi người trong nhóm hiểu được Scrum, làm theo Scrum đồng thời hỗ trợ nhóm phát triển để họ có thể toàn tâm toàn ý làm việc Nếu có ai đó thắc mắc về quy trình trong Scrum, ý nghĩa của Scrum hay những vấn đề liên quan đến Scrum khác, hãy tìm gặp Scrum Master

Các sự kiện trong Scrum:

Sprint: Sprint là những chu kỳ nhỏ để phát triển sản phẩm Trong Sprint, nhóm sẽ tập trung phát triển những chức năng cụ thể nào đó và hoàn hiện nó vào cuối mỗi Sprint Mỗi Sprint sẽ có thời gian cố định được thống nhất, thường là từ 2- 4 tuần Họp kế hoạch Sprint (Sprint Planning Meeting): Diễn ra vào đầu mỗi Sprint bao gồm: Chủ sản phẩm, Scrum Master và Nhóm phát triển Chủ sản phẩm sẽ trình bày mục tiêu của Sprint (Sprint goal) và những đầu mục công việc có độ ưu tiên cao trong danh sách các đầu mục công việc (được gọi là Product Backlog) sau đó đội phát triển sẽ thảo luận (đặt câu hỏi, ước lượng độ lớn, định ra những công việc cần phải làm v.v) Những đầu mục công việc mà nhóm thống nhất sẽ làm trong Sprint

sẽ được chuyển qua một danh sách công việc khác gọi là Sprint Backlog Cơ bản, sau buổi họp kế hoạch Sprint, ta sẽ biết được Mục tiêu của Sprint và những việc đầu mục cần làm trong Sprint

Họp Scrum hằng ngày (Daily Scrum Meeting): Sau họp kế hoạch Sprint, nhóm sẽ bắt tay vào công việc phát triển và nhóm sẽ có cuộc họp ngắn vào mỗi đầu ngày Buổi họp này thường diễn ra ngắn khoảng 15 phút và cố định về thời gian, địa điểm họp Trong cuộc họp này, từng người trong nhóm phát triển lần lượt trình bày để trả lời 3 câu hỏi Hôm qua đã làm gì? Hôm nay sẽ làm gì? Có khó khăn trở ngại gì không?

Scrum Master là người chịu trách nhiệm giải quyết hoặc tìm giải pháp cho những khó khăn, trở ngại mà nhóm gặp phải và đảm bảo là nó được giải quyết sớm nhất có thể để nhóm có thể hoàn thành công việc

Họp sơ kết Sprint (Sprint Review Meeting): Vào cuối mỗi Sprint, nhóm sẽ trình bày những phần mình đã làm được trong Sprint hay còn gọi là demo trên sản phẩm thật Thành phần tham dự là tất cả những ai quan tâm đến sản phẩm Cuộc họp sẽ giúp

đánh giá xem nhóm có đạt được mục tiêu đề ra ở buổi họp kế hoạch Sprint hay không

Họp cải tiến Sprint (Sprint Retrospective Meeting): Buổi họp này thường diễn ra ngay sau buổi họp sơ kết Sprint và mất tầm khoảng 1-2 giờ thảo luận Trong buổi họp nhóm sẽ đánh giá những việc mình đã làm và cách để làm cho nó tốt hơn Sau khi có được danh sách những việc “cần bắt đầu làm”, “không nên làm tiếp”, “nên duy trì làm tiếp”, nhóm sẽ thống nhất chọn ra vài thứ mà nhóm sẽ tập trung để cải tiến trong Sprint kế tiếp Kết quả thực thi những cải tiến này sẽ được thảo luận trong buổi họp cải tiến của Sprint sau

Công cụ trong Scrum:

Product Backlog: Đây là danh sách ưu tiên các tính năng (feature) hoặc đầu ra khác của dự án, có thể hiểu như là danh sách yêu cầu (requirement) của dự án Product Owner chịu trách nhiệm sắp xếp độ ưu tiên cho từng hạng mục (Product Backlog Item) trong Product Backlog dựa trên các giá trị do Product Owner định nghĩa (thường là giá trị thương mại – business value)

User stories

Business Priority

Story Point

Hình 2.7 Sprint Backlog

Nguồn: https://www.mountaingoatsoftware.com/agile/scrum/sprint-backlog Biểu đồ Burndown (Burndown chart): Được dùng để đo tiến độ của Sprint hay của

dự án Không giống như biểu đồ Gantt chart (biểu đồ Gantt cho thấy ai làm việc gì

và mất bao nhiêu thời gian để hoàn thành) thì biểu đồ Burndown sẽ cho thấy nhóm còn bao nhiêu thời gian để hoàn thành công việc đã được định ra lúc đầu Biểu đồ Burndown đi xuống là một dấu hiệu tốt cho tiến độ hoàn thành công việc

Hình 2.8 Burndown Chart

Nguồn: https://www.mountaingoatsoftware.com/agile/scrum/sprint-backlog