Thiết kế, xây dựng hệ thống phần mềm giảng dạy kịch hát dân tộc trường đại học sân khấu điện ảnh

Danh mục các thuật ngữ Thuật ngữ nghiệp vụ truyền thống, được các thế hệ nghệ nhân, nghệ sĩ sáng tạo, thể hiện, đạt đến độ chuẩn mực, được xem là khuôn mẫu nghệ thuật KEEPS Các sơ đồ U

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Trần Hữu Nguyên

Thiết kế, xây dựng hệ thống phần mềm giảng dạy kịch hát dân tộc Trường Đại học Sân khấu điện ảnh

LUẬN VĂN TỐT NGHIỆP THẠC SĨ HỆ CHÍNH QUY

Ngành: Công Nghệ Thông Tin

HÀ NỘI - 2017

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

LUẬN VĂN TỐT NGHIỆP THẠC SĨ CÔNG NGHỆ THÔNG TIN

Cán bộ hướng dẫn: PGS TS Bùi Thế Duy

Cán bộ đồng hướng dẫn: TS Ngô Thị Duyên

HÀ NỘI - 2017

LỜI CAM ĐOAN

Tôi xin cam đoan luận văn này là công trình nghiên cứu của riêng tôi dưới sự hướng dẫn khoa học của PGS TS Bùi Thế Duy, đồng hướng dẫn TS Ngô Thị Duyên Các số liệu, kết quả được trình bày trong luận văn là chính xác và trung thực Tôi đã trích dẫn đầy đủ nguồn gốc các tài liệu tham khảo, công trình nghiên cứu liên quan Ngoại trừ các trích dẫn này, luận văn hoàn toàn là công việc của cá nhân tôi

Luận văn được hoàn thành trong thời gian tôi là học viên Khoa Công Nghệ Thông Tin, Trường Đại Học Công Nghệ, Đại Học Quốc Gia Hà Nội

Hà Nội, ngày tháng 11 năm 2017

HỌC VIÊN

Trần Hữu Nguyên

LỜI CẢM ƠN

Trong quá trình học và xây dựng luận văn này, tôi nhận được sự giúp đỡ, hỗ trợ của các

thầy cô Ban Giám hiệu nhà trường và các đơn vị phòng ban Trường Đại học Công nghệ -

Đại học Quốc gia Hà Nội

Đầu tiên, tôi xin gửi lời cảm ơn chân thành đến PGS TS Bùi Thế Duy, đồng hướng dẫn

TS Ngô Thị Duyên đã trực tiếp hướng dẫn tôi thực hiện luận văn này Thầy, cô đã tận tình

chỉ bảo, cung cấp cho tôi kiến thức, tài liệu cùng các phương pháp nghiên cứu, giải quyết

vấn đề một cách khoa học từ đó giúp tôi sáng tỏ từng bước trong quá trình hoàn thiện luận

văn

Tôi cũng xin bày tỏ lòng biết ơn tới các thầy cô giáo trong Phòng Thí nghiệm Tương tác

Người – Máy, Bộ môn Công Nghệ Phần Mềm, Bộ môn Các Hệ Thống Thông Tin, những

người đã đem trí tuệ, công sức của mình truyền đạt lại cho chúng tôi Những kiến thức này

đã giúp ích rất nhiều cho tôi trong quá trình học tập và công tác

Cuối cùng, tôi xin gửi lời cảm ơn đến gia đình và bạn bè, những người luôn bên tôi, động

viên và khích lệ tôi trong quá trình học và thực hiện đề tài nghiên cứu của mình

HỌC VIÊN

Trần Hữu Nguyên

Mục lục

LỜI CAM ĐOAN 1

LỜI CẢM ƠN 2

DANH MỤC CÁC THUẬT NGỮ 6

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

DANH MỤC BẢNG BIỂU 7

DANH MỤC HÌNH VẼ 7

MỞ ĐẦU 9

CHƯƠNG 1 GIỚI THIỆU 10

1.1 M ỤC ĐÍCH VÀ Ý NGHĨA CỦA ĐỀ TÀI 10

1.2 Đ ỐI TƯỢNG VÀ PHẠM VI NGHIÊN CỨU 11

1.3 P HƯƠNG PHÁP NGHIÊN CỨU 11

1.3.1 Phương pháp nghiên cứu Lý thuyết 11

1.3.2 Phương pháp nghiên cứu Thực nghiệm 12

1.4 C ẤU TRÚC LUẬN VĂN 13

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

2.1 Y ÊU CẦU 15

2.1.1 Yêu cầu trong kỹ nghệ hệ thống và kỹ nghệ phần mềm 15

2.1.2 Một số nhân tố trong phát triển yêu cầu 16

2.1.3 Các yêu cầu tốt 16

2.1.4 Khả năng kiểm thử 17

2.1.5 Các thay đổi đối với các yêu cầu 17

2.1.6 Tính cần thiết của sự chính xác trong các yêu cầu phần mềm 18

2.2 P HÂN TÍCH YÊU CẦU 18

2.2.1 Các kỹ thuật chính 18

2.2.2 Các vấn đề 19

2.2.3 Các giải pháp 20

2.3 K Ỹ NGHỆ YÊU CẦU TRUYỀN THỐNG 21

2.3.1 Bên liên quan 21

2.3.2 Các mô hình Xã hội – Kỹ thuật (Socio-technical models) 22

2.3.3 Phương pháp các hệ thống mềm 27

2.3.4 Phương pháp Thiết kế hợp tác (Participatory Design) 27

2.3.5 Phương pháp nhân chủng học (Ethnographic Methods) 28

2.3.6 Tóm lược 28

2.4 K Ỹ NGHỆ YÊU CẦU TRONG A GILE S CRUM 29

2.4.1 Quá trình hình thành 29

2.4.2 Vai trò của Chủ sản phẩm (Product Owner) trong Scrum 29

2.4.3 Quy trình và các cuộc họp trong Scrum 31

2.4.4 Hướng tiếp cận các Bên liên quan (Stakeholder) 39

2.4.5 Làm mịn Product Backlog (Grooming Product Backlog) 39

2.4.6 User Story và UML Use Case 42

2.4.7 User Story và Acceptance Criteria 43

2.4.8 Tốc độ thay đổi yêu cầu qua Release Burndown Chart 45

2.5 M Ô HÌNH HÓA TRONG DỰ ÁN A GILE 47

2.5.1 Phân loại nhóm mô hình KEEPS và TEMPS 48

2.5.2 Các mô hình trong KEEPS 49

2.5.3 Sử dụng KEEPS trong nhóm Scrum mở rộng 52

2.5.4 Tóm lược 52

CHƯƠNG 3 PHƯƠNG PHÁP THU THẬP YÊU CẦU 53

3.1 T IẾP CẬN CÁC BÊN LIÊN QUAN 53

3.1.1 Xác định các bên liên quan 53

3.1.2 Phân tích các bên liên quan 54

3.1.3 Cộng tác với các Player 55

3.1.4 Thu hút sự quan tâm các Subject 55

3.1.5 Thao khảo ý kiến của các Context Setter hay Referee 55

3.1.6 Thông báo thông tin tới Crowd 56

3.1.7 Lưới Tầm ảnh hưởng-Độ quan tâm (Power-Interest Grid) 56

3.2 B Ộ CÂU HỎI PHỎNG VẤN CÁC BÊN LIÊN QUAN (Q&A) 57

3.3 X ÂY DỰNG U SER S TORY , P RODUCT B ACKLOG 57

3.3.1 Xây dựng các Epic 57

3.3.2 Xây dựng các User Story 58

3.3.3 Scrum Taskboard: SPRINT_2017_03_03 59

3.3.4 Bảng Kanban 60

3.4 T ÓM LƯỢC 60

CHƯƠNG 4 PHÂN TÍCH & THIẾT KẾ HỆ THỐNG 61

4.1 P HÂN TÍCH HỆ THỐNG 61

4.1.1 Mô tả quy trình nghiệp vụ 61

4.1.2 Đề xuất quy trình tin học hóa 61

4.2 C ÁC YÊU CẦU CỦA PHẦN MỀM 63

4.2.1 Định nghĩa các thuật ngữ 63

4.2.2 Tài liệu tham khảo 65

4.2.3 Các yêu cầu ban đầu 65

4.2.4 Mô hình phân rã chức năng của hệ thống 66

4.2.5 Yêu cầu Chức năng 67

4.2.6 Yêu cầu Phi chức năng 70

4.3 T HIẾT KẾ HỆ THỐNG 71

4.3.1 Mô hình tổng thể Hệ thống 71

4.3.2 Thiết kế chi tiết 73

4.3.3 Thiết kế Cơ sở dữ liệu 88

4.3.4 Thiết kế giao diện 90

4.4 T ÓM LƯỢC 90

KẾT LUẬN 91

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

PHỤ LỤC 94

P HỤ LỤC I B Ộ CÂU HỎI PHỎNG VẤN CÁC BÊN LIÊN QUAN (Q&A) 94

Cán bộ quản lý khoa Kịch hát dân tộc 94

Giảng viên Khoa kịch hát dân tộc 96

Sinh viên 97

Ban lãnh đạo nhà trường ĐH Sân khấu Điện ảnh 98

Nhân viên Phòng CNTT 98

P HỤ LỤC II D ANH SÁCH CÁC E PIC 99

P HỤ LỤC III D ANH SÁCH CÁC U SER S TORY 103

P HỤ LỤC IV D ANH SÁCH CÁC P ROTOTYPE 110

Danh mục các thuật ngữ

Thuật ngữ nghiệp vụ

truyền thống, được các thế hệ nghệ nhân, nghệ sĩ sáng tạo, thể hiện, đạt đến độ chuẩn mực, được xem là khuôn mẫu nghệ thuật

KEEPS Các sơ đồ UML được nhóm phát triển giữ lại phục vụ cho các

cuộc họp, hội thảo (workshop)

TEMPS Các sơ đồ UML được nhóm phát triển sử dụng trong các cuộc

họp nội bộ và sẽ loại bỏ khi hoàn thành mã chương trình

Potentially Shippable

Product Increment Phần tăng trường chuyển giao được của sản phẩm

Internal Meeting Daily Meeting (Stand Meeting) – Cuộc họp nhóm hằng ngày

Sprint Meeting – Cuộc họp Sprint

Stakeholder Meeting Các cuộc họp với các bên liên quan như:

Product Strategy – Cuộc họp chiến lược sản phẩm Roadmaping Workshop – Buổi hội thảo lộ trình Sprint Review Meeting – Cuộc họp đánh giá Sprint

Danh mục chữ viết tắt

