1. Trang chủ
  2. » Luận Văn - Báo Cáo

Á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

76 24 1

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 76
Dung lượng 1,26 MB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

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 1

PHAN 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 2

CÔ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 5

TÓ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 6

ABSTRACT

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 7

MỤ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 8

2.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 9

PHỤ LỤC 52

Trang 10

DANH 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 11

củ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 12

DANH 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 13

DANH 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 14

Quality 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 15

CHƯƠ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 16

TableWinder 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 17

1.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 19

Nướ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 20

Chươ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 21

CHƯƠ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 22

Thiế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 23

nhiề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 24

2.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 25

hà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 26

hơ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 29

thì 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 30

nghiệ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 31

Siminn 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 32

tụ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 33

Chủ 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 35

CHƯƠ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 36

Giá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 37

Bả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 38

Biể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

Ngày đăng: 01/02/2021, 00:21

Nguồn tham khảo

Tài liệu tham khảo Loại Chi tiết
[1] Atlassian (2011). Web page for the Jira project tracking tool. Retrieved November 29, 2011, from http://www.atlassian.com/software/jira/overview Link
[3] Heuvel, M V D. (2011) Explicit Policies Make Life Simpler. Retrieved April 29, 2014, fromhttp://scrumfamily.wordpress.com/2011/10/10/explicit-policies-make-life-simpler/ Link
[6] Kniberg, H. & Skarin, M. (2009). Kanban and Scrum — making the most of both. Retrieved March 7, 2009, from http://www.InfoQ.com Link
[10] Pahuja, S. (2012). What is Scrumban?, Retrieved Feb 5, 2014 from http://www.solutionsiq.com/resources/agileiq-blog/bid/87799/What-is-Scrumban Link
[16] Schwaber, K. (2010, June 10). Telling it like it is [Web log comment]. Retrieved November 29, 2011, fromhttp://kenschwaber.wordpress.com/2010/06/10/waterfall-leankanban-and-scrum-2/ Link
[17] Sutherland, J. (2007). The Scrum papers: Nuts, bolts, and origins of an agile process. Retrieved March 19, 2010, fromhttp://www.scrumtraininginstitute.com/home/stream_download/scrumpapers [18] Sugimori, Y., Kusunoki, K., Cho, F. and Uchikawa, S. (1977) Link
[21] Yuval, Y (2012). ‗So what is scrum-ban?‘ Retrieved January 10, 2014, from http://yuvalyeret.com/2012/04/28/so-what-is-scrumban/ Link
[2] Hauksson J.G. (2011). Frjỏls verslun – 300 stổrstu fyrirtổkin. Reykjavik, Heimur hf Khác
[4] Ingason H.T, Jonasson E.G & H.I (2013). The Project Kanban Wall: Combining Kanban and Scrum for Coordinating Software Projects, Vol. II, Issue VIII – August 2013 Khác
[5] Khan, Z. (2014). Scrumban - Adaptive Agile Development Process - Using scrumban to improve software development process. May 2014. Thesis Khác
[7] Ladas, C. (2008). Scrumban: Essays on Kanban systems for lean software development. Seattle: Modus Cooperandi Press Khác
[8] Liker J. K. (2004). The Toyota way: 14 management principles from the world's greatest manufacturer. New York: McGraw-Hill Khác
[9] Mahnic V. (2014). Improving Software Development through Combination of Scrum and Kanban, Trzaska 25, SI-1000 Ljubljana, Slovenia Khác
[11] Rodríguez P. (2013). Combining Lean Thinking And Agile Software Development: A Case Study of a Finnish Provider of Wireless Embedded Systems Detailed, hicss, pp.4770-4779, 2014 47th Hawaii International Conference on System Sciences, 2014 Khác
[12] Royce, W. W., Managing the Development of Large Software Systems, Proc. 9th. Intern. Conf. Software Engineering, IEEE Computer Society, 1987, 328-338 Originally published in Proc. WESCON, 1970 Khác
[13] Royce, W., TRW's Ada Process Model for Incremental Development of Large Software Systems, Proc. 12th. Intern. Conf. Software Engineering, Nice, France, 2-11, IEEE Computer Society, 1990 Khác
[14] Schwaber K. (2004). Agile project management with scrum. Redmond, Washington: Microsoft Press Khác
[15] Schwaber, K. and Beedle, M. (2002) Agile software development with Scrum, Upper Saddle River, NJ: Prentice Hall Khác
[19] Takeuchi H. & Nonaka I. (1986). The New Product Development Game. Harvard Business Review. January - February 1986. Harvard Business School Publishing.Boston Khác
[20] Yin R.K. (2009). Case Study Research – Design and Mehods. 4th edition. Sage Publications, California Khác

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

🧩 Sản phẩm bạn có thể quan tâm

w