Đề 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

Sản xuất được định nghĩa là hành động của 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

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

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ápAgile 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 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 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 22

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

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

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 rasả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ộcvào bạnso 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 Sản xuất được định nghĩa là hành động của 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 và kỹ thuật 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 phát triển phần mềm chưa có nhiều nghiên cứu quan tâm đến nguyên tắc và kỹ thuật, công 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ểnphần mềmchung nhưCapability Maturity ModelIntegrated của Viện Kĩ nghệphần mềm Mỹ (SEI)vàtiêu chuẩn ISO9000/9001đã đượchình thành đểchuẩn hóa quy trìnhphát triển phần mềm, cũng như họ đã tiêu chuẩn hóa sản xuất các sản phẩm truyền thống Các nguyên tắc và tính chuyên nghiệp đã được mô tả như là viên đạn bạc.Thật không may,sự tiếp tục của cuộc khủng hoảng phần mềm

vào năm 1980 cho thấy việc tìm kiếm phương pháp phát triển phần mềm hoàn hảo

vẫn chưa kết thúc (Brooks 1986)

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ủa

phát triển đã được hoàn thiện hơn (Mah 2008).Tuy nhiên, khi áp dụng Lean vào

thực tế đã chứng minh khác nhau, cải tiến trong việc phát triển phần mềm 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ụ)Leantrong sản xuất phần mềm là

gì?

3 Làm thế nào để triển khai các nguyên tắc và thực hành Lean cho các công ty sản

xuất phần mềm tại thành phố Hồ Chí Minh?

Mục tiêu cụ thể

- 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 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ý dự án có sự lựa chọn đúng đắn hơn Commented [U1]: Nên viết cụ thể (theo kiểu mỗi mục tiêu là

một gạch đầu dòng)

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 Leanvà 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íchtậ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ế phần mềm 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 đíchcủ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 tôi sử dụngcá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 phát triển phần mềm và không có nguyên tắc Lean tinh khiết vì vậy việc 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 phần mềm pháttriển

và hợp nhất chúng lại được 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 sản xuất phần mềm 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áctiêu chí lựa chọncác báo cáo, bài nghiên cứunhư sau:

• Các bài nghiên cứu,báo cáo liên quan đến phương pháp sản xuất phần mềm 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ồnthông tinuy 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ảotừ các chuyên giatrong lĩnh vực phần mềm

Không có dữ liệu thực nghiệm trong nghiên cứu này, tuy dữ liệu thực nghiệm có thể làm cho kết quảnghiên cứu mạnh mẽ hơn nhưng đâ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 phát triển phần mềm một phương pháp phát triển phần mềm mới đó là sản xuất phần mềm 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 6phầ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: 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ột sả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ộtthực hành tốt nhấtcủ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ì Theo Dennis, Wixonm và Tegarden (2005), giai đoạn lập kế hoạch thường chiếm khoảng 15% của tổng vòng đời phát triển (SDLC), đây là quá trình cơ bản để xác định phạm vi của hệ thống/sản phẩm, hiểu

được lý do tại sao một hệ thống nên được xây dựng và làm thế nào các nhóm dự án

sẽ xây dựng thông qua tính kỹ thuật, kinh tế và tính khả thi.Giai đoạn phân tích chiếm khoảng 15% của SDLC, phân tích hệ thống hiện tại, những vấn đề của hệ thống và sau đó xác định cách để thiết kế các hệ thống mới thông qua các yêu cầu thu thập được từ khách hàng Giai đoạn thiết kế chiếm 35% của SDLC, quyết định

hệ thống sẽ hoạt động như thế nào về phần cứng, phần mềm và cơ sở hạ tầng mạng Giai đoạn thực hiện chiếm khoảng 30% của SDLC và là giai đoạn mã hóa thực tế xảy ra Giai đoạn kiểm thử (test) chiếm 15%, giai đoạn bảo trì chiếm 5% còn lại của SDLC và tập trung vào lắp đặt, kế hoạch hỗ trợ, tài liệu hướng dẫnvà gỡ lỗi Hình dưới đây cho thấy một vòng đời thác nước điển hình

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)