Chức viết tắt Ý nghĩa

SAD Software Analysis and Design

Danh mục bảng biểu

B ẢNG 1: M Ô TẢ U SER S TORY TRONG U SE C ASE 43

B ẢNG 2: L ƯỚI T ẦM ẢNH HƯỞNG -Đ Ộ QUAN TÂM (P OWER -I NTEREST G RID ) LÝ THUYẾT 54

B ẢNG 3: L ƯỚI T ẦM ẢNH HƯỞNG -Đ Ộ QUAN TÂM (P OWER -I NTEREST G RID ) CỦA DỰ ÁN 56

B ẢNG 4: N GƯỜI SỬ DỤNG HỆ THỐNG 67

B ẢNG 5: D ANH SÁCH U SER S TORY 67

B ẢNG 6: B ẢNG MÔ TẢ CHI TIẾT U SE C ASE 74

Danh mục hình vẽ H ÌNH 1: 7 GIAI ĐOẠN CỦA PHƯƠNG PHÁP TRUYỀN THỐNG CÁC HỆ THỐNG MỀM 27

H ÌNH 2: V AI TRÒ CẦU NỐI CỦA C HỦ SẢN PHẨM (P RODUCT O WNER ) 30

H ÌNH 3: Q UY TRÌNH S CRUM 32

H ÌNH 4: S Ử DỤNG CÁC CUỘC HỌP ĐỂ HOÀN THIỆN , ĐÁNH GIÁ YÊU CẦU 35

H ÌNH 5: S PRINT B URNDOWN C HART 36

H ÌNH 6: V ÒNG ĐỜI CỦA U SER S TORY 39

H ÌNH 7: C ÁC HOẠT ĐỘNG TRONG S PRINT VÀ QUÁ TRÌNH LÀM MỊN P RODUCT B ACKLOG 40

H ÌNH 8: C ÁC HOẠT ĐỘNG LÀM MỊN P RODUCT B ACKLOG 40

H ÌNH 9: L ỢI ÍCH CỦA QUÁ TRÌNH LÀM MỊN P RODUCT B ACKLOG 42

H ÌNH 10: Q UÁ TRÌNH LÀM MỊN U SER S TORY 44

H ÌNH 11: C ẤU TRÚC CỦA U SER S TORY 45

H ÌNH 12: R ELEASE B URNDOWN C HART CƠ BẢN 46

H ÌNH 13: R ELEASE B URNDOWN C HART QUAN TÂM TỚI THAY ĐỔI YÊU CẦU Ở S PRINT HIỆN TẠI 46

H ÌNH 14: R ELEASE B URNDOWN C HART QUAN TÂM TỚI XU HƯỚNG THAY ĐỔI YÊU CẦU Ở CÁC S PRINT 47

H ÌNH 15: M Ô HÌNH HÓA TRONG S CRUM VỚI KEEPS VÀ TEMPS 48

H ÌNH 16: C ÁC KEEPS A RCHITECTURE BAO GỒM CÁC C LASS /P ACKAGE D IAGRAM 49

H ÌNH 17: C ÁC KEEPS D OMAIN M ODEL BAO GỒM CÁC C LASS D IAGRAM 50

H ÌNH 18: C ÁC K EY U SE C ASE BAO GỒM CÁC U SE C ASE D IAGRAM 51

H ÌNH 19: C ÁC K EY U SE C ASE BAO GỒM CÁC C OMMUNICATION D IAGRAM 51

H ÌNH 20: T IGER TEAM VÀ S UB TEAMS 52

H ÌNH 21: V AI TRÒ TRUNG TÂM CỦA CHỦ SẢN PHẨM ĐỐI VỚI CÁC BÊN LIÊN QUAN VÀ NHÓM PHÁT TRIỂN 53

H ÌNH 22: KEEP P ACKAGE D IAGRAM CHO YÊU CẦU CHỨC NĂNG VÀ PHI CHỨC NĂNG 66

H ÌNH 23: KEEP P ACKAGE D IAGRAM CHO YÊU CẦU CHỨC NĂNG QUẢN LÝ NỘI DUNG GIẢNG DẠY , HỌC TẬP 69

H ÌNH 24: KEEP P ACKAGE D IAGRAM CHO YÊU CẦU CHỨC NĂNG CHUNG CỦA HỆ THỐNG 69

H ÌNH 25: KEEP P ACKAGE D IAGRAM CHO YÊU CẦU PHI CHỨC NĂNG 70

H ÌNH 26: KEEP C OMPONENT D IAGRAM N GƯỜI DÙNG TƯƠNG TÁC VỚI HỆ THỐNG THÔNG QUA GIAO DIỆN W EB 71

H ÌNH 27: M Ô HÌNH KIẾN TRÚC LOGIC 72

H ÌNH 28: KEEP N ETWORK D IAGRAM K IẾN TRÚC VẬT LÝ CỦA HỆ THỐNG 73

H ÌNH 29: KEEP P ACKAGE D IAGRAM CHO TÁC NHÂN THAM GIA HỆ THỐNG 73

H ÌNH 30: KEEP P ACKAGE D IAGRAM CHO CÁC U SE C ASE Q UẢN TRỊ H Ệ THỐNG 75

H ÌNH 31: KEEP P ACKAGE D IAGRAM CHO CÁC U SE C ASE Q UẢN LÝ Q UYỀN NGƯỜI DÙNG 76

H ÌNH 32: KEEP P ACKAGE D IAGRAM CHO CÁC U SE C ASE Q UẢN TRỊ N GƯỜI DÙNG 77

H ÌNH 33: TEMP S EQUENCE D IAGRAM CHO U SE C ASE H IỂN THỊ L ỊCH SỬ N GƯỜI DÙNG 78

H ÌNH 34: TEMP S EQUENCE D IAGRAM CHO U SE C ASE H IỂN THỊ T HÔNG TIN CHI TIẾT T ÀI KHOẢN 78

H ÌNH 35: TEMP S EQUENCE D IAGRAM CHO U SE C ASE H IỂN THỊ CÁC T ẠC VỤ TRONG QUÁ KHỨ 79

H ÌNH 36: TEMP S EQUENCE D IAGRAM CHO U SE C ASE X ÓA N GƯỜI DÙNG 79

H ÌNH 37: TEMP S EQUENCE D IAGRAM CHO U SE C ASE Đ ÓNG T ÀI KHOẢN 80

H ÌNH 38: TEMP S EQUENCE D IAGRAM CHO U SE C ASE Đ ĂNG NHẬP 80

H ÌNH 39: KEEP P ACKAGE D IAGRAM CHO CÁC U SE C ASE Q UẢN LÝ T HÔNG TIN CHUNG 81

H ÌNH 40: KEEP P ACKAGE D IAGRAM CHO CÁC U SE C ASE Q UẢN LÝ DỮ LIỆU Đ A PHƯƠNG TIỆN _N GƯỜI QUẢN TRỊ 82

H ÌNH 41: KEEP P ACKAGE D IAGRAM CHO CÁC U SE C ASE Q UẢN LÝ D Ữ LIỆU Đ A PHƯƠNG TIỆN _G IẢNG VIÊN 83

H ÌNH 42: KEEP P ACKAGE D IAGRAM CHO CÁC U SE C ASE Q UẢN LÝ D Ữ LIỆU Đ A PHƯƠNG TIỆN _S INH VIÊN 84

H ÌNH 43: KEEP P ACKAGE D IAGRAM CHO CÁC U SE C ASE Q UẢN LÝ B ÀI GIẢNG _N GƯỜI QUẢN TRỊ 85

H ÌNH 44: KEEP P ACKAGE D IAGRAM CHO CÁC U SE C ASE Q UẢN LÝ B ÀI GIẢNG _G IẢNG VIÊN 86

H ÌNH 45: KEEP P ACKAGE D IAGRAM CHO CÁC U SE C ASE Q UẢN LÝ B ÀI GIẢNG _S INH VIÊN 87

H ÌNH 46: TEMP S EQUENCE D IAGRAM CHO U SE C ASE B IÊN SOẠN N ỘI DUNG BÀI GIẢNG 88

H ÌNH 47: KEEP C LASS D IAGRAM MÔ TẢ MỐI QUAN HỆ GIỮA CÁC BẢNG 89

Cá nhân tôi thời gian đầu của quá trình học và tham gia các dự án, tôi được tiếp cận với quy trình phát triển phần mềm truyền thống Waterfall, các dự án được lập kế hoạch cẩn thận, được tiến hành với rất nhiều khâu trung gian, và thông thường khách hàng sẽ phải chờ đợi cho tới khi hệ thống phần mềm hoàn thiện cơ bản Các bên liên quan hầu như chỉ nhận được tài liệu dự án mà không được dùng thử, trải nghiệm và đưa ra các phản hồi cho các chức năng đã hoàn thành Việc không nắm được tiến độ các chức năng khiến khách hàng và các bên liên quan tỏ ra sốt ruột, lo lắng và qua thời gian họ mất dần sự quan tâm tới dự án, và kết quả tất yếu với hầu hết các dự án mới có nhiều yêu cầu nghiệp vụ đặc thù hoặc phải đấu nối phức tạp thì sản phẩm bàn giao tới người dùng cuối là không đạt yêu cầu hoặc gặp rất nhiều khó khăn trong quá trình tích hợp hoặc vận hành không ổn định

Các dự án của những năm sau đấy, tôi được tiếp cận với phương pháp phát triển phầm mềm Agile, cụ thể là Scrum và Kanban, ở một số dự án gần đây, nhóm phát triển phần mềm chúng tôi sử dụng Scrumban Sự thay đổi có thể dễ dàng nhận thấy giữa một dự án Waterfall

và dự án Agile là với Agile, chúng tôi phải tổ chức rất nhiều các cuộc họp, bao gồm các cuộc họp nội bộ nhóm phát triển và các cuộc họp với các bên liên quan Quá trình này lặp

đi lặp lại qua các Sprint nhằm thúc đẩy sự phát triển mối quan hệ bền vững giữa ban lãnh đạo, các thành viên đội phát triển và người dùng Việc duy trì một nhịp độ liên tục không giới hạn các buổi họp này giúp chúng tôi và các bên liên quan có chung một tầm nhìn về sản phẩm Trong thời gian này tôi vẫn chưa dành nhiều công sức để nghiên cứu kỹ về lý thuyết Agile, tôi chỉ tiếp cận nó theo một quy trình làm việc đã được tổ chức bởi Scrum Mater, nhưng tôi vẫn dễ dàng nhận ra được giá trị từ việc áp dụng Agile thông qua chất lượng sản phẩm và mức độ hài lòng của khách hàng qua từng dự án Vì vậy tôi mong muốn qua luận văn này sẽ nghiên cứu sâu hơn phương pháp luận Agile và các thay đổi có giá trị

