Đề xuất mô hình sản xuất phần mềm theo lean một nghiên cứu tình huống tại tp hồ chí minh

Tuy nhiên, tư duy phương pháp Lean vẫn còn để mở nhiều câu hỏi trong lĩnh vực phát triển phần mềm như khác biệt cơ bản so với sản xuất phần mềm truyền thống là gì, nguyên tắc của Lean tr

LÊ THỊ THANH TRÂM

ĐỀ XUẤT MÔ HÌNH SẢN XUẤT PHẦN MỀM THEO LEAN MỘT NGHIÊN CỨU TÌNH HUỐNG TẠI TP HỒ CHÍ MINH

Chuyên ngành: QUẢN TRỊ KINH DOANH

LUẬN VĂN THẠC SĨ

TP HỒ CHÍ MINH, tháng 05 năm 2014

Cán bộ hướng dẫn khoa học: Phó giáo sư, Tiến sĩ Bùi Nguyên Hùng

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

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

Luận văn/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Ệ LUẬN VĂ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á luận văn thạc sĩ gồm:

NHIỆM VỤ LUẬN VĂN THẠC SĨ Họ và tên học viên: LÊ THỊ THANH TRÂM… Giới tính: Nam / Nữ

Ngày, tháng, năm sinh: 20-12-1987… Nơi sinh: LÂM ĐỒNG

Chuyên ngành: QUẢN TRỊ KINH DOANH … MSHV: 12170976

Khoá (Năm trúng tuyển): Khóa 2012

1- TÊN ĐỀ TÀI: Đề xuất mô hình sản xuất phần mềm theo Lean, một nghiên cứu tình huống tại thành phố Hồ Chí Minh

2- NHIỆM VỤ LUẬN VĂN/KHÓA LUẬN: Đã hoàn thành mục tiêu nghiên cứu luận văn - Sự khác biệt giữa hai phương pháp sản xuất phần mềm: truyền thống và linh hoạt - Đưa ra các gợi ý về nguyên tắc và thực hành Lean trong SXPM - Đ ưa ra được mô hình chuyển đổi Lean và các khó khăn có thể gặp phải cho một công ty SXPM tại thành phố Hồ Chí Minh

3- NGÀY GIAO NHIỆM VỤ: 22-11-2013

4- NGÀY HOÀN THÀNH NHIỆM VỤ: 19-05-2014

5- HỌ VÀ TÊN CÁN BỘ HƯỚNG DẪN: Phó giáo sư, Tiến sĩ BÙI NGUYÊN HÙNG

Nội dung và đề cương Luận văn thạc sĩ đã được Hội Đồng Chuyên Ngành thông qua Tp HCM, ngày 19 tháng 05 năm 2014

CÁN BỘ HƯỚNG DẪN KHOA QL CHUYÊN NGÀNH

PGS TS BÙI NGUYÊN HÙNG PGS TS LÊ NGUYỄN HẬU

giáo sư, Tiến sĩ Bùi Nguyên Hùng, người đã hỗ trợ và động viên tôi để hoàn thành luận văn này Thực sự đây là một niềm vui khi có cơ hội làm việc với thầy, người đã dạy tôi cách kiên nhẫn tìm tòi và khuyến khích tôi phải đối mặt với những thách thức một cách tích cực Tôi cảm ơn thầy vì những hướng dẫn tuyệt vời của thầy đã cho tôi thấy hướng nghiên cứu tập trung, luôn đảm bảo rằng tôi đi đúng hướng nhưng đồng thời cũng cho tôi sự tự do và tự chủ trong cách suy nghĩ

Tôi cũng xin gửi lời cảm ơn đến công ty Pyramid-Consulting Viet Nam đã cho tôi một môi trường tốt để thực hiện nghiên cứu của mình Tôi thực sự cảm ơn các chuyên gia

và đồng nghiệp trong suốt quá trình nghiên cứu đã tham gia thảo luận, tranh cãi và đóng góp ý kiến cho nghiên cứu này

Cuối cùng, lời cảm ơn nồng nhiệt nhất đến gia đình tôi đã luôn bên cạnh, giúp đỡ tôi rất nhiều về mặt tinh thần khi thực hiện luận văn này

Xin chân thành gửi lời cảm ơn đến tất cả!

cầu của khách hàng, do đó, các phương pháp phát triển phần mềm mới mà ban đầu gây

ra tranh cãi như phương pháp linh hoạt Đặc biệt là phương pháp phát triển phần mềm tinh gọn - LEAN là một trong những phương pháp linh hoạt và nay đã có được một bản sắc riêng của nó Tuy nhiên, tư duy phương pháp Lean vẫn còn để mở nhiều câu hỏi trong lĩnh vực phát triển phần mềm như khác biệt cơ bản so với sản xuất phần mềm truyền thống là gì, nguyên tắc của Lean trong SXPM là gì, khả năng tương thích của Lean cho các công ty SXPM ở thành phố Hồ Chí Minh?

Luận án này đề cập đến tư duy Lean và các nguyên tắc, công cụ thực hành Lean trong sản xuất phần mềm và làm thế nào để triển khai Lean cho các công ty trong lĩnh vực sản xuất phần mềm bằng cách phân tích các tình huống về cách thức một tổ chức phần mềm chuyên chuyển đổi trong thực tế, các khó khăn và thách thức mà công ty có thể phải đối mặt Nghiên cứu được thực hiện trong bốn giai đoạn, đầu tiên là tìm hiểu các tài liệu có liên quan để xác định cơ hội nghiên cứu Thứ hai, một chiến lược tìm hiểu

đã được sử dụng để đưa ra được những nguyên tắc và thực hành Lean trong SXPM Giai đoạn thứ ba chúng tôi tiến hành tìm hiểu cụ thể làm như thế nào để triển khai Lean trong thực tế các công ty SXPM tại TP.HCM, bằng cách tiến hành nghiên cứu trên bốn tình huống cụ thể Cuối cùng, trong giai đoạn thứ tư, kết quả của các giai đoạn nghiên cứu trước đây đã tổng hợp được để rút ra kết luận và phác thảo ý nghĩa của nghiên cứu

Kết quả nghiên cứu đã khẳng định sự quan tâm của các cá nhân và tổ chức trong việc triển khai Lean trong sản xuất phần mềm Không giống như trong sản xuất, biên giới của Lean không được định nghĩa rõ ràng trong lĩnh vực phần mềm Tuy nhiên kết quả nghiên cứu cũng cung cấp bằng chứng có nhiều điểm tương thích giữa phương pháp triển khai Lean cho sản xuất phần mềm và Lean trong sản xuất Mô hình triển khai Lean của Anvari và cộng sự có một số điều chỉnh để phù hợp hơn với các công ty SXPM tại TP HCM

The demand for software Engineering Technology is increasing everyday There are many discussions about Agile and Lean manufacturing models in the industry but even now, things are changing Lean manufacturing in particular is one of the most well-known manufacturing models However, there are still many open questions about Lean software development, its development principles, how it compares to traditional methods, and how to apply it to software companies in Ho Chi Minh City.

This thesis refers to the principles, tools, and practices of Lean software development

as well as the methods for implementing them in software companies The research method used analyzed case studies to discover which principles, practices, and models were most suitable for the software industry It was also uncovered the difficulties and pitfalls faced by software companies This thesis includes four stages: the first looks into relevant documents which identify research opportunities The second, based on related research, lists out Lean principles and practices in software development and transfer models In the third step, technical experts from various software companies were interviewed for their opinions on the most suitable transfer methods Finally, the results of previous studies were integrated in order to draw conclusions and emphasize the significance of this thesis

The research results confirm the interest of technical experts in Lean software development Lean software development differs from Lean manufacturing (though frontiers are often not clearly defined in the software industry) However, the research also points to correlation between transfer methods for implementing Lean software development and Lean manufacturing Lean deployment models for Anvari at al have also been slightly customized further for software companies in Ho Chi Minh City

1.3 Phạm vi, giới hạn đề tài 10

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

1.5 Ý nghĩa của nghiên cứu 12

1.6 Bố cục luận văn 13

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

2.1 Phần mềm và các khái niệm liên quan 15

2.1.1 Phần mềm 15

2.1.2 Quy trình phát triển phần mềm 15