(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

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àophát triểnlặp và tăng dần giá trị, những gì được chia sẻ giữacá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 cholợ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ữaphươ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

triển ngắn

Điểm mạnh  Phương pháp đơn giản, kiến

trúc tự nhiên  Vòng đời phát triển ngắn

Đ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

 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 chosả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í, là 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ápLean vàphương phápAgile

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

hàng Chỉ làm những gì khách hàng mong muốn và những gì đem lại giá trị cho khách hàng

Các nguyên tắc Lean của Womack &Jones (2003)

Womack and Jones (2003) đưa ra 5 nguyên tắc Lean như sau

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

Hiểu được giá trị mà khách hàng mong muốn (WJ1-Understand Customer Value) Chỉ có những gì khách hàng cảm nhận là giá trị quan trọng thì mới quan trọng đối với sự phát triển sản phẩm

Phân tích chuỗi giá trị (WJ2) Một khi giá trị cần thiết để cung cấp cho khách hàng

đã được xác định, bạn cần phải phân tích tất cả các bước trong quy trình kinh doanh của bạn để xác định những nhân tố thực sự giá trị Nếu một hành động không gia tăng giá trị, bạn nên xem xét đổi hoặc loại bỏ nó từ quá trình này Tạo dòng chảy công việc liên tục (WJ3) thay vì di chuyển các sản phẩm từ một trung tâm làm việc đến trung tâm tiếp theo với số lượng lớn, quy trình sản xuất nên tạo dòng chảy liên tục từ nguyên liệu đến thành phẩm trong các tế bào sản xuất chuyên dụng

Xây dựng hệ thống kéo (WJ4) thay vì sản xuất và tồn trữ hàng tồn kho, công ty nên thiết lập hệ thống kéo từ nhu cầu khách hàng tới thành phẩm Công việc tiếp sau sẽ không được thực hiện trừ khi cóyêu cầu từ bước kế tiếp nó

Sự hoàn hảo

Hệ thống kéo Dòng chảy công việc Phân tích chuỗi giá trị Hiểu được giá trị mà khách hàng mong muốn

Hoàn thiện (WJ5) Khi loại bỏ lãng phí từ các quá trình và sản phẩm được sản xuất

từ dòng chảy liên tục theo nhu cầu từ khách hàng, bạn sẽ nhận ra rằng không có

sự kết thúc trong việc cố gắng giảm thời gian, chi phí, không gian, những khuyết tật và công sức

Liker & Morgan, 2006 đưa ra 13 nguyên tắc chia thành 3 nhóm là con người, quy

trình và công cụ như sau Bằng cách sử dụng các nguyên tắc và thực hành, ông mô

tả giá trị cốt lõi và bản chất của sản xuất tinh gọn trong một mô hình được gọi là hệ thống sản xuất sản phẩm tinh gọn (Lean Product Development System: LPDS) Mô hình LPDS có ba nhóm (1) quá trình, (2) những người lao động có tay nghề cao và (3) các công cụ và công nghệ Chúng được mô tả bằng 13 nguyên tắc bên dưới Bảng 2-8: Các Nguyên tắc Lean của Liker & Morgan 2006

LM3 Tạo ra một dòng chảy quá trình phát triển sản phẩmLM4 Sử dụng nghiêm ngặt tiêu hệ thống tiêu chuẩn để giảm biến thể, tạo sự linh hoạt và dự đoán kết quả

Lao động có

tay nghề cao

LM5 Phát triển một hệ thống kỹ sư trưởng phát triển để tích hợp

từ đầu đến cuốiLM6 Tổ chức để cân bằng chức năng chuyên môn và tích hợp chức năng chéo

LM7 Phát triển kỹ thuật và năng lực trong tất cả kỹ sưLM8 Tích hợp đầy đủ các nhà cung cấp vào hệ thống phát triển sản phẩm

LM9 Xây dựng môi trường học tập và cải tiến liên tụcLM10 Xây dựng một nền văn hóa không ngừng cải thiện

LM13 Sử dụng công cụ tiêu chuẩn hóa

2.5.2.2 Các nguyên tắc Lean áp dụng trong SXPM

Các nguyên tắc cơ bản thật sự không thay đổi theo thời gian hay không gian, trong khi những công cụ và thực hành thì tùy thuộc vào từng tình huống cụ thể Những công cụ và thực hành nên được phân biệt như bạn chuyển từ một môi trường sang môi trường khác và họ cũng thay đổi như một tình huống phát triển (Mary & Tom Poppendieck, 2003)

Ahlstrom và Karlsson (1996, 1998) đã mô tả 8 nguyên tắc Lean cho phát triển sản

phẩm phần mềm

- (A1) Loại bỏ lãng phí là nguyên tắc đầu tiên của Lean: lãng phí là một cái gì

đó không mang lại giá trị cho khách hàng

- (A2) Cải tiến liên tục là cải thiện hệ thống sản xuất dần dần, nơi hoàn hảo là mục tiêu duy nhất

- (A3) Không khuyết tật (không lỗi) để đạt được chất lượng cao, cần có sự tập trung của tất cả các bộ phận và làm đúng từ khi bắt đầu sản xuất

- (A4) Lịch trình kéo: một nguyên tắc khác là lập lịch trình kéo mà sản phẩm được thông qua một hệ thống kéo (đơn đặt hàng, yêu cầu)

- (A5) Phát triển nhóm đa chức năng Nhóm đa chức năng dùng để chỉ những đội hoặc một nhóm người lao động có thể hoạt động nhiệm vụ khác nhau Thống kê cho thấy một nhóm đa chức năng có thể thực hiện tốt hơn nhiều so với bất kỳ tổ chức công việc truyền thống

- (A6) Trao quyền cho nhóm, phân cấp trách nhiệm là nguyên tắc mà không

có đội ngũ giám sát thực hiện nhiệm vụ giám sát Nó cũng giúp làm giảm mức độ phân cấp trong tổ chức

- (A7) Xây dựng đội ngũ lãnh đạo đảm nhiệm tất cả các vai trò giám sát như

tư vấn, huấn luyện, hỗ trợ, cho nhóm đa chức năng

- (A8) Hệ thống thông tin theo chiều dọc đề cập đến luồng thông tin trực tiếp đến người ra quyết định có liên quan Nó giúp thông tin phản hồi nhanh và hành động khắc phục ngay lập tức

Poppendieck& Poppendieck (2003) đã đề xuất bảy nguyên tắc Lean trong sản

xuất phần mềm như sau

- (P1) Loại bỏ lãng phí, loại bỏ tất cả các tính năng không đem lại giá trị cho khách hàng

- (P2) Đề cao việc học tập liên tục (Amplify learning) Sau mỗi vòng phát triển lặp có rất nhiều bài học được rút ra và đừng bao giờ kì vọng một sản phẩm hoàn hảo ngay từ lần đầu tiên bàn giao

- (P3) Hoãn cam kết tức là quyết định muộn thì tốt hơn là quyết định sớm nhưng mang lại nhiều sai sót, quyết định muộn nhưng có đầy đủ thông tin và

dữ liệu cần thiết cho quyết định đó

- (P4) Cung cấp sản phẩm càng nhanh càng tốt để nhanh chóng nhận được phản hồi của khách hàng cho biết “what they need now” (khách hàng cần gì)

và thay đổi cho phù hợp

- (P5) Trao quyền cho các nhóm phát triển (dự án), cho họ khả năng ra quyết định trong phạm vi công việc

- (P6) Xây dựng tính toàn vẹn tức là bàn giao cho khách hàng sản phẩm mà họ cần

- (P7)Xem xét toàn bộ, các chuyên gia cần xem xét tổng thể và nâng cao hiệu suất cho toàn hệ thống

Poppendieck và Cusumano (2012) gần đây đã mô tả 7 nguyên tắc Lean sửa đổi

của họ năm 2003 cho SXPM dựa trên kinh nghiệm triển khai Tác giả gợi ý Lean như một tập hợp các nguyên tắc chứ không phải là một tập các thực hành (best practice) Sau đó áp dụng nguyên tắc Lean trong phát triển phần mềm có ý nghĩa hơn và tăng chất lượng sản phẩm Các nguyên tắc đó là

- (PC1) Tối ưu hóa toàn bộ: là để xác định nhu cầu của khách hàng và những

- (PC6) Sự tham gia của tất cả mọi người

- (PC7) Cải tiến liên tục để tốt lên từng ngày, không có sự kết thúc của tốt nhất

vì vậy tổ chức và cá nhân phải liên tục cải thiện mình

Middleton và cộng sự (2005) Lean là một phương pháp kết hợp mà nó tập trung

vào tất cả các đặc điểm của tổ chức đặc biệt về phát triển con người Cácnguyên tắc được tuân thủ trong môi trường SXPM đó là thiết lập dòng chảy công việc liên tục (MA1) bằng cách ước lượng số lượng công việc và làm cho quá trình suông sẻ Nguyên tắc thứ hai là phải xác định giá trị khách hàng mong muốn (MA2) sau đó tiến hành thiết kế ma trận cấu trúc (MA3), phân bổ nhịp độ hoặc Takt time (MA4) sao cho công việc không bị ùn tắc Nguyên tắc thứ 5 là liên kết các quy trình (MA5) lại với nhau cho chặc chẽ, chuẩn hóa quy trình, thủ tục (MA6) để loại bỏ các quy trình không cần thiết và giảm thiểu sai sót Xây dựng văn hóa dừng lại và sửa chữa các vấn đề ngay lập tức làm tăng độ tin cậy của khách hàng Loại bỏ chi phí làm lại (Eliminate rework MA7) Cân bằng công việc (MA8), Công bố kết quả (MA9) Ra quyết định dựa trên dữ liệu (MA10) và nguyên tắc cuối cùng là hạn chế công việc tồn đọng, dở dang (MA11) Mức sản phẩm dở dang: được đề cập rằng các yêu cầu, thiết kế và mã hóa (code) nên được giữ càng thấp càng tốt, chỉ cung cấp khi cần thiết

Joey Cho trong một nghiên cứu của mình năm 2010 cũng đưa ra bảy nguyên tắc

Lean áp dụng trong SXPM như bên dưới

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

(Nguồn: Joey Cho, 2010)

2 Khuếch đại việc học tập

Tạo ra sản phẩm thông qua những vòng lặp và gia tăng giá trị cho sản phẩm qua từng vòng lặp

Thu thập thông tin phản hổi qua từng vòng lặp

và điều chỉnh cho vòng lặp tiếp theo

3 Quyết định càng muộn càng tốt

Bất kỳ quá trình nào cũng sẽ cung cấp một khả năng thay đổi khác bằng cách trì hoãn quyết định càng muộn càng tốt

4 Cung cấpsản phẩm càng nhanh càng tốt

Cung cấp những sản phẩm nhỏ nhưng làm việc được và càng nhanh càng tốt

Cung cấp thường xuyên các phiên bản làm việc của một sản phẩm cuối cùng là một chìa khóa để phát triển nhanh chóng

Giao hàng sớm và thường xuyên của các tính năng phần mềm nhỏlàm tăng khả năng thành công

5 Trao quyền cho cácnhóm