mà nó tạo ra tới kỹ nghệ yêu cầu cũng như các thay đổi trong quy trình phát triển phần mềm

Chương 1 Giới thiệu

1.1 Mục đích và ý nghĩa của đề tài

Ứng dụng khoa học, công nghệ vào việc nâng cao chất lượng giảng dạy các loại hình văn hóa nghệ thuật là một trong những mục tiêu góp phần bảo tồn và phát huy các di sản văn hóa phi vật thể trước xu thế toàn cầu hóa và hội nhập như hiện nay Trên thực tế đã có nhiều

hệ thống phần mềm được xây dựng và áp dụng trong các trường Đại học khối Văn hóa Nghệ thuật nhưng vẫn tồn tại những hạn chế như không thỏa mãn đầy đủ các yêu cầu giảng dạy và học tập hoặc vượt quá ngân sách và thời gian Một trong những nguyên nhân chính

là các dự án không đầu tư thời gian và công sức ở khâu phân tích, thiết kế mà bắt tay vào lập trình quá sớm Việc không nắm rõ các yêu cầu của các bên liên quan hoặc thiếu các phương pháp khoa học và yếu kém ở khả năng mô hình hóa các khối chức năng sẽ dẫn đến việc xây dựng một hệ thống không đạt được các mục tiêu của dự án hoặc không như mong đợi của người sử dụng

Tôi đã từng đảm nhiệm các vai trò khác nhau trong nhóm phát triển phần mềm vì vậy tôi muốn xây dựng cho mình các kỹ năng để trở thành một Chủ sản phẩm (Product Owner) bằng việc củng cố phương pháp luận về kỹ nghệ yêu cầu cũng như kỹ năng thiết kế hệ thống và cách thức tổ chức một dự án Agile phù hợp

Trong luận văn này, mục tiêu thứ nhất tôi cần trình bày được các phương pháp quản lý yêu cầu người dùng bao gồm việc thu thập, quản lý các yêu cầu người dùng và áp dụng các kiến thức này trong quá trình quản lý các yêu cầu đầu vào trong dự án Scrum

Song song với kỹ năng quản lý yêu cầu người dùng, mục tiêu thứ hai tôi cần trình bày được phương pháp mô hình hóa trực quan và áp dụng hiểu quả phương pháp này trong dự án Scrum nhằm giúp các thành viên đội dự án hoặc khách hàng hiểu về hệ thống và giao tiếp với nhau một cách logic có khoa học Tôi cũng cần áp dụng kiến thức này vào quá trình xây dựng các biểu đồ kỹ thuật và các tài liệu đặc tả

Sau quá trình phân tích yêu cầu ban đầu tôi xem xét việc sử dụng một Open Source Framework làm nền tảng để xây dựng hệ thống quản trị nội dung nhằm giúp giảm thiểu thời gian và nỗ lực của nhóm nghiên cứu đối với các yêu cầu của một hệ thống E-Learning thông thường, mặt khác phải là một framework đã trưởng thành, hoạt động ổn định và có

kiến trúc tốt nhằm đảm bảo quá trình phát triển tuân thủ các chuẩn và dễ dàng tích hợp, mở rộng trong tương lai

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

Quá trình nghiên cứu và xây dựng luận văn được tiến hành song song cùng quá trình thực hiện dự án Xây dựng Hệ thống phần mềm hỗ trợ giảng dạy theo mô hình “vai mẫu” đối với kịch hát dân tộc

Các khâu trong quá trình phân tích, thiết kế bao gồm: Làm việc với các bên liên quan; Quản

lý yêu cầu; Theo dõi tiến độ thực hiện dự án; Tìm hiểu môi trường triển khai dự án; Tìm hiểu các hoạt động quản lý đào tạo, hoạt động dạy và học tại trường cho tới thời điểm hiệu tại và đề xuất các khâu có thể cải tiến; đều được tôi cùng nhóm nghiên cứu thực hiện đề tài khoa học công nghệ trường Đại học Công nghệ - Đại học Quốc Gia Hà Nội thảo luận cùng với đại diện người dùng tại Trường Đại học Sân khấu Điện ảnh Hà Nội

Các bước đều được thực hiện theo quy trình của các phương pháp và mô hình tôi đang nghiên cứu dựa trên sự phối hợp và thống nhất chặt chẽ cùng đại diện khách hàng cũng như người dùng cuối

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

Trong quá trình xây dựng luận văn tôi sử dụng các phương pháp nghiên cứu sau:

1.3.1 Phương pháp nghiên cứu Lý thuyết

Là các phương pháp thu thập thông tin khoa học trên cơ sở nghiên cứu các văn bản, tài liệu

đã có và bằng các thao tác tư duy logic để rút ra kết luận khoa học cần thiết

Phương pháp phân loại và hệ thống hóa lý thuyết: Phân loại là sắp xếp các tài liệu khoa

học theo từng mặt, từng đơn vị, từng vấn đề có cùng dấu hiệu bản chất, cùng một hướng phát triển Hệ thống hóa là sắp xếp tri thức thành một hệ thống trên cơ sở một mô hình lý

thuyết làm sự hiểu biết về đối tượng đầy đủ hơn

Phương pháp Mô hình hóa: Là phương pháp nghiên cứu các đối tượng bằng cách xây

dựng mô hình gần giống với đối tượng, tái hiện lại đối tượng theo các cơ cấu, chức năng

của đối tượng

1.3.2 Phương pháp nghiên cứu Thực nghiệm

Là các phương pháp tác động trực tiếp vào đối tượng có trong thực tiễn để làm rõ bản chất

và các quy luật của đối tượng

Phương pháp phân tích tổng kết kinh nghiệm: Là phương pháp nghiên cứu và xem xét

lại những thành quả thực tiễn trong quá khứ để rút ra kết luận bổ ích cho thực tiễn và khoa

học

Phương pháp thực nghiệm khoa học: Là phương pháp mà các nhà nghiên cứu chủ động

tác động vào đối tượng và theo dõi quá trình diễn biến sự kiện mà đối tượng tham gia để hướng sự phát triển của chúng theo mục tiêu dự kiến của mình

1.4 Cấu trúc luận văn

“Chương 1: Giới thiệu”, trình bày nội dung dự án “Xây dựng Hệ thống phần mềm hỗ trợ

giảng dạy theo mô hình “Vai mẫu” đối với kịch hát dân tộc”, trong dự án này tôi đã áp dụng các kiến thức về Kỹ nghệ yêu cầu, và phương pháp Agile là hướng tôi lựa chọn để xây dựng luận văn này

“Chương 2: Cơ Sở Lý Thuyết”, trình bày lý thuyết Yêu cầu người dùng và các vấn đề

ảnh hưởng tới quá trình thu thập yêu cầu Tiếp theo là lý thuyết Kỹ nghệ yêu cầu truyền thống trong các mô hình Xã hội – Kỹ thuật Sau đó tôi tập trung nói về Kỹ nghệ yêu cầu được hệ thống và sử dụng trong phương pháp Agile Scrum Cuối cùng tôi trình bày cách thức áp dụng các kỹ thuật mô hình hóa UML trong các dự án Agile

“Chương 3: Phương pháp thu thập yêu cầu”, trình bày kỹ thuật tiếp cận các Bên liên

quan nhằm thu thập yêu cầu Sau đó tôi liệt kê các Epic, Product Backlog và các User Story thu được sau các buổi trò chuyện, các cuộc họp với các Bên liên quan hoặc với nhóm phát triển Tôi cũng đưa ra ví dụ về Scrum Taskboard và bảng Kanban thu được ở một thời điểm

cụ thể trong quá trình thực hiện Sprint

“Chương 4: Phân tích & Thiết kế Hệ thống” là kết quả của quá trình xây dựng tài liệu

dự án bao gồm: Tài liệu đặc tả yêu cầu người dùng và tài liệu đặc tả yêu cầu hệ thống Phần mềm hỗ trợ giảng dạy theo mô hình “Vai mẫu” đối với Kịch hát dân tộc Sau đấy tôi triển khai nhanh các thiết kế thông qua việc xây dựng các prototype nhằm thu thập phản hồi từ người dùng

Cuối cùng là kết luận sau quá trình nghiên cứu, xây dựng luận văn và áp dụng các kiến thức này vào dự án

Chương 2 Cơ Sở Lý Thuyết

Công nghệ đóng vai trò cầu nối trong mối quan hệ giữa người sử dụng và máy tính, nó được

sử dụng trong một ngữ cảnh cụ thể và bị ảnh hưởng bởi nhiều yếu tố trong ngữ cảnh đó Việc xác định các yếu tố này giúp người thiết kế cũng như nhóm phát triển xây dựng các

hệ thống công nghệ phần mềm phù hợp với tổ chức, đáp ứng được các yêu cầu của tổ chức

đó

Dựa trên các phương pháp phân tích, người thiết kế hệ thống cần xác định những người khác nhau bị ảnh hưởng bởi việc triển khai một hệ thống hay được gọi là các bên liên quan Nhu cầu của các bên liên quan là khác nhau và có thể phức tạp và mâu thuẫn vì vậy cần hệ thống hoá chức năng thông qua việc sử dụng quy trình và phương pháp khoa học để đảm bảo tính hiệu quả, tính thực tiễn của hệ thống

Chúng ta sẽ nghiên cứu kỹ hơn về bối cảnh sử dụng của tổ chức và thảo luận một số vấn đề chung có thể ảnh hưởng đến việc chấp nhận công nghệ trong các tổ chức Sau đó chúng ta xem xét một số cách tiếp cận để mô hình hóa bối cảnh xã hội - tổ chức và yêu cầu của các bên liên quan trong đó

Thu thập yêu cầu là một phần quan trọng của tất cả các phương pháp kỹ thuật phần mềm nhưng thường hoạt động này tập trung chủ yếu vào các yêu cầu chức năng của hệ thống - những gì hệ thống phải có khả năng làm được - ít nhấn mạnh vào các vấn đề về con người, các vấn đề phi chức năng như tính khả dụng và mức độ chấp nhận được, … Ngay cả khi những vấn đề này được xem xét, chúng chỉ có thể phản ánh quan điểm của người quản lý

về nhu cầu của người dùng hơn là thu thập thông tin từ người dùng Các mô hình yêu cầu của các bên liên quan được xây dựng để đảm bảo sự cân bằng trong quá trình xây dựng yêu cầu chức năng và yêu cầu phi chức năng bằng cách xác định nhu cầu của tất cả các bên liên quan, bao gồm cả người sử dụng và bất cứ ai khác bị ảnh hưởng bởi hệ thống, đặt trong bối cảnh mà hệ thống sẽ được sử dụng