2.2 Tổng quan mô hình phát triển truyền thống 17

2.2.1 Mô hình thác nước (Waterfall) 17

2.2.2 Những thất bại của mô hình truyền thống 20

2.3 Các mô hình phát triển phần mềm linh hoạt 21

2.3.1 Tổng quan về phát triển phần mềm linh hoạt 21

2.3.2 Lập trình Scrum 24

2.3.3 Sự khác nhau giữa mô hình truyền thống và mô hình linh hoạt 25

2.3.4 Những điểm mạnh và điểm yếu của phương pháp truyền thống và linh hoạt 27 2.4 Phương pháp sản xuất Lean 28

2.4.1 Triết lí Lean 29

2.4.2 Lean trong sản xuất các sản phẩm khác (không phải phần mềm) 30

2.4.3 Các lĩnh vực sản xuất áp dụng phương pháp Lean 30

2.5 Sản xuất phần mềm theo phương pháp Lean 32

2.5.1 Sự khác biệt giữa phương pháp Lean và phương pháp Agile 33

2.5.2 Các nguyên tắc Lean 34

2.5.3 Tổng hợp các nguyên tắc Lean trong SXPM 41

2.5.4 Các công cụ và thực hành Lean (Tool & Best Practice) 45

2.5.5 Tổng hợp các nguyên tắc và thực hành Lean cho ngành SXPM 52

2.6 Cách thức triển khai Lean 54

2.6.1 Mô hình triển khai chuyển đổi Leancủa Phillip Magnier (2008) 54

2.6.2 Mô hình triển khai Lean 8 bước của Lonnie Wilson 2010 58

2.6.3 Mô hình triển khai Lean của tổ chức tư vấn CICC 60

2.6.4 Mô hình triển khai Lean của Anvari và cộng sự 2010 61

2.6.5 Mô hình của Kotter cho các doanh nghiệp CNTT 2011 62

2.6.6 Mô hình triển khai Lean tổng hợp của Avari và cộng sự 2011 64

2.6.7 Phân tích so sánh và lựa chọn mô hình 70

CHƯƠNG 3: PHƯƠNG PHÁP NGHIÊN CỨU 73

3.1 Chiến lược nghiên cứu định tính 73

3.2 Thiết kế nghiên cứu tình huống 74

3.3 Thiết kế nghiên cứu 77

3.4 Phương pháp thu thập dữ liệu 78

3.5 Phương pháp phân tích dữ liệu và lý giải 82

3.6 Xác minh 83

CHƯƠNG 4: KẾT QUẢ 84

4.1 Xem xét các nguyên tắc Lean áp dụng trong SXPM 84

4.2 Đánh giá tính khả thi của mô hình triển khai Lean 87

4.2.1 Giai đoạn điều tra ban đầu 87

4.2.2 Giai đoạn 1: Chuẩn bị 88

4.2.3 Giai đoạn 2: triển khai phương pháp Lean cho dự án thí điểm 89

4.2.4 Giai đoạn 3: Mở rộng cho toàn hệ thống 91

4.2.5 Giai đoạn 4: Tiến tới sự hoàn hảo 92

4.3 Về thời gian triển khai 95

4.3.1 Thời gian triển khai dự án thí điểm 95

4.3.2 Thời gian triển khai Lean cho toàn công ty 96

4.4 Khó khăn và thử thách khi triển khai phương pháp Lean 97

CHƯƠNG 5: KẾT LUẬN 101

5.1 Trả lời câu hỏi nghiên cứu 101

5.2 Hạn chế của nghiên cứu 103

5.3 Hướng nghiên cứu tiếp theo 103

TÀI LIỆU THAM KHẢO 105

PHỤ LỤC 108

PHỤ LỤC 1: Thông tin chuyên gia Đoàn Đức Đề (mã CG1) 108

PHỤ LỤC 2: Thông tin chuyên gia Ngô Sơn Dương (mã CG2) 110

PHỤ LỤC 3: Thông tin Thạc sĩ Ngô Nguyễn Lộc Nguyên (mã ThS1) 114

PHỤ LỤC 4: Thông tin chuyên gia Trương Đắc Bình (mã CG4) 116

PHỤ LỤC 5: Nội dung thảo luận CG1 118

PHỤ LỤC 6: Nội dung thảo luận CG2 124

PHỤ LỤC 7: Nội dung thảo luận ThS1 135

PHỤ LỤC 8: Nội dung thảo luận CG4 146

PHỤ LỤC 9: Bảng câu hỏi bán cấu trúc 157

PHỤ LỤC 10: Bảng tổng hợp các nguyên tắc Lean 160

PHỤ LỤC 11: Những đề xuất cho nhà lãnh đạo khi chuyển đổi Lean 162

DANH MỤC BẢNG BIỂU

Bảng 2-1: Lịch sử phát triển của phương pháp linh hoạt và các tác giả nổi tiếng 21

Bảng 2-2: Tuyên ngôn của phương pháp lập trình linh hoạt 22

Bảng 2-3: 12 nguyên tắc sau bản tuyên ngôn lập trình linh hoạt 23

Bảng 2-4: Sự khác biệt cơ bản giữa mô hình truyền thống và linh hoạt 26

Bảng 2-5: Đặc điểm, điểm mạnh và điểm yếu của SX truyền thống và linh hoạt 27

Bảng 2-6: Những thực hành hiện tại và đề nghị thực hành Lean theo lĩnh vực 31

Bảng 2-7: Sự khác biệt giữa Lean và Agile về triết lý cốt lõi 33

Bảng 2-8: Các Nguyên tắc Lean của Liker & Morgan 2006 36

Bảng 2-9: Các nguyên tắc sản xuất Lean trong sản xuất phần mềm 40

Bảng 2-10: Lãng phí trong sản xuất và lãng phí trong SXPM 41

Bảng 2-11: Các công cụ và thực hành tương ứng với các nguyên tắc Lean 47

Bảng 2-12: Tóm tắt các nguyên tắc Lean trong SXPM 53

Bảng 2-13: So sánh ưu, nhược điểm của các mô hình 71

Bảng 3-1: Các phương pháp nghiên cứu định tính (Myers, M.2000) 73

Bảng 3-2: Chiến lược lựa chọn tình huống đơn lẻ hoặc đa tình huống 74

Bảng 3-3: Sự khác biệt giữa thảo luận trong NC định tính và NC định lượng 79

Bảng 3-4: Các bước phân tích dữ liệu và lý giải 82

DANH MỤC HÌNH

Hình 2-1 Các mô hình sản xuất phần mềm được sử dụng rộng rãi 16

Hình 2-2: Mô hình thác nước (Waterfall) 18

Hình 2-3: Độ phân tán của dự án 20

Hình 2-4: Phương pháp phát triển linh hoạt (SCRUM) 25

Hình 2-5: Lịch sử phát triển các mô hình sản xuất 29

Hình 2-6: Các lĩnh vực áp dụng Lean và các thực hành được đề nghị 31

Hình 2-7: Các nguyên tắc Lean của Womack and Jones 2003 35

Hình 2-8: Ví dụ về hệ thống Kéo, Kanban trong SXPM 50

Hình 2-9: Mô hình chuyển đổi Lean của Phillip Magnier 2008 55

Hình 2-10: Ba giai đoạn và 21 bước triển khai Lean 62

Hình 2-11: Các giai đoạn chuyển đổi Lean trong ngành CNTT (Kotter 2011) 63

Hinh 2-12: Mô hình triển khai Lean tổng hợp của Avari và cộng sự 2011 66

Hình 3-1: Quy trình nghiên cứu 78

Hình 4-1: Các công việc được thể hiện trong một bảng Kanban 90

Hình 4-2: Mô hình chuyển đổi Lean sau điều chỉnh (Anvari và cộng sự, 2011) 94

Hình 4-3: Ví dụ về công cụ phần mềm “Kanban board” 100

DANH MỤC TỪ/THUẬT NGỮ VIẾT TẮT

STT Từ viết

1 ASDM Agile software development

method

Phương pháp phát triển phần mềm linh hoạt

2 CI Continuous improvement Cải tiến liên tục

4 CMMI Capability Maturity Model

Integration

Mô hình đánh giá mức độ tăng trưởng và năng lực tổ chức về mặt quy trình

