Nghiên cứu phương pháp Kanban và áp dụng phát triển phần mềm quản lý con dấu

Rất nhiều dự án bị chậm tiến độ, không thoả mãn yêu cầu người sử dụng và trầm trọng hơn là không đúng nghiệp vụ.Có thể kể ra đây một số nguyên nhân khiến cho dự án không được thành công

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

PHẠM CÔNG THIÊN LÝ

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC: TS TRƯƠNG ANH HOÀNG

NGHIÊN CỨU PHƯƠNG PHÁP KANBAN

VÀ ÁP DỤNG PHÁT TRIỂN PHẦN MỀM

QUẢN LÝ CON DẤU

Ngành: Công nghệ thông tin

Chuyên ngành: Công nghệ phần mềm

Mã số: 60.48.10

Hà Nô ̣i – 2013

LỜI NÓI ĐẦU

Trong quá trình làm việc, tôi đã tham gia vào nhiều dự án tin học tại nơi công tác Một trong những điều tôi thấy rõ nhất ở các dự án, đó là tỉ lệ thành công thường chưa cao Rất nhiều dự án bị chậm tiến độ, không thoả mãn yêu cầu người sử dụng và trầm trọng hơn là không đúng nghiệp vụ.Có thể kể ra đây một số nguyên nhân khiến cho dự án không được thành công là: Quy trình quản lý dự án không tốt, công nghệ áp dụng lỗi thời, khả năng của người phát triển có giới hạn và sự cộng tác với khách hàng không được đảm bảo

Xuất phát từ lý do đó nên tôi đã chọn nghiên cứu lĩnh vực quản lý dự án và các phương pháp phát triển phần mềm, với mục đích là làm sao giảm được rủi ro khi thực hiện dự án, đưa ra được sản phẩm có chất lượng cao nhất mà vẫn đảm bảo thực hiện đúng tiến độ

Trong luận văn này, tôi tập trung nghiên cứu phương pháp phát triển phần mềm tiên tiến hiện đang được chú ý của các nhà phát triển phần mềm trên thế giới, và áp dụng phù hợp với điều kiện thực tế cơ quan mình đang công tác

Tôi xin được gửi lời cảm ơn chân thành đến thầy giáo TS Trương Anh Hoàng đã tận tình hướng dẫn, cảm ơn Văn phòng Công an tỉnh Tuyên Quang đã tạo điều kiện để tôi

có thể áp dụng thử nghiệm những kiến thức được nghiên cứu

LỜI CAM ĐOAN

Tôi xin cam đoan rằng, ngoại trừ các nội dung đƣợc trích từ tài liệu tham khảo hoặc các công trình khác nhƣ đã ghi rõ trong luận văn, các kết quả nêu trong luận văn này là

do chính tôi thực hiện và chƣa từng đƣợc ai công bố trong bất cứ công trình nào khác

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

Phạm Công Thiên Lý

MỤC LỤC

DANH MỤC CÁC BẢNG 5

DANH MỤC CÁC HÌNH VẼ 5

DANH MỤC CÁC TỪ VIẾT TẮT 5

Chương 1 GIỚI THIỆU 7

1.1 Đặt vấn đề 7

1.2 Hướng tiếp cận của đề tài 7

1.3 Nội dung của luận văn 10

Chương 2 TỔNG QUAN 12

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

2.1.1 Lịch sử 12

2.2.2 Phương pháp linh hoạt 14

2.2 Một số phương pháp phát triển phần mềm linh hoạt tiêu biểu 16

2.2.1 Extreme Programming 16

2.2.2 Scrum 18

2.2.3 Phương pháp phát triển phần mềm thích nghi 21

2.3 Kết chương 23

Chương 3 PHƯƠNG PHÁP KANBAN 24

3.1 Giới thiệu 24

3.2 Kanban là gì? 26

3.3 Quy trình Kanban 26

3.3.1 Trực quan quy trình làm việc của bạn 26

3.3.2 Giới hạn công việc đang tiến hành 28

3.3.3 Thiết lập các chính sách đảm bảo chất lượng 31

3.3.4 Đo dòng chảy 33

2.3.5 Ưu tiên 38

3.3.6 Xác định các lớp dịch vụ 40

3.3.7 Quản lý lưu lượng 43

3.3.8 Thiết lập thỏa thuận mức độ dịch vụ 45

3.3.9 Tập trung vào cải tiến liên tục 46

3.4 Kết chương 47

Chương 4 ÁP DỤNG PHƯƠNG PHÁP KABAN VÀO PHÁT TRIỂN PHẦN MỀM

QUẢN LÝ CON DẤU 49

4.1 Quy trình làm việc hiện tại 49

4.2 Phát triển phần mềm 51

4.2.1 Giai đoạn khảo sát 51

4.2.2 Giai đoạn lập kế hoạch 55

4.2.3 Giai đoạn phát triển 57

4.2.4 Giai đoạn đưa ra sản phẩm 60

4.2.5 Giai đoạn bảo trì 61

4.2.6 Giai đoạn kết thúc 61

4.3 Thảo luận và đánh giá 61

4.4 Kết chương 63

Chương 5 KẾT LUẬN 65

TÀI LIỆU THAM KHẢO 67

DANH MỤC CÁC BẢNG

Bảng 4.1 – Đánh giá kết quả thử nghiệm 63

DANH MỤC CÁC HÌNH VẼ Hình 2.1 Quy trình XP 17

Hình 2.2 Quy trình Scrum 19

Hình 2.3 Quy trình ASD 21

Hình 3.1: Ví dụ về bản đổ luồng giá trị mô tả 1 quy trình sản suất phần mềm 27

Hình 3.2: Quy trình làm việc đƣợc trực quan trên bảng 28

Hình 3.3 Trực quan các giới hạn công việc đang làm sử dụng việc đánh số trên tiêu đề cột 30

Hình 3.4: Kéo và đẩy 31

Hình 3.5: Chính sách rõ ràng hiển thị trên bảng 33

Hình 3 6: Ví dụ về sơ đồ luồng tích lũy 34

Hình 3.7 Ví dụ về biểu đồ Cycle time 36

Hình 3.8 Ví dụ về biểu đồ tỷ lệ lỗi 37

Hình 3.9: Ví dụ về biểu đồ các hạng mục bị chặn 38

Hình 3.10: Trực quan hạng mục bị chặn với nhãn mầu hồng 38

Hình 3.11 : Trực quan các chính sách ƣu tiên trên bảng 40

Hình 3.12: Trực quan các lớp dịch vụ sử dụng các thẻ màu khác nhau 43

Hình 4.1 Biểu đồ trạng thái UML mô tả quy trình làm việc 50

Hình 4.2 Trực quan quy trình làm việc hiện tại của nhóm làm việc 51

Hình 4 3 Gắn thẻ công việc vào bảng 52

Hình 4.4 Thông tin chi tiết một thẻ công việc 53

Hình 4 5 Trực quan giới hạn WIP 56

Hình 4.6 Trực quan chính sách trên bảng 57

Hình 4 7 Tách giai đoạn phát triển 58

Hình 4.8 Mô hình ca sử dụng ở mức cao 58

Hình 4.9 Mô hình ca sử dụng “Cấp phép khắc dấu” 59

Hình 4.10 Mô hình ca sử dụng “Tổng hợp tình hình quản lý con dấu” 60

Hình 4 11 Biểu đồ luồng tích lũy số công việc ở mỗi giai đoạn phát triển 60

Hình 4.12 Quy trình làm việc sau khi áp dụng Kanban 62

Hình 4.13 Biểu đồ Cycle time 63

DANH MỤC CÁC TỪ VIẾT TẮT

Từ viết tắt Thuật ngữ Tiếng việt

ASD Adaptive Software Development Phát triển phần mềm thích nghi

XP Extreme Programming Lập trình cực hạn

WIP Work In Progress Công việc đang làm

UML Unified Modeling Language Ngôn ngữ mô hình hóa thống nhất CFD Cumulative Flow Diagrams Sơ đồ luồng tích lũy

KPI Key Performance Indicator Chỉ số thực thi quan trọng

COD Cost of Delay Chi phí trễ

Chương 1 GIỚI THIỆU

1.1 Đặt vấn đề

Ở Việt Nam hiện nay, có rất nhiều công ty đang sử dụng một trong các quy trình phần mềm của phương pháp linh hoạt (agile method) sản xuất phần mềm Các phương pháp linh hoạt điển hình được áp dụng ở Việt Nạm hiện này là Scrum và eXtreme Programming Đây là hai phương pháp truyền thống của phương pháp linh hoạt Và hiện nay cộng đồng phát triển phần mềm sử dụng phương pháp linh hoạt đang hướng tới một số phương pháp phát triển phần mềm mới hơn như Crystal, Dynamic Systems Development, Feature-Driven Development và thêm nữa là phương pháp Kanban Kanban dịch từ tiếng Nhật có nghĩa là thẻ thông tin [9] Còn đúng chính xác thuật ngữ chuyên môn của môn "Quản lý công học" và kinh tế học thì phải là "Phương pháp quản lý Kanban " (Kanban method ) Đây là một thuật ngữ bắt nguồn từ công ty chế tạo xe hơi Toyota Nói đến công ty Toyota thì ngoài vấn đề kỹ thuật đặc sắc của họ phải nói đến phương pháp quản lý rất hiệu quả của họ mà người Nhật gọi là "Phương thức quản lý Toyota", một phương thức quản lý xí nghiệp thông minh tạo đòn bẩy phát triển kinh tế của Nhật bản và là tiêu chuẩn quản lý xí nghiệp của các tập đoàn sản xuất lớn của Nhật hiện tại Phương thức quản lý Toyota gồm có 2 trụ cột đó là "Phương thức quản lý KANBAN" và "Tự động hóa" [9]

Phương pháp Kanban tại Toyota là 1 phương tiện báo có nhu cầu, mô ̣t phiếu yêu cầu

có khổ giấy cỡ A6, trong đó có ghi đi ̣a điểm lấy hàng, đi ̣a điểm nhâ ̣n hàng, tên và mã số chi tiết hoă ̣c sản phẩm cần có, số “Kanban”, tổng số phiếu “Kanban”, ngày xuất phiếu, lô ̣ trình và số lượng chi tiết được xếp trong mô ̣t thùng chứa