Tôi bắt đầu chương này bằng việc trình bày các khái niệm cơ bản về yêu cầu người dùng sau đó thảo luận về một số vấn đề phát sinh trong tổ chức khi áp dụng các giải pháp công nghệ mới Tiếp đến tôi phác thảo một số mô hình và phương pháp có thể được sử dụng để nắm bắt quan điểm rộng hơn về yêu cầu của các bên liên quan, bao gồm các mô hình xã hội – kỹ thuật (Socio-Technical models), phương pháp các hệ thống mềm (Soft Systems

Methodology), thiết kế hợp tác (Participatory Design) và phương pháp nhân chủng học (Ethonographic Approach)

Trọng tâm của luận văn này tôi tập trung tìm hiểu về quy trình xử lý yêu cầu người dùng bằng phương pháp Agile Scrum kết hợp hiệu quả các công cụ mô hình hoá trong UML

2.1 Yêu cầu

Trong các ngành kỹ thuật, một yêu cầu (Requirement) là một đòi hỏi được tài liệu hóa về

các chức năng và đặc điểm của một sản phẩm hoặc dịch vụ Thuật ngữ này thường được dùng trong các ngành kỹ nghệ hệ thống và kỹ nghệ phần mềm

Trong cách tiếp cận truyền thống của ngành kỹ nghệ, các tập yêu cầu được dùng làm đầu vào cho các giai đoạn thiết kết trong quá trình phát triển sản phẩm

Pha phát triển các yêu cầu có thể được thực hiện sau một nghiên cứu tiền khả thi(Feasibility

Study), hoặc một pha phân tích khái niệm của dự án Pha yêu cầu có thể được chia thành

các phần: thu thập yêu cầu (từ những người có vai trò quan trọng đối với sản phẩm/dịch vụ), phân tích yêu cầu (kiểm tra tính nhất quán và hoàn chỉnh), định nghĩa yêu cầu (viết các yêu cầu mang tính mô tả dành cho các nhà phát triển), và đặc tả (tạo cầu nối đầu tiên giữa các yêu cầu và thiết kế)

2.1.1 Yêu cầu trong kỹ nghệ hệ thống và kỹ nghệ phần mềm

Có ba loại yêu cầu: yêu cầu chức năng, yêu cầu phi chức năng (hay yêu cầu hiệu năng hoặc yêu cầu chất lượng dịch vụ), và mục tiêu thiết kế

Yêu cầu chức năng mô tả xem hệ thống phải làm gì, nghĩa là hệ thống phải có khả năng

thực hiện những công việc gì Ví dụ: "Hệ thống cần lưu trữ tất cả chi tiết về đơn đặt hàng của khách hàng"

Yêu cầu phi chức năng là các ràng buộc về các loại giải pháp thỏa mãn các yêu cầu chức

năng Các yêu cầu này mô tả về chính hệ thống, và về việc nó cần thực hiện các chức năng của mình tốt đến mức độ nào, chẳng hạn yêu cầu loại này là yêu cầu về tính sẵn có, khả năng kiểm thử, khả năng bảo trì, và tính dễ sử dụng Có thể chia các yêu cầu phi chức năng thành hai loại:

1 Ràng buộc về hiệu năng: chẳng hạn "hệ thống cần phục vụ liên tục từ 5 giờ sáng đến

9 giờ tối.", "mỗi đơn đặt hàng cần được lưu trữ trong tối thiểu 7 năm"

2 Ràng buộc về quá trình phát triển hệ thống: Thời gian, tài nguyên, chất lượng Ví dụ: khi nào hệ thống cần hoàn thành (thời gian); tổng chi phí cho phát triển hệ thống (tài nguyên); cần áp dụng các tiêu chuẩn nào cho quá trình phát triển hệ thống, trong

đó có các phương pháp quản lý dự án và phát triển hệ thống (chất lượng)

Mục tiêu thiết kế là các hướng dẫn cho việc lựa chọn giải pháp Có nhiều tính năng quan

trọng đối với một hệ thống, nhưng nhiều trường hợp không thể có giải pháp đạt được mọi tính năng ở mức tối ưu Do đó cần có một thứ tự ưu tiên, tính năng nào cần được ưu tiên hơn tính năng nào Nếu khách hàng không mô tả thứ tự ưu tiên, nhà phát triển phần mềm

sẽ tự chọn thứ tự và thứ tự này có thể không phải cái mà khách hàng mong muốn

Một tập hợp các yêu cầu định nghĩa các tính chất hay tính năng của hệ thống cần xây dựng Một danh sách yêu cầu 'tốt' thường tránh nói đến chuyện hệ thống cần thi hành các yêu

cầu bằng cách nào, mà để các quyết định dạng này cho người thiết kế hệ thống Việc mô

tả cách cài đặt hệ thống được gọi là thiên kiến cài đặt (Implementation Bias)

2.1.2 Một số nhân tố trong phát triển yêu cầu

Việc trình bày các yêu cầu ở một cách lý tưởng là rất khó Người dùng khó hình dung được hết những thông tin nào là cần thiết cho các nhà phát triển, và hai bên có thể không thực sự hiểu các cách diễn đạt của nhau Thông thường, người ta thuê Người dùng chuyên

gia (Expert User) làm cầu nối giữa người dùng và các nhà phát triển Những người dùng

chuyên gia này có thể biểu đạt các yêu cầu chức năng sao cho chúng có thể dễ chuyển thành

một tính năng thiết kế của hệ thống, trong khi người dùng cuối (End User) vẫn hiểu được

2.1.3 Các yêu cầu tốt

Theo lý thuyết, các yêu cầu tốt nên có các tính chất sau:

• Cần thiết – Cái cần phải nhắc đến nếu không hệ thống sẽ thiếu một phần tử quan

trọng mà không một thành phần nào khác của hệ thống có thể bù lại được

• Không mù mờ đa nghĩa – Chỉ có một cách hiểu

• Ngắn gọn súc tích – Được diễn đạt bằng ngôn ngữ mô tả ngắn gọn và dễ hiểu, trong

• Nhất quán – Không mâu thuẫn với một yêu cầu khác; các yêu cầu sử dụng cùng hệ

thống ngôn ngữ và thuật ngữ cho các khái niệm

• Hoàn chỉnh – Các nội dung được trình bày đầy đủ tại chỗ để người đọc không phải

xem thêm tài liệu khác để có thể hiểu được nội dung của yêu cầu

• Đạt được – Một khối lượng thực tiễn có thể được thực hiện trong lượng tiền/tài

nguyên/thời gian có được

• Kiểm thử được – Phải có khả năng xác định xem yêu cầu đã được thỏa mãn hay

chưa bằng một trong 4 phương pháp duyệt (inspection), phân tích, trình diễn, hoặc kiểm thử (test)

2.1.4 Khả năng kiểm thử

Hầu hết các yêu cầu cần có khả năng kiểm thử được Nếu không, phải sử dụng một phương

pháp kiểm định khác (ví dụ phân tích, duyệt lại thiết kế) Các yêu cầu kiểm thử được là một

thành phần quan trọng của việc kiểm định (Validation)

Một số yêu cầu không thể kiểm thử được do chính cấu trúc của nó Trong đó có các yêu

cầu nói rằng hệ thống cần luôn luôn hay không bao giờ thể hiện một tính chất nào đó Việc

kiểm thử thích đáng cho các yêu cầu này sẽ cần đến một chu trình kiểm thử vô hạn Những yêu cầu như vậy cần được viết lại để nói về một khoảng thời gian có tính thực tế hơn Các yêu cầu phi chức năng không kiểm thử được có thể vẫn được giữ để làm tài liệu về chủ

ý của khách hàng; tuy nhiên, chúng thường dẫn đến các yêu cầu quy trình mà chúng được xác định là một phương pháp thực tiễn cho việc thỏa mãn yêu cầu ban đầu Ví dụ, một yêu cầu phi chức năng rằng không được có các Backdoor có thể được thỏa mãn bằng cách thay

nó bằng một yêu cầu quy trình rằng cần sử dụng phương pháp lập trình cặp (Pair

Programming)

2.1.5 Các thay đổi đối với các yêu cầu

Theo thời gian, các yêu cầu có thể thay đổi Trong trường hợp này, một khi đã được xác

định và thông qua, các yêu cầu cần được đưa vào quy trình Kiểm soát thay đổi (Change

Control) Với nhiều dự án, một số yêu cầu được thay đổi trước khi hệ thống được hoàn

thiện Đặc tính này của các yêu cầu đã dẫn đến các nghiên cứu và thực hành về quản lý yêu

cầu (Requirements Management)

2.1.6 Tính cần thiết của sự chính xác trong các yêu cầu phần mềm

Một số phương pháp luận Kỹ nghệ phần mềm hiện đại, chẳng hạn như Lập trình cực đoan

(Extreme Programming), đã nghi ngờ sự cần thiết của các yêu cầu phần mềm được mô tả

chính xác - cái mà các phương pháp luận này coi là một cái đích di động Thay vào đó, họ

mô tả các yêu cầu một cách phi hình thức bằng các "Câu chuyện người dùng" hay User Story (Yêu cầu được viết ngắn gọn trong một cái thẻ nhỏ với nội dung giải thích một khía cạnh của những gì mà hệ thống cần làm), và tạo một chuỗi các trường hợp kiểm thử chấp

nhận (Acceptance Test Case) cho User Story này

2.2 Phân tích yêu cầu

Phân tích yêu cầu là việc xác định các yêu cầu cho một hệ thống mới hoặc hệ thống đã triển khai dựa trên các để xuất, mong muốn của những người có vai trò quan trọng đối với hệ thống, chẳng hạn người sử dụng đưa ra Việc phân tích yêu cầu có ý nghĩa quan trọng đối với thành công của một dự án

Quá trình phân tích yêu cầu một cách có hệ thống còn được gọi là kỹ nghệ yêu cầu (Requirements Engineering) Đôi khi nó còn được gọi một cách không thật chính xác

bằng những cái tên như thu thập yêu cầu (Requirements Gathering, Requirements Capture), hoặc đặc tả yêu cầu (Requirements Specification) Thuật ngữ "phân tích yêu cầu" còn được

áp dụng cụ thể cho công việc thuần túy phân tích (thay vì các việc khác chẳng hạn như làm

rõ yêu cầu hay viết tài liệu yêu cầu)

2.2.1 Các kỹ thuật chính

Về khái niệm, việc phân tích yêu cầu bao gồm ba loại hoạt động sau:

Làm rõ yêu cầu (Eliciting Requirements): Giao tiếp với khách hàng và người sử dụng để

xác định các yêu cầu của họ

Xem xét yêu cầu (Analyzing Requirements): Xác định xem các yêu cầu được đặt ra có ở

tình trạng không rõ ràng, không hoàn chỉnh, đa nghĩa, hoặc mâu thuẫn hay không, và giải quyết các vấn đề đó

Làm tài liệu yêu cầu (Recording Requirements): Các yêu cầu có thể được ghi lại theo

nhiều hình thức, chẳng hạn các tài liệu ngôn ngữ tự nhiên, các Tình huống sử dụng (Use

Case), Câu chuyện người dùng (User Story), hoặc các đặc tả tiến trình

Pha phân tích yêu cầu có thể là một quá trình dài và khó khăn, cần đến nhiều kĩ năng tâm

lý khéo léo Các hệ thống mới làm thay đổi môi trường và các mối quan hệ giữa con người,

do đó điều quan trọng là phải xác định được tất cả những người có vai trò quan trọng, xem xét tất cả các nhu cầu của họ và đảm bảo rằng họ hiểu được các hàm ý của hệ thống mới Các nhà phân tích có thể sử dụng một số kĩ thuật để làm rõ các yêu cầu của khách hàng Trong lịch sử, các kỹ thuật này bao gồm các cuộc phỏng vấn, thành lập các Nhóm trọng

tâm (Focus Group) với các cuộc họp bàn về yêu cầu (Requirements Workshops), và tạo ra các danh sách yêu cầu Các kỹ thuật hiện đại hơn gồm có Tạo nguyên mẫu (Prototyping),

và Tình huống sử dụng (Use Case) Khi cần thiết, nhà phân tích sẽ kết hợp các phương

pháp này để thiết lập các yêu cầu chính xác của những người có vai trò quan trọng, nhằm mục đích xây dựng một hệ thống thỏa mãn các yêu cầu doanh nghiệp

2.2.2 Các vấn đề

2.2.2.1 Vấn đề về người dùng và khách hàng

Trong cuốn Rapid Development, Steve McConnell đã liệt kê một loạt các khả năng người

dùng có thể cản trở quá trình thu thập yêu cầu:

1 Người dùng không hiểu họ muốn gì

2 Người dùng không tuân theo một bộ yêu cầu đã được tài liệu hóa

3 Người dùng nhất định đòi hỏi các yêu cầu mới sau khi chi phí và kế hoạch phát triển

đã được hoạch định xong

4 Mức độ giao tiếp với người dùng là thấp

5 Người dùng thường không tham gia các đợt thẩm định hoặc không thể tham gia

6 Người dùng không hiểu kỹ thuật

7 Người dùng không hiểu quy trình phát triển

Những điều này có thể dẫn tới tình huống khi yêu cầu người dùng liên tục thay đổi ngay cả khi việc phát triển hệ thống hay sản phẩm đã được bắt đầu

Việc phân tích có thể do các kỹ sư hoặc lập trình viên thực hiện, thay vì các nhân viên có

kỹ năng và kiến thức miền ứng dụng để có thể hiểu các nhu cầu của khách hàng một cách đúng đắn

3 Phần mềm xử lý cứng nhắc các quy trình nghiệp vụ mà tổ chức đang vận hành

4 Chi phí phải trả và lợi ích đạt được khi sử dụng phần mềm là không tương xứng

2.3 Kỹ nghệ yêu cầu truyền thống

Như chúng ta đã thấy, những vấn đề có thể xuất hiện khi một hệ thống được xây dựng mà không có sự hiểu biết đầy đủ về tất cả những người sẽ bị ảnh hưởng bởi nó Nhưng làm thế nào chúng ta có thể hiểu rõ hơn và hỗ trợ các tổ chức có cấu trúc phức tạp, khi các nhóm làm việc và các nhu cầu của bên liên quan có khả năng mâu thuẫn lẫn nhau? Chúng ta bắt đầu bằng cách thu thập và phân tích các yêu cầu, nhưng chúng ta cần phải làm việc này trong hoàn cảnh mà các công việc của tổ chức vẫn đang diễn ra, có tính đến sự phức tạp của các mối quan tâm của các bên liên quan khác nhau và các cấu trúc và quy trình hoạt động trong các nhóm làm việc

Phần tiếp theo trình bày một số phương pháp tiếp cận: Mô hình kỹ thuật-xã hội Technical Modeling), phương pháp các hệ thống mềm (Soft Systems Methodology), thiết