5 JIT Just in time Đúng thời gian

6 LSD Lean software development Phát triển/Sản xuất phần mềm

tinh gọn

7 LPO Lean promotion Office Một nhóm chuyển đổi Lean,

nhóm này cung cấp cho các nhà quản lý giá trị dòng hỗ trợ kỹ thuật với:

• Đào tạo Lean

• Tiến hành hội thảo kaizen

• Đo lường sự tiến bộ, tiến trình

8 SCRUM Scrum Tên một phương pháp phát triển

Thiết lập mục tiêu định hướng các hoạt động liên quan hoặc tương tác với nhau mà biến đổi đầu vào thành đầu ra trong bối cảnh phát triển công nghệ phần mềm (ISO / IEC 12207)

16 VSM Value Stream Mapping Sơ đồ chuỗi giá trị

17 XP Extreme programming Lập trình cực đại

CHƯƠNG 1: GIỚI THIỆU ĐỀ TÀI

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

Ngành công nghiệp phần mềm đã và đang đóng góp to lớn cho nền kinh tếViệt Nam.Tổng doanh thu công nghiệp CNTT Việt Nam năm 2012 đạt 25,5 tỷ USD, tăng tới 86% so với năm 2011, theo số liệu của Sách trắng về CNTT-TT 2013 vừa được Bộ TT&TT công bố tháng 7/2013 Theo đó, công nghiệp phần mềm đối mặt với nhiều khó khăn do ảnh hưởng của kinh tế trong nước và thị trường nội địa nên tốc độ tăng trưởng năm 2012 không còn giữ được mức như các năm trước, chỉ tăng 3,1% so với năm 2011, đạt trên 1,2 tỷ USD Quy mô ngành công nghiệp phần mềm tính tới tháng 04/2011: có hơn 1.000 doanh nghiệp phần mềm, tăng gần sáu lần so với năm 2000, tổng số lao động ngành công nghiệp phần mềm là 64.000 người Một

số doanh nghiệp có trên 1.000 lao động như FPT Software, TMA Solutions, CSC, GCS, Logigear, Harvey Nash, VinaGame

Theo công bố của viện công nghệ SEI (2013), Việt Nam đã có 4 doanh nghiệp đạt chứng chỉ cao nhất về quy trình quản lý chất lượng sản xuất phần mềm quốc tế CMMI mức 5, 23 doanh nghiệp đạt CMM mức 3

Tuy nhiên trong bài phân tích “Công nghiệp phần mềm Việt Nam mười năm thăng trầm” (Hồng Nhung-Tuyết Ân, 2011), tác giả đã phỏng vấn các giám đốc điều hành của các công ty phần mềm lớn tại Việt Nam như: TMA, Global CyberSoft, FPT, GSC, và nhận thấy thực trạng ngành phần mềm Việt Nam phát triển chưa tương xứng với tiềm năng và kỳ vọng Hiện Việt Nam chưa có doanh nghiệp phần mềm

đủ tầm để phát triển các sản phẩm phần mềm ở quy mô lớn và chuyên ngành, cũng chưa có sản phẩm có thương hiệu xuất khẩu Một phần lý do được đưa ra là phương thức sản xuất chưa có sự thay đổi để đáp ứng với điều kiện kinh tế ngày càng cạnh tranh

Trong những năm qua, nhiều "Phương thức sản xuất phần mềm tốt nhất" đã xuất hiện và biến mất Một loạt các phương thức mới xuất hiện từ những năm 1990 là

phương thức sản xuất linh hoạt (Agile methodologies) như AUP, Scrum, XP, RUP,

và Lean (2003) Phát triển phần mềm tinh gọn (Lean) là một mô hình mới nổi thừa

kế các nguyên tắc Lean trong sản xuất để giảm thiểu chi phí và nâng cao chất lượng theo thời gian Lean manufacturing đã được áp dụng thành công đối với các công ty sản xuất, vậy đối với phát triển phần mềm thì như thế nào? Và liệu các nguyên tắc

và thực hành sản xuất linh hoạt Lean có phải là một phương thức sản xuất tốt để tạo

ra sản phẩm phần mềm chất lượng trong điều kiện cạnh tranh ngày càng gay gắt? Thật khó có thể đưa ra kết luận, phương thức sản xuất nào tốt phụ thuộc vào việc so sánh nó với phương pháp nào, trong hoàn cảnh nào

Phương pháp truyền thống phát triển phần mềm dựa trên các nguyên tắc sản xuất, các nguyên tắc này được định nghĩa là việc tạo ra hoặc sản xuất một cách cơ học, hoặc sự biến đổi của nguyên liệu thô thành sản phẩm hoàn chỉnh trong khi đó phương pháp sản xuất tinh gọn là một phương pháp mới nổi thừa kế các nguyên tắc Lean trong sản xuất và các nhà nghiên cứu cũng như các chuyên gia trong lĩnh vực SXPM chưa có nhiều nghiên cứu quan tâm đến nguyên tắc Lean cho lĩnh vực này

Do đó, có một nhu cầu mạnh mẽ cho các nghiên cứu thực nghiệm trong lĩnh vực

này, đề tài “Đề xuất mô hình sản xuất phần mềm theo Lean, một nghiên cứu tình

huống tại thành phố Hồ Chí Minh” Bài nghiên cứu này có thể coi là điểm khởi

hành vì nó tổng hợp và các công trình nghiên cứu, những đóng góp quan trọng nhất được cập nhật cho tới thời điểm hiện nay

1.2 Mục tiêu nghiên cứu và câu hỏi nghiên cứu

Quá trình phát triển PM như Capability Maturity Model Integrated của Viện Kĩ nghệ phần mềm Mỹ (SEI) và tiêu chuẩn ISO9000/9001 được hình thành để chuẩn hóa quy trình phát triển phần mềm Các nguyên tắc và tính chuyên nghiệp đã được

mô tả như là viên đạn bạc Phương pháp tiếp theo cho thấy triển vọng là các nguyên tắc của Nhật Bản về chất lượng Với việc bổ sung các nguyên tắc Lean, mô hình sản xuất truyền thống đã được hoàn thiện hơn (Mah 2008) Tuy đã phát triển nhiều phương pháp SXPM nhưng các dự án hiện nay vẫn còn tồn đọng những vấn đề

nghiêm trọng như trong những năm 80 như giao hàng trễ hạn và yêu cầu khách hàng chưa được thực hiện (Mah.M,2008) Hầu hết các nhà nghiên cứu đều cho rằng không có phương pháp duy nhất có thể giải quyết tất cả sự phức tạp trong phát triển phần mềm (Brooks 1995) Điều đó dẫn tới một câu hỏi là vậy phương pháp sản xuất nào đem lại hiệu quả tốt nhất?

Câu hỏi nghiên cứu

Mục đích của nghiên cứu này nhằm trả lời các câu hỏi nghiên cứu sau:

1 Sự khác biệt giữa các nguyên tắc và kỹ thuật, công cụ của mô hình sản xuất phần mềm truyền thống và sản xuất phần mềm linh hoạt là gì?

2 Các nguyên tắc và thực hành (kỹ thuật, công cụ) Lean trong sản xuất phần mềm

- Đưa ra các gợi ý về nguyên tắc và thực hànhLean trong SXPM

- Đưa rađược mô hình chuyển đổi Lean và các khó khăn có thể gặp phải cho một công ty SXPM tại thành phố Hồ Chí Minh sau khi lấy ý kiến một số chuyên gia

Dựa trên các kết quả nghiên cứu của nhiều tác giả trên thế giới và đóng góp của những cá nhân tham gia nghiên cứu chúng tôi sẽ đưa ra những nguyên tắc và mô hình để giúp các nhà quản lý có sự lựa chọn đúng đắn hơn

1.3 Phạm vi, giới hạn đề tài

Bài nghiên cứu này sẽ tập trung vào tìm hiểu các phương thức sản xuất phần mềm theo phương pháp truyền thống và phương pháp Lean, các nguyên tắc, thực hành và công cụ triển khai Lean và các nguyên tắc cũng như là các công cụ và kỹ thuật phù

hợp khi áp dụng Lean cho các công ty sản xuất phần mềm ở khu vực thành phố Hồ Chí Minh