Vì vậy, trong khi hệ thống Kanban là một khái niệm tương đối mới trong công nghệ thông tin, nó đã được sử dụng cách đây hơn 50 năm trong hệ thống sản xuất Tinh gọn (Lean production systems) ở Toyota Việc sử dụng Kanban trong phần mềm được đi tiên phong bởi David Anderson, người mà đã có sự phối hợp chặt chẽ với Don Reinertsen, đã nỗ lực mở rộng các hiều biết về sản xuất Tinh gọn và sử dụng Kanban

để trực quan và tối ưu hóa quy trình làm việc (workflow) trong phát triển, bảo trì và các hoạt động của công nghệ thông tin Với sự tập trung nhất quán vào dòng chảy (flow) và bối cảnh (context), Kanban cung cấp một cách tiếp cận ít quy tắc cho Phương pháp linh hoạt và trở thành một phần mở rộng phổ biến cho các phương pháp truyền thống của phương pháp linh hoạt như Scrum và XP

1.2 Hướng tiếp cận của đề tài

Đề tài sẽ tập trung vào việc nghiên cứu ứng dụng quy trình phần mềm Kanban và áp dụng phát triển phần mềm quản lý con dấu – phần mềm quản lý công tác nghiệp vụ của ngành Công an

Trong quá trình làm việc tại Văn phòng Công an tỉnh Tuyên Quang tôi đã tham gia phát triển một số dự án phần mềm với quy mô từ nhỏ tới trung bình với vai trò người phát triển

Dự án đầu tiên là Hệ thống quản lý Vũ khí và Công cụ hỗ trợ trên địa bàn tỉnh Tuyên Quang Khách hàng là Phòng quản lý Hành chính Công an Tỉnh Tuyên Quang Dự án bắt đầu năm 2008 và kết thúc năm 2010, nhưng đến nay Khách hàng sử dụng vẫn bị khiếm khuyết và đươc bảo trì nhiều lần

Dự án thứ hai là Hệ thống Quản lý Vật liệu nổ trên địa bàn tỉnh Tuyên Quang Khách hàng là phòng Phòng cháy chữa cháy Công an tỉnh Tuyên Quang Dự án này đã không được áp dụng vào thực tế do quy trình quản lý và quy trình nghiệp vụ của phòng ban thay đổi, do đó các chức năng phần mềm không còn phù hợp nữa

Dự án thứ ba là Hệ thống Quản lý vi phạm An toàn giao thông Khách hàng là phòng Cảnh sát Giao thông Công an tỉnh Tuyên Quang Đây là một dự án mức trung bình, với mục tiêu là xây dựng hệ thống xử phạt vi phạm hành chính an toàn giao thông đường bộ Dự án này được triển khai thực tế từ đầu năm 2012, đến này đã bảo trì 3 lần

Qua một số dự án đã triển khai, theo tôi các dự án này chưa thành công Còn nhiều vấn

đề tồn tại trong việc phát triển phần mềm cũng như việc phân phối phần mềm tới người sử dụng Và nguyên nhân chính dẫn đến dự án không thành công nằm ở phía người quản lý và người phát triển dự án Người quản lý không đưa ra được một quy trình làm việc hợp lý như:

- Hệ thống làm việc quá tải dẫn đến chất lượng sản phẩm thấp Khi nhu cầu làm việc và lưu lượng công việc không cần bằng, có thể tạo ra một số tắc nghẽn trong hệ thống, để kịp đưa ra sản phẩm đúng tiến độ, một số tắc nghẽn có thể bị

bỏ qua hoặc được giải quyết không triệt để dẫn đến chất lượng của phần mềm thấp

- Các chính sách làm việc không rõ ràng dẫn đến các rủi ro trong hệ thống như: công việc bị tắc nghẽn, việc phát triển bị phụ thuộc vào người phát triển Một

hệ thống sản xuất phần mềm bao gồm nhiều nhóm làm việc Sản phẩm cuối cùng được tạo ra bởi sự kết hợp đồng bộ các phần công việc của mỗi nhóm Để các phần công việc của mỗi nhóm là đồng bộ thì phải có các chính sách rõ ràng cho mỗi nhóm và mỗi giai đoạn của quy trình sản xuất Khi có sự thay đổi về nhân sự, việc phát triển tiếp công việc sẽ không bị phụ thuộc vào người trước

đó, hệ thống sẽ không bị tắc nghẽn vì lý do này

- Không đưa ra được các dự đoán cho quy trình làm việc ảnh hưởng đến thời hạn phát hành Tạo niềm tin với khách hàng là rất quan trọng Khách hàng luôn muốn chúng ta đưa ra lời hứa về thời gian phát hành sản phẩm, và thời gian này phải là ngắn nhất có thể Vì vậy một quy trình làm việc tốt thì có thể đưa ra được các dự báo như: điểm tắc nghẽn, điểm cần ưu tiên, và thời gian có thể hoàn thành xong một hạng mục công viêc Từ các dự bào này người quản lý có thể dự đoán được thời gian phát hành sản phẩm cho khách hàng

- Quy trình làm việc không trực quan làm cho các bên liên quan như khách hàng, chủ sở hữu sản phẩm, người phát triển… phối hợp với nhau không tốt Trong quá trình làm việc, người quản lý luôn phải biết nhân viên của mình có đang làm việc hiệu quả không, các thành viên luôn phải kết hợp làm việc cùng nhau

Và khách hàng luôn muốn biết sản phẩm có đúng như yêu cầu của mình không Khi quy trình làm việc luôn được nhìn thấy trước măt (giả sử được ghi rõ trên một tấm bảng), thì tất cả mọi người có thể nhìn thấy ai đang làm việc gì, việc đó đang ở vị trì nào trong giai đoạn phát triển, chỗ nào bị tắc nghẽn

Có thể rút ra được một số kinh nghiệm khi triển khai các dự án trên là:

- Việc liên hệ với khách hàng thường xuyên là điều rất quan trọng, bởi khách hàng là người am hiểu nghiệp vụ nhất, đồng thời họ biết những gì mà phần mềm phải đáp ứng Ngoài ra khách hàng đóng vai trò quan trọng trong việc kiểm thử phần mềm, phát hiện lỗi cũng như các chức năng không phù hợp

- Việc quản lý dự án phải được chú trọng Để làm được điều này, người quản lý cần có kinh nghiệm, khả năng lập kế hoạch tốt và nhanh nhạy trong việc xử lý các tình huống

- Cần phải có một quy trình phát triển phần mềm hiệu quả Quy trình tốt sẽ làm tăng khả năng làm việc của các thành viên trong nhóm, chuẩn hóa các tài liệu,

từ đó giảm bớt các tác động tiêu cực khi đội ngũ phát triển thay đổi

Từ việc rút ra các điều trên, trong một dự án mà chúng tôi đang triển khai, tôi quyết định thử nghiệm đưa nhóm làm việc của mình vào một quy trình làm việc hoàn toàn mới bằng cách áp dụng phương pháp linh hoạt, mà cụ thể là phương pháp Kanban vào

hệ thống phân phối phần mềm của chúng tôi

Do đó đề tài sẽ tiếp cận theo hướng nghiên cứu quy trình phần mềm Kanban và áp dụng phát triển phần mềm quản lý con dấu

Đây là phần mềm quản lý việc cấp và sử dụng con dấu trên toàn bộ địa bàn của tỉnh Tuyên Quang Công tác quản lý con dấu của các cơ quan nhà nước, tổ chức chính trị, tổ chức chính trị - xã hội, tổ chức xã hội - nghề nghiệp, hội quần chúng, tổ chức kinh tế, đơn vị vũ trang, cơ quan, tổ chức nước ngoài v.v, được lực lượng chuyên trách của Công

an tiến hành bằng phương pháp thủ công Hệ thống hồ sơ này tuy được rà soát, bổ sung

thường xuyên nhưng qua quá trình công tác số lượng các hồ sơ, sổ sách này trải qua nhiều thời kỳ, nhiều cán bộ theo dõi quản lý cho nên việc tìm kiếm các hồ sơ, ghi nhận các thông tin về con dấu gây mất rất nhiều thời gian, độ chính xác chưa cao Trong thực

tế công tác luôn có những yêu cầu đặt ra đối với công tác quản lý con dấu như:

- Tra cứu tìm kiếm thông tin về toàn bộ hồ sơ hoặc thông tin của một con dấu cụ thể;

- Thống kê xem cơ quan, tổ chức có bao nhiêu con dấu, đã huỷ, đổi bao nhiêu lần; vấn đề cấp phép sử dụng cho các con dấu;

- Báo cáo, so sánh số liệu về con dấu của các cơ quan, tổ chức theo các mốc thời gian khác nhau;

- Xem trực tiếp trích yếu các các mẫu dấu trong hồ sơ lưu trữ

- Vị trí hồ sơ con dấu của cơ quan tổ chức nằm ở đâu trong kho hồ sơ (phục vụ việc tra cứu trực tiếp)

- Con dấu tại thời điểm sử dụng đã đã hết hạn hay chưa (có trường hợp dấu đã hết hạn, đổi nhưng không làm thủ tục huỷ theo quy định mà vẫn sử dụng)

- Truy nguyên nhanh mẫu dấu đang sử dụng có phải là con dấu đã được phép sử dụng hay chưa

Khi gặp những yêu cầu như trên, nếu bằng phương pháp quản lý thủ công như hiện nay để tìm ra được câu trả lời nhanh chóng, chính xác sẽ mất rất nhiều thời gian để tìm kiếm trong hệ thống hồ sơ đã lưu trữ, thậm chí có thể không tìm ra được câu trả lời chính xác bởi vì hồ sơ các con dấu rất nhiều, được lưu trong nhiều sổ sách, dẫn đến khó tìm kiếm hoặc tìm kiếm không chính xác Từ đó yêu cầu một công cụ điện tử có thể nhanh chóng đáp ứng những yêu cầu trên

1.3 Nội dung của luận văn

Phần còn lại của luận văn sẽ bao gồm các chương sau:

Chương 2, trình bày tổng quan về phương pháp phát triển phần mềm linh hoạt, và giới thiệu chung nhất một số phương pháp phát triển phần mềm truyền thống của phương pháp phát triển phần mềm linh hoạt Các phương pháp được giới thiệu bao gồm: Extreme Programming, Scrum và Adaptive Software Development

Chương 3, trình bày chi tiết một phương pháp phát triển phần mềm mới ra đời của phương pháp linh hoạt – Phương pháp Kanban

Dựa trên những kiến thức nghiên cứu được trong chương 3 được áp dụng thử nghiệm phương pháp Kanban để phát triển 1 phần mềm – Phần mềm quản lý con dấu tại Công

an tỉnh Tuyên Quang Chương này trình bày chi tiết các giai đoạn phát triển phần mềm

có áp dụng phương pháp Kanban và kết quả đánh giá của quá trình thử nghiệm

Cuối cùng là Chương 5, đưa ra kết luận cho toàn bộ quá trình nghiên cứu đề tài

ra rằng những bước phát triển ban đầu gây cản trở các bước sau [11] Ngành công nghiệp và công nghệ phát triển quá nhanh, các yêu cầu thay đổi với “tốc độ làm quá tải các phương pháp truyền thống” [11], và các khách hàng ngày càng trở lên thiếu dứt khoát với các yêu cầu của họ trong các lần gặp đầu tiên Kết quả là, một số chuyên gia

tư vấn có các phương pháp phát triển độc lập để đáp ứng với sự thay đổi tất yếu mà họ

đã trải qua Các phương pháp linh hoạt thực sự là một bộ sưu tập các kỹ năng khác nhau, chia sẻ các giá trị và các nguyên lý cơ bản Ví dụ vào những năm 1975, một kỹ thuật dựa trên vòng lập tăng cường được sử dụng nhiều [21]

Việc cải tiến quy trình phần mềm là một sự tiến hóa trong đó việc xây dựng các quy trình mới hơn dựa trên các thất bại và thành công của những cái đi trước đó, vì vậy để thực sự hiểu bước đi linh hoạt, chúng ta cần xem xét các phương pháp ra đời trước nó

Mô hình thác nước [16] ra đời đầu tiên, là cách để đánh giá và xây dựng các nhu cầu người sử dụng Nó bắt đầu với một tập các phân tích đầy đủ các yêu cầu người sử dụng Qua vài tháng làm việc căng thẳng với người sử dụng và khách hàng, các kỹ sư

sẽ thiết lập một tập các yêu cầu chức năng và phi chức năng đầy đủ và dứt khoát (không thêm bớt gì nữa) Các thông tin này được tài liệu cho các giai đoạn tiếp theo đó

là thiết kế, ở đó các kỹ sư phối hợp với những người khác, chẳng hạn như với các chuyên gia cấu trúc dữ liệu và cơ sở dữ liệu, để tạo ra một kiến trúc tối ưu cho hệ thống Tiếp theo các lập trình viên thực thi các các thiết kế đã được tài liệu này, và cuối cùng, một hệ thống được thiết kế xong, hoàn hảo được kiểm thử và phát hành[4] Quy trình này trên lý thuyết là tốt, nhưng thực tế nó không luôn luôn là cách làm việc hay như viết ở trên Thứ nhất là, người sử dụng thay đổi các ý định của họ Sau nhiều tháng, hoặc thậm chí hàng năm, thu thập các yêu cầu và xây dựng các sơ đồ và mô hình thử nghiệm, người dùng vẫn không chắc chắn về những gì họ muốn – Những cái

họ nhìn thấy được trong sản phẩm là nó không được tốt Thứ hai là các yêu cầu có xu hướng thay đổi khi đang phát triển giữa chừng và khi các yêu cầu được thay đổi, khó thích nghi với các thay đổi

Các kỹ thuật gia tăng và lặp tập trung vào việc phân rã chu kỳ phát triển thánh các phần nhỏ hơn được tiến hóa từ mô hình thác nước [4], lấy quy trình phía sau của mô

hình thác nước và lặp đi lặp lại nó trong suốt vòng đời phát triển Phát triển gia tăng nhằm giảm thời gian phát triển bằng cách phân rã dự án thành các phiên bản gia tăng gối lên nhau Đối với mô hình thác nước, tất cả các yêu cầu được phân tích trước khi phát triển bắt đầu; tuy nhiên, các yêu cầu này sau đó được chia thành các gia tăng của các chức năng độc lập Việc phát triển mỗi gia tăng có thể được chồng lên nhau, do đó tiết kiệm được thời gian xử lý đồng thời trên toàn bộ dự án

Trong khi phát triển gia tăng xem xét việc tiết kiệm thời gian, thì các phương pháp tiên tiến như phát triển lặp và mô hình xoắn ốc [6] nhằm mục tiêu xử lý các yêu cầu thay đổi và quản lý rủi ro tốt hơn Các mô hình này đánh giá các nhân tố quan trọng trong cách lập kế hoạch và cấu trúc ở nhiều thời điểm trong quy trình hơn là cố gắng giảm thiểu khi chúng xuất hiện trong dự án

Phát triển lặp phân rã dự án thành các bước lặp có độ dài thay đổi, mỗi lần sản xuất một sản phẩm hoàn chỉnh và xây dựng trên mã và tài liệu của sản phẩm trước đó Phiên bản đầu tiên bắt đầu với sản phẩm cơ bản nhất, và mỗi lần lặp tiếp theo sẽ thêm vào các tập chức năng hợp lý Mỗi phần nhỏ là một quy trình thác nước của mình với phân tích, sau đó là thiết kế, thực thi, và cuối cùng là kiểm thử Phát triển lặp đối phó tốt với sự thay đổi, như chỉ các dùng yêu cầu hoàn chỉnh cho phiên bản hiện tại Mặc

dù các yêu cầu dự kiến cần phải trong phiên bản tiếp theo, chúng không cần có mặt trọng phiên bản hiện tại cho đến giai đoạn phân tích tiếp theo Cách tiếp cận này cho phép thay đổi công nghệ hoặc khách hàng thay đổi dự định của mình với tác động nhỏ nhất trên đà của dự án

Tương tự, mô hình xoắn ốc tránh việc chi tiết và xác định toàn bộ hệ thống trước Không giống như phát triển lặp, trong mô hình này hệ thống được xây dựng từng phần bằng cách ưu tiên hóa từng phần theo chức năng, nó ưu tiên các yêu cầu theo rủi ro

Mô hình xoắn ốc và phát triển lặp cũng là một bước nhảy vọt với sự linh hoạt thông qua quy trình thác nước, nhưng một số người nghĩ rằng họ vẫn không đáp ứng đươc để thay đổi linh hoạt cần thiết trong sự phát triển thế giới kinh doanh

Một mô hình khác là mô hình trưởng thành (CMM) [14], “một mô hình mức 5 mô tả thực tiễn quản lý, kỹ thuật và quy định các ưu tiên cải tiến cho tổ chức phần mềm” [14] Mô hình xác định 18 khu vực quan trọng của quy trình và 52 mục tiêu cho một tổ chức để trở thành một tổ chức mức 5 Hầu hết mức độ trưởng thành của các tổ chức phần mềm là hỗn độn (CMM mức 1) và chỉ một vài tổ chức đước “tối ưu” (CMM mức 5) CMM tập trung chủ yếu vào các dự án lớn và các tổ chức lớn, nhưng có thể được thay đổi để phù hợp với các dự án vừa và nhỏ do thực tế nó được xây dựng một cách chung phù hợp với nhu cầu của các tổ chức đa dạng Mục tiêu của CMM là đạt được quy trình thống nhất, có khả năng dự đoán, và có độ tin cậy [15]

Mặc dù CMM tập trung vào việc phát triển phần mềm thành quy trình có thể dự đoán, xác định và có thể lặp được, nhưng các nhà khoa học phát hiện ra rằng nhiều cái trong quy trình thực tế phần lớn không dự đoán trước và không thể lăp lại bởi vì [18]:

 Quy trình này chỉ mới bắt đầu được tìm hiểu

 Quy trình này quá phức tạp

 Quy trình đang biến đổi và không thể dự đoán được

Schwaber, người phát triển Scrum, nhận ra rằng để thực sự linh hoạt, một quy trình cần phải chấp nhận thay đổi chứ không phải là khả năng dự đoán [18] Các chuyên gia nhận thấy rằng các phương pháp đáp ứng được với sự thay đổi nhanh chóng là cần thiết, và trong môi trường năng động, “sự sáng tạo, là cách duy nhất để quản lý các vấn đề của phát triển phần mềm phức tạp” [7]

Các chuyên gia như Mary Poppendieck và Bob Charette cũng bắt đầu tìm kiếm các nguyên lý kỹ thuật khác cho quy trình, chuyển sang một trong những xu hướng công nghiệp đổi mới lúc bấy giờ, đó là sản xuất Tinh gọn (Lean Manufacturing) Bắt đầu sau chiến tranh thế giới thứ 2 bởi Toyoda Sakichi, nó không được phố biến cho đến đầu những năm 1980 Trong khi các nhà máy sản xuất ở Mỹ chạy 100% công suất của máy sản xuất và có một đống hàng tồn kho khổng lồ của cả sản phẩm và vật tư, thì Toyota chỉ giữ đủ nguồn cung trong tay để chạy nhà máy trong một ngày, và chỉ sản xuất đủ sản phẩm của đơn hàng hiện tại

Năm 2000, dự án đầu tiên của Beck và Jeffries sử dụng phương pháp eXtreme Programming [11] ra đời và thu về thành công ngoài mong đợi

Cũng vào năm 2000, Cockburn đã sử dụng những gì mà ông học được ở IBM để phát triển phương pháp Crystal [11]

2.2.2 Phương pháp linh hoạt

Các phương pháp phát triền linh hoạt được gọi với cái tên tiếng anh là Agile, có nghĩa

là nhanh nhẹn, linh hoạt, khéo léo trong hành động, là các phương pháp dựa trên các quy trình phát triển nhanh Điều này đặc biệt cần thiết trong lĩnh vực Internet và truyền thông di động đang phát triển nhanh chóng