(Socio-kế hợp tác (Participatory Design), phương pháp nhân chủng học (Ethnographic Methods)

và điều tra theo ngữ cảnh (Contextual Inquiry) Các phương pháp này có hướng tiếp cận hơi khác nhau cho cùng một vấn đề nhưng đều nhằm mục đích để hiểu được thực tế của bối cảnh công việc và quan điểm khác nhau của các bên liên quan Các phương pháp này cũng cho thấy công nghệ có thể được triển khai thành công chỉ khi nó được thực hiện với một sự hiểu biết về bối cảnh sử dụng Trước khi chúng ta xem xét chi tiết hơn những phương pháp tiếp cận này, chúng ta cần làm rõ ý nghĩa của thuật ngữ "Các bên liên quan"

2.3.1 Bên liên quan

Hiểu được các bên liên quan là yếu tố then chốt để tiếp cận tối đa các yêu cầu, vì trong một môi trường tổ chức, nó không chỉ đơn giản là người dùng cuối bị ảnh hưởng bởi việc giới thiệu công nghệ mới Bên liên quan có thể được định nghĩa là bất cứ ai bị ảnh hưởng bởi

sự thành công hay thất bại của hệ thống Các nhóm bên liên quan theo cách tiếp cận CUSTOM là:

• Các bên liên quan chính là những người thực sự sử dụng hệ thống - những người

dùng cuối

• Các bên liên quan thứ cấp là những người không trực tiếp sử dụng hệ thống, nhưng

nhận được kết quả từ nó hoặc cung cấp đầu vào cho nó (ví dụ như ai đó nhận được báo cáo do hệ thống sản xuất)

• Các bên liên quan cấp cao là những người không thuộc hai nhóm đầu tiên nhưng

những người trực tiếp bị ảnh hưởng bởi sự thành công hay thất bại của hệ thống (ví

dụ giám đốc có lợi nhuận tăng hoặc giảm tùy thuộc vào sự thành công của hệ thống) Tạo điều kiện thuận lợi cho các bên liên quan là những người có liên quan đến việc thiết

kế, phát triển và bảo trì hệ thống Mục tiêu của nhóm thiết kế là đáp ứng nhu cầu của càng nhiều bên liên quan càng tốt Tuy nhiên, thực tế là nhu cầu của các bên liên quan thường là mâu thuẫn với nhau

2.3.2 Các mô hình Xã hội – Kỹ thuật (Socio-technical models)

Các mô hình Xã hội – Kỹ thuật sử dụng các phương pháp khác nhau nhằm nắm bắt yếu tố như:

• Vấn đề được giải quyết: Cần phải hiểu tại sao công nghệ này lại được đề xuất và các vấn đề nó có thể giải quyết

• Các bên liên quan bị ảnh hưởng, bao gồm Chủ yếu (Primary), Thứ yếu (Secondary), Hạng thứ ba (Tertiary) và Thực hiện (Facilitating), cùng với mục đích và nhiệm vụ của những bên liên quan này

• Các nhóm làm việc trong tổ chức, cả chính thức và không chính thức

• Các thay đổi hoặc chuyển đổi sẽ được hỗ trợ

• Công nghệ được đề xuất và cách thức hoạt động trong tổ chức Những khó khăn bên ngoài, các ảnh hưởng và các biện pháp thực hiện

Thông tin được thu thập bằng các phương pháp như phỏng vấn, quan sát và tổ chức các cuộc họp giữa các bên và phân tích tài liệu Các phương pháp hướng dẫn quá trình thu thập thông tin này và giúp nhà phân tích hiểu được những yêu cầu cần thiết cho quá trình phát triển dự án Bằng cách cố gắng hiểu những vấn đề này, phương pháp tiếp cận Xã hội – Kỹ thuật nhằm cung cấp một cái nhìn chi tiết về vai trò của công nghệ và các yêu cầu của việc triển khai thành công

Sau đây tôi trình bày hai phương pháp Xã hội – Kỹ thuật USTM và OSTA để minh họa cách thức nó hoạt động trong thực tế

2.3.2.1 User skills and Task Match - USTM/CUSTOM methodology

1 USTM

Phương pháp USTM được chia thành 7 giai đoạn (Stage):

1 Business Case: Một thành viên của nhóm có trách nhiệm đối với Business Case và đưa ra sự luận giải ban đầu cho hệ thống được đề xuất

2 Nhóm làm việc: Mục tiêu của giai đoạn này là xác định các nhóm làm việc có liên quan đến hệ thống đề xuất Sản phẩm của nhóm làm việc phụ thuộc vào mối quan

hệ của họ với hệ thống, và lựa chọn một nhóm công việc chính và mô tả của nó một cách chi tiết

3 Người dùng: Một danh sách người dùng chung được tạo ra, người dùng được phân loại theo mối quan hệ của họ đối với hệ thống đề xuất Ba bộ vấn đề được xác định: quan điểm tổ chức của người dùng, các thuộc tính cá nhân của người dùng chung,

và ‘typical day in life’ của người dùng chung thời điểm hiện tại và khi triển khai hệ thống đề xuất

4 Đối tượng: Nhóm được yêu cầu xác định các đối tượng liên quan đến hệ thống đề xuất, phân loại họ theo mối quan hệ của họ với hệ thống và tạo ra các cấu trúc đối tượng ban đầu Thủ tục xác định danh sách các đối tượng bao gồm hai bước: cùng nhau tạo ra một danh sách các đối tượng bằng cách động não và cùng đánh giá và đồng thuật về danh sách các đối tượng được chọn

5 Nhiệm vụ: Một nhiệm vụ được định nghĩa là một hành động được thực hiện bởi một người dùng chung trên một đối tượng Một danh sách các nhiệm vụ được tạo ra, các nhiệm vụ này được tích hợp vào một sơ đồ phân cấp và các mối quan hệ giữa nhiệm

vụ và hệ thống được xác định

6 Tương tác: Mục đích của giai đoạn này là hiểu mối quan hệ giữa người dùng chung, đối tượng và nhiệm vụ và để xác định sự khác biệt giữa người dùng, đối tượng và nhiệm vụ khác nhau Các thuộc tính được liệt kê để ràng buộc hệ thống cần phải hỗ trợ chúng nhưng không nêu rõ công nghệ nào cần sử dụng vào thời điểm này

7 Hợp nhất: Mục đích của giai đoạn này là đánh giá lại Business Case và đưa ra quyết định cho các hành động tiếp theo Ngoài ra, chất lượng của thông tin thu thập cũng được xác định ở giai đoạn này

2 CUSTOM

CUSTOM là một phương pháp luận Xã hội – Kỹ thuật được thiết kế để sử dụng trong các

tổ chức nhỏ Nó dựa trên phương pháp User skills and Task Match (USTM), nó được phát triển để cho phép các đội thiết kế hiểu và ghi chép đầy đủ các yêu cầu của người sử dụng CUSTOM tập trung vào việc thiết lập các yêu cầu của các bên liên quan: Tất cả các bên liên quan được xem xét, không chỉ những người dùng cuối

Nó được áp dụng ở giai đoạn thiết kế ban đầu khi sản phẩm chưa hình thành và có thể đang chỉ là một cơ hội, do đó, sự nó tập trung vào kỹ thuật nắm bắt yêu cầu Nó là một phương pháp dựa trên biểu mẫu, cung cấp một bộ câu hỏi để áp dụng ở từng giai đoạn của nó

Có sáu giai đoạn chính của việc thực hiện trong một phân tích CUSTOM:

1 Mô tả bối cảnh tổ chức, bao gồm các mục tiêu chính, đặc tính vật lý, bối cảnh chính trị và kinh tế

2 Xác định và mô tả các bên liên quan Tất cả các bên liên quan cần được đặt tên, phân loại (Chủ yếu (Primary), Thứ yếu (Secondary), Hạng thứ ba (Tertiary) hoặc Thực hiện (Facilitating)) và được mô tả trong các vấn đề cá nhân, vai trò của họ trong tổ chức và công việc của họ Ví dụ, CUSTOM giải quyết các vấn đề như động lực của các bên liên quan, giảm thiểu, kiến thức, kỹ năng, quyền hạn và ảnh hưởng trong tổ chức, công việc hàng ngày và vân vân

3 Xác định và mô tả các nhóm làm việc Một nhóm làm việc là bất kỳ nhóm người nào làm việc cùng nhau trên cùng một nhiệm vụ dù chính thức hay không chính thức Một lần nữa, nhóm làm việc được mô tả về vai trò của họ trong tổ chức và đặc điểm của họ

4 Xác định và mô tả các cặp đối tượng-tác vụ (Task-Object Pairs) Đây là những tạc

vụ (Task) cần phải được thực hiện, cùng với các đối tượng (Object) được sử dụng

để thực hiện chúng hoặc chúng được áp dụng

5 Xác định nhu cầu của các bên liên quan Các giai đoạn 2-4 được mô tả dưới dạng hệ thống hiện tại và hệ thống được đề xuất Nhu cầu của các bên liên quan được xác định bằng cách xem xét sự khác nhau giữa hai hệ thống này Ví dụ, nếu một bên liên quan được xác định là hiện đang thiếu một kỹ năng cụ thể được yêu cầu trong hệ thống đề xuất hơn là một nhu cầu để đào tạo được xác định

6 Hợp nhất và kiểm tra các yêu cầu của các bên liên quan Ở đây danh sách các bên liên quan cần được kiểm tra dựa trên các tiêu chí được xác định ở giai đoạn đầu Các giai đoạn từ 2 đến 4 được mô tả dưới dạng tình hình hiện tại (trước khi áp dụng kỹ thuật mới) và tình hình đề xuất (sau khi triển khai) Các bên liên quan được yêu cầu bày tỏ quan điểm của họ không chỉ về vai trò và vị trí hiện tại của họ mà còn về những mong đợi của họ trong bối cảnh những thay đổi sẽ được thực hiện Bằng cách này, các mối quan tâm

và mục tiêu của các bên liên quan được xây dựng Ngoài ra, xem xét tác động của công nghệ đối với thông lệ làm việc (Giai đoạn 3) và các chuyển đổi sẽ được hỗ trợ bởi hệ thống

đã được xác định (Giai đoạn 4)

Những thay đổi từ vị trí hiện tại đến vị trí đề xuất đại diện cho các vấn đề cần được giải quyết để đảm bảo triển khai thành công, và những điều này được trình bày rõ ràng trong các giai đoạn 5 và 6

CUSTOM cung cấp cách thức hữu ích để xem xét các yêu cầu của các bên liên quan bằng việc sử dụng các form và câu hỏi làm cho công việc này trở nên dễ dàng hơn, nhưng có thể mất thời gian ban đầu để áp dụng Đối với các tình huống ít phức tạp hơn, có sẵn một phiên bản rút gọn của quá trình phân tích các bên liên quan CUSTOM Phiên bản này cũng cung cấp checklist cho các cuộc điều tra cho giai đoạn 2-4

Phiên bản rút gọn của CUSTOM phân tích các bên liên quan

Câu hỏi CUSTOM điều tra một loạt các đặc điểm của các bên liên quan, như sau:

• Các bên liên quan phải đạt được những gì và làm thế nào để đo lường thành công?

• Các nguồn thu hút sự quan tâm của các bên liên quan là gì? Những nguồn gốc của

sự không hài lòng và căng thẳng?

• Người có liên quan có kiến thức và kỹ năng gì?

• Thái độ của các bên liên quan đối với công việc là như thế nào và công nghệ máy tính là gì?

• Có bất kỳ thuộc tính làm việc nhóm (workgroup) nào của các bên liên quan ảnh hưởng đến khả năng chấp nhận của sản phẩm không?

• Các đặc điểm về nhiệm vụ của các bên liên quan như tần suất làm việc, phân chia công việc, và các lựa chọn thực hiện công việc?

• Người có liên quan phải xem xét các vấn đề cụ thể liên quan đến tính trách nhiệm, tính bảo mật hay tính riêng tư?

• Các điều kiện vật lý mà bên liên quan đang làm việc là gì?

2.3.2.2 Open System Task Analysis (OSTA)

OSTA là một phương pháp tiếp cận Xã hội – Kỹ thuật khác nhằm mô tả những gì xảy ra khi một hệ thống kỹ thuật được đưa vào môi trường làm việc có tổ chức Giống như CUSTOM, OSTA chỉ rõ khía cạnh xã hội và kỹ thuật của hệ thống Tuy nhiên, trong khi CUSTOM các khía cạnh này được các nhà phân tích giới hạn trong quan điểm của các bên liên quan thì trong OSTA họ lại nắm bắt thông qua việc tập trung vào các nhiệm vụ OSTA có tám giai đoạn chính:

• Nhiệm vụ chính mà công nghệ phải hỗ trợ được xác định theo mục tiêu của người

• Hệ thống kỹ thuật được mô tả dưới dạng cấu hình và tích hợp với các hệ thống khác

• Các tiêu chí về sự hài lòng về hiệu quả hoạt động được xác lập, cho thấy các yêu cầu

xã hội và kỹ thuật của hệ thống

• Hệ thống kỹ thuật mới được xác định

OSTA sử dụng các ký hiệu quen thuộc với các nhà thiết kế, chẳng hạn như sơ đồ luồng dữ liệu và mô tả văn bản

2.3.3 Phương pháp các hệ thống mềm

Phương pháp các hệ thống mềm (Soft Systems Methodology - SSM) cũng phát sinh trong cùng bối cảnh của phương pháp Mô hình Xã hội – Kỹ thuật nhưng nhìn nhận tổ chức như

là một hệ thống trong đó công nghệ và con người là thành phần SSM có bảy giai đoạn và

có một sự phân biệt giữa các giai đoạn “Thế giới thực” (1-2, 5-7) và các giai đoạn của hệ thống (3-4)

Hình 1: 7 giai đoạn của phương pháp truyền thống các hệ thống mềm

2.3.4 Phương pháp Thiết kế hợp tác (Participatory Design)

Thiết kế hợp tác là một triết lý bao gồm toàn bộ chu trình thiết kế Đó là thiết kế tại nơi làm việc, nơi mà người sử dụng tham gia không chỉ là một người cung cấp các thông tin khi cần thiết mà còn là một thành viên của đội thiết kế Người dùng vì vậy là những người cộng tác tích cực trong quá trình thiết kế chứ không phải là những người tham gia thụ động mà sự tham gia của họ hoàn toàn do nhà thiết kế chi phối Lập luận rằng người sử dụng là chuyên gia trong bối cảnh công việc và một thiết kế chỉ có thể có hiệu quả trong bối cảnh đó nếu các chuyên gia này được phép đóng góp tích cực vào quá trình thiết kế Ngoài ra, việc giới thiệu một hệ thống mới có thể thay đổi bối cảnh công việc và quy trình tổ chức và sẽ chỉ được chấp nhận nếu những thay đổi này được chấp nhận bởi người dùng Thiết kế hợp tác

do đó nhằm mục đích tinh chỉnh các yêu cầu của hệ thống lặp đi lặp lại thông qua một quá trình thiết kế trong đó người dùng đang tích cực tham gia

Thiết kế hợp tác có ba đặc điểm cụ thể Nó nhằm cải thiện môi trường làm việc và nhiệm

vụ bằng việc liên tục giới thiệu các thiết kế Điều này làm cho bối cảnh thiết kế và đánh giá hoặc làm việc theo định hướng người dùng hơn là định hướng hệ thống Thứ hai, nó được đặc trưng bởi sự hợp tác: Người sử dụng bao gồm trong đội ngũ thiết kế và có thể đóng góp cho mọi giai đoạn của thiết kế Cuối cùng, cách tiếp cận là lặp đi lặp lại: Thiết kế phải được đánh giá và sửa đổi ở từng giai đoạn

2.3.5 Phương pháp nhân chủng học (Ethnographic Methods)

Tất cả các phương pháp truyền thống được xem xét ở trên đã bao gồm một số hình thức tư vấn và quan sát của các bên liên quan Tuy nhiên, trọng tâm của việc này là thu thập các quan điểm của các bên liên quan hơn là nghiên cứu cách họ làm việc thực tế

Dân tộc học dựa trên việc ghi lại chi tiết các tương tác giữa con người với môi trường Nó đặc biệt tập trung vào các mối quan hệ trong tổ chức và cách chúng ảnh hưởng đến bản chất của công việc Nhà phân tích sử dụng phương pháp này không tham gia tích cực vào tình hình và không nhìn mọi thứ từ quan điểm của một cá nhân cụ thể Mục đích là để hiểu được tình hình từ bên trong khuôn khổ của tổ chức Họ cố gắng đưa ra quan điểm khách quan về tình hình của tổ chức Họ báo cáo và không suy đoán, vì vậy thường không rõ ràng rằng cách tiếp cận của họ có thể đóng góp vào việc thiết kế các hệ thống mới hay không

2.3.6 Tóm lược

Trong phần này, tôi nói về các cách tiếp cận tổ chức xã hội để thu thập yêu cầu của các bên liên quan, bao gồm các mô hình xã hội – kỹ thuật, phương pháp hệ thống mềm, thiết kế hợp tác và các phương pháp nhân chủng học Các mô hình xã hội – kỹ thuật tập trung vào việc thể hiện song song cả khía cạnh con người và kỹ thuật của hệ thống để đạt được một giải pháp tương thích với nhau Còn trong mô hình tổ chức SSM, người dùng là một phần, và được xem như một hệ thống Phương pháp thiết kế hợp tác cho thấy người sử dụng không chỉ hoạt động trong việc sử dụng công nghệ mà còn trong việc thiết kế nó Phương pháp nhân chủng học đặt người dùng trong ngữ cảnh, cố gắng thu thập thông tin trên quan điểm không thiên vị về văn hoá làm việc và thực tiễn của người dùng

2.4 Kỹ nghệ yêu cầu trong Agile Scrum

2.4.1 Quá trình hình thành

Vào đầu thế kỉ XX, các nghiên cứu cho quá trình phân tích yêu cầu tập trung vào việc con người cần phải làm gì để thích ứng với những thay đổi về kỹ thuật, hay tương tác giữa người và máy là quá trình mà con người đang ở thế bị động Chủ nghĩa công nghệ quyết định, quan điểm cho thấy sự thay đổi xã hội chủ yếu là do kỹ thuật, tư tưởng mà các yếu tố con người và xã hội là mối quan tâm thứ yếu ở thời điểm bấy giờ

Những thập niên sau đó, quan điểm các mô hình Xã hội – Kỹ thuật (Socio-technical models)

có cách nhìn khác, nó phản ánh đúng vị trí công nghệ bằng việc nhấn mạnh rằng các hệ thống làm việc bao gồm cả nhân lực và máy móc và đó là mối quan hệ tương hỗ Mô hình này cho rằng các thành phần liên quan đến hệ thống tương tác lẫn nhau vì vậy cần quan tâm đến khía cạnh kỹ thuật, xã hội, tổ chức và con người trong thiết kế Họ thừa nhận thực tế là công nghệ không được phát triển một cách độc lập mà là một phần của môi trường tổ chức rộng lớn hơn

Thập kỉ 80 của thế kỉ XX chứng kiến thời kì khủng hoảng phương pháp luận phát triển phần mềm, do tỉ lệ thất bại của các dự án phần mềm quá cao Hàng loạt nỗ lực của các nhà thực hành cũng như giới hàn lâm đã cố gắng tìm ra phương pháp hữu hiệu để đảm bảo tính hiệu quả trong phát triển phần mềm

Thập kỉ 90, nhiều phương pháp phát triển phần mềm với quy trình nhẹ (light weight) và linh hoạt ra đời, như XP, Scrum, FDD, Crystal, và nhanh chóng được lan rộng

Từ 11 - 13 tháng 2 năm 2001, 17 nhà phát minh và nhà thực hành đã họp nhau tại bang Utah, Hoa Kì, để thảo luận về hướng đi mới trong phương pháp luận phát triển phần mềm

Họ đã đi đến thống nhất và cho ra đời bản Tuyên ngôn Agile đánh dấu một xu thế mới trong phát triển phần mềm Đặc trưng quan trọng của Agile cũng như Scrum: Tiếp cận tăng trưởng lặp là tiền đề cho sự phát triển của kỹ nghệ yêu cầu hiện nay

2.4.2 Vai trò của Chủ sản phẩm (Product Owner) trong Scrum

Chủ sản phẩm (Product Owner) chịu trách nhiệm tối đa hóa giá trị của sản phẩm và công việc của nhóm phát triển thông qua việc quản lý Product Backlog là một danh sách sắp thứ

tự tất cả những gì cần thiết của sản phẩm Nó là nguồn yêu cầu duy nhất thể hiện các thay đổi trong sản phẩm

Để Product Owner thành công, cả tổ chức phải tôn trọng các quyết định của người này Các quyết định đó được hiển thị trong nội dung và thứ tự trong Product Backlog Không ai ngoài Product Owner được phép yêu cầu nhóm phát triển làm gì khác và nhóm phát triển cũng không được phép làm gì theo lời bất cứ người nào khác

Là Product Owner, chúng ta nên trực tiếp giao tiếp với khách hàng và người dùng, nhóm phát triển và các bên liên quan khác (Key Stakeholders), như hình dưới đây cho thấy

Hình 2: Vai trò cầu nối của Chủ sản phẩm (Product Owner)

Ở trên là vai trò của các thành viên tham gia Scrum, bao gồm Product Owner, Scrum Master,

và nhóm phát triển cho thấy Product Owner phải có mối quan hệ gần gũi và sự tin tưởng từ các thành viên Scrum khác: Scrum xem Product Owner là cầu nối của đội Scrum rộng hơn Điều này rất có ý nghĩa vì để hoàn thiện sản phẩm Product Owner cần tiếp thu kiến thức về các hoạt động tiếp thị và kinh doanh cũng như văn hóa của công ty trong quá trình làm việc với Senior Management, Marketing and Sales cũng như quá trình cộng tác với Scrum Master và nhóm phát triển

2.4.3 Quy trình và các cuộc họp trong Scrum

2.4.3.1 Các đặc điểm

Các đặc điểm Agile Scrum sau đây đều ảnh hưởng trực tiếp tới phương pháp thu thập vào quản lý yêu cầu:

Tăng trưởng và lặp Các phương pháp Agile phân chia công việc trong ngắn hạn, ở mỗi

chu trình đều có đầy đủ các công đoạn trong quy trình phát triển phần mềm và ở mỗi Sprint đều có các bước phân tích yêu cầu hay làm mịn Product Backlog

Giao tiếp thường xuyên một cách hiệu quả Product Owner đại diện cho nhóm phát triển

làm việc cùng các bên liên quan của khách hàng Product Owner có trách nhiệm làm rõ tất

cả các yêu cầu của các bên liên quan và truyền tải chúng tới các thành viên trong nhóm phát triển

Thích ứng và chấp nhận các thay đổi Các developer qua các buổi họp hằng ngày (Daily

Meeting) hoặc ở đầu hoặc cuối mỗi giai đoạn (Sprint Meeting) sẽ sao trao đổi với nhau để cập nhật và đồng bộ trạng thái công việc, họ cần phải thích ứng ngay với tình huống mới

hoặc các yêu cầu hoặc thay đổi yêu cầu từ phía khách hàng

Hướng tới chất lượng sản phẩm Liên kết chặt chẽ giữa nhóm phát triển và khách hàng

tạo nên một sản phẩm chất lượng, từ cách tiếp cận này rất nhiều kỹ thuật và công cụ được

sử dụng để nâng cao chất lượng sản phẩm, bao gồm các kỹ thuật: Test Unit Automation, Build Automation, Deployment Automation, Aspect Oriented Programming, Design Pattern, Code Refactoring, …

2.4.3.2 Quy trình Scrum

Chủ sản phẩm (Product Owner) tạo ra Product Backlog chứa các yêu cầu của dự án được sắp theo thứ tự ưu tiên Nhóm phát triển sẽ hiện thực lần lượt các yêu cầu của Product Owner qua các Sprint với đầu vào là các hạng mục trong Product Backlog, đầu ra là các Phần tăng trưởng chuyển giao được của sản phẩm (Potentially Shippable Product Increment)

Scrum Master đảm bảo các sự kiện được diễn ra và người tham dự hiểu được mục đích của

sự kiện Scrum Master hướng dẫn mọi người luôn làm việc trong khuôn khổ thời gian được

phép Trong cuộc họp các cuộc họp, Scrum Master tham dự như là một thành viên của nhóm chịu trách nhiệm về quy trình

Hình 3: Quy trình Scrum

2.4.3.3 Họp kế hoạch Sprint

Công việc trong Sprint được lên kế hoạch trong buổi Họp Kế hoạch Sprint (Sprint Planning Meeting) Kế hoạch cho Sprint được tạo ra nhờ nỗ lực cộng tác của toàn bộ Nhóm Scrum Buổi Họp Kế hoạch Sprint được đóng khung trong 8 tiếng cho mỗi Sprint một tháng Với các Sprint ngắn hơn thì thời gian cho buổi họp được rút ngắn lại Ví dụ như một Sprint hai tuần có thể chỉ cần họp kế hoạch tới 4 tiếng là đủ

Buổi Họp Kế hoạch Sprint có hai phần, mỗi phần chiếm một nửa khung thời gian Hai phần của buổi Họp Kế hoạch Sprint lần lượt trả lời hai câu hỏi sau đây:

• Mục tiêu của Sprint này là gì?

• Sprint này phải chuyển giao cái gì?

• Làm sao để đạt được điều đó?

Phần Một: Phải làm gì trong Sprint này?

Trong phần này, nhóm phát triển làm việc để dự báo chức năng sẽ được phát triển trong Sprint Product Owner trình bày các hạng mục Product Backlog được xếp thứ tự cho nhóm phát triển và toàn bộ Nhóm Scrum sẽ hợp tác để tìm hiểu công việc phải làm trong Sprint Đầu vào của buổi họp này là Product Backlog, phần tăng trưởng của sản phẩm gần đây nhất, năng lực hiện có của nhóm phát triển trong Sprint tới và hiệu suất trong quá khứ của nhóm phát triển Số lượng hạng mục được chọn từ Product Backlog cho Sprint này sẽ hoàn toàn phụ thuộc vào nhóm phát triển Chỉ nhóm phát triển có thể đánh giá họ có thể hoàn thành những gì trong Sprint tới đây

Sau khi nhóm phát triển dự báo các hạng mục Product Backlog sẽ được chuyển giao trong Sprint, Nhóm Scrum xác lập Mục tiêu Sprint Mục tiêu Sprint có thể tạo ra một sợi dây ràng buộc cho những nỗ lực của cả nhóm phát triển hướng đến một mục tiêu chung

Phần Hai: Làm sao để hoàn thành công việc đã chọn?

Sau khi đã chọn công việc cho Sprint, nhóm phát triển quyết định cách thức để xây dựng các chức năng sẽ có trong phần tăng trưởng “hoàn chỉnh” trong suốt Sprint Các hạng mục Product Backlog được lựa chọn cho Sprint cộng với kế hoạch để chuyển giao chúng được

gọi là Sprint Backlog

Nhóm phát triển thường bắt đầu công việc bằng cách thiết kế hệ thống và các công việc cần thiết để chuyển Product Backlog thành gói sản phẩm chạy được Công việc có thể lớn nhỏ khác nhau Tuy vậy, một lượng công việc vừa đủ được lên kế hoạch trong suốt buổi Họp

Kế hoạch Sprint cho nhóm phát triển sẽ dự báo những thứ có thể làm trong Sprint sắp tới Các công việc được lên kế hoạch trong những ngày đầu tiên của Sprint bởi nhóm phát triển

sẽ được phân tách thành các đơn vị nhỏ hơn trong phạm vi một ngày hoặc nhỏ hơn nữa ở cuối buổi họp

Nhóm phát triển sẽ tự tổ chức để làm việc trên Sprint Backlog, cả khi lập kế hoạch lẫn thực thi kế hoạch trong suốt Sprint

Khi nhóm phát triển lên kế hoạch, họ hướng mọi điều tới Mục tiêu Sprint Trong suốt Sprint, các công việc cần làm đôi khi hơi khác so với kế hoạch ban đầu Khi đó, nhóm phát triển

sẽ cùng làm việc với Product Owner để xác định lại kế hoạch sao cho vẫn đạt được Mục

tiêu Sprint Mục tiêu Sprint cung cấp sự linh hoạt cần thiết sao cho các chức năng cơ bản vẫn được hoàn thành vào cuối Sprint

Product Owner có thể giúp nhóm phát triển làm sáng tỏ các khúc mắc về các hạng mục được lựa chọn trong Product Backlog, cũng như giúp nhóm đưa ra quyết định trong một số trường hợp đặc biệt Nếu nhóm phát triển thấy có quá nhiều hoặc quá ít việc, họ có thể thương lượng thêm với Product Owner về việc này Nhóm phát triển cũng có thể mời một

số người khác tham dự để hỗ trợ một số vấn đề kĩ thuật hoặc chuyên môn

Kết thúc buổi Họp Kế hoạch Sprint, nhóm phát triển phải biết cách giải thích cho Product Owner và Scrum Master biết họ sẽ dự định làm việc như thế nào với tư cách một nhóm tự

tổ chức để hoàn thành Mục tiêu Sprint và tạo ra phần tăng trưởng theo yêu cầu

Mục tiêu Sprint

Mục tiêu Sprint (Sprint Goal) là một tập các mục tiêu cần đạt trong một Sprint sau khi triển khai một phần của Product Backlog Nó cung cấp các gợi ý để nhóm phát triển xây dựng các Phần tăng trưởng (Increment) Mục tiêu Sprint cho phép nhóm phát triển có một số sự linh hoạt nhất định về việc phải triển khai các chức năng như thế nào trong suốt Sprint Các hạng mục Product Backlog được chọn chuyển giao một chức năng đầy đủ có thể là một Mục tiêu Sprint Mục tiêu Sprint nên là một bộ các yêu cầu gắn kết khiến nhóm phát triển làm việc cùng nhau thay vì phân rã mỗi người một việc

Khi nhóm phát triển làm việc, họ sẽ ghi nhớ Mục tiêu này trong đầu Để thỏa mãn Mục tiêu Sprint, họ sẽ triển khai các chức năng cũng như các kĩ thuật cần thiết Nếu công việc phức tạp hơn dự kiến thì họ có thể cộng tác với Product Owner để thương lượng lại về phạm vi của Sprint Backlog trong Sprint

Hình 4: Sử dụng các cuộc họp để hoàn thiện, đánh giá yêu cầu

2.4.3.4 Họp Scrum hằng ngày (Daily Scrum)

Cuộc họp Daily Scrum được đóng khung trong 15 phút để nhóm phát triển đồng bộ hóa các hoạt động của thành viên và tạo lập kế hoạch cho 24 giờ tiếp theo Điều này có được nhờ việc thanh tra các công việc kể từ cuộc họp Daily Scrum trước và dự báo những công việc

sẽ được hoàn thành trước buổi họp lần sau

Cuộc họp Daily Scrum được tổ chức tại cùng một địa điểm để giảm thiểu sự phức tạp không cần thiết Trong suốt cuộc họp, mỗi thành viên nhóm phát triển giải thích rõ:

• Tôi đã làm những gì kể từ hôm qua để giúp nhóm phát triển đạt mục tiêu Sprint?

• Tôi sẽ làm những gì hôm nay để giúp nhóm phát triển đạt được mục tiêu Sprint?

• Tôi có nhìn thấy vấn đề gì cản trở nhóm phát triển đạt được mục tiêu Sprint?

Nhóm phát triển sử dụng cuộc họp Daily Scrum để đánh giá tiến độ công việc hướng tới Mục tiêu Sprint và đánh giá xu hướng tiến triển của công việc trong Sprint Backlog Cuộc họp Daily Scrum tối ưu hóa khả năng để nhóm phát triển có thể đạt được Mục tiêu Sprint Một số nhóm Scrum sử dụng công cụ phần mềm quán lý tiến độ như Atlassian Jira, quá

trình họ cập nhật khối lượng công việc còn lại (Remaining Effort) là thông tin đầu vào của Sprint Burndown Chart

Hình 5: Sprint Burndown Chart

Hằng ngày, nhóm phát triển có thể giải thích cho Product Owner và Scrum Master biết họ định làm gì với tư cách là một nhóm tự quản để hoàn thành mục tiêu và tạo ra các phần tăng trưởng cần thiết trong Sprint

Scrum Master đảm bảo cho nhóm phát triển tham gia họp, nhưng chính nhóm phát triển mới có trách nhiệm chính trong cuộc họp Daily Scrum Scrum Master phải hướng dẫn cho nhóm phát triển biết cách giữ cuộc họp ngắn gọn trong phạm vi khung thời gian 15 phút Scrum Master phải áp đặt quy tắc về việc chỉ có nhóm phát triển mới được tham gia cuộc họp Daily Scrum

Họp Daily Scrum sẽ cải tiến quá trình giao tiếp, lược bỏ các buổi họp hành không cần thiết, nhận biết và loại bỏ các trở lực trong quá trình phát triển, nhấn mạnh và phát huy các quyết định nhanh chóng và nâng cao mức độ hiểu biết của nhóm phát triển về dự án Cuộc họp này là chìa khóa của cơ chế thanh tra và thích nghi trong Scrum

2.4.3.5 Sơ kết Sprint

Buổi Sơ kết Sprint (Sprint Review) được tổ chức khi Sprint kết thúc để rà soát lại phần tăng trưởng vừa làm ra trong Sprint đó và để thực hiện các biện pháp thích nghi đối với Product Backlog nếu cần Trong cuộc họp này, Nhóm Scrum và các bên liên quan sẽ trao đổi với nhau về những gì vừa hoàn thành trong Sprint vừa rồi Trên cơ sở đó và những sự thay đổi trong Product Backlog trong suốt Sprint, người tham dự cuộc họp sẽ hợp tác để thảo luận

về những công việc sắp triển khai Đây là cuộc họp không trang trọng và việc trình bày về gói tăng trưởng chủ yếu nhằm mục đích cung cấp các phản hồi hữu ích và khuyến khích sự cộng tác giữa các bên Cuộc họp này được đóng khung trong bốn giờ cho các Sprint có độ dài một tháng Sprint ngắn hơn thì thời gian họp rút bớt cho phù hợp Buổi Sơ kết Sprint có một số đặc điểm sau:

• Product Owner mời mọi người tham dự bao gồm Nhóm Scrum và những người liên quan

• Product Owner xác nhận phần nào là “Hoàn thành” và phần nào chưa “Hoàn thành”

• Nhóm phát triển thảo luận những điều thuận lợi trong Sprint vừa qua, những khó khăn mà nhóm đã trải qua và cách thức giải quyết các vấn đề đó

• Nhóm phát triển trình diễn các phần việc đã “Hoàn thành” và trả lời các câu hỏi về gói tăng trưởng

• Product Owner trao đổi về Product Backlog Dựa trên tiến độ hiện thời, Product Owner đưa ra dự đoán ngày hoàn thành dự án (nếu cần)

• Toàn bộ nhóm thảo luận về những gì sẽ làm, nhờ đó buổi Sơ kết Sprint cung cấp các giá trị đầu vào cho buổi Họp Kế hoạch Sprint tiếp theo

• Xem xét lại thời gian biểu, tài chính, cơ sở vật chất, cũng như các yếu tố thị trường cho bản phát hành dự kiến của sản phẩm

Kết quả của cuộc họp Sơ kết Sprint là một bản Product Backlog đã được cập nhật, với các hạng mục dự định sẽ được triển khai trong Sprint tới Product Backlog có thể được điều chỉnh toàn diện để thích ứng với các cơ hội mới

2.4.3.6 Cải tiến Sprint

Buổi họp Cải tiến Sprint (Sprint Retrospective) là cơ hội để Nhóm Scrum tự thanh tra và đưa ra kế hoạch cho các cải tiến trong Sprint tiếp theo

Buổi họp Cải tiến Sprint được tổ chức ngay sau Sơ kết Sprint và trước khi cuộc Họp Kế hoạch Sprint tiếp theo diễn ra Cuộc họp này được đóng khung trong phạm vi ba giờ cho các Sprint một tháng Sprint ngắn hơn thì cuộc họp sẽ được rút ngắn lại cho phù hợp Mục đích của cuộc họp Cải tiến Sprint là để:

• Thanh tra lại tất cả các yếu tố trong Sprint vừa diễn ra, từ con người, các mối quan

Kết thúc cuộc họp Cải tiến Sprint, Nhóm Scrum phải xác định được các cải tiến sẽ được triển khai trong Sprint tới Việc triển khai các cải tiến này chính là sự thích nghi của Nhóm Scrum Mặc dù các cải tiến có thể được triển khai tại bất kì thời điểm nào đó, cuộc họp Cải tiến Sprint cung cấp một phiên làm việc chính thức để tập trung vào việc thanh tra và thích nghi

2.4.3.7 Tóm lược

Các cuộc họp diễn ra trong từng Sprint có sự tham gia của Chủ sản phẩm (Product Owner), Scrum Master và nhóm phát triển bao gồm: Họp kế hoạch Sprint (Sprint Planning Meeting), Họp Scrum hằng ngày (Daily Meeting), Họp sơ kết Sprint (Sprint Review Meeting), Họp cải tiến Sprint (Sprint Retrospective Meeting) Các cuộc họp này sẽ làm thay đổi các đơn

vị yêu cầu dùng User Story qua sơ đồ sau