Phân tích tập trung vào quá trình chuyển đổi của một công ty SXPM từ phương pháp sản xuất truyền thống sang sản xuất phần mềm tinh gọn (Lean software development) Quá trình bàn giao và duy trì sau khi triển khai sẽ không được phân tích trong bài, đồng thời bài nghiên cứu cũng tập trung vào các nhóm phát triển phần mềm chứ không phải là cách thiết kế PM và kiến trúc hệ thống Nghiên cứu này cũng không phân loại các dạng dự án như phát triển hay duy trì mà chỉ tập trung vào quá trình chuyển đổi sang phương pháp Lean của một công ty SXPM bất

kì tại thành phố HCM

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

Mục đích của nghiên cứu này là cung cấp một điểm khởi đầu, một đánh giá định tính các lý thuyết và mô hình nghiên cứu đi trước nhằm so sánh sự khác biệt và đưa

ra một mô hình tổng quát cho các công ty muốn triển khai áp dụng Lean để giảm thiểu lãng phí, nâng cao năng suất và chất lượng theo thời gian

Với thời gian cho phép, phương pháp thu thập dữ liệu cho bài nghiên cứu này là thu thập các dữ liệu thứ cấp, các lý thuyết có liên quan cũng như các bài nghiên cứu trước của các tác giả khác nhau để đưa ra mô hình chung nhất cho phương pháp Lean trong phần mềm

- Đối với phương pháp truyền thống chúng tôi sử dụng các nguyên tắc của phát triển phần mềm truyền thống theo tiêu chuẩn ISO và CMMI được Viện

kỹ nghệ phần mềm Mỹ (SEI) xây dựng và phát triển cho tới hiện nay

- Phương pháp Lean là mới trong lĩnh vực SXPM và không có nguyên tắc Lean tinh khiết vì vậy chúng tôi sẽ tập hợp các nguyên tắc Lean từ các tác giả nổi tiếng khác nhau có liên quan đến SXPM và hợp nhất chúng lại để sử dụng cho nghiên cứu này

Sau đó sẽ tiến hành so sánh, phân tích giữa phương pháp truyền thống và phương pháp Lean có gì khác biệt và đưa ra mô hình chung cho việc áp dụng phương pháp

SXPM theo Lean và sẽ thu thập dữ liệu sơ cấp bằng cách lấy ý kiến các chuyên gia trong ngành phần mềm tại thành phố Hồ Chí Minh để xem xét khả năng triển khai

áp dụng Lean cho các công ty phần mềm khu vực này

Các tiêu chí lựa chọn các báo cáo, bài nghiên cứu như sau:

• Các bài nghiên cứu,báo cáo liên quan đến phương pháp SXPM tinh gọn

• Các bài báo, nghiên cứu về phương pháp sản xuất phần mềm truyền thống

• Các nguồn thông tin uy tín, bài báo cáo nghiên cứu được đăng trên các tạp chí chuyên ngành

• Tài liệu tham khảo từ các chuyên gia trong lĩnh vực phần mềm

Đây là một mô hình mới, chưa được triển khai tại Việt Nam nên phương pháp nghiên cứu định tính này sẽ làm nền tảng cho các nghiên cứu sau trong lĩnh vực phần mềm tại Việt Nam

1.5 Ý nghĩa của nghiên cứu

Nguyên tắc Lean cho các dự án phát triển phần mềm đã được các công ty trên thế giới áp dụng từ hơn mười năm trước khi nghiên cứu đầu tiên của Alhastrom và cộng

sự năm 1996, 1998 và năm 2003 Mary và Tom Poppendiek cũng đã đưa ra những khái niệm của mình về Lean trong SXPM Và sau đó, nhiều tác giả đã thực hiện nghiên cứu và triển khai áp dụng Lean trong phần mềm như Middleton và cộng sự(2005), Poppendieck& Poppendieck (2006), Kenji Hiranabe (2008), Naftanalla Ionel (2009), Er.Kirtesh Jailia và cộng sự (2011), Joey Cho (2010), Mohammad Shahidul Islam (2013) Hiện nay, Việt Nam cũng có một số các diễn dàn (Forum) của các chuyên gia trong lĩnh vực phần mềm đã bàn bạc, thảo luận về các nguyên tắc Lean như Hà Nội Scrum, Leansixsigma Tuy nhiên về lĩnh vực nghiên cứu Lean cho phần mềm tại Việt Nam theo tìm hiểu của chúng tôi thì vẫn chưa có Vì vậy:

Về mặt lý thuyết, nghiên cứu này sẽ đóng góp thêm vào nền tảng kiến thức các phương pháp SXPM một phương pháp SXPM mới đó là SXPM tinh gọn (Lean software development), đồng thời đưa ra được các nguyên tắc, công cụ và thực hành Lean một cách tổng quát

Về thực tiễn, nghiên cứu này sẽ là một nền tảng để các công ty tại thành phố Hồ Chí Minh có thể lựa chọn một mô hình triển khai bao gồm những nguyên tắc, thực hành

và công cụ phù hợp nhất của Lean trong ngành SXPM để tạo ra sản phẩm phần mềm có chất lượng tốt hơn với chi phí, thời gian là thấp nhất

1.6 Bố cục luận văn

Bài nghiên cứu này sẽ bao gồm 6 phần

- Chương 1: Giới thiệu

Phần này sẽ giới thiệu toàn cảnh ngành công nghiệp phần mềm Việt Nam nhấn mạnh lí do tại sao có nghiên cứu này cũng như là mục tiêu nghiên cứu,

ý nghĩa nghiên cứu, đối tượng nghiên cứu, giới hạn, phạm vi đề tài

- Chương 2: Lý thuyết

Giới thiệu các khái niệm liên quan tới mô hình phát triển phần mềm Các lý thuyết về sản xuất tinh gọn (Lean manufacturing), các lý thuyết liên quan tới phát triển phần mềm Các nguyên tắc và thực hành phát triển phần mềm linh hoạt (Lean) của các tác giả khác nhau trên thế giới và tổng hợp, đưa ra các nguyên tắc và thực hành Lean chung nhất áp dụng cho sản xuất phần mềm sau khi xem xét các nghiên cứu trước

Đưa ra và lựa chọn mô hình triển khai Lean cho công ty sản xuất PM

- Chương 3: Phương pháp nghiên cứu

Đưa ra mô hình nghiên cứu, cách thức thu thập, xử lí dữ liệu nghiên cứu

- Chương 4:Phân tích các nguyên tắc và mô hình triển khai Lean

Đưa ra sự khác biệt giữa các nguyên tắc và thực hành sản xuất phần mềm truyền thống và sản xuất phần mềm theo Lean

Phân tích và so sánh giữa kết quả phỏng vấn các chuyên gia trong lĩnh vực phần mềm với kết quả của mô hình đưa ra từ nghiên cứu lý thuyết

- Chương 5: Kết luận

Đưa ra kết luận chung và hạn chế của nghiên cứu, đề xuất hướng nghiên cứu tiếp theo, những thuận lợi và khó khăn khi triển khai Lean cho các công ty SXPM tại thành phố Hồ Chí Minh

- Những phụ lục đính kèm

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

2.1 Phần mềm và các khái niệm liên quan

2.1.1 Phần mềm

Định nghĩa

Phần mềm là một tập hợp những câu lệnh hoặc chỉ thị (Instruction) được viết bằng một hoặc nhiều ngôn ngữ lập trình theo một trật tự xác định, và các dữ liệu hay tài

liệu liên quan nhằm tự động thực hiện một số nhiệm vụ hay chức năng hoặc giải

quyết một vấn đề cụ thể nào đó (Pressman, 1997, trích luận văn Mai Nguyen, 2006)

Đặc tính chungcủa phần mềm

Là hàng hóa vô hình không nhìn thấy được

Chất lượng phần mềm không mòn đi mà có xu hướng tốt lên sau mỗi lần có lỗi được phát hiện và sửa lỗi

Phần mềm vốn chứa lỗi tiềm tàng theo quy mô càng lớn thì khả năng chứa lỗi càng cao

Lỗi phần mềm dễ được phát hiện bởi người dùng

Qui trình phát triển phần mềm (Software Development/Engineering Process - SEP)