Các dự án phát triển theo các phương pháp linh hoạt dựa trên các giá trị thương mại, quy trình thực hiện dự án được dựa trên việc đáp ứng thực tế hơn là theo kế hoạch Việc quản lý rủi ro đạt được bởi sự cộng tác chặt chẽ với khách hàng, giảm chu kỳ phát hành và tập trung vào ưu tiên các chức năng quan trọng trước

Tuyên ngôn của phương pháp linh hoạt được đưa ra bởi một nhóm hoạt động trong lĩnh vực phần mềm vào năm 2001 Những người mà đại diện cho các phương pháp như Extreme Programming (XP), Scrum, Crystal và các phương pháp khác cùng thống nhất đưa ra một bản tuyên ngôn Nội dung bản tuyên ngôn có những điểm chính sau:

“Chúng ta dần phát hiện ra những cách phát triển phần mềm tốt hơn bằng cách thực hiện nó và giúp người khác thực hiện nó Qua công việc này, chúng ta thu được các giá trị:

 Các cá nhân và sự tương tác với nhau quan trọng hơn các quy trình và các công cụ

 Làm phần mềm quan trọng hơn việc lập tài liệu

 Việc hợp tác với khách hàng quan trọng hơn việc ký kết hợp đồng

 Đáp ứng thay đổi quan trọng hơn việc theo một kế hoạch

Trong đó những thành phần bên phải là quan trọng, nhưng chúng ta coi trọng những thành phần bên trái hơn.” [3]

Tuyên ngôn này đã trở thành một phần quan trong cho phong trào các phương pháp linh hoạt, đặc trưng của nó là các giá trị và các phương pháp này khác với các phương pháp truyền thống như thế nào Câu đầu tiên cho thấy, chúng ta không phải lúc nào cũng có giải pháp cho mọi thứ, mà giải pháp nằm chính bên trong của công việc Và

để tìm được giải pháp, thì không thể chỉ dựa vào các lý thuyết mà phải trực tiếp làm công việc phát triển phầm mềm Những câu sau gồm hai phần, phần bên phải có giá trị

ít hơn phần bên trái mặc dù điều này không có nghĩa là phần bên trái không quan trọng Chúng ta sẽ xem ý nghĩa của từng câu

Giá trị 1 cho thấy những quy trình và công cụ là quan trọng Sẽ không thể phát triển một phần mềm tốt nếu không có quy trình và công cụ tốt, vì lẽ đó nên dùng công cụ tốt nhất hiện có Nhưng điều mà bản tuyên ngôn muốn nhấn mạnh là vai trò của từng cá nhân và mối quan hệ của các cá nhân với nhau trong đội ngũ phát triển phần mềm Đối với một dự án thành công, thì cần phải lập tài liệu một cách đầy đủ Nhưng bản thân tài liệu sẽ không giúp được gì nếu không có sản phẩm thực sự Vì thế, việc tạo ra sản phẩm phần mềm quan trọng hơn, và tài liệu chỉ đóng vai trò hỗ trợ phần mềm, mô

tả phần mềm một cách chính xác

Việc ký kết hợp đồng là quan trọng nhưng không đủ Một môi trường hợp tác tốt sẽ giúp cho những người phát triển đưa ra giải pháp tốt nhất cho khách hàng Các hợp đồng định nghĩa những điều khoản ràng buộc mà trong đó cả hai phía đối tác đều phải tuân theo, nhưng những người phát triển cần hợp tác với khách hàng để có thể hiểu rõ yêu cầu cũng như những gì cần phải đưa ra

Và cuối cùng, chúng ta thấy là việc lập kế hoạch là không thể thiếu Kế hoạch giúp công việc được định hướng tốt hơn Tuy nhiên thực tế có rất nhiều thay đổi, và cứ nếu nhất nhất tuân theo kế hoạch thì có thể sẽ dẫn đến thất bại Do đó cần phải đáp ứng những thay đổi để có thể điều chỉnh sao cho phù hợp

Ở đây không có sự mâu thuẫn giữa các phương pháp truyền thống và các phương pháp phát triển nhanh Vấn đề làở chỗ nhữngđiều mà các phương pháp phát triển nhanh và các phương pháp truyền thống chú trọng vào là khác nhau Điểm chính của các phương phát phát triển nhanh là việc đáp ứng thay đổi trong khi các phương pháp truyền thống tập trung vào kế hoạch

2.2 Một số phương pháp phát triển phần mềm linh hoạt tiêu biểu

Hiện nay, đã có nhiều phương pháp phát triển linh hoạt được đề xuất và áp dụng Mỗi phương pháp có một cách tiếp cận khác nhau, đưa ra những quy trình, các hướng dẫn thực hiện riêng Nhưng chung nhất, các phương pháp này đều có những tính chất đã được tuyên bố trong bản tuyên ngôn về các phương pháp phát triển nhanh như: tính tương tác cao, coi trọng vai trò khách hàng, khả năng đáp ứng thay đổi nhanh Phần này sẽ giới thiệu một số phương pháp phát triển phần mềm tiêu biểu thuộc lớp các phương pháp phát triển linh hoạt, bao gồm ExtremeProgramming (XP), Scrum và Adaptive Software Development (ASD) Các phương pháp này là các phương pháp truyền thống của linh hoạt Chúng đã được áp dụng nhiều ở Việt Nam, và có nhiều tài liệu tham khảo Do đó phần này chỉ giới thiệu qua quy trình của các phương pháp trên

và tập trung vào nghiên cứu một phương pháp Kanban – một phương pháp linh hoạt mới hơn vào chương sau

2.2.1 Extreme Programming

Extreme Programming (XP) là một trong những phương pháp phát triển linh hoạt tiêu biểu nhất Phương pháp này được đề xuất và áp dụng từ khi cách tiếp cận linh hoạt còn chưa phổ biến rộng rãi XP ra đời từ thực tiễn muốn khắc phục các vấn đề gặp phải trong các cách tiếp cận truyền thống có chu kỳ phát triển phần mềm dài như phần mềm không đáp ứng yêu cầu khách hàng, khả năng áp dụng của sản phẩm thấp, hay không đảm bảo tiến độ thực hiện Dựa trên những kinh nghiệm thực tế đã có từ trước, cộng với những thành công qua quá trình áp dụng thử nghiệm, XP đã được tổng quát lên thành lý thuyết với một loạt các nguyên lý và các bài học thực tiễn

Theo mô tả của Beck’s [5] vòng đời quy trình XP gồm các giai đoạn: khảo sát, lập kế hoạch, vòng lặp phát triển, đưa ra sản phẩm, bảo trì và kết thúc dự án

2.2.1.1 Giai đoạn khảo sát

Trước khi bắt đầu việc phát triển, nhóm phát triển cần đánh giá và phải đảm bảo năng lực thực hiện dự án, bao gồm những yếu tố như nhân lực, kỹ năng, công nghệ, thời gian

Trong giai đoạn này, các khách hàng viết ra các yêu cầu mà họ muốn có trong phiên bản đầu tiên Mỗi yêu cầu này tương ứng với một chức năng của chương trình Tuy nhiên việc này không phải lúc nào cũng diễn ra suôn sẻ Việc chậm trễ thường xuyên

xảy ra do khách hàng có thể biết những gì mà những người lập trình cần, nhưng khó biết được những gì mà người lập trình không cần

Song song với đó, các thành viên dự án làm quen với các công cụ, công nghệ và cách

sẽ làm việc trong dự án Cần xây dựng một mô hình nguyên mẫu cho hệ thống nhằm kiểm tra công nghệ được sử dụng và khảo sát các kiến trúc có thể của hệ thống Giai đoạn khảo sát kéo dài từ vài tuần đến vài tháng, phụ thuộc nhiều vào mức độ quen thuộc công nghệ của các lập trình viên

Hình 2.1 Quy trình XP

2.2.1.2 Giai đoạn lập kế hoạch

Mục đích của giai đoạn lập kế hoạch là cho phép khách hàng và những người phát triển thoả thuận một ngày đưa ra những chức năng quan trọng nhất Công việc phải thực hiện là thiết đặt mức độ ưu tiên cho các yêu cầu và thống nhất nội dung của phiên bản đầu tiên Đầu tiên, các lập trình viên sẽ ước lượng công sức cần để giải quyết các yêu cầu, sau đó thống nhất lịch trình làm việc Thời gian cho lịch trình của phiên bản đầu tiên trong khoảng từ hai đến sáu tháng Việc lập kế hoạch kéo dài một vài ngày

2.2.1.3 Các vòng lặp phát triển

Lịch trình được thiết lập trong giai đoạn lập kế hoạch được chia nhỏ thành một vài vòng thời gian kéo dài từ một đến bốn tuần Ở vòng lặp đầu tiên, cần tạo ra một hệ thống có kiến trúc của hệ thống tổng thể Việc này được thực hiện bằng cách chọn các nhiệm vụ mà buộc phải xây dựng kiến trúc cho hệ thống tổng thể Tại mỗi vòng lặp khách hàng quyết định nhiệm vụ cho mỗi vòng lặp, và ở cuối mỗi vòng lặp, các kết quả được được đưa ra và được tiến hành kiểm thử chức năng

Kết thúc vòng lặp cuối, hệ thống sẵn sàng chuyển sang giai đoạn đưa ra sản phẩm đầu tiên

2.2.1.4 Giai đoạn đưa ra sản phẩm

Ở giai đoạn này, các sản phẩm được kiểm thử song song, và có thể vẫn có những thay đổi Những thay đổi này được ghi nhận và áp dụng cho phiên bản hiện thời hoặc phiên bản kế tiếp

Ngoài ra, trong giai đoạn này cần phải tiến hành cải tiến hiệu năng, tối ưu hoá chương trình Và công việc chính đó là chuyển giao sản phẩm cho khách hàng và bắt đầu đưa vào vận hành

2.2.1.5 Bảo trì

