Phương pháp Scrumban được áp dụng cho một tình huống thực tế là dự án AOTea theo 8 bước chính: chuẩn bị danh sách công việc tồn kho, tạo danh sách công việc tồn kho, cập nhật hàng đợi sẵ
Trang 1PHAN MINH TÂM
ÁP DỤNG SCRUMBAN ĐỂ KHẮC PHỤC TỶ LỆ SẢN PHẨM
DỞ DANG VÀ NÂNG CAO TỶ LỆ GIAO HÀNG ĐÚNG HẸN
CỦA CÔNG TY GLOBAL FACTORIES TEM BV
Chuyên ngành: Quản trị kinh doanh
Mã số: 60340102
KHÓA LUẬN THẠC SĨ
TP HỒ CHÍ MINH, tháng 08 năm 2014
Trang 2CÔNG TRÌNH ĐƯỢC HOÀN THÀNH TẠI TRƯỜNG ĐẠI HỌC BÁCH KHOA ĐẠI HỌC QUỐC GIA TP HỒ CHÍ MINH
Cán bộ hướng dẫn khoa học: TS Nguyễn Thúy Quỳnh Loan
Cán bộ chấm nhận xét 1:
Cán bộ chấm nhận xét 2:
Khóa luận thạc sĩ được bảo vệ/nhận xét tại HỘI ĐỒNG CHẤM BẢO VỆ KHÓA LUẬN THẠC SĨ TRƯỜNG ĐẠI HỌC BÁCH KHOA, ngày tháng năm
Thành phần Hội đồng đánh giá khóa luận thạc sĩ gồm:
Trang 3ĐẠI HỌC QUỐC GIA TP HCM CỘNG HOÀ XÃ HỘI CHỦ NGHĨA VIỆT NAM TRƯỜNG ĐẠI HỌC BÁCH KHOA Độc Lập - Tự Do - Hạnh Phúc
Tp HCM, ngày 15 tháng 08 năm 2014
NHIỆM VỤ KHÓA LUẬN THẠC SĨ
Họ và tên học viên: PHAN MINH TÂM Giới tính: Nam Ngày, tháng, năm sinh: 09/03/1982 Nơi sinh: Bến Tre
Khoá (Năm trúng tuyển): 2012
1- TÊN ĐỀ TÀI: Áp dụng Scrumban để khắc phục tỷ lệ sản phẩm dỡ dang và nâng cao tỷ lệ
giao hàng đúng hẹn của công ty Global Factories Tem BV
2- NHIỆM VỤ KHÓA LUẬN:
Nhiệm vụ của Khóa luận bao gồm các phần sau đây:
(1) Phân tích hiện trạng của công tác phát triển phần mềm của công ty Global Factories Tem
BV nói chung và dự án phần mềm quản lý dược phẩm AOTea nói riêng
(2) Áp dụng phương Scrumban để làm giảm tỷ lệ sản phẩm dỡ dang và nâng cao tỷ lệ giao hàng đúng hẹn
3- NGÀY GIAO NHIỆM VỤ: 28/04/2014
4- NGÀY HOÀN THÀNH NHIỆM VỤ: 15/08/2014
5- HỌ VÀ TÊN CÁN BỘ HƯỚNG DẪN: TS Nguyễn Thúy Quỳnh Loan
Nội dung và đề cương Khóa luận thạc sĩ đã được Hội Đồng Chuyên Ngành thông qua
CÁN BỘ HƯỚNG DẪN KHOA QL CHUYÊN NGÀNH
Trang 5TÓM TẮT NỘI DUNG
Vấn đề mà bộ phận phát triển phần mềm công ty Global Factories Tem BV nói chung và dự án AOTea nói riêng đang gặp phải là tỷ lệ giao hàng trễ hẹn còn cao Nguyên nhân chính của việc giao hàng trễ hẹn là do tồn tại quá nhiều WIP trong quá trình phát triển dự án WIP phát sinh nhiều trong quá trình phát triển là do mô hình quản lý Thác Nước không còn phù hợp nữa Các nguyên nhân gây ra việc giao hàng trễ hẹn và các tác động của chúng đến kết quả của dự án AOTea được xác định thông qua phương pháp chuyên gia bằng công cụ phỏng vấn sâu các thành viên trực tiếp tham gia dự án Phương pháp Scrumban được áp dụng cho một tình huống thực tế là dự án AOTea theo 8 bước chính: chuẩn bị danh sách công việc tồn kho, tạo danh sách công việc tồn kho, cập nhật hàng đợi sẵn sàng, giới hạn kích cỡ
của Hàng đợi sẵn sàng bằng cách kéo công việc từ danh sách công việc tồn kho,
thực hiện trình diễn kết quả của sprint, thực hiện cuộc họp rút ra bài học kinh nghiệm của sprint, kiểm tra sản phẩm đã thực hiện và thực hiện triển khai sản phẩm cho khách hàng Các kết quả đạt sau cùng được xác định thông qua 2 phương pháp: thu thập nhận định từ các chuyên gia bằng công cụ phỏng vấn sâu và đo đạc kết quả bằng dữ liệu của dự án qua các sprint Đặc biệt, kết quả từ 2 phương pháp đều đưa
ra cùng một kết luận rằng phương pháp Scrumban đã giúp dự án AOTea cải thiện được thời gian giao hàng đúng hẹn, WIP được giảm đáng kể qua các sprint, sự hợp tác làm việc của các thành viên trong đội suôn sẻ, đoàn kết hơn, tình trạng thắt cổ chai được phát hiện và xử lý rất sớm trước khi triển khai cho khách hàng
Trang 6ABSTRACT
The problem that the Software Development Department of Global Factories Tem BV in general and AOTea project have been encountering is frequently missing the delivering deadline The root cause of this problem is due to the massive existence of WIP during the development process WIP has been generated in a large amount because the Waterfall model is not a good choice for AOTea project anymore Causes for missing deadline and their influence to the result of AOTea are identified through Delphi method by asking questionnaires to experts participating in the project The Scrumban methodology is applied for AOTea project following 8 steps: Grooming ahead of ready queue update, Product backlog, Ready queue update, Size limited ready queue, Sprint demo, Sprint retrospective, Release testing and Product deployment The result is finalized through 2 methods: collecting viewpoint from experts by in-depth interview technique and measuring the project‘s data in sprints Particularly, results from two these methodologies lead to the same conclusion that Scrumban methodology definitely helps improving the delivery time, WIP is reduced significantly through sprints, better communication between members in project, bottlenecks are detected and resolved early before deploying products to customers
Trang 7MỤC LỤC
NHIỆM VỤ KHÓA LUẬN THẠC SĨ ii
LỜI CẢM ƠN iii
TÓM TẮT NỘI DUNG iv
ABSTRACT v
MỤC LỤC vi
DANH MỤC CÁC BẢNG ix
DANH MỤC CÁC BIỂU ĐỒ x
DANH MỤC CÁC HÌNH xi
DANH MỤC THUẬT NGỮ VÀ TỪ VIẾT TẮT xii
CHƯƠNG 1: MỞ ĐẦU 1
1.1 TỔNG QUAN 1
1.2 LÝ DO HÌNH THÀNH ĐỀ TÀI 1
1.3 MỤC TIÊU NGHIÊN CỨU 2
1.4 Ý NGHĨA ĐỀ TÀI 3
1.5 PHẠM VI NGHIÊN CỨU 3
1.5.1 Không gian nghiên cứu 3
1.5.2 Thời gian nghiên cứu 4
1.6 PHƯƠNG PHÁP NGHIÊN CỨU 4
1.7 BỐ CỤC ĐỀ TÀI 5
CHƯƠNG 2: CƠ SỞ LÝ THUYẾT 7
2.1 QUY TRÌNH PHÁT TRIỂN PHẦN MỀM THEO MÔ HÌNH THÁC NƯỚC 7
2.2 QUY TRÌNH PHÁT TRIỂN PHẦN MỀM THEO MÔ HÌNH LINH HOẠT (Agile) 8
2.2.1 Scrum 9
2.2.2 Kanban 10
2.2.3 Scrumban 11
2.2.4 Các nghiên cứu có trước của Scrumban 15
Trang 82.2.5 Một số vấn đề các doanh nghiệp gặp phải khi áp dụng Scrumban 18
2.3 NỘI DUNG NGHIÊN CỨU 19
2.4 TÓM TẮT CHƯƠNG 20
CHƯƠNG 3: THỰC TRẠNG PHÁT TRIỂN PHẦN MỀM TẠI CÔNG TY GLOBAL FACTORIES TEM BV 21
3.1 GIỚI THIỆU TỔNG QUAN VỀ CÔNG TY 21
3.2 THƯ T A NG QUẢN LÝ HIỆN TẠI CỦA DOANH NGHIỆP 22
3.3 THƯ T A NG TRONG CÁCH QUẢN LÝ DỰ ÁN AOTea 24
3.4 NGUYÊN NHÂN LÀM CHẬM TRỄ TIẾN ĐỘ GIAO HÀNG CỦA DỰ ÁN AOTea 30
3.5 TÁ ĐỘNG CỦA CÁC NGUYÊN NHÂN ĐẾN VIỆC GIAO HÀNG TRỄ HẸN CỦA DỰ ÁN AOTea 31 3.6 TÓM TẮT CHƯƠNG 31
CHƯƠNG 4: ÁP DỤNG PHƯƠNG PHÁP SCRUMBAN CHO DỰ ÁN AOTea TẠI CÔNG TY GLOBAL FACTORIES TEM BV 32
4.1 QUY TRÌNH PHÁT TRIỂN PHẦN MỀM HIỆN TẠI CỦA DỰ ÁN AOTea 32
4.2 ÁP DỤNG PHƯƠNG PHÁP SCRUMBAN CHO DỰ ÁN AOTea 33
4.2.1 Các bước cần thực hiện trong phương pháp Scrumban 33
4.2.2 Thực hiện phương pháp Scrumban 33
4.3 NHẬN ĐỊNH KẾT QUẢ SAU KHI ÁP DỤNG GIẢI PHÁP 44
4.3.1 Phương pháp A: Đo đạc các kết quả của các sprint đã thực hiện 44
4.3.2 Phương pháp B: Phỏng vấn các nhận định của các thành viên tham dự án AOTea 46 4.4 TỔNG KẾT CHƯƠNG 46
CHƯƠNG 5: KẾT LUẬN 47
5.1 CÁC KẾT QUẢ CHÍNH CỦA ĐỀ TÀI 47
5.2 KIẾN NGHỊ 48
5.3 HẠN CHẾ VÀ ĐỊNH HƯỚNG NGHIÊN CỨU TIẾP THEO 48
TÀI LIỆU THAM KHẢO 49
Trang 9PHỤ LỤC 52
Trang 10DANH MỤC CÁC BẢNG
Trang
Bảng 3.1: Tỷ lệ giao hàng đúng hẹn của 3 dự án Pill Programmer, System Web và AOTea 23 Bảng 3.2: Bảng mô tả tác động của các nguyên nhân đến việc giao hàng trễ hẹn 26 Bảng 4.1: Danh sách các thành viên của dự án AOTea 34 Bảng 4.2: Bảng so sánh sự khác biệt giữa 2 danh sách công việc ở 2 mô hình Thác Nước và Scrumban 35 Bảng 4.3: Bảng so sánh về độ hiệu quả trong việc trình diễn kết quả của dự án AOTea theo 2 mô hình Thác Nước và Scrumban 42
Trang 11của dự án AOTea 24
Biểu đồ 3.4: Biểu đồ thể hiện các nguyên nhân chính làm chậm tiến độ giao hàng 25
Biểu đồ 4.1: Biểu đồ tỷ lệ giao hàng thực tế so với mục tiêu của 5 sprint sau khi áp
dụng giải pháp Scrumban của dự án phần mềm AOTea 45
Trang 12DANH MỤC CÁC HÌNH
Trang
Hình 2.1: Quy trình sản xuất phần mềm theo mô hình Thác Nước 7 Hình 2.2: Hình ảnh dòng công việc trong Scrumban bằng công cụ phần mềm Jira 12 Hình 2.3: Quá trình phát triển một phần mềm mới theo quy trình Scrumban 14 Hình 3.1: Cấu trúc của Global Factories Tem BV tại Việt Nam 21 Hình 4.1: Quy trình phát triển phần mềm của dự án AOTea 31 Hình 4.2: Quá trình chuẩn bị công việc tồn kho của dự án AOTea theo mô hình Thác Nước 33 Hình 4.3: Quá trình chuẩn bị công việc tồn kho của dự án AOTea theo mô hình Scrumban 34 Hình 4.4: Danh sách công việc tồn kho được tạo cho dự án AOTea theo mô hình Thác Nước 37 Hình 4.5: Các mẫu công việc được tạo bởi PO bằng công cụ Team Foundation Server theo mô hình Scrumban 38 Hình 4.6: Danh sách các công việc trong Hàng đợi sẵn sàng của dự án AOTea 40
Trang 13DANH MỤC THUẬT NGỮ VÀ TỪ VIẾT TẮT
Agile Software Development Phát triển phần mềm theo mô hình
Linh Hoạt
Global Factories Tem BV GF Công ty Global Factories Tem BV
nhằm phát triển một phần nhỏ của sản phẩm
Product Backlog PB Danh sách các công việc cần làm cho
Project Management PM Quản lý dự án
Trang 14Quality Assurance QA Đảm bảo chất lƣợng
Response For Proposal RFP Bảng yêu cầu chính thức
Sprint Backlog PB Danh sách công việc cần thực hiện
trong sprint
các công việc đã cam kết với khách
hàng
Team Foundation Server TFS Công cụ của Microsoft hỗ trợ quản lý
dự án theo Kanban
Work In Process WIP Sản phẩm dỡ dang
Trang 15CHƯƠNG 1: MỞ ĐẦU
Trong nền kinh tế thị trường, một doanh nghiệp muốn đứng vững thì cần tạo
ưu thế riêng thông qua các yếu tố thiết yếu của sản phẩm như: chất lượng sản phẩm, giá cả, giao diện, tính tiện dụng và nhanh chóng Để đạt được mục tiêu trên đòi hỏi các doanh nghiệp phải có chính sách kinh doanh hợp lý, quản lý hiệu quả Đặc biệt, doanh nghiệp cần tập trung nâng cao tiêu chí giao hàng đúng hạn, đúng yêu cầu, hạn chế tỷ lệ sản phẩm dỡ dang (WIP) và cải tiến chất lượng sản phẩm để tăng uy tín đối với khách hàng Trong phát triển sản phẩm phần mềm, WIP là không thể tránh khỏi và cũng là nguyên nhân chính ảnh hưởng đến thời gian giao hàng của doanh nghiệp bởi do không được quản lý hiệu quả
Để quản lý WIP tốt thì cần có một quy trình phát triển và quản lý phần mềm hiệu quả phù hợp với tính chất của một dự án phần mềm cụ thể nào đó Một quy trình phát triển phần mềm nào như quy trình Thác Nước, Scrumban, cũng đều có điểm lợi và bất lợi Nhà quản lý dự án là người hiểu rõ dự án nhất và sẽ là người quyết định chọn quy trình nào phù hợp nhất cho dự án
Công ty Global Factories Tem BV (GF) được thành lập năm 2009 hoạt động trên lĩnh vực kiểm định bao bì thuốc Doanh nghiệp có 2 mảng hoạt động chính: mảng thiết kế thiết bị phần cứng, mảng thiết kế và sản xuất phần mềm cho thiết bị Hiện tại, trong mảng thiết bị phần cứng có 11 sản phẩm bao gồm: MDM 1 series, MDM 2 series, MDM 3 series & Winder, Vision Station, TPM Winder, The BOX, Pouch Magnifier, Medicine dispensers, Medicine carts, Standalone Winder và
Trang 16TableWinder Ngoài ra, có 6 phần mềm đang phục vụ cho mảng thiết kế và sản xuất phần mềm cho thiết bị bao gồm: Phần mềm Pill Programmer, MDM, MDM Server, Medicine Detection Check-out, System Web, AOTea Khách hàng hiện nay của công ty GF là Hà Lan, Úc, Trung Quốc v.v Cứ mỗi 6 tháng, công ty thường có các cuộc triển lãm phần mềm tại các quốc gia trên Vấn đề hiện tại của doanh nghiệp là giao hàng trễ hẹn Nguyên nhân là do cách sắp xếp công việc và phân bố nhân lực chưa thật sự hợp lý Do yêu cầu của các dự án của công ty đòi hỏi tính linh hoạt, thay đổi liên tục nhưng quy trình Thác Nước hiện tại lại cồng kềnh, kém linh hoạt và có tính phản hồi chậm Hơn nữa, các công việc được thiết kế và chuyển giao cho nhân công có tính chuyên môn hóa và ít có tính thay thế Do vậy, khi một mắc xích trong nhân lực bị vấn đề do khách quan hoặc chủ quan thì tình trạng thắt cổ chai sẽ xảy ra và đội phát triển không có cơ hội sửa chữa những lỗ hỏng và lỗi kịp thời, nên tồn tại rất nhiều WIP sau mỗi sprint thực hiện Kết quả là công ty hay dời ngày triển lãm dẫn đến nhiều khách hàng không thật sự hài lòng Với mong muốn đóng góp nâng cao chất lượng đầu ra các sản phẩm của công
ty, tác giả thực hiện nghiên cứu cách làm giảm tỷ lệ WIP để nâng cao tỷ lệ giao hàng đúng hẹn bằng phương pháp Scrumban trong bộ phận phát triển phần mềm
Phân tích các nguyên nhân gây ra WIP và tác động của chúng trong quá trình phát triển phần mềm
Áp dụng phương pháp quản lý theo mô hình Scrumban để làm giảm tỷ lệ WIP của dự án phần mềm quản lý dược phẩm AOTea của doanh nghiệp
Phân tích kết quả của dự án AOTea sau khi áp dụng giải pháp Scrumban
Trang 171.4 Ý NGHĨA ĐỀ TÀI
Các ngành công nghiệp khác hầu hết đều sử dụng phần mềm để phục vụ cho việc sản xuất ra sản phẩm cuối Do đó, đòi hỏi phần mềm phải hoạt động có độ chính xác và độ tin cậy rất cao để làm giảm chi phí sản xuất
Hiện nay có khoảng 1/3 tổng số dự án phần mềm của công ty GF trong đó có
dự án AOTea chưa đáp ứng tốt vấn đề giao hàng đúng hẹn Quá nhiều WIP trong quá trình phát triển là nguyên nhân chính làm chậm trễ tiến độ giao hàng Giải pháp gốc rễ và hiệu quả nhất để làm giảm WIP trong quá trình phát triển phần mềm
là sự chọn lựa quy trình phát triển và quản lý phù hợp với dự án Dự án AOTea đang sử dụng quy trình phát triển theo mô hình Thác Nước được xem là chưa phù hợp với tính chất hay thay đổi yêu cầu của dự án Do vậy, mục đích của đề tài này giúp lựa chọn một quy trình phát triển phần mềm linh hoạt Scrumban để giúp làm giảm tỷ lệ WIP và nâng cao tỷ lệ giao hàng đúng hẹn cho khách hàng Nếu giải pháp này được áp dụng cho dự án AOTea đạt hiệu quả thì hy vọng Scrumban sẽ được công ty GF xem xét áp dụng cho các dự án chưa hiệu quả khác
1.5.1 Không gian nghiên cứu
Đề tài này tập trung vào các sản phẩm phần mềm của công ty GF, trong đó phần mềm quản lý dược phẩm AOTea được chọn để thực hiện nghiên cứu bởi vì sản phẩm này có tỷ lệ giao hàng trễ hẹn cao nhất trong tất cả các sản phẩm của doanh nghiệp AOTea là một trang web quản lý dược phẩm trực tuyến được phát triển bởi kỹ sư phần mềm thuộc phòng sản xuất phần mềm của công ty có trụ sở đặt tại thành phố Hồ Chí Minh
Trang 18Đối tượng được phỏng vấn để lấy dữ liệu là tất cả các thành viên của dự án gồm người quản lý, trưởng nhóm và các kỹ sư phần mềm có kinh nghiệm từ 5 năm trở lên của bộ phận phát triển phần mềm AOTea của công ty GF
1.5.2 Thời gian nghiên cứu
Thời gian thực hiện đề tài từ ngày 28 tháng 04 năm 2014 đến ngày 18 tháng 08 năm 2014
1.6.1 Phương pháp nghiên cứu tình huống
Phương pháp nghiên cứu tình huống sẽ phù hợp cho đề tài này bởi vì người nghiên cứu có ít quyền điều khiển các sự kiện và bởi vì các hiện tượng hiện hành đều xuất hiện bối cảnh cuộc sống thực (Yin, 2009) Nghiên cứu này sẽ được thực hiện theo quy trình nghiên cứu tình huống tổng quát được đề nghị bởi Yin, bao gồm các giai đoạn hoạch định, thiết kế, chuẩn bị, thu thập, phân tích và chia sẽ
Tình huống: Dự án phần mềm quản lý dược phẩm AOTea và các vấn đề trước khi áp dụng giải pháp Scrumban
AOTea là một phần mềm quản lý dược phẩm được phát triển bởi đội ngũ kỹ sư của công ty GF bao gồm 9 thành viên tham gia: 1 quản lý dự án, 1 trưởng nhóm, 4 lập trình viên và 3 kiểm tra viên Dự án đã trải qua 2 chặng phát triển sau 10 tháng Chặng thứ nhất kéo dài 5 tháng và chặng thứ hai bao gồm 5 sprint với mỗi sprint kéo dài 1 tháng Một thành phần của sản phẩm sẽ được cam kết thực hiện bởi đội phát triển ở mỗi đầu của sprint
WIP là vấn đề mà dự án AOTea đang gặp phải trong suốt quá trình thực hiện
dự án Cụ thể là kết quả giao hàng của chặng 1 được quản lý theo mô hình Thác
Trang 19Nước đều trễ hẹn do tồn tại nhiều WIP ở mỗi sprint Do yêu cầu của dự án đòi hỏi tính linh hoạt, thay đổi liên tục nhưng quy trình phát triển lại cồng kềnh, kém linh hoạt, tính phản hồi chậm Kết quả là đội phát triển không có cơ hội sửa chữa những
lỗ hỏng và lỗi kịp thời, nên tồn tại rất nhiều WIP sau mỗi sprint thực hiện
1.6.2 Phương pháp thu thập dữ liệu
Dữ liệu sơ cấp: Là một thành viên trong dự án phần mềm AOTea, tác giả tiến
hành điều tra các nguyên nhân chính gây ra WIP và tác động của các nguyên nhân trong quá trình phát triển bằng quan sát thực tế, ghi chép lại tỷ lệ WIP và
tỷ lệ giao hàng trễ hẹn Công cụ được dùng cho việc thu thập dữ liệu là phỏng vấn dạng bán cấu trúc Quá trình phỏng vấn này được thực hiện qua 2 giai đoạn: giai đoạn phỏng vấn tất cả các thành viên tham gia dự án AOTea về các nguyên nhân chính dẫn đến việc giao hàng trễ hẹn do WIP và giai đoạn phỏng vấn tất cả các thành viên cùng tham gia dự án về kết quả sau khi áp dụng phương pháp
Dữ liệu thứ cấp: Số liệu được thu thập từ phòng quản lý sản xuất, bộ phận sản
xuất, bộ phận kinh doanh và các tài liệu tham khảo khác của doanh nghiệp
Trang 20Chương II: Cơ sở lý thuyết
Chương này trình bày cụ thể các lý thuyết nền để hỗ trợ cho việc giải thích, mô
tả đề tài và nội dung cần nghiên cứu Danh sách các lý thuyết nền được áp dụng trong đề tài bao gồm: Lập trình linh hoạt, Scrum, Kanban, Scrumban, Quá trình chuẩn bị danh sách công việc cho sản phẩm và Quá trình phát triển một phần mềm mới dựa vào quy trình Scrumban
Chương III: Thực trạng phát triển phần mềm tại công ty Global Factories Tem BV
Chương này ngoài việc mô tả thực trạng hiện tại của quy trình phát triển phần mềm của doanh nghiệp nói chung và dự án AOTea nói riêng, còn trình bày các nguyên nhân và các tác động của WIP đối với kết quả của dự án thông qua các dữ liệu thực tế từ phòng quản lý sản xuất
Chương IV: Áp dụng phương pháp Scrumban cho dự án AOTea tại công ty Global Factories Tem BV
Phần đầu của chương này mô tả cách ứng dụng Scrumban để làm giảm WIP trong phát triển phần mềm và áp dụng cho dự án AOTea của công ty Phần sau cùng của chương là phân tích kết quả đạt được sau khi áp dụng giải pháp
Chương V: Kết luận
Chương này nêu tổng quát vấn đề của công ty, kết quả đạt được sau khi áp dụng phương pháp Scrumban, các hạn chế và đề xuất cho hướng nghiên cứu kế tiếp
Trang 21CHƯƠNG 2: CƠ SỞ LÝ THUYẾT
NƯỚC
Khoảng 20 năm về trước, các dự án phát triển phần mềm được thực hiện theo
mô hình Thác Nước và các biến thể của mô hình này như V-model Các mô hình này quy định lập trình theo hướng tuyến tính theo các bước tuần tự như: Tìm hiểu yêu cầu khách hàng, Thiết kế, Xây dựng, Kiểm tra và Bảo Trì Tuy nhiên, sau này người ta thấy rằng mô hình Thác Nước không còn phù hợp nữa do nhu cầu của khách hàng thay đổi liên tục và chi phí của dự án quá cao do chỉ được chỉnh sửa hoặc thay đổi khi đã hoàn thành xong các bước của quy trình Hình 1.1 mô tả 5 bước chính quy trình phát triển phần mềm theo mô hình Thác Nước
Hình 2.1: Quy trình sản xuất phần mềm theo mô hình Thác Nước (Royce, 1970)
Phân tích yêu cầu (Requirements): Trong bước này, toàn bộ yêu cầu phần mềm được nhận biết và phạm vi được xác định Những yêu cầu đó được thể hiện chi tiết theo văn bản chuẩn doanh nghiệp Để chuyển sang bước tiếp theo của quá trình thì cần người có trách nhiệm phê chuẩn, và khi đã sang bước tiếp theo thì các hạn chế
ít có cơ hội được thay đổi
Trang 22Thiết kế (Design): Trước khi bước sang giai đoạn mã hóa, toàn bộ giải pháp của hệ
thống cũng như kiến trúc cần được xác định, văn bản hóa và được phê chuẩn bởi người quản lý
Xây dựng (Implementation): Đây là giai đoạn hiện thực hóa giải pháp đã được
đưa ra (từ bước 2) thành ra các mã nguồn và những chương trình thực thi được
Kiểm tra (Verification): Trước khi phần mềm được chuyển giao tới khách hàng
hay người dùng cuối, nó cần được kiểm thử để bảo đảm về chất lượng Các lỗi tìm được và những đoạn mã nguồn không đạt chuẩn được đưa trở lại các lập trình viên
xử lí (bước 4) cho tới khi nào ―hết lỗi‖
Bảo trì (Maintenance): Khi chất lượng phần mềm được ―bảo đảm‖, toàn bộ phần
mềm được chuyển giao tới người dùng Công đoạn tiếp theo là nhận phản hồi như lỗi, hỗ trợ kĩ thuật, các việc ―vá lỗi‖, bảo trì v.v
Hiện tại, đa số các dự án trong công ty GF nói chung và dự án AOTea nói riêng phụ thuộc vào mong muốn của khách hàng nên dễ thay đổi, trong khi các quy tắc của quy trình Thác Nước mà công ty đang áp dụng thì cồng kềnh, ít linh hoạt và tính phản hồi chậm nên dễ gây ra WIP trong quá trình phát triển và ảnh hưởng trực tiếp đến thời gian giao hàng của doanh nghiệp Nói một cách khác, quy trình Thác Nước là thực trạng của quy trình phát triển phần mềm của công ty GF
HOẠT (Agile)
Trong những năm gần đây, Agile được biết đến như là quản lý theo Lean trong ngành công nghệ thông tin Agile là một cách tiếp cận quản lý với sự hỗ trợ của
Trang 23nhiều công cụ quản lý dự án Thật vậy, Scrum là một công cụ quản lý của Agile, được biết đến như là phương thức tập trung vào phát triển và giao hàng thông qua nhiều phân đoạn chặt chẽ giúp tương tác trực quan đối khách hàng Ngày này, Scrum được sử dụng rộng rãi và thành công trong ngành công nghệ phần mềm
2.2.1 Scrum
Scrum không phải là một quy trình hoặc một kỹ thuật, mà là một khung chuẩn
có thể sử dụng để hoàn thành dự án hoặc sản phẩm (Schwaber & Sutherland, 2011) Hơn nữa, Scrum là một khung thực nghiệm cho phát triển phần mềm và có
3 yếu tố quan trọng trong điều khiển quá trình thực nghiệm là tính minh bạch, tính
giám sát và tính thích ứng (Schwaber & Sutherland, 2011)
Tính thích ứng
Phải được thực hiện càng sớm càng tốt để phát hiện các sai lệch trong chức năng hoặc hướng đi dẫn đến các kết quả không chấp nhận được Scrum định nghĩa bốn điểm chính thức cho tính giám sát và tính thích ứng là Sprint Planning, Daily Scrum, Sprint Review và Sprint Retrospective (Schwaber & Sutherland, 2011)
Trang 242.2.2 Kanban
Kanban là một hệ thống quản lý sản xuất theo Just-In-Time, sử dụng hết khả năng và năng suất của công nhân (Sugimori et al., 1977) Hệ thống Kanban hướng các đội của dự án hình ảnh hóa luồng công việc, làm giảm WIP tại mỗi gian đoạn
và đo thời gian chu kỳ (Kniberg, 2009) Khi áp dụng Kanban, luồng công việc trong dự án được hình ảnh hóa bằng bảng Kanban, là một bảng trắng theo truyền thống hoặc là một công cụ phần mềm như Team Foundation Server, Jira Phương
pháp Kanban dựa trên 3 nguyên tắc chính là hình ảnh hóa quy trình, làm giảm WIP
và kiểm soát thời gian giao hàng
Hình ảnh hóa quy trình
Đây là quá trình quản lý bằng hình ảnh các công việc di chuyển qua các giai đoạn khác nhau trong quá trình phát triển trên bảng Kanban Hình ảnh hóa quy trình giúp đội phát triển biết được tiến trình của công việc Nếu một giai đoạn nào
đó của luồng công việc bị tắt nghẽn, thông báo sẽ được gửi cho đội phát triển để nhanh chóng xử lý (Mahnic, 2013)
Làm giảm WIP
Theo cơ chế ―kéo‖, Kanban đưa ra một giới hạn tối đa số lượng công việc trong mỗi giai đoạn phát triển với ý tưởng là không cho phép thực hiện một mẫu công việc mới nào cả dù cho các mẫu công việc hiện tại đã được chuyển giao cho khách hàng rồi Công việc mới chỉ thật sự được kéo vào hệ thống khi có công suất hữu dụng thay vì được đẩy từ bên ngoài vào hệ thống Giới hạn WIP trong một giai đoạn sẽ cho biết công suất để xử lý các mẫu công việc dở dang trong một giai đoạn của luồng công việc trong quá trình phát triển Quan trọng hơn là thời gian giao
Trang 25hàng được làm giảm, một yếu tố được xem là thước đo cho năng suất làm việc của đội phát triển (Mahnic, 2013)
Kiểm soát thời gian giao hàng
Thời gian giao hàng là một trong những thước đo quan trọng trong Kanban và
đo thời gian trung bình để hoàn thành một mẫu việc Ý tưởng chính trong Kanban
là tối ưu hóa quá trình để làm ngắn lại và dự đoán được thời gian giao hàng đến mức chính xác nhất có thể (Kniberg, 2009) Đội phát triển tập trung vào việc cải thiện thời gian giao hàng để ước lượng lượng công việc được thực hiện trong một
thời đoạn để vừa làm giảm thời gian giao hàng và vừa nâng cao hiệu năng của đội
Mô hình Scrumban là sự kết hợp giữa các tính năng ưu việt của 2 mô hình Scrum và Kanban Một mặt, sử dụng các quy tắc của Scrum để trở nên linh hoạt, mặt khác tận dụng tính chất cải tiến quá trình của Kanban để giúp đội liên tục cải tiến quá trình (Pahuja, 2012) Dưới đây là các nguyên tắc cơ bản của Scrumban
Hình ảnh hóa quá trình
Đây là tính chất quan trọng nhất của Kanban được áp dụng trong Scrumban Trong Scrum, đội thường bắt đầu các công việc trong một print và cố gắng di chuyển chúng đến giai đoạn hoàn thành Tuy nhiên, ý tưởng của Scrumban là phải hình ảnh hóa dòng công việc đi vào hoặc ra khỏi sprint (Yuval, 2012) để xác định được đâu là vùng tắc nghẽn và biết được ai đang làm công việc gì và ở trạng thái nào tại một thời điểm Theo định nghĩa của Heuvel (2011), các chính sách trong Scrumban/Kanban là các cơ chế, qui tắc hoặc các quá trình quản lý cách hệ thống vận hành Khi các chính sách này được hình ảnh hóa, hệ thống sẽ trở nên dễ hiểu
Trang 26hơn Các thành viên trong hệ thống sẽ liên tục đánh giá và cải tiến các cơ chế hiện tại khi cần thiết Hình 2.2 là một minh họa về dòng công việc trong Scrumban đƣợc tạo bởi công cụ phần mềm Jira
Hình 2.2: Hình ảnh dòng công việc trong Scrumban bằng công cụ phần mềm Jira
(Nguồn: Atlassian, 2011)
Trên hình 2.2, công cụ Jira thể hiện bảng Kanban rút gọn chỉ còn 3 cột chính thể hiện 3 trạng thái khác nhau của luồng công việc, các trạng thái từ trái sang phải lần lƣợt là trạng thái sẵn sàng (To do), trạng thái đang thực hiện (In Progress), trạng thái hoàn thành (Done) Hơn nữa, công cụ này còn hỗ trợ xác định công việc nào do ai đang thực hiện ở trạng thái nào Ở cột To do có 4 mẫu công việc (ANERDS-36, ANERDS-5, ANERDS-17 và ANERDS-15), có 2 mẫu công việc đang đƣợc thực hiện ở cột In Progress (ANERDS-38 và ANERDS-24) và sau cùng
là có 2 công việc đã đƣợc thực hiện xong ở cột Done (ANERDS-1 và 22)
Làm giảm WIP
Trang 27Đây là một đặc điểm quan trọng mà Scrumban kế thừa từ Kanban với ý tưởng chính là giữ cho đội phát triển tập trung vào các công việc đã được giao hơn là các công việc mới Điều này sẽ đảm bảo luồng công việc không có tắt nghẽn trong bất
cứ giai đoạn nào và qua đó giúp cho đội có sự hợp tác tốt hơn Một khi đã đến giới hạn của một giai đoạn nào đó, các thành viên của đội sẽ sẵn lòng giúp đỡ các thành viên khác thay vì bắt đầu công việc mới Giới hạn WIP là một cách rất tốt để điều khiển sự cộng tác thật sự của đội (Yuval, 2012)
Các cuộc họp lên kế hoạch cho sprint
Không giống Scrum, Scrumban có cuộc họp ngắn hơn trong việc lên kế hoạch thực hiện các công việc trong hàng đợi tồn kho bởi vì độ ưu tiên của công việc thường thay đổi Đội chỉ thật sự kéo các công việc vào hàng đợi sẵn sàng với số lượng ít các công việc có độ ưu tiên cao Do đó, ―quá trình lên kế hoạch lý tưởng nhất là luôn luôn giao việc cho đội phát triển các công việc khả thi nhất trong sprint
kế tiếp, không thêm hoặc cũng không bớt‖ (Ladas, 2008)
Các buổi họp hàng ngày, xem xét và nhìn lại quá khứ
Đây là các nghi thức được Scrumban kế thừa từ mô hình Scrum Các cuộc họp xem xét lại quá khứ của sprint và cuộc họp hàng ngày giúp cho đội hiểu hơn về trạng thái của sản phẩm, nhận được các phản hồi tất cả các thành viên để giúp đội cải tiến các quy tắc chung, cải tiến toàn bộ quá trình và rút ra bài học kinh nghiệm cho các sprint kế tiếp
Quá trình phát triển một phần mềm mới dựa vào quy trình Scrumban
Quá trình phát triển một phần mềm mới áp dụng theo quy trình Scrumban bao gồm 8 bước chính (hình 2.3): Chuẩn bị cập nhật hàng đợi sẵn sàng hàng tuần
Trang 28(Grooming ahead of Ready Queue Update), Tạo danh sách tồn kho công việc (Product Backlog), Cập nhật hàng đợi sẵn sàng (Ready Queue Update), Giới hạn kích cỡ hàng đợi sẵn sàng (Size Limited Ready Queue), Trình diễn kết quả của sprint (Sprint Demo), Cuộc họp rút ra bài học kinh nghiệm từ sprint (Sprint Retrospective), Kiểm tra sản phẩm (Release Testing) và Triển khai sản phẩm (Product Deployment)
Hình 2.3: Quá trình phát triển một phần mềm mới theo quy trình Scrumban
(Nguồn: Khan, 2014)
Ở hình 2.3, sau khi nhận yêu cầu từ khách hàng (Requirements), chủ sản phẩm (PO), và các thành viên của đội tổ chức cuộc họp hàng tuần để chuẩn bị danh sách công việc tồn kho (Product Backlog Grooming) Kết quả của cuộc họp chuẩn bị này là danh sách các công việc tồn đọng được sắp xếp ưu tiên theo hướng sự kiện với các yêu cầu được cập nhật nhất từ PO Sau khi đã danh sách này đã có thứ tự,
Trang 29thì có một cuộc họp diễn ra để Cập nhật hàng đợi sẵn sàng (Ready Queue Update) Cuộc họp này có thể được tổ chức khi cần thiết hoặc diễn ra hàng tuần
Kết quả của cuộc họp cập Ready Queue Update là một Hàng đợi sẵn sàng
được giới hạn về kích thước (Size Limited Ready Queue) Hàng đợi này có được là
do các công việc được kéo về từ Product Backlog Giới hạn của kích thước được xác định tùy vào từng trạng thái của User Story Nếu đang ở trạng thái ―In Progress‖ thì kích thước sẽ là (N*2-2), trong trạng thái ―Review‖ hoặc ―Testing‖ thì kích thước sẽ là (N-1), còn ở trạng thái ―Done‖ thì kích thước sẽ là không với N
là số lập trình viên trong một đội phát triển
Một câu hỏi đặt ra là ―Có cần cập nhật Hàng đợi sẵn sàng không?‖ (Is Backlog
Update Needed?) Nếu cần thiết (YES) thì trở lại bước Ready Queue Update Nhưng nếu không cần thiết (NO) thì tiến hành việc trình diễn kết quả thực hiện của
sprint (Sprint Demo) Sau buổi Sprint, cuộc họp rút kinh nghiệm từ sprint vừa rồi
(Sprint Retrospective) được tổ chức song song với bước Kiểm tra kết quả thực hiện (Release Testing) Nếu trong cuộc họp rút bài học kinh nghiệm của sprint, đội phát
triển hay PO tìm ra các vấn đề quan trọng thì sẽ cập nhật ngay Hàng đợi sẵn sàng
để chuẩn bị cho sprint kế tiếp Cuộc họp này nên diễn ra hai tuần một lần Sau cùng của quá trình Scrumban là triển khai sản phẩm cho khách hàng (Product Deployment)
2.2.4 Các nghiên cứu có trước của Scrumban
Scrumban được ứng dụng để cải tiến quy trình phát triển phần mềm (Khan, 2014) Nghiên cứu đã đưa ra một mô hình phát triển mới linh hoạt cho đội phát triển và chứng minh bằng cách áp dụng vào một tình huống cụ thể là một doanh
Trang 30nghiệp với 65 nhân viên Kết quả thu được là quá trình phát triển phần mềm được cải thiện đáng kể, sự hợp tác giữa các thành viên trong đội được nâng cao và các
quy tắc công việc được cải tiến liên tục
Scrumban được ứng dụng trong phát triển phần mềm bằng cách tận dụng các
ưu điểm của Scrum và Kanban (Mahnic, 2014) Nghiên cứu này đã nâng cấp các nghiên cứu có trước về bảng Kanban bằng cách đề nghị một bảng Kanban tổng quát hơn và các nguyên tắc để sử dụng bảng này Bảng Kanban này sẽ được áp dụng cho các đội phát triển theo quy trình Scrumban Hơn nữa, một giải pháp kết hợp các ưu điểm của Scrum và Kanban cho quá trình phát triển phần mềm cũng
được đưa ra trong nghiên cứu này
Sự kết hợp giữa Scrum và Kanban trong kết nối các dự án phần mềm (Ingason, Gestsson & Jonasson, 2013) Nghiên cứu này đưa ra một giải pháp cụ thể để giải quyết vấn đề kết nối giữa các dự án với nhau dựa trên nghiên cứu trước đó
―Kanban and Scrum, making the most of both‖ của Henrik Kniberg and Mattias Skarin năm 2009 Kết quả của nghiên cứu là một công cụ Project Kanban Wall (PKW), được dùng để minh họa diễn biến của các luồng dự án (thay vì các luồng công việc) Cải tiến của công cụ này so với công cụ Kanban truyền thống là tối ưu hóa luồng của các dự án phần mềm và nâng cao khả năng kết nối giữa bộ phận phát triển và bộ phận quản lý của dự án Giải pháp đầy đủ của nghiên cứu này là sự kết hợp sử dụng công cụ PKW song song với công cụ Scrum và công cụ khác để phát
triển phần mềm
Triển khai Scrumban trong công ty cung cấp bưu chính viễn thông Siminn của IceLand
Trang 31Siminn là một công ty cung cấp bưu chính viễn thông của IceLand với doanh thu 153 triệu euro trong năm 2010, gấp đôi Vodafone của IceLand (Hauksson, 2011) Siminn có 2 bộ phận chính là PMO (Project Management Offices) và SDD (Software Development Department) Nhiều dự án của Siminn SDD rất phức tạp, định nghĩa không rõ ràng và không có thời gian kết thúc xác định trước Lý do cho điều này là nhằm đảm bảo cho Siminn luôn đáp ứng dịch vụ khách hàng tốt hơn Vấn đề mà Siminn đang gặp phải chính là các dự án không được xác định rõ ràng
từ lúc đầu cho đến kết thúc Để giải quyết vấn đề trên, Siminn đã áp dụng Scrumban cho bộ phận SDD Việc quan trọng cần làm là tạo một đội để chuẩn bị và giám sát dự án Đội này bao gồm một quản lý dự án từ bộ phận Siminn PMO, một
SM và một phân tích viên nghiệp vụ từ bộ phận Siminn SDD Công ty đã sử dụng
hệ thống quản lý dự án Jira (Atlassian, 2011) để theo dõi tất cả các dự án Giai đoạn đầu tiên là xem xét hệ thống hiện tại và định nghĩa luồng công việc hiện hành và gắn chúng với bảng Kanban Điều này giúp cho đội có thể đánh giá quá trình, nhìn thấy những thứ tốt hơn để làm và xác định nút thắt cổ chai Nút thắt cổ chai được thể hiện là cột ―In progress‖ trên bảng Kanban Scrum là phương thức được dùng
để giải quyết cột ―In progress‖ đó
Triển khai Scrumban trong công ty phát triển phần mềm dược phẩm PDX
Công ty có 10,000 đại lý trên khắp nước Mỹ và 20% kê đơn thuốc ở Mỹ đều thông qua các hệ thống của PDX Công ty đã bắt đầu thực hiện quy trình phát triển phần mềm theo mô hình Agile cách đây 4 năm Công ty đã phát triển hệ thống quản
lý dược sử dụng phương thức Scrum trong quy trình hỗ trợ sản xuất và mang lại một ít thành công Vấn đề gặp phải chính là sự thay đổi độ ưu tiên rất liên tục và thời gian triển khai cho các lần vá lỗi là rất ngắn Các phân đoạn của Scrum thì liên
Trang 32tục ngừng hoặc bị điều chỉnh, các thiết kế thì thiếu làm cho khách hàng, chủ sản phẩm và các thành viên của đội đều không hài lòng Cuộc họp mỗi ngày cho hơn
20 lập trình viên ở nhiều quốc gia khác nhau làm mất nhiều thời gian Công ty đã giải quyết vấn đề bằng cách áp dụng 15 phút cho các buổi họp Scrum thông thường
và tối đa là 1 giờ cho các buổi thật sự là quan trọng
2.2.5 Một số vấn đề các doanh nghiệp gặp phải khi áp dụng Scrumban
Khó khăn về thời gian trong việc hoàn thành kế hoạch của sprint
Các thành viên của đội nhiều lần không thể đồng tình với thời gian ước lượng bởi vì các User Story chưa hoàn thành, vì thế các cuộc họp lên kế hoạch kéo dài
hoặc các buổi họp ước lượng thời gian thực hiện bị hủy bỏ do quá nhiều công việc
Thiếu sự cộng tác và nhiều vấn đề trong việc tự tổ chức
Một trong những trở ngại lớn nhất mà các thành viên của đội đối mặt là thiếu
sự cộng tác và tính tự tổ chức Các thành viên của đội chỉ cố gắng tập trung vào
công việc được giao và không có sự liên kết với các thành viên khác của đội
Các công việc được giao không hoàn thành trong một sprint
Thông thường một đội phát triển không thể hoàn thành các công việc của sprint khi các công việc quá phức tạp Đó thường là các công việc nghiên cứu mới, giải quyết vấn đề mang tính hệ thống rất phức tạp và do đó rất khó để đưa ra thời gian ước lượng chính xác Kết quả là, nhiều công việc trong một sprint bị dồn cho
bộ phận kiểm định chất lượng
Chủ sản phẩm thay đổi độ ưu tiên trong sprint
Trang 33Chủ sản phẩm thực hiện thay đổi độ ưu tiên của các công việc trong một sprint
và thêm các công việc vào sprint mà không được ước lượng trước
Đề tài sẽ thực hiện 7 nội dung nghiên cứu chính sau:
1) Phân tích thực trạng quản lý dự án phần mềm hiện tại của công ty GF
2) Phân tích thực trạng quản lý dự án phần mềm quản lý dược phẩm AOTea 3) Xác định các nguyên nhân làm chậm trễ tiến độ giao hàng của dự án AOTea 4) Xác định các tác động của các nguyên nhân gây ra việc giao hàng bị chậm trễ của dự án AOTea
5) Áp dụng phương pháp Scrumban cho việc phát triển dự án phần mềm AOTea theo 8 bước (tham khảo hình 2.3 trang 14):
- Bước 1: Chuẩn bị danh sách công việc tồn kho (Product Backlog Grooming)
- Bước 2: Tạo danh sách công việc tồn kho (Product Backlog)
- Bước 3: Cập nhật hàng đợi sẵn sàng (Ready Queue Update)
- Bước 4: Giới hạn kích cỡ của Hàng đợi sẵn sàng bằng cách kéo công việc từ
danh sách công việc tồn kho
- Bước 5: Thực hiện trình diễn kết quả của sprint (Sprint Demo)
- Bước 6: Thực hiện cuộc họp rút ra bài học kinh nghiệm của sprint
- Bước 7: Kiểm tra sản phẩm đã thực hiện (Release Testing)
Trang 34- Bước 8: Thực hiện triển khai sản phẩm cho khách hàng (Product Deployment)
6) Phân tích kết quả sau khi áp dụng giải pháp
7) Đưa ra kết luận và kiến nghị
Các nội dung 1, 2, 3 và 4 sẽ được thể hiện chi tiết trong chương 3 Chương 4 sẽ trình bày các nội dung 5 và 6 Nội dung 7 được đề xuất trong chương 5
Chương này diễn giải chi tiết các lý thuyết nền cần thiết cho nghiên cứu Phần đầu của chương trình bày lý thuyết về quy trình phát triển phần mềm theo 2 mô hình bao gồm mô hình Thác Nước và mô hình Scrumban Hơn nữa, các tính chất quan trọng của Scrum như tính minh bạch, tính giám sát, tính thích ứng, của Kanban như tính hình ảnh hóa quy trình, làm giảm WIP, đo thời gian giao hàng và của Scrumban như tính chất kéo công việc, làm giảm WIP, tường minh hóa các quy tắc của đội, cuộc họp lên kế hoạch cho sprint, cuộc họp hàng ngày, cuộc họp xem xét và cuộc họp nhìn lại quá khứ, thước đo và ước lượng công việc của sprint cũng lần lượt được trình bày Ngoài ra, chương này còn giới thiệu 1 quy trình quan
trọng của Scrumban là quy trình Phát triển một phần mềm mới theo mô hình
Scrumban Ngoài việc giới thiệu 3 nghiên cứu có trước về Scrumban, chương này
còn trình bày 2 tình huống áp dụng thực tế Scrumban trong quá trình phát triển phần mềm là phần mềm viễn thông của Siminn và phần mềm dược phẩm PDX Phần sau cùng của chương là phần trình bày nội dung nghiên cứu của đề tài
Trang 35CHƯƠNG 3: THỰC TRẠNG PHÁT TRIỂN PHẦN MỀM TẠI
CÔNG TY GLOBAL FACTORIES TEM BV
3.1 GIỚI THIỆU TỔNG QUAN VỀ CÔNG TY
Công ty Global Factories Tem BV (GF) là một doanh nghiệp toàn cầu chuyên sản xuất các thiết bị và phần mềm hỗ trợ y khoa Hiện tại công ty có 3 bộ phận chính bao gồm bộ phận quản lý dự án Project Management Office (PMO), bộ phận phát triển phần cứng thiết bị y khoa Medical Device Development Department (MDDD) và bộ phận phát triển phần mềm Software Development Department (SDD) Các thiết bị do bộ phận MDDD do đội thuộc chi nhánh ở Hà Lan phát triển tập trung vào 2 mảng chính là phát hiện và phân phối (Tham khảo biểu mẫu 1 và 2 của phụ lục)
Hình 3.1: Cấu trúc của Global Factories Tem BV tại Việt Nam
Giám đốc Châu Á
Lập trình viên
Kiểm tra viên
Lập trình viên
Kiểm tra viên
Trang 36Giám đốc điều hành Châu Á chịu trách nhiệm toàn bộ vấn đề kinh doanh của
GF tại Châu Á Quản lý thu mua chịu trách nhiệm thu mua các nguyên vật liệu để sản xuất các thiết bị hỗ trợ y khoa Kiến trúc sư kỹ thuật chịu trách nhiệm tất cả các vấn đề kỹ thuật của toàn bộ dự án phần mềm trong công ty Trưởng đội là người đứng đầu quản lý chịu trách nhiệm của một dự án cụ thể và gửi báo cáo lên kiến trúc sư kỹ thuật về vấn đề kỹ thuật của dự án mà mình quản lý
3.2 THỰC TRẠNG QUẢN LÝ HIỆN TẠI CỦA DOANH NGHIỆP
Đây là bước 1 trong nội dụng nghiên cứu, xác định vấn đề trong cách quản lý hiện tại của công ty GF hoạt động trong môi trường tương đối cạnh tranh, tổ chức phải đảm bảo không đưa sản phẩm ra thị trường chậm hơn đối thủ cạnh tranh Do
đó GF phải chịu áp lực đáp ứng nhu cầu, giao hàng nhanh chóng và hiệu quả Tuy nhiên, nhiều dự án phần mềm trong công ty chưa được định nghĩa tốt, yêu cầu còn mập mờ và thời gian kết thúc dự án chưa được xác định rõ ngay từ đầu, độ ưu tiên cũng hay bị thay đổi nên rất khó để xác định phạm vi một cách rõ ràng
Hiện tại vấn đề giao hàng trễ hẹn của doanh nghiệp xảy ra trên nhiều dự án mà nguyên chính là do tồn tại quá nhiều WIP Biểu đồ 3.2, 3.3 và 3.4 thể hiện tỷ lệ giao hàng thực tế so với mục tiêu của 3 dự án của doanh nghiệp bao gồm Pill Programmer, System Web và AOTea trong 5 sprint đầu tiên
Nhận xét:
Thông tin từ bảng 3.1 cho thấy ba sản phẩm phần mềm của công ty đều bị giao hàng trễ hạn do tồn động nhiều WIP, trong đó sản phẩm AOTea có tỷ lệ giao hàng trễ hẹn là cao nhất
Trang 37Bảng 3.1: Tỷ lệ giao hàng đúng hẹn của 3 dự án Pill Programmer, System Web và AOTea
Biểu đồ 3.1: Biểu đồ tỷ lệ giao hàng thực tế so với mục tiêu 5 sprint đầu tiên của dự
án phần mềm Pill Programmer (Nguồn: Ph ng Q S lobal actories
Trang 38Biểu đồ 3.2: Biểu đồ tỷ lệ giao hàng thực tế so với mục tiêu 5 sprint đầu tiên của dự
án phần mềm System Web (Nguồn: Ph ng Q S lobal actories
Biểu đồ 3.3: Biểu đồ tỷ lệ giao hàng thực tế so với mục tiêu của năm sprint đầu tiên
của dự án AOTea (Nguồn: Ph ng Q S lobal actories
3.3 THỰC TRẠNG TRONG CÁCH QUẢN LÝ DỰ ÁN AOTea
Đây là bước 2 trong nội dụng cần nghiên cứu, xác định vấn đề của dự án AOTea Dự án AOTea là ứng dụng web hỗ trợ người dùng tìm kiếm và quản lý viên thuốc, bao thuốc thuộc các tiệm thuốc khác nhau Dự án AOTea được phân
ra làm nhiều sprint nhưng phạm vi của các sprint như khung thời gian và số lượng công việc chưa được xác định rõ ràng Yêu cầu của dự án chưa được định nghĩa tốt
và phải thường xuyên bị thay đổi trong giai đoạn phát triển Vấn đề này phát sinh là
do chủ sở hữu phẩm luôn cầu toàn trong việc cải tiến chức năng và dịch vụ cho