là phương pháp phát triển hay sản xuất ra sản phẩm phần mềm

Quy trình phần mềm (vòng đời phần mềm) được chia thành các giai đoạn chính:

SEP có tính chất quyết định để tạo ra sản phẩm chất luợng tốt với chi phí thấp và năng suất cao, có ý nghĩa quan trọng đối với các công ty sản xuất hay gia công phần mềm

Do tính chất của phần mềm là một sản phẩm vô hình, phức tạp và rất khó để quản

lý, do đó việc nghiên cứu quy trình phát triển phần mềm là một trong những lĩnh vực nghiên cứu quan trọng trong lĩnh vực này.Một quá trìnhphần mềm có thểđược coi làmột bộ công cụ, phương pháp và thực hành được sử dụngđể sản xuất mộtsản phẩm phần mềm (Humphrey, 2006) Theo thời gian, nhu cầu của khách hàng về chức năng và chất lượng liên tục phát triển dẫn đến nhu cầu biến động cao đòi hỏi các công ty phần mềm để có tính linh hoạt cao Vì vậy, ngày càng nhiều công ty phần mềm bắt đầu áp dụng phương pháp gia tăng và linh hoạt như Scrum, Lean software development, Kanban, XP, Theo kết quả khảo sát của Forrester tháng 11 năm 2011, các phương pháp sản xuất được sử dụng rộng rãi nhất được thể hiện trong hình sau:

Hình 2-1 Các mô hình sản xuất phần mềm được sử dụng rộng rãi

Forrester đã công bố kết quả nghiên cứu sau cuộc khảo sát mang tên “Làm thế nào

để thực hiện phát triển linh hoạt trong tổ chức của bạn?” Nghiên cứu này được thực hiện thông qua khảo sát trực tuyến 205 công ty phần mềm đã và đang thực hiện

phần mềm linh hoạt trên thế giới, chấp nhận các câu trả lời có nhiều hơn một lựa chọn Cuộc khảo sát này đem lại một sự hiểu biết tốt về cách thức các công ty thực hiện phát triển phần mềm linh hoạt trên thế giới chứ không chỉ là sự tiếp nhận mô hình phát triển linh hoạt Kết quả khảo sát đưa ra những con số khá thú vị, tỷ lệ các

dự án theo mô hình linh hoạt (224%) cao gấp đôi so với mô hình truyền thống (102.9%), điều này chứng tỏ xu hướng phát triển của mô hình linh hoạt (Scrum, TDD, Kanban, XP, LSD) đang dần chiếm ưu thế so với mô hình truyển thống (Waterfall và lặp)

Định nghĩa thực hành tốt nhất (Best practice)

Một thực hành tốt nhất của Lean Manufacturing/Lean software development được định nghĩa là kỹ thuật của hệ thống tinh gọn, tức là một công cụ, một thủ tục hoặc một tập hợp các hành động nhằm cải thiện năng suất và/hoặc giảm chi phí Do đó,

số lượng thực hành tốt nhất càng cao thì mức độ trưởng thành hệ thống Lean là càng cao (Alessandro Incisa & Ruggero Moretto 2013)

2.2 Tổng quan mô hình phát triển truyền thống

SDLC còn được gọi là chu trình hay vòng đời phát triển phần mềm (SDLC –Software Development Life Cycle) SDLC là tập hợp các công việc và quan hệ giữa chúng với nhau diễn ra trong quá trình phát triển phần mềm Có khá nhiều mô hình SDLC khác nhau, trong đó một số được ứng dụng khá phổ biến trên thế giới như bên dưới

2.2.1 Mô hình thác nước (Waterfall)

Là một mô hình của quy trình phát triển phần mềm cổ điển nhất, Royce (1970) đã định nghĩa quá trình phát triển có cấu trúc và tuần tự trông giống như một dòng chảy, với các pha được thực hiện theo trật tự nghiêm ngặt và không có sự quay lui hay nhảy vượt pha, bao gồm các giai đoạn phân tích yêu cầu, thiết kế, triển khai thực hiện, kiểm thử, liên kết và bảo trì

Hình 2-2: Mô hình thác nước (Waterfall)

1 Phân tích các yêu cầu:

Phân tích hệ thống dịch vụ, khó khăn và mục tiêu về sản phẩmmà người dùng mong muốn, được hình thành bởi sự gợi ý về hệ thống của chuyên gia phân tích và hiểu biết người dùng Sau đó các yếu tố này được định nghĩa sao cho có thể hiểu được bởi cả người phát triển và người sử dụng

2 Thiết kế phần mềm và hệ thống

Thiết kế hệ thống các quá trình, các bộ phận và các yêu cầu về cả phần mềm lẫn phần cứng Hoàn tất hầu như tất cả kiến trúc của các hệ thống này Thiết kế phần mềm tham gia vào việc biểu thị các chức năng hệ thống phần mềm mà có thể được chuyển dạng thành một hay nhiều chương trình khả thi

3 Thực hiện và thử nghiệm đơn vị:

Trong giai đoạn này, thiết kế phần mềm phải được chứng thực như là một tập hợp nhiều chương trình hay nhiều đơn vị nhỏ Thử nghiệm đơn vị bao gồm xác minh rằng mỗi đơn vị thỏa mãn đặc tả của nó

4 Tổng hợp và thử nghiệm toàn bộ:

Các đơn vị chương trình riêng lẻ hay các chương trình được tích hợp lại và thử nghiệm như là một hệ thống hoàn tất và chứng tỏ được các yêu cầu của phần mềm được thỏa mãn Sau khi thử nghiệm phần mềm được cung ứng cho người tiêu dùng

5 Cài đặt và bảo trì:

Thông thường (nhưng không bắt buộc) đây là giai đoạn lâu nhất của chu kỳ sống (của sản phẩm) Phần mềm được cài đặt và được dùng trong thực tế Bảo trì bao gồm điều chỉnh các lỗi mà chưa được phát hiện trong các giai đọan trước của chu kì sống, nâng cấp sự thực hiện của hệ thống các đơn vị và nâng cao hệ thống dịch vụ cho là các phát hiện vê yêu cầu mới

Mô hình thác nước tinh khiết thực hiện tốt cho các sản phẩm với các yêu cầu

được hiểu rõ ràng ngay từ đầu dự án và các công cụ kỹ thuật, kiến trúc và cơ sở hạ tầng Điểm yếu của nó là không giao tiếp thường xuyên với khách hàng cũng như ít giao tiếp trong đội dự án làm cho nó không linh hoạt khicần có thay đổi hoặc sản phẩm cần sự phát triển một cách nhanh chóng khi yêu cầu chưa rõ ràng ngay từ đầu Nhận thấy những điểm yếu đó, năm 1981, Boehm có mở rộng và sửa đổi mô hình thác nước tinh khiết thành mô hình thác nước sửa đổi sử dụng các giai đoạn tương

tự như cácthác nước tinh khiết nhưng cho phép các giai đoạn chồng lên nhau khi cần thiết Thác nước tinh khiết khi đó có thể chia thành các tiểu dự án ở giai đoạn thích hợp

Điểm yếu của mô hình này là nó không linh hoạt, rất nhiều các tài liệu phải tạo ra trong suốt quá trình phát triền của dự án như tài liệu đặc tả, tài liệu thiết kế kiến trúc, tài liệu thiết kế chi tiết, các báo cáo kiểm tra chất lượng, các báo cáo của trưởng dự án, nhân viên kiểm tra chất lượng, Các bộ phận của dự án chia ra thành những bộ phận riêng theo giai đoạn Hệ thống khi cài đặt đôi khi không dùng được

vì không thỏa mãn được yêu cầu của khách hàng Mặc dù vậy mô hình này phản ảnh thực tế công nghệ, đây vẫn là mô hình cơ sở cho đa số các hệ thống phát triển phần mềm

2.2.2 Những thất bại của mô hình truyền thống

Một nghiên cứu thú vị được thực hiện bởi Standish Group trong 8,380 dự án từ năm

2002 đến năm 2010 cho 2 phương pháp truyền thống và linh hoạt Người trả lời đại diện cho các công ty phần mềm lớn cho thấy chỉ có một tỷ lệ nhỏ các dự án (14%) với các phương pháp truyền thống đã được hoàn thành đúng thời gian và kinh phí với tất cả các tính năng và chức năng yêu cầu 29% số dự án đã được hoàn thành vượt ngân sách, vượt quá thời gian cho phép và cung cấp ít tính năng hơn,57% số