Sau khi phiên bản đầu tiên được chuyển giao cho khách hàng sử dụng, dự án XP phải đồng thời duy trì hoạt động của sản phẩm và bắt đầu những vòng lặp mới Để làm điều này, giai đoạn bảo trì đòi hỏi công sức cho việc hỗ trợ khách hàng Do đó, tốc độ phát triển có thể chậm lại Giai đoạn bảo trì có thể yêu cầu phải kết nạp thêm các thành viên mới vào đội dự án và thay đổi cấu trúc đội

2.2.1.6 Kết thúc

Khi khách hàng không còn nhiệm vụ nào cần thực hiện nữa Các yêu cầu mà hệ thống phục vụ khách hàng cần thoả mãn trên các phương diện như tính năng, độ tin cậy Trong giai đoạn này, cần hoàn thiện các tài liệu cần thiết về hệ thống khi không có thêm sự thay đổi về kiến trúc, thiết kế hay mã nguồn Ngoài ra, cũng có thể tiến hành kết thúc khi hệ thống không đưa ra được đầu ra mong muốn, hay sẽ rất tốn kém nếu phát triển tiếp

2.2.2 Scrum

Thuật ngữ “Scrum” được trình bày lần đầu tiên trong bài báo của Takeuchi và Nonaka [20] về khả năng thích nghi, nhanh chóng, tính tự tổ chức trong việc phát triển phần mềm Scrum được biết đến như là một phương pháp quản lý nâng cao, áp dụng cho các hệ thống hiện có Do đó, có thể áp dụng Scrum với các phương pháp phát triển phần mềm khác

Ý tưởng chính của Scrum là cho rằng việc phát triển một hệ thống cần phải quản lý một loạt các đại lượng như các yêu cầu, thời gian, tài nguyên hay công nghệ dùng để phát triển, mà những đại lượng này hoàn toàn có thể thay đổi trong quá trình phát triển Từ đó cho thấy quá trình phát triển dự án mang tính không ổn định, phức tạp, khó dự đoán trước Do đó cần thiết phải có một quy trình phát triển có tính linh hoạt cao để có thể đáp ứng được những thay đổi này, và sản phẩm đầu ra phải có tính ứng dụng cao, đáp ứng được yêu cầu khách hàng

Scrum là một phương pháp hướng quy trình Quy trình Scrum chia thành ba giai đoạn, giai đoạn bắt đầu và lập kế hoạch, giai đoạn phát triển, và giai đoạn kết thúc và đưa ra sản phẩm [18]

Hình 2.2 Quy trình Scrum

2.2.2.1 Giai đoạn bắt đầu và lập kế hoạch

Trước khi dự án bắt đầu, tất cả các yêu cầu hệ thống được liệt kê và tập hợp dưới dạng các phiếu công việc, được gọi là các Backlog Tập hợp các phiếu công việc của toàn

bộ sản phẩm được gọi là Product Backlog Product Backlog cho ta cái nhìn tổng thể về các chức năng của sản phẩm cuối cùng Các yêu cầu này có thể thu được từ khách hàng, từ bộ phần bán hàng hay từ những người phát triển phẩn mềm Người tạo ra Product Backlog được gọi là Product Owner (người sở hữu), thông thường là khách hàng, hoặc là người quản lý trong công ty Tiếp theo, các yêu cầu này được xác định

độ ưu tiên và ước lượng nhân lực cần thiết để cài đặt các tính năng yêu cầu Danh sách này liên tục được cập nhật thêm các mục mới cũng như được xác định lại độ ưu tiên cho các công việc và ước lượng nhân lực, tài nguyên sao cho chính xác hơn

Trong giai đoạn này còn phải đưa ra được nhóm dự án, các công cụ và tài nguyên cần thiết, đánh giá rủi ro và tiến hành đào tạo nếu thấy cần thiết Ngoài ra, thiết kế tổng thể cũng phải được định nghĩa trong giai đoạn này

Trước khi tiến hành phát triển, người sở hữu chọn những công việc cần tiến hành trong vòng lặp đầu tiên của giai đoạn phát triển Các công việc này được tập hợp dưới một danh sách gọi là Sprint Backlog Trong khi đó, nhóm phát triển chuẩn bị những gì cần thiết và ước lượng thời gian sao cho công việc có thể hoàn thành trong vòng 30 ngày,

là khoảng thời gian một vòng lặp được quy định bởi Scrum Việc thống nhất kế hoạch giữa người sở hữu và nhóm phát triển được tiến hành trong một cuộc họp

Công việc cuối cùng là xác định mục tiêu phải hoàn thành trong vòng lặp, gọi là Sprint Goal Việc xác định mục tiêu này để cho đội phát triển thấy được lý do của những công việc mình phải làm

2.2.2.2 Giai đoạn phát triển

Toàn bộ giai đoạn phát triển được phân thành các vòng lặp, mỗi vòng lặp kéo dài 30 ngày, gọi là Sprint Trong mỗi vòng lặp, các thành viên của dự án chọn các công việc

từ Sprint Backlog, làm việc sao cho đạt được mục tiêu đề ra trong Sprint Goal Trong vòng lặp, các công việc lại được chia thành các khoảng thời gian nhỏhơn:

 Phát triển – Tiến hành phân tích, thiết kế, cài đặt, kiểm thử và viết tài liệu cho

những chức năng được lựa chọn

 Đóng gói – Tạo bộ cài đặt của sản phẩm đến thời điểm hiện thời

 Xem lại – Tất cả các thành viên trong nhóm họp với nhau để cùng xem xét lại

để đưa ra cách giải quyết những vấn đề gặp phải

 Điều chỉnh – Tổng hợp các thông tin thu được từ cuộc họp và tiến hành điều

chỉnh

Trong giai đoạn này, các thành viên gặp nhau trong cuộc họp hàng ngày Cuộc họp này nên kéo dài trong khoảng 15 phút Trong cuộc họp, các thành viên trong nhóm phải đưa ra được:

Cuối mỗi vòng lặp, các kết quả được thể hiện cho người sở hữu, người quản lý và những ai quan tâm Dựa vào đó, người sở hữu phải chuẩn bị để đưa ra những tính năng cần thiết phải cài đặt trong vòng lặp kế tiếp Nếu toàn bộ các chức năng đã hoàn thành, thì dự án bước sang giai đoạn cuối là đưa ra sản phẩm

2.2.2.3 Giai đoạn kết thúc và đưa ra sản phẩm

Khi sản phẩm đã sẵn sàng được phát hành, người quản lý sẽ tuyên bố đóng dự án và tiến hành việc đưa ra sản phẩm Trong giai đoạn này, một số công việc khác cần phải được chuẩn bị tiến hành như tập hợp tài liệu sử dụng, đào tạo người dùng, phát triển kinh doanh

2.2.3 Phương pháp phát triển phần mềm thích nghi

Phương pháp phát triển phần mềm thích nghi (Adaptive Software Development – ASD) được phát triển bởi James A Highsmith, là một trong những phương pháp thuộc lớp các phương pháp phát triển nhanh Phương pháp này tập trung chủ yếu trong việc giải quyết các vấn đề xuất hiện trong các hệ thống phức tạp, nhiều thay đổi

Tư tưởng chủ đạo của ASD cho rằng, trong môi trường liên tục có những thay đổi bất thường thì việc thích nghi là rất quan trọng Xuất phát từ quan điểm đó, ASD đưa ra một quy trình mang tính lặp lại, quá trình “học” được tiến hành qua mỗi vòng lặp để tăng cường khả năng thích nghi

Một dự án phát triển theo ASD được tiến thành thông qua các vòng lặp, các vòng lặp gồm ba giai đoạn: suy đoán, cộng tác và học Tên của các giai đoạn được đặt như vậy

cho thấy một số đặc trưng của phương pháp này Từ suy đoán (từ gốc trong tiếng Anh

là “Speculate”) được sử dụng thay cho từ lập kế hoạch (Plan) là bởi vì việc lập kế hoạch thường dựa trên những gìđã rõ ràng, chắc chắn, trong khi mọi thứ đều có thể

thay đổi Từ cộng tác (Collaborate) được sử dụng cho quá trình phát triển nhằm nhấn mạnh vai trò của việc cộng tác giữa các thành viên, và từ học (Learn) được sử dụng để

muốn nói đến việc rút ra những kiến thức, bài học để tránh gặp phải những lỗi đã gặp phải

Hình 2.3 Quy trình ASD Việc đưa ra quy trình như vậy còn khá trừu tượng và mơ hồ, tuy nhiên với những mô

tả kỹ hơn từng giai đoạn có thể giúp cho việc hiểu quy trình này được dễ dàng hơn

2.2.3.1 Khởi động dự án và lập kế hoạch

ASD cho rằng, chúng ta không thể biết mọi thứ, cho nên chúng ta chỉ có thể lập kế hoạch dựa trên những hiểu biết có hạn Thêm vào đó, chúng ta phảiđưa ra những giả thiết cho những kiến thức còn hổng Do việc lập kế hoạch chỉ dựa trên những kiến thức có hạn, nên việc thay đổi kế hoạch là rất tự nhiên, khi mà chúng ta thu được những kiến thức mới Khởi động dự án và lập kế hoạch là giai đoạn đầu tiên, trong

đó các công việc sau được thực hiện [22]

Công việc đầu tiên cần thực hiện đó là định nghĩa nhiệm vụ của dự án Nhiệm vụ này đưa ra một khung cơ bản cho sản phẩm cuối cùng, giúp định hướng cho quá trình phát triển sản phẩm Phạm vi dự án cũng phải được ước lượng, đồng thời đội ngũ phát triển cũng phải được định hình cơ bản Mục tiêu của dự án là hoàn thành nhiệm vụ này, mặc dù tại thời điểm bắt đầu, những yêu cầu có thể còn rất mơ hồ, nhưng sẽ rõ ràng hơn trong quá trình hực hiện dự án

Công việc tiếp theo cần thực hiện là phải xác định thời gian thực hiện ho toàn bộ dự

án Dựa vào khoảng thời gian này, khung thời gian cho mỗi vòng lặp được định nghĩa Các vòng lặp được lập kế hoạch, độ dài của một vòng lặp phụ thuộc vào kích cỡ dự án

và mức độ khả thi, nhưng thường trong khoảng từ 2 đến 8 tuần Việc lập kế hoạch này bao gồm cả việc gán các khung thời gian cho mỗi vòng lặp