dự án đã bị hủy bỏ tại một số điểm trong chu kỳ phát triển hoặc thử thách (Standish Group, 2010) Hình bên dưới hiển thị kết quả của nghiên cứu Nghiên cứu này cũng cho thấy một tỷ lệ khả quan hơn thuộc về các dự án linh hoạt, có 42% các dự án công đã được hoàn thành đúng thời gian, về ngân sách và với tất cả các tính năng và chức năng ban đầu được xác định Hơn nữa, nghiên cứu cho thấy tỷ lệ thất bại là 9% thấp hơn 3 lần so với mô hình truyền thống là 29%

Hình 2-3: Độ phân tán của dự án Một số điểm mạnh của mô hình truyền thống

- Tạo ra một hình ảnh chung về hệ thống trước khi phát triển

- Dễ dàng cho các nhà phát triển hiểu hệ thống và làm theo

Một số vấn đề chính (điểm yếu) của mô hình truyền thống

- Thay đổi yêu cầu thì không được chào đón, việc thay đổi yêu cầu chỉ được phép trong quá trình thu thập và phân tích yêu cầu

- Việc xác nhận thì không được thực hiện đầy đủ, lỗi của giai đoạn trước có thể bị ẩn giấu và gia tăng trong các giai đoạn tiếp theo Trong hấu hết các trường hợp thì lỗi được phát hiện trễ trong giai đoạn kiểm nghiệm nên chi phí sửa lỗi và làm lại là rất cao

- Nhận phản hồi của khách hàng chậm trễ dẫn đến làm không đúng yêu cầu, không thỏa mãn được những thay đổi khách hàng

Để giải quyết một số những sai phạm của các phương pháp truyền thống , phương pháp linh hoạt đã được đề xuất (Beck và cộng sự 2001)

2.3 Các mô hình phát triển phần mềm linh hoạt

2.3.1 Tổng quan về phát triển phần mềm linh hoạt

Các mô hình phát triển linh hoạt được một nhóm các kỹ sư phần mềm đưa ra nhằm khắc phục những hạn chế của mô hình SX truyền thống SXPM linh hoạt là quy trình mà trong đó cấu trúc khởi động ban đầu sẽ nhỏ nhưng linh động và lớn dần của các đề án phần mềm nhằm tìm ra các khó khăn trước khi nó trở thành vấn đề có thể dẫn tới những hủy hoại Quy trình này nhấn mạnh sự gọn nhẹ và tập trung hơn

là các phương pháp truyền thống Các quy trình linh hoạt dùng các thông tin phản hồi thay vì dùng các kế hoạch như là một cơ chế điều khiển chính William và Cockburn (2003) đề cập đến việc lập trình eXtreme (XP), Scrum, Crystal và phát triển phần mềm thích ứng (ASD) đã được phát triển ở Mỹ bởi Ken Beck và Eric Gamma, Ken Schwaber và Jeff Sutherland, Alistair Cockburn và Jim Highsmith Bảng dưới cho thấy tên các quốc gia và người sáng lập kết hợp với các phương pháp sản xuất phần mềm linh hoạt khác nhau

Bảng 2-1: Lịch sử phát triển của phương pháp linh hoạt và các tác giả nổi tiếng

Khu vực Phương pháp linh hoạt Tác giả (năm)

Crystal Methods Alistair Cockburn (2004)Adaptive Software Development

(ASD)

Jim Highsmith (2004)

Lean Software Development Tom and Mary Poppendieck

(2003)Châu Âu Dynamic Systems

Development Method (DSDM)

Dane Faulkner (1994)

Châu Úc Feature Driven Development (FDD) Peter Code, Jeff DeLuca

(1999)

Tuyên ngôn và nguyên tắc của lập trình linh hoạt (Beck và cộng sự, 2001)

Liên minh linh hoạt tin rằng cách tốt nhất để sản xuất ra sản phẩm phần mềm tốt là

đề cao các giá trị bên trái hơn so với các giá trị truyền thống bên phải

Bảng 2-2: Tuyên ngôn của phương pháp lập trình linh hoạt

Phương pháp linh hoạt Phương pháp truyền thống

Phần mềm làm việc được Tài liệu hoàn chỉnh

Như thể hiện trong bảng trên, phương pháp linh hoạt tập trung (1) vào các cá nhân

và tương tác hơn là các quy trình và công cụ, (2) phần mềm làm việc hơn là tài liệu hoàn chỉnh, (3) sự hợp tác của khách hàng nhiều giá trị hơn so với đàm phán hợp đồng và (4) ập trung vào ứng phó với thay đổi hơn là lên một kế hoạch hoàn chỉnh

Đó là bản tuyên ngôn của phương pháp sản xuất linh hoạt (Beck và cộng sự 2001)

Các đội dự án tập trung vào phát triển lặp và tăng dần giá trị, những gì được chia sẻ giữa các phương pháp là nơi mà yêu cầu và các giải pháp phát triển thông qua sự hợp tác giữa việc tự tổ chức, các đội liên chức năng (Bjornvig và cộng sự 2010) Một trong những nhà phát triển phương pháp linh hoạt, Kent Beck (2001) đã phát triển tuyên ngôn linh hoạt thành mười hai nguyên tắc linh hoạt Các nguyên tắc này xác định các ý nghĩa cụ thể đằng sau bản tuyên ngôn Các nguyên tắc cụ thể được trình bày trong bảng sau:

Bảng 2-3: 12 nguyên tắc sau bản tuyên ngôn lập trình linh hoạt

(Beck và cộng sự 2001)

01 Ưu tiên cao nhất của chúng tôi là đáp ứng khách hàng thông qua giao các phần mềm có giá trị sớm và liên tục

02

Hoan nghênh yêu cầu thay đổi, thậm chí trong giai đoạn cuối của sự phát triển Quá trình linh hoạt khai thác thay đổi cho lợi thế cạnh tranh của khách hàng

03 Cung cấp phần mềm làm việc một cách thường xuyên, từ một vài tuần đến vài tháng, với ưu tiên cho các quãng thời gian ngắn

04 Khách hàng và nhóm phát triển phải làm việc cùng nhau hàng ngày trong dự án

05 Xây dựng các dự án dựa trên tôn trọng cá nhân Cung cấp cho họ môi trường

và hỗ trợ mà họ cần và tin tưởng họ để có được công việc làm

06 Phương pháp hiệu quả nhất trong việc truyền đạt thông tin trong một nhóm là cuộc trò chuyện face to face (gặp mặt trực tiếp)

07 Phần mềm làm việc là thước đo chính của tiến độ dự án

08 Quy trình linh hoạt thúc đẩy phát triển bền vững Các nhà đầu tư, nhà phát triển và người dùng sẽ có thể duy trì một tốc độ ổn định vô thời hạn

09 Kỹ thuật tốt và thiết kế tốt giúp tăng cường sự nhanh nhẹn

10 Đơn giản là nghệ thuật để tối đa hóa số lượng công việc không thực hiện là điều cần thiết

11 Kiến trúc tốt nhất, yêu cầu và thiết kế tốt xuất phát từ tự tổ chức của nhóm phát triển

12 Định kỳ, nhóm phát triển phản ánh về cách làm việc để trở nên hiệu quả hơn, sau đó điều chỉnh hành vi của mình cho phù hợp

2.3.2 Lập trình Scrum

Scrum là một trong 2 phương pháp linh hoạt được biết đến nhiều nhất Trong phát triển phần mềm theo Scrum, các giai đoạn được xúc tiến trong các bước cực nhỏ và liên tục so với các quy trình kiểu cũ Bước đầu tiên (với chủ định là không hoàn tất) cho đến các bước có thể chỉ tốn một ngày hay một tuần, thay vì phải tốn nhiều tháng như trong phương pháp thác nước Giai đoạn đầu người ta thực hiện việc thu thập các yêu cầu và chia nhỏ ra thành cách tính năng, sắp xếp độ ưu tiên cho các tính năng này Kế đến là giai đoạn thực hiện những vòng lặp nhỏ (Sprint), mỗi vòng lặp bao gồm các bước như chia nhỏ yêu cầu thành các công việc, thiết kế cấu trúc, thực thi, kiểm tra và bàn giao tính năng theo độ ưu tiên lúc đầu Thiết kế và kiến trúc được điều chỉnh và nâng cao sau mỗi vòng lặp, một vòng lặp thông thường kéo dài từ một đến bốn tuần Hình bên dưới thể hiện một vòng đời phát triển theo phương pháp Scrum

Hình 2-4: Phương pháp phát triểnlinh hoạt (SCRUM)

2.3.3 Sự khác nhau giữa mô hình truyền thống và mô hình linh hoạt

Có rất nhiều đặc điểm khác nhau giữa linh hoạt và truyền thống Theo nghiên cứu của Boehm (2002) có 9 sự khác biệt chính giữa phương pháp linh hoạt và truyền thống thể hiện trong bảng bên dưới Boehm cho rằng mục tiêu chính của việc sử dụng mô hình linh hoạt là cung cấp giá trị nhanh chóng, trong khi mục tiêu chính của mô hình truyền thống là về tính bảo đảm cao (thông qua hợp đồng, báo cáo, đặc

tả, cam kết, ) Theo ông mô hình linh hoạt là một lựa chọn tốt hơn khi yêu cầu chưa biết đến lúc bắt đầu của dự án, hoặc thay đổi nhanh chóng, trong khi mô hình truyền thống là tốt hơn khi yêu cầu được biết đến ở giai đoạn đầu của dự án và phần lớn ổn định trong suốt thời gian của dự án Liên quan đến sự tham gia của khách hàng, Boehm cho rằng mô hình linh hoạt cần sự hiểu biết và hợp tác của khách hàng trong khi mô hình truyền thống cần khách hàng tập trung hơn vào điều khoản hợp đồng Trong mô hình linh hoạt các nhà phát triển phải nhanh nhẹn, hiểu biết, đồng vị và hợp tác Trong mô hình truyền thống các nhà phát triển cần có kế hoạch định hướng

và có kỹ năng thích hợp để truy cập kiến thức bên ngoài Hơn một sự khác biệt rất

đáng chú ý là chi phí tái cấu trúc trong mô hình linh hoạt là rẻ hơn so với truyền thống Mô hình linh hoạt có những rủi ro chưa biết có thể có tác động lớn đến dự

án, trong khi các rủi ro trong mô hình truyền thống được tìm hiểu rõ ràng và vì thếtác động tác động nhỏ đến dự án Nhìn chung, như thể hiện trong bảng, Boehm tin các phương pháp phát triển phần mềm linh hoạt (ASDMs) nên được sử dụng cho các nhóm và các dự án nhỏ Nếu kích thước của các nhóm và các dự án lớn, ông gợi

ý sử dụng mô hình truyền thống

Bảng 2-4: Sự khác biệt cơ bản giữa mô hình truyền thống và linh hoạt

(Boehm, 2002)

Đặc điểm dự án Các mô hình truyền thống Các mô hình linh hoạt

1 Mục tiêu chính Tính đảm bảo cao Đáp ứng nhanh

Được thiết kế cho các yêu cầu hiện tại

5 Kế hoạch và

kiểm soát

Các bản kế hoạch được ghi nhận thành tài liệu và kiểm soát định lượng

Các bản kế hoạch nội bộ và kiểm soát định tính

6 Khách hàng

Chỉ tương tác với khách hàng khi cần thiết, tập trung vào các điều khoản trong hợp đồng

Tương tác với khách hàng thường xuyên trong suốt quá trình phát triển (Cần có sự tham gia của khách hàng)

Bảng 2-5: Đặc điểm, điểm mạnh và điểm yếu của SX truyền thống và linh hoạt

(Nguồn: Joey Cho, 2010)

Phương pháp truyền thống Phương pháp linh hoạt

Đặc điểm Kế hoạch tổng quát Lặp và gia tăng

Quá trình được hệ thống hóa Hợp tác với khách hàng Việc tái sử dụng chặc chẽ,

khắc khe Giao hàng thường xuyên Tài liệu nhiều Con người là trung tâm Thiết kế lớn ngay từ đầu Gọn nhẹ và vòng đời phát

Sự hài lòng khách hàng cao

Tỷ lệ lỗi thấp Thích ứng nhanh với sự thay đổi của khách hàng

Điểm yếu Đáp ứng thay đổi chậm Có thể đã bỏ bớt những tài

liệu quan trọng và phụ thuộc nhiều vào kỹ năng, kiến thức, kinh nghiệm con người

Có xu hướng vượt quá ngân sách

Chưa thử nghiệm cho những

dự án quan trọng

Có xu hướng trễ hạn cao Không thích hợp với dự án ổn

định Khó khăn khi tạo ra một bộ

đầy đủ các yêu cầu ngay từ đầu dự án

Có thể thành công chỉ với những người tài năng và thích

tự do Không thích hợp với dự án quy mô lớn

2.4 Phương pháp sản xuất Lean

Việc áp dụng Lean vào phát triển phần mềm linh hoạt là một khái niệm hữu ích, chủ yếu là vì nó cung cấp cơ hội sử dụng các khái niệm của Lean như loại bỏ lãng phí

và đưa ra chuỗi giá trị trong sản xuất phần mềm Phát triển phần mềm Lean thực chất là một bản dịch của Lean trong sản xuất vào sản xuất phần mềm (Bjornvig và cộng sự, 2010) Nhiều nguyên tắc Lean được chia sẻ giữa cộng đồng sản xuất linh hoạt và gần đây phát triển phần mềm Lean đã đạt được một danh tiếng vững chắc trong cộng đồng linh hoạt (Poppendieck và cộng sự 2003, 2006; Bjornvig và cộng

sự, 2010) Mục đích của phần tiếp theo là thiết lập một khuôn khổ phát triển phần mềm theo Lean bắt đầu với triết lý cốt lõi của sản xuất tinh gọn

2.4.1 Triết lí Lean