Tiếp theo là việc lên lịch trình thực hiện các vòng lặp Trong bước này, mỗi vòng lặp được gắn với một “chủ đề”, là vấn đề chính cần được chú ý khi thực hiện vòng lặp Cuối cùng, các tính năng được gán cho các vòng lặp Các khách hàng là người quyết định dựa trên mức độ ưu tiên của từng tính năng Những người phát triển sẽ hỗ trợ cho khách hàng bằng việc ước lượng thời gian, rủi ro và các đại lượng khác

2.2.3.2 Giai đoạn phát triển các tính năng

Trong giai đoạn này, các đặc tính của sản phẩm được phát triển Giống như Scrum, ASD không đưa ra các hướng dẫn chi tiết trong việc làm thế nào để phát triển mà chỉ đơn thuần đưa ra một bộ khung phục vụ cho việc quản lý Điều mà ASD muốn nhấn mạnh, đó chính là việc hợp tác giữa các thành viên Theo Highsmith, việc hợp tác đặc biệt quan trọng, ông đưa ra quan điểm rằng một cá nhân riêng lẻ không thể có toàn bộ khả năng cần thiết cho một dự án [22] Những người quản lý phải có nhiệm vụ tạo ra một môi trường cộng tác tốt, đồng thời các thành viên trong nhóm phải tăng cường trao đổi và hỗ trợ nhau trong công việc

2.2.3.3 Đánh giá lại chất lượng công việc

Mọi người không ai là biết tất cả mọi thứ, và do đó cần phải học Kiến thức thu được sau khi suy ngẫm về một cái gì đó, rồi tiến hành thử nghiệm và đánh giá kết quả Trong giai đoạn này, những tính năng được phát triển trong giai đoạn trước được trình

dưới góc độ khách hàng hoặc người sử dụng Nhiều khi, về mặt tính năng thì những chức năng đã cài đặt là thoả mãn, nhưng về mặt sử dụng, thuật ngữ, bố trí có thể cần phải cải tiến đề thuận tiện hơn

Ngoài ra, các thành viên trong nhóm cũng cần phải thảo luận về những vấn đề kỹ thuật gặp phải, từ đó rút ra được những bài học để tránh mắc phải hoặc biết cách xử lý trong trường hợp tương tự ASD cho rằng, không thể có quan điểm luôn phải đúng, mà cho rằng ai cũng có thể mắc lỗi, và điều quan trọng là phải học được những kinh nghiệm từ những lỗi đó

Để đánh giá lại chất lượng công việc, cần phải xem xét lại những tính năng đã làm có hoạt động không, và nó hoạt động như thế nào, công việc của nhóm có vướng mắc gì không Cuối cùng, cần đánh giá hiện trạng của dự án, những gì đã làm được và chưa làm được và có kế hoạch cho những công việc tiếp theo

2.3 Kết chương

Trong chương này, tôi đã giới thiệu tổng quan về phương pháp phát triển phần mềm linh hoạt, và trình bày lướt qua một số quy trình truyền thống của phương pháp linh hoạt

Trước tiên là ASD, phương pháp này đưa ra một mô hình khá chung, mang tính chất định hướng, nên việc áp dụng ASD khá linh động, tính tuỳ biến cao Tuy nhiên, phương pháp này không đưa ra nhiều hướng dẫn cụ thể nên đòi hỏi những người quản

lý phải có kỹ năng quản lý tốt

Scrum đưa ra những tiêu chuẩn, hướng dẫn đủ chi tiết để có thể áp dụng được ngay, mặc dù có thể là không dễ Tuy nhiên, phương pháp này thiếu những hướng dẫn cụ thể

về mặt kỹ thuật lập trình, nên có thể áp dụng kết hợp với một phương pháp phát triển phần mềm khác

Và cuối cùng là XP, đưa ra nhiều ý tưởng khá hay và hiệu quả, như khách hàng cùng làm việc hay lập trình theo cặp XP không cứng nhắc việc áp dụng, mà chỉ mang tính chất chỉ đạo, nên việc áp dụng XP dễ hơn Chúng ta có thể áp dụng XP đầy đủ, nhưng cũng có thể sử dụng những gợi ý của phương pháp này và kết hợp với các phương pháp khác để có thể thu được hiệu quả cao nhất

Chương tiếp theo sẽ trình bày chi tiết một phương pháp linh hoạt hoàn toàn mới được

áp dụng vào sản xuất phần mềm – Phương pháp Kanban

Chương 3 PHƯƠNG PHÁP KANBAN

Trong chương 2 chúng ta đã có cái nhìn tổng thể về phương pháp phát triển phần mềm linh hoạt và mộ số quy trình của một số phương pháp truyền thống của phương pháp này

Trong chương này trình bày một phương pháp phát triền phầm mềm mới hơn đó là phương pháp Kaban

3.1 Giới thiệu

Thuật ngữ Kanban trong tiếng Nhật có nghĩa là cái thẻ [10] Một thẻ gắn vào một phần của công việc Mỗi thẻ hoạt động được bắt đầu Một công việc mới bất kỳ phải đợi trong một hàng đợi (queue) tới khi nào một thẻ trở nên sẵn sàng Khi một vài việc được hoàn thành, thẻ được bóc ra và tái chế Với một thẻ rảnh rỗi, một phần mới của công việc trong hàng đợi có thể được bắt đầu

Cơ chế này được hiểu như một hệ thống kéo bởi vì công việc mới được kéo vào trong

hệ thống khi có khả năng xử lý nó, chứ không phải bị đẩy vào trong hệ thống dựa trên nhu cầu Một hệ thông kéo không thể bị quá tải nếu khả năng (dung lượng) cũng như

là việc xác định số các thẻ tín hiệu trong sự lưu thông đã được thiết lập một cách hợp

lý Có thể hình dung một hệ thống Kanban qua ví dụ sau:

Trong một công viên, công viên chính là hệ thống: khách thăm quan là công việc đang làm (WIP), và dung lượng được giới hạn bởi số thẻ vào cửa được lưu thông Những khách thăm quan mới đến được vào khi có vé sẵn sàng trên tay Một ngày bình thường điều này không có vấn đề gì Tuy nhiên, vào ngày đông đúc, ví dụ ngày nghỉ, khi tất cả các vé được đưa ra, khách thăm quan mới phải xếp hàng bên ngoài cổng và chờ đợi thẻ được tái sử dụng từ các khách đã thăm quan xong khi họ rời đi Hệ thống Kanan cung cấp một phương pháp đơn giản, rẻ tiền và dễ dàng thực hiện để kiểm soát kích thước của đám đông bằng cách giới hạn số người bên trong công viên Điều này cho phép người giám sát công viên duy trì hoạt động trong điều kiện tốt và tránh thiệt hại gây ra bởi quá nhiều người tham gia và bị quá tải

Trong phát triển phần mềm, một hệ thống Kanban ảo dùng để giới hạn công việc đang tiến hành Các thẻ Kanban này không làm chức năng thực sự như là tín hiệu để kéo công việc thay vào đó, chúng đại diện cho các hạng mục do đó gọi là “ảo”, vì không

có thẻ tín hiệu vật lý Tín hiệu để kéo công việc mới được suy ra từ định lượng trực quan công việc đang làm từ một số chỉ số của giới hạn (dung lương- công suất) Theo David J Anderson [10] sử dụng một hệ thống Kanban để giới hạn công việc đang làm của nhóm đến khả năng chấp nhận được và để cân bằng nhu cầu trong nhóm

so với thông lượng công việc giao cho họ Bằng cách này nhóm có thể đạt được tốc độ

ổn định của phát triển để tất cả các cá nhân có thể cân bằng được công việc và cuộc

suất, và nó thách thức một nhóm tập trung vào giải quyết các vấn đề này để duy trì ổn đinh một dòng chảy công việc Bằng cách cung cấp khả năng hiển thị chất lượng và xử

lý các vấn đề, nó làm rõ ràng sự tác động của các lỗi, tắc nghẽn, biến động, và chi phi kinh tế trên dòng chảy và lưu lượng Các thao tác đơn giản của việc giới hạn công việc đang làm của Kanban khuyến khích chất lượng cao hơn và hiệu suất lơn hơn Sự kết hợp của việc cải thiện dòng chảy và chất lượng tốt hơn giúp cho thời gian chờ (khoảng thời gian giữa giai đoạn hoạch định và lúc bắt đầu sản xuất) ngắn hơn và cải thiện khả năng dự báo và đúng hiệu năng hàng ngày Bằng cách thiết lập một nhịp phát hành thường xuyên và phân phối nó một cách liên tục, Kanban giúp xây dựng lòng tin đối với khách hàng

Thực hiện tất cả điều này, Kanban góp phần vào sự phát triển văn hóa của tổ chức Bằng cách công khai vấn đề, tập trung một tổ chức vào giải quyết chúng, và loại trừ ảnh hưởng của chúng trong tương lai, Kanban tạo điều kiện cho sự xuất hiện của một

tổ chức cải tiến liên tục, được trao quyền đánh giá cao, uy tín cao, có tính hợp tác cao Các bảng thẻ đã trở thành cơ chế kiểm soát trực quan phổ biến trong phát triển phần mềm linh hoạt Sử dụng một bảng ghi chú với các thẻ được ghim trên bảng, để theo dõi công việc đang làm đã trở nên phổ biến Nó quan sát giá trị ở các giai đoạn đầu, các bảng thẻ này vốn không phải là hệ thống Kanban Chúng đơn thuần là các hệ thống điều khiển trực quan Chúng cho phép các đội quan sát trực quan công việc đang làm và để tự tổ chức, phân công nhiệm vụ riêng, và việc di chuyển công việc tồn đọng

để hoàn thành mà không có sự chỉ đạo từ người quản lý trực tiếp Tuy nhiên, nếu không có giới hạn rõ ràng cho công việc đang làm và không có tín hiệu để kéo công việc mới vào hệ thống, thì đó không phải là hệ thống Kanban

Mỗi thẻ trực quan biểu diễn một phần riêng biệt công việc có giá trị của khách hàng mang một số thông tin Các thông tin về thẻ phải tạo điều kiện cho hệ thống kéo để các