(Nguồn: http://www.strategosinc.com/) Hình 2-5: Lịch sử phát triển các mô hình sản xuất

Lean là một triết lý quản trị quá trình bắt nguồn từ hệ thống sản xuất Toyota (TPS) TPS được phát triển từ những năm 1950 trở đi Ohno quan sát thấy một nhu cầu cải thiện hệ thống sản xuất để cạnh tranh trong thị trường xe hơi hiện đang cạnh tranh gay gắt của Nhật Bản Mục tiêu chính của ông là để rút ngắn thời gian dẫn giữa lượng đặt hàng và xe hơi trong dây chuyền sản xuất (Ohno 1988) Thảo luận và đạt được cải tiến liên tục hiệu quả, ông đã phát minh thuật ngữ giá trị Giá trị được định nghĩa là bất kỳ hành động hoặc quá trình mà khách hàng sẽ sẵn sàng trả tiền Khách hàng trong định nghĩa này là bất cứ ai tiêu thụ sản phẩm hay dịch vụ Poppendieck

và cộng sự (2003) lập luận rằng cùng những định nghĩa này áp dụng cho sản xuất phần mềm, thiết kế, thử nghiệm trong một nỗ lực phát triển là không có giá trị cho đến khi khách hàng thu được giá trị từ việc bàn giao các tính năng sản phẩm phần mềm mới (Poppendieck và cộng sự 2003) Triết lý Lean cũng bao gồm loại bỏ lãng phí, loại bỏ bất cứ điều gì mà không mang lại giá trị cho khách hàng Nếu một hoạt động được xác định là lãng phí, nó nên được loại bỏ càng nhanh càng tốt

(Ohno1988) Khi lãng phí được loại bỏ, chất lượng được cải thiện và thời gian sản xuất, chi phí sản xuất giảm.

2.4.2 Lean trong sản xuất các sản phẩm khác (không phải phần mềm)

Vào giữa những năm 1940, công ty Toyota với nhu cầu nâng cao hiệu quả sản xuất

để cạnh tranh, đồng thời tại thời điểm đó ngành công nghiệp ô tô Mỹ có năng suất cao khoảng chín lần hơn Toyota (Ohno, 1988) Để tìm ra cách sản xuất hiệu quả hơn Toyota đã tiến hành xem xét phương pháp sản xuất của Mỹ, phương pháp sản xuất này được dựa trên suy nghĩ truyền thống đó là sản xuất hàng loạt (Wu và Wee, 2009) Tuy nhiên phương pháp này là không phù hợp với Toyota vì hạn chế về nhu cầu (Ohno,1988) Vì vậy Toyota sử dụng kết hợp lý thuyết Ford để tạo nên một phương pháp mới để sản xuất những chiếc xe và đặt tên là hệ thống sản xuất Toyota (TPS) Các nguyên tắc cần được thực hiện trong quá trình phát triển để đạt được việc loại bỏ lãng phí theo TPS là:

- Thiết lập dòng chảy công việc một cách liên tục

- Gia tăng giá trị từ nhu cầu để tránh dư thừa, lãng phí

- Loại bỏ sự quá tải của những người tham gia vào quá trình

- Ngăn ngừa các vấn đề chất lượng ngay sau khi phát hiện

- Sử dụng các phương pháp ổn định để duy trì khả năng dự đoán, sử dụng công nghệ để hỗ trợ người lao động cũng như sử dụng các công cụ trực quan

để làm nổi bật vấn đề

Hai trụ cột của triết lý quản lý TPS là"Tôn trọng con người" và "Cải tiến liên tục” Việc đầu tiên gia tăng giá trị cho các tổ chức là tôn trọng nhân viên, đối tác và khách hàng Sau đó là tổ chức áp dụng TPS cần tạo ra văn hoá cải tiến liên tục, bằng cách cho phép các nhà phát triển thử nghiệm, lặp lại và học hỏi

2.4.3 Các lĩnh vực sản xuất áp dụng phương pháp Lean

Bên dưới là kết quả nghiên cứu của Alessandro và cộng sự năm 2011 về các lĩnh vực được đề nghị áp dụng Lean và những thực hành được đề nghị cho từng lĩnh vực Trong đó sản xuất phần mềm hiện tại đang áp dụng 13 thực hành tốt nhất (13

best practices) và được đề nghị thêm 4 thực hành (best practices) khác để nâng cao hiệu quả sản xuất như sau

Bảng 2-6: Những thực hành hiện tại và đề nghị thực hành Lean theo lĩnh vực

Lĩnh vực

Số lượng các thực hành hiện tại

Số lượng các thực hành được

đề nghị

Tổng số các thực hành cho từng lĩnh vực

Chi tiết các thực hành và công cụ Lean được đề nghị áp dụng trong lĩnh vực phần mềm như sau:

Hiện tại:

1 Phương pháp tiếp cận Lean

2 Đồng bộ hóa các nhóm dự án/chuẩn hóa quy trình

3 Sự tham gia của khách hàng

4 Tối ưu hóa dòng chảy thông tin (giao tiếp)

5 Tập trung vào hiệu suất đầu ra/thành quả đầu ra

6 Kỹ thuật/thiết kế tinh gọn

7 Tinh gọn hệ thống phân phối

8 Xem dự án như là một hệ thống sản xuất tạm thời/nhất thời

9 Công cụ hỗ trợ trực quan/quản lý trực quan

10 Kaizen (Kaizen in product quality/reliability/Maintainability)

11 Quản lý yêu cầu một cách tinh gọn

12 Nâng cao, phát triển các nhóm đa chức năng

13 Niềm tin vào khả năng tự quản lý của nhóm

Đề xuất áp dụng:

1 Tổ chức hội thảo về Lean

2 Bài học kinh nghiệm Lean

3 Dịch vụ tinh gọn (Lean service)

4 Xu hướng xây dựng văn hóa Lean trong tổ chức

2.5 Sản xuất phần mềm theophương pháp Lean

Lean đã được triển khai áp dụng cho các công ty thuộc nhiều lĩnh vực khác nhau từ nhiều năm trước và những nguyên tắc, triết lí này được Mary và Tom Poppendieck

áp dụng vào lĩnh vực phần mềm từ năm 2003 Nhiều tác giả khác nhau đã cung cấp các nguyên tắc, thực hành Lean khác nhau, có thể kết luận rằng Lean không có nguyên tắc tinh khiết của nó Theo Curt Hibbs (2008) Lean trong sản xuất phần mềm không phải là các mệnh lệnh mà là các phân tích và mục tiêu mở, nó cung cấp

giá trị cho khách hàng với tốc độ nhanh hơn (chủ yếu thông qua việc loại bỏ các lãng phí) Trong phần này chúng tôi sẽ mô tả các nguyên tắc được đề cập của một

số tác giả nổi tiếng có khả năng áp dụng trong phát triển phần mềm

2.5.1 Sự khác biệt giữa phương pháp Lean và phương pháp Agile

Các mô hình linh hoạt nói chung như SCRUM, XP, RAP, có một số thuộc tính riêng biệt khác nhau tuy nhiên những thuộc tính nàychủ yếu đến từ các nguyên tắc

cơ bản của Lean nhằm giảm thiểu thời gian, chi phí sản xuất, công sức làm lại work), giảm sự lãng phí và tăng hiệu suất Tuy nhiên giữa SXPM linh hoạt và SXPM tinh gọn có những sự khác biệt cơ bản như sau

(re-Bảng 2-7: Sự khác biệt giữa Lean và Agile về triết lý cốt lõi

(Nguồn: Bjornvig và cộng sự, 2010)

1 Suy nghĩ và làm (Think and Do) Làm (Do)

2 Kiểm tra->Lên kế hoạch-> thực hiện Thực hiện -> Kiểm tra -> Lên kế hoạch

6 Tập trung vào quy trình Tập trung vào con người

7 Đội, nhóm (Làm việc như một đơn vị) Cá nhân và tương tác

8 Hệ thống phức tạp (Complicated) Hệ thống phức tạp (Complex)

9 Dựa vào tiêu chuẩn Kiểm tra và thích ứng

10 Làm lại trong thiết kế để bổ sung giá trị,

trong quá trình thì đó là lãng phí

Giảm thiểu việc làm trước của bất cứ loại nào và làm lại mã để có được chất lượng

11 Đưa ra các quyết định chuyển tiếp (Ma

2.5.2.1 Các nguyên tắc Lean trong sản xuất (Không phải SXPM)

Taiichi Ohno (1988) đã đưa ra 12 nguyên tắc trong đó

Loại bỏ lãng phí (O1) là nguyên tắc đầu tiên trong hệ thống sản xuất Toyota, ông cũng xác định 7 loại lãng phí trong sản xuất Nguyên tắc thứ hai là xây dựng chất lượng từ gốc (O2) hay làm đúng ngay từ đầu để giảm thiểu khuyết tật và chi phí sửa lỗi Để đảm bảo được các sản phẩm chất lượng, Ohno cũng đề xuất sử dụng máy móc tự động hóa (O3) trong sản xuất.Máy móc tự động hóa có thể làm giảm việc sản xuất thừa và mặc khác nó tối thiểu sản phẩm lỗi.Một nguyên tắc khác mà Ohno

đề xuất là giảm nhịp độ sản xuất (O4-slow growth production), ông không chủ trương sản xuất hàng loạt (mass production) vì nó đem lại nhiều sự lãng phí Dòng chảy quá trình (O5) là một nguyên tắc mà JIT được sử dụng để thiết lập nguyên tắc này Ngoài ra tối thiểu hóa chi phí (O6) sản xuất cũng là một nguyên tắc trong đó nhấn mạnh giá trị sản phẩm đem lại cho khách hàng, khuyến khích từ bỏ cách tính toán lợi nhuận truyền thống (Giá bán = Lợi nhuận + Chi phí thực tế) Nguyên tắc tiếp theo là trao quyền cho nhóm (O7) vàphát triển nhóm đa kỹ năng (O8) để nâng cao hiệu quả sản xuất Nguyên tắc 9 là cân bằng mức độ sản xuất (Production leveling) (O9), chuẩn hóa công việc, quy trình(O10), nhận diện nguồn gốc vấn đề (O11) nhằm đưa ra giải pháp có thể giải quyết triệt để vấn đề và xây dựng hệ thống

“Kéo” (O12) sản phảm từ khách hàng chứ không phải đẩy sản phẩm cho khách