cá nhân đưa ra quyết định kéo của chính họ Thông tin trên một thẻ có thể thay đổi bởi hạng mục công việc hoặc bởi các lớp dịch vụ (thảo luận trong mục 3.3.8)

Ví dụ tên của hạng mục được viết ở giữa Ngày mà thẻ vào hệ thống được viết ở dưới cùng bên trái, cái này cung cấp 2 mục địch: Thúc đẩy đầu vào, đầu ra của hàng đợi cho lớp chuẩn của dịch vụ, và nó cho phép các thành viên trong nhóm xem xét bao nhiêu ngày để hết hạn đối với các thỏa thuận mức dịch vụ (mô tả trong mục 3.3.8) Để cố định lớp ngày phân phối của các hạng mục dịch vụ, thời hạn giao được yêu cầu được viết dưới góc bên phải của thẻ

Có thể sử dụng một vài dấu hiệu, ví dụ như một dấu hoa thị để cho biết rằng hạng mục

là muộn đối với mục tiêu của thời gian sản xuất (lead time) trong thỏa thuận mức dịch

vụ Tên của người được giao cũng được viết trên thẻ

Theo nguyên tắc chung, thiết kế một thẻ sử dụng đại diện cho một phần công việc của

cá nhân nên có đủ thông tin để tạo thuận lợi cho các quyết định quản lý dự án, như

hạng mục nào được kéo tiếp theo, mà không có sự can thiếp hoặc chỉ đạo của người quản lý Cách tốt nhất là trao quyền cho các thành viên trong nhóm với sự rõ ràng, minh bạch quy trình, mục đích và mục tiêu của dự án, và thông tin rủi ro Khi hiểu được sâu sắc hơn về các lớp dịch vụ và các thỏa thuận mức dịch vụ, chúng ta sẽ khám phá ra rằng Kanban tạo điều kiện mạnh mẽ cho cơ chể tự tổ chức và quản lý rủi ro Bằng cách trao quyền cho các thành viên trong đội thực hiện kế hoạch của chính họ và các quyết định ưu tiên, thể hiện sự tôn trọng đối với cá nhân với một niềm tin trong hệ thống ( hoặc thiết kế quy trình)

2 Tạo ra các chính sách rõ ràng (Make Policies Explicit) Tạo ra các chính sách

mà chúng ta đang hoạt động một cách minh bạch

3 Đo và quả lý lưu lượng (Measure and Manage Flow) Đo và quản lý lưu lượng

để đưa ra các quyết định và hình dung ra kết quả

4 Xác định các cơ hội cải tiến Tạo ra một nền văn hóa cải tiến liên tục là công việc của tất cả mọi người

Có nhiều cách để áp dụng Kanban nhưng cách tốt nhất để giới thiệu Kanban vào trong một tổ chức là dần dần chứ không phải thông qua việc chuyển kế hoạch và chương trình đào tạo Từ các nguyên tắc trên, chúng ta có thể có các bước dưới đây để đưa hệ thống Kanban vào quy trình làm việc

3.3 Quy trình Kanban

3.3.1 Trực quan quy trình làm việc

Bước đầu tiên hướng tới việc trực quan quy trình làm việc, chính là phải hiểu hệ thống hiện tại của chúng ta hoạt động như thế nào

* Hiểu về hệ thống cung cấp phần mềm

Để có thể đưa ra quyết định đúng về việc làm thế nào tối ưu quy trình làm việc, bước đầu tiên là phải hiểu những gì chúng ta đang làm Để hiểu được quy trình hiện tại của bạn cách tốt nhất là vẽ sơ đồ toàn bộ quy trình làm việc cung cấp phần mềm của chúng

ta và không chỉ tập trung vào phần "phát triển"

Chúng ta có thể sử dụng bản đồ dòng giá trị (Value Stream Maps), biểu đồ trạng thái trong UML, sơ đồ quy trình công việc, hoặc một loại khác nào đó để xác định quy trình của mình.

Cách phổ biến nhất hiện nay là sử dụng khái niệm của hệ thống sản xuất Tinh gọn (Lean): bản đồ dòng giá trị (Value Stream Maps) Ở dạng đơn giản, một biểu đồ dòng giá trị mô tả các giai đoạn mà công việc của chúng ta trải qua, từ nguyên liệu thô đến thành phẩm, trong trường hợp sản xuất phần mềm, từ ý tưởng mơ hồ đến một tính năng làm việc trong sản phẩm Điều quan trọng khi dùng nó để thấy được từng giai đoạn là hình dạng đầu tiên của thông tin Ví dụ, một giai đoạn được gọi là "Kiểm thử" gồm nhiều việc hơn là chỉ để thử nghiệm (sửa chữa, phân tích, tái cấu trúc, thảo luận, cập nhật, vv), nhưng kể từ khi hình dạng nguyên thủy của thông tin đến là "Kiểm thử", chúng ta sẽ xác định được công việc của chúng ta là đang trong giai đoạn "Kiểm thử", trong khi tất cả các hoạt động này đang xảy ra Khoảng cách giữa các giai đoạn của chúng ta, nơi mà không có thông tin nào được thêm vào, được định nghĩa là "thời gian chờ đợi" Hình 3.1 cho thấy một ví dụ từ một dự án thực tế

Hình 3.1: Ví dụ về bản đổ luồng giá trị mô tả 1 quy trình sản suất phần mềm

* Trực quan hệ thống

Khi đã có nắm được quy trình làm việc hiện tại, bước tiếp theo là trực quan nó Đơn giản nhất để làm điều này là sử dụng một tấm bảng, nhưng nếu ta đang làm việc trong một nhóm phân tán bạn có thể sử dụng một công cụ quản lý công việc trực tuyến Không có gì làm cho công việc của chúng ta có thể nhìn thấy tốt hơn là có nó ngay trước mặt chúng ta ở tất cả các thời gian và có thể chạm vào nó

`Thường thì sẽ có ít nhất hai loại giai đoạn: giai đoạn “Hoạt động”, nơi mà hoạt động công việc đang được thực hiện, và các giai đoạn “Đệm”, nơi công việc đang chờ đợi sẽ được phát hành / phát triển, nhưng sau này có thể phát sinh nhiều hơn

Có một bảng cho nhóm làm việc, viết lên đó những gì ta muốn, đây là công cụ quản lý trực quan nhanh chóng Ở phiên bản đầu tiên, bảng của chúng ta có thể trông giống một vài thứ như hình 3.2 (biểu diễn tất cả công việc cần để hoàn thành một chức năng, chứ không chỉ là việc phát triển)

Hình 3.2: Quy trình làm việc được trực quan trên bảng Mọi chức năng bắt đầu từ các ý tưởng lờ mờ trong cột “Hàng đợi đầu vào” (hình 3.2)

và kết thúc trong cột "Phát hành", nơi một chức năng được rời đi khi nó thực sự làm việc Nguyên tắc chung là "bạn chỉ có thể quản lý công việc bạn có thể thấy"

Trực quan công việc cho một số lợi ích, quan trọng nhất là:

- Tập trung vào "tổng thể" ( Focus on “The Whole”) Có thể thể nhìn thấy chính

xác công việc của chúng ta ảnh hưởng đến những người khác như thế nào, và ngược lại

- Minh bạch (Transparency) Mọi người đều biết chính xác những gì đang xảy ra

và không có thông tin nào bị che dấu

- Xác định các lãng phí (Identifying waste) Tự nhiên chúng ta bắt đầu đặt câu hỏi

về lý do tại sao chúng ta đang làm mọi thứ theo cách ta đang làm

3.3.2 Giới hạn công việc đang tiến hành

Khi ta đã làm chủ được việc trực quan công việc, chúng ta đã sẵn sàng để tiếp tục sang bước tiếp theo - hạn chế công việc đang làm (WIP)

* Hiểu về công việc đang tiến hành

Để hiểu lý do tại sao giới hạn WIP có ý nghĩa, chúng ta xem xét thuật ngữ: Thời gian quay vòng (Cycle time ) = Công việc trong tiến trình (WIP) / lưu lượng (Throughput) trên đơn vị thời gian

Cycle time mô tả thời gian một hạng mục công việc đi qua hệ thống của chúng ta, hoặc nói cách khác, "bao nhiêu lâu từ lúc một chức năng được lựa chọn để thực hiện cho đến khi nó được dùng trong sản xuất" Xác định việc "lựa chọn để thực hiện" như thế nào phụ thuộc vào hoàn cảnh của chúng ta

WIP mô tả số lượng công việc đang xử lý của hệ thống Có bao nhiêu “story points”/”user stories”/”backlog items” hiện tại đang tiến hành trong hệ thống? Nó phụ

thuộc vào hoàn cảnh Một số người cho rằng nó bao gồm tất cả các hạng mục đang chờ xử lý, trong khi những người khác cho rằng nó chỉ bao gồm các hạng mục được lựa chọn để thực hiện

Lưu lượng trên đơn vị thời gian đơn giản là số lượng trung bình của công việc đã hoàn thành trong một thời gian nhất định

Điều này có nghĩa là cho một một hệ thống với 100 câu chuyện người sử dụng (công việc đang làm) và lưu lượng là 2 câu chuyện người dùng trên / 1 tuần, cycle time trung bình là 100/2 = 50 tuần hoặc gần như một năm Để giảm cycle time xuống 25 tuần có thể được thực hiện bằng cách hoặc là tăng gấp đôi lưu lượng là 4 câu chuyện người dùng/ 1 tuần hoặc bằng cách giảm số lượng câu chuyện người dùng đang tiến hành xuống còn 50 Trong hầu hết các trường hợp giảm công việc đang làm hơn là tăng lưu lượng

Chúng ta có thể ước lượng, việc giới hạn công việc đang làm là giảm tất cả cycle time

để tăng lưu lượng và giảm thiểu số lượng công việc mà chúng ta đã đầu tư thời gian và nguồn lực, nhưng vẫn chưa tạo ra bất kỳ giá trị kinh doanh nào

Chúng ta thực hiện việc này như thế nào? Việc đầu tiên chúng ta phải làm là tao ra sự

nỗ lực tốt nhất của bản thân để xác định bao nhiêu hạng mục mà chúng ta sẽ cho phép trong mỗi giai đoạn trên bảng ở mỗi lần Tốt nhất là để hoạt động này được dẫn dắt bởi các chính sách mà nhóm của ta có thể áp dụng

* Trực quan các giới hạn công việc đang làm

Trực quan giới hạn như thế nào là tùy vào chúng ta Trong hình 3.3, bảng chia các giai đoạn hoạt động thành hai giai đoạn con “đang làm” và “làm xong”, các giới hạn công

việc đang làm được viết trên mỗi tiêu đề cột Điều này có thể làm cho ta nhìn sâu sắc vào hệ thống của chúng ta đang làm việc như thế nào và đây là cách phổ biến để thực hiện nó trong công nghệ thông tin

Hình 3.3 Trực quan các giới hạn công việc đang làm sử dụng việc đánh số trên tiêu đề cột

* Tìm ra các giới hạn công việc đang làm đúng

Chúng ta nên thiết lập giới hạn công việc đang làm chặt chẽ ngay từ đầu Cách thứ nhất là quan sát hệ thống của chúng ta và thiết lập các giới hạn vừa đủ cho quy trình làm việc hiện tại Sau đó, xác định nơi tắc nghẽn và điều chỉnh giới hạn ở một thời

điểm Một cách tiếp cận triệt để hơn để thiết lập các giới hạn trên các cột ở giai đoạn hoạt động chặt chẽ hơn để hệ thống có thể để xử lý và làm bước đệm cho từng giai

đoạn Sau đó, quan sát nơi mà công việc bị tích tụ lại, và nới lỏng dần cho đến khi công việc trôi qua hệ thống Cả hai đều đòi hỏi một số kinh nghiệm, vì vậy đừng mong đợi để làm được nó ngay lần đầu tiên Không có kết luận cuối cùng là cái nào tốt hơn, nhưng việc thiết lập các giới hạn với các chính sách trong đầu dường như sử dụng cả hai cách này

Trong mọi tình huống, quan trọng là phải thiết lập một chính sách rõ ràng để quyết định tách hoặc thay đổi giới hạn sẽ thực hiện như thế nào Một cách hay là cả nhóm cùng đưa ra quyết định Điều này đảm bảo rằng mọi người đều được nói lên ý kiến của mình và hiểu được quyết định

Luôn luôn nhớ rằng giới hạn ban đầu là suy đoán tốt nhất, được đặt ra trong thời gian

mà ở đó số lượng thông tin sẵn có ít nhất Khi có được thêm thông tin về hệ thống , các giới hạn nên được điều chỉnh liên tục để chúng ta tìm ra những cách làm việc tối

ưu Nếu vẫn đang làm việc với các giới hạn ban đầu không khác gì các giai đoạn 3 tháng sau khi bắt đầu, có thể ta đã bỏ qua bước quan trọng nhất, cụ thể là bước cải tiến liên tục, sẽ giới thiệu chi tiết hơn sau đây Các giới hạn mà quá bé sẽ cản trở dòng chảy

và sẽ làm cho mọi người nhàn rỗi quá lâu, trong khi giới hạn được quá lớn sẽ làm tăng thời gian quay vòng (cycle time) và sẽ làm cho hạng mục công việc trễ quá lâu

Chúng ta sẽ nhanh chóng nhận ra với các giới hạn WIP đúng chỗ, hệ thống có thể chỉ làm việc đúng công xuất Chúng ta cần phải kết thúc công việc rồi mới được phép bắt đầu một việc mới Mặc dù nghe có vẻ tầm thường, nhưng nó là khái niệm cốt lõi của một hệ thống lập lịch kéo của Lean và là một công cụ mạnh mẽ đáng kinh ngạc trên

hành trình đi đên một hệ thống phân phối phần mềm hiệu quả, bền vững hơn và có thể

dự đoán trước được

Một phép ẩn dụ phổ biến là hệ thống như một chuỗi các kẹp giấy Càng kéo nó càng đi theo một đường thẳng đẹp, nhưng nếu thay vào đó ta đẩy nó, tất cả chúng đều sụp đổ với nhau trong một đống hỗn độn, mỗi mục hạng mục sẽ chặn các phần còn lại (được minh họa trong hình 3.4)

Hình 3.4: Kéo và đẩy Khi thảo luận về công việc đang làm, chúng ta thường tập trung kỹ lưỡng về số lượng các hạng mục đang xử lý Tuy nhiên, chúng ta không nên quên rằng kích thước là quan trọng Các hạng mục lớn sẽ chặn các nguồn tài nguyên trong thời gian dài của thời gian và sẽ tạo ra sự xáo trộn trong dòng chảy, trong khi các hạng mục nhỏ hơn sẽ chảy nhanh hơn rất nhiều thông qua hệ thống và sẽ cung cấp cho chúng ta thông tin phản hồi ngay lập tức Phân rã các hạng mục xuống để tổi thiểu tập tính năng thương phẩm nhỏ nhất, đây là một nhiệm vụ khó khăn và nó đòi hỏi trí tưởng tượng cũng như

kỹ năng và kinh nghiệm

thiết kế phù hợp lúc ban đầu Thỉnh thoảng điều này được chấp nhận, vì khi phát hành phần mềm sẽ lấy được thống tin phản hồi thực tế, đây là cách rẻ nhất để mua thông tin Cũng có thể có trường hợp tìm ra lỗi này để xử lý trước có thể đòi hỏi chúng ta nhiều thời gian và tiền bạc hơn là sửa chữa nó sau đó

Vậy tại sao nó đắt như vậy? Hãy xem xét một vài tình huống phổ biến trong phát triển phần mềm

Một người sử dụng (hãy gọi anh ta là A) không thể hoàn thành nhiệm vụ của anh ta bởi vì một lỗi trong hệ thống của chúng ta Hoặc A viết một báo cáo bị lỗi hoặc gọi hỗ trợ cấp độ đầu tiên để giải quyết vấn đề này Tuy nhiên, A không biết nhiều về cái gì cần cho một người phát triển có thể khảo sát vấn đề hoặc có thể người hỗ trợ ở cấp độ đầu tiên không hiểu hệ thống như anh ta phải làm Trong cả hai trường hợp, thông tin sai lệch hoặc không đầy đủ được đưa đến người phát triển, họ có thể theo đuổi việc giải quyết một vấn đề khác (cái mà có thể thực sự không phải là một vấn đề, nhưng thay vào đó dẫn đền một lỗi khác) hoặc đơn giản là bỏ cuộc Điều này tiếp diễn cho tới tận cuối cùng, các mối được giải quyết hết Tuy nhiên, không chỉ làm cho A không hoàn thành nhiệm vụ, thông tin sai đã bị ghi vào cơ sở dữ liệu, cái mà bây giờ cần một tập lệnh SQL phức tạp đề chuyển sang trạng thái có ý nghĩa Không phải là không phổ biến các tình huống xảy ra giống như vậy, nguồn nhân lực bỏ ra so với việc bỏ ra thời gian giới thiệu các lỗi ở nơi đầu tiên

Hơn nữa, vấn đề chất lượng khiến chúng ta phải chuyển đổi nhiệm vụ và có thể phải chữa cháy Chúng ta tự nhiên phải đặt một công việc mà chúng ta đang làm sang một bên để sửa chữa một lỗi nghiêm trọng hoặc các vấn đề có tính khả dụng trong sản phẩm, khi đó sau nửa ngày các vấn đề cuối cùng cũng được sửa xong thì chúng ta không thể nhớ ra các vấn đề phức tạp nào mà chúng ta đang làm trước đó và phải mất thêm nửa giờ trở lại trạng thái làm việc lúc đầu

* Trực quan các chính sách

Làm thế nào để đưa các chính sách vào phát triển phần mềm? Chúng ta đã trực quan công việc trên bảng và đặt ra giới hạn công việc trên đó Tất cả là ta cần làm bây giờ là thêm các chính sách ta đang sử dụng để đảm bảo chất lượng và tính nhất quán Để làm điều này, bảng của ta có thể như hình 3.5

Lưu ý rằng toàn bộ các giai đoạn có thể có chính sách bảo đảm chất lượng và các chính sách đó cũng có thể được dùng để bảo đảm tính nhất quán và chất lượng trong chính quy trình của nó (ví dụ theo dõi cycle time và tỷ lệ lỗi)

Hình 3.5: Chính sách rõ ràng hiển thị trên bảng Luôn luôn ghi nhớ rằng ta không bao giờ là nô lệ cho các chính sách và các danh sách kiểm tra của chính chúng ta Chúng ta là một nhân viên có kiến thức chuyên môn không ngừng học hỏi và cố gắng cải tiến hệ thống ta làm việc chứ không phải là một robot Bắt đầu bằng cách thêm các thủ tục ta đang sử dụng hiện tại và thêm/xóa/thay đổi chúng khi ta tìm ra cách thức mới tốt hơn để đảm bảo chất lượng Mọi sai sót là một cơ hội để suy nghĩ về việc quản lý bên trong hệ thống như thế nào

Khi sử dụng Kanban, điều quan trọng là tất cả mọi người cam kết tôn trọng các chính sách đã thỏa thuận (đầu tiên chúng chỉ mô tả quy trình hiện tại của chúng ta) và nó cần một quyết định của cả nhóm mới thay đổi được chúng Nhớ rằng, khi muốn phá vỡ một chính sách, thường là lý do tốt là khởi đầu hoàn hảo cho một cuộc thảo luận cần thiết “Thay đổi chúng; không phá vỡ chúng” là nguyên tắc luôn luôn lặp lại nhiều lần khi thực hiện Kanban

* Hiểu về thước đo

Khi thảo luận vê thước đo, một quy tắc luôn nhớ: “Hệ thống phân phối phần mềm của

ta chỉ có một năng xuất nhất định” Nếu cố gằng ép hệ thống của chúng ta vượt quá khả năng của nó, sẽ dẫn tới chất lượng thấp hơn, tốc độ không bền vững, chi phí bảo trì cao hơn, hoặc tất cả mọi thứ