Mở đầu Mục đích chính của chƣơng này là nêu bức tranh chung về đề tài, giới thiệu sơ lƣợc vấn đề mà công ty GF đang gặp phải, đƣa ra các lý do hình thành đề tài, mục tiêu nghiên cứu và ý nghĩa của việc hình thành đề tài này. Song song với việc xác định phạm vi nghiên cứu, phƣơng pháp nghiên cứu cũng đƣợc chỉ rõ. Phần cuối cùng của chƣơng này sẽ là bố cục của đề tài. 6 Chƣơng II: Cơ sở lý thuyết Chƣơng này trình bày cụ thể các lý thuyết nền để hỗ trợ cho việc giải thích, mô tả đề tài và nội dung cần nghiên cứu.
Danh sách các lý thuyết nền đƣợc áp dụng trong đề tài bao gồm: Lập trình linh hoạt, Scrum, Kanban, Scrumban, Quá trình chuẩn bị danh sách công việc cho sản phẩm và Quá trình phát triển một phần mềm mới dựa vào quy trình Scrumban. Chƣơng III: Thực trạng phát triển phần mềm tại công ty Global Factories Tem BV Chƣơng này ngoài việc mô tả thực trạng hiện tại của quy trình phát triển phần mềm của doanh nghiệp nói chung và dự án AOTea nói riêng, còn trình bày các nguyên nhân và các tác động của WIP đối với kết quả của dự án thông qua các dữ liệu thực tế từ phòng quản lý sản xuất. Chƣơng IV: Áp dụng phƣơng pháp Scrumban cho dự án AOTea tại công ty Global Factories Tem BV Phần đầu của chƣơng này mô tả cách ứng dụng Scrumban để làm giảm WIP trong phát triển phần mềm và áp dụng cho dự án AOTea của công ty. Phần sau cùng của chƣơng là phân tích kết quả đạt đƣợc sau khi áp dụng giải pháp.
Chƣơng V: Kết luận Chƣơng này nêu tổng quát vấn đề của công ty, kết quả đạt đƣợc sau khi áp dụng phƣơng pháp Scrumban, các hạn chế và đề xuất cho hƣớng nghiên cứu kế tiếp. 7 CHƢƠNG 2: CƠ SỞ LÝ THUYẾT 2.1 QUY TRÌNH PHÁT TRIỂN PHẦN MỀM THEO MÔ HÌNH THÁC NƢỚC Khoảng 20 năm về trƣớc, các dự án phát triển phần mềm đƣợc thực hiện theo mô hình Thác Nƣớc và các biến thể của mô hình này nhƣ V-model. Các mô hình này quy định lập trình theo hƣớng tuyến tính theo các bƣớc tuần tự nhƣ: Tìm hiểu yêu cầu khách hàng, Thiết kế, Xây dựng, Kiểm tra và Bảo Trì. Tuy nhiên, sau này ngƣời ta thấy rằng mô hình Thác Nƣớc không còn phù hợp nữa do nhu cầu của khách hàng thay đổi liên tục và chi phí của dự án quá cao do chỉ đƣợc chỉnh sửa hoặc thay đổi khi đã hoàn thành xong các bƣớc của quy trình.1 mô tả 5 bƣớc chính quy trình phát triển phần mềm theo mô hình Thác Nƣớc.1: Quy trình sản xuất phần mềm theo mô hình Thác Nƣớc (Royce, 1970) Phân tích yêu cầu (Requirements): Trong bƣớc này, toàn bộ yêu cầu phần mềm đƣợc nhận biết và phạm vi đƣợc xác định.
Những yêu cầu đó đƣợc thể hiện chi tiết theo văn bản chuẩn doanh nghiệp. Để chuyển sang bƣớc tiếp theo của quá trình thì cần ngƣời có trách nhiệm phê chuẩn, và khi đã sang bƣớc tiếp theo thì các hạn chế ít có cơ hội đƣợc thay đổi. 8 Thiết kế (Design): Trƣớc khi bƣớc sang giai đoạn mã hóa, toàn bộ giải pháp của hệ thống cũng nhƣ kiến trúc cần đƣợc xác định, văn bản hóa và đƣợc phê chuẩn bởi ngƣời quản lý. Xây dựng (Implementation): Đây là giai đoạn hiện thực hóa giải pháp đã đƣợc đƣa ra (từ bƣớc 2) thành ra các mã nguồn và những chƣơng trình thực thi đƣợc.
Kiểm tra (Verification): Trƣớc khi phần mềm đƣợc chuyển giao tới khách hàng hay ngƣời dùng cuối, nó cần đƣợc kiểm thử để bảo đảm về chất lƣợng. Các lỗi tìm đƣợc và những đoạn mã nguồn không đạt chuẩn đƣợc đƣa trở lại các lập trình viên xử lí (bƣớc 4) cho tới khi nào ―hết lỗi‖. Bảo trì (Maintenance): Khi chất lƣợng phần mềm đƣợc ―bảo đảm‖, toàn bộ phần mềm đƣợc chuyển giao tới ngƣời dùng. Công đoạn tiếp theo là nhận phản hồi nhƣ lỗi, hỗ trợ kĩ thuật, các việc ―vá lỗi‖, bảo trì v.
Hiện tại, đa số các dự án trong công ty GF nói chung và dự án AOTea nói riêng phụ thuộc vào mong muốn của khách hàng nên dễ thay đổi, trong khi các quy tắc của quy trình Thác Nƣớc mà công ty đang áp dụng thì cồng kềnh, ít linh hoạt và tính phản hồi chậm nên dễ gây ra WIP trong quá trình phát triển và ảnh hƣởng trực tiếp đến thời gian giao hàng của doanh nghiệp. Nói một cách khác, quy trình Thác Nƣớc là thực trạng của quy trình phát triển phần mềm của công ty GF.2 QUY TRÌNH PHÁT TRIỂN PHẦN MỀM THEO MÔ HÌNH LINH HOẠT (Agile) Trong những năm gần đây, Agile đƣợc biết đến nhƣ là quản lý theo Lean trong ngành công nghệ thông tin. Agile là một cách tiếp cận quản lý với sự hỗ trợ của 9 nhiều công cụ quản lý dự án. Thật vậy, Scrum là một công cụ quản lý của Agile, đƣợc biết đến nhƣ là phƣơng thức tập trung vào phát triển và giao hàng thông qua nhiều phân đoạn chặt chẽ giúp tƣơng tác trực quan đối khách hàng.
Ngày này, Scrum đƣợc sử dụng rộng rãi và thành công trong ngành công nghệ phần mềm.1 Scrum Scrum không phải là một quy trình hoặc một kỹ thuật, mà là một khung chuẩn có thể sử dụng để hoàn thành dự án hoặc sản phẩm (Schwaber & Sutherland, 2011). Hơn nữa, Scrum là một khung thực nghiệm cho phát triển phần mềm và có 3 yếu tố quan trọng trong điều khiển quá trình thực nghiệm là tính minh bạch, tính giám sát và tính thích ứng (Schwaber & Sutherland, 2011). Tính minh bạch Tính minh bạch đòi hỏi xây dựng một chuẩn chung cho quá trình giúp các bộ phận liên quan hiểu những sự việc đang diễn ra (Schwaber & Sutherland, 2011). Tính giám sát Việc giám sát cần đƣợc tổ chức thƣờng xuyên cho các tác nhân để sớm phát hiện các tính năng hoặc hƣớng đi không nhƣ mong đợi.
Tuy nhiên, các cuộc giám sát không hẳn thực hiện cho các công việc thực sự (Schwaber & Sutherland, 2011). Tính thích ứng Phải đƣợc thực hiện càng sớm càng tốt để phát hiện các sai lệch trong chức năng hoặc hƣớng đi dẫn đến các kết quả không chấp nhận đƣợc. Scrum định nghĩa bốn điểm chính thức cho tính giám sát và tính thích ứng là Sprint Planning, Daily Scrum, Sprint Review và Sprint Retrospective (Schwaber & Sutherland, 2011).2 Kanban Kanban là một hệ thống quản lý sản xuất theo Just-In-Time, sử dụng hết khả năng và năng suất của công nhân (Sugimori et al. Hệ thống Kanban hƣớng các đội của dự án hình ảnh hóa luồng công việc, làm giảm WIP tại mỗi gian đoạn và đo thời gian chu kỳ (Kniberg, 2009).
Khi áp dụng Kanban, luồng công việc trong dự án đƣợc hình ảnh hóa bằng bảng Kanban, là một bảng trắng theo truyền thống hoặc là một công cụ phần mềm nhƣ Team Foundation Server, Jira. Phƣơng pháp Kanban dựa trên 3 nguyên tắc chính là hình ảnh hóa quy trình, làm giảm WIP và kiểm soát thời gian giao hàng. Hình ảnh hóa quy trình Đây là quá trình quản lý bằng hình ảnh các công việc di chuyển qua các giai đoạn khác nhau trong quá trình phát triển trên bảng Kanban. Hình ảnh hóa quy trình giúp đội phát triển biết đƣợc tiến trình của công việc.
Nếu một giai đoạn nào đó của luồng công việc bị tắt nghẽn, thông báo sẽ đƣợc gửi cho đội phát triển để nhanh chóng xử lý (Mahnic, 2013). Làm giảm WIP Theo cơ chế ―kéo‖, Kanban đƣa ra một giới hạn tối đa số lƣợng công việc trong mỗi giai đoạn phát triển với ý tƣởng là không cho phép thực hiện một mẫu công việc mới nào cả dù cho các mẫu công việc hiện tại đã đƣợc chuyển giao cho khách hàng rồi. Công việc mới chỉ thật sự đƣợc kéo vào hệ thống khi có công suất hữu dụng thay vì đƣợc đẩy từ bên ngoài vào hệ thống. Giới hạn WIP trong một giai đoạn sẽ cho biết công suất để xử lý các mẫu công việc dở dang trong một giai đoạn của luồng công việc trong quá trình phát triển.
Quan trọng hơn là thời gian giao 11 hàng đƣợc làm giảm, một yếu tố đƣợc xem là thƣớc đo cho năng suất làm việc của đội phát triển (Mahnic, 2013). Kiểm soát thời gian giao hàng Thời gian giao hàng là một trong những thƣớc đo quan trọng trong Kanban và đo thời gian trung bình để hoàn thành một mẫu việc. Ý tƣởng chính trong Kanban là tối ƣu hóa quá trình để làm ngắn lại và dự đoán đƣợc thời gian giao hàng đến mức chính xác nhất có thể (Kniberg, 2009). Đội phát triển tập trung vào việc cải thiện thời gian giao hàng để ƣớc lƣợng lƣợng công việc đƣợc thực hiện trong một thời đoạn để vừa làm giảm thời gian giao hàng và vừa nâng cao hiệu năng của đội.3 Scrumban Mô hình Scrumban là sự kết hợp giữa các tính năng ƣu việt của 2 mô hình Scrum và Kanban.
Một mặt, sử dụng các quy tắc của Scrum để trở nên linh hoạt, mặt khác tận dụng tính chất cải tiến quá trình của Kanban để giúp đội liên tục cải tiến quá trình (Pahuja, 2012). Dƣới đây là các nguyên tắc cơ bản của Scrumban. Hình ảnh hóa quá trình Đây là tính chất quan trọng nhất của Kanban đƣợc áp dụng trong Scrumban. Trong Scrum, đội thƣờng bắt đầu các công việc trong một print và cố gắng di chuyển chúng đến giai đoạn hoàn thành.
Tuy nhiên, ý tƣởng của Scrumban là phải hình ảnh hóa dòng công việc đi vào hoặc ra khỏi sprint (Yuval, 2012) để xác định đƣợc đâu là vùng tắc nghẽn và biết đƣợc ai đang làm công việc gì và ở trạng thái nào tại một thời điểm. Theo định nghĩa của Heuvel (2011), các chính sách trong Scrumban/Kanban là các cơ chế, qui tắc hoặc các quá trình quản lý cách hệ thống vận hành. Khi các chính sách này đƣợc hình ảnh hóa, hệ thống sẽ trở nên dễ hiểu 12 hơn. Các thành viên trong hệ thống sẽ liên tục đánh giá và cải tiến các cơ chế hiện tại khi cần thiết.2 là một minh họa về dòng công việc trong Scrumban đƣợc tạo bởi công cụ phần mềm Jira.2: Hình ảnh dòng công việc trong Scrumban bằng công cụ phần mềm Jira (Nguồn: Atlassian, 2011) Trên hình 2.2, công cụ Jira thể hiện bảng Kanban rút gọn chỉ còn 3 cột chính thể hiện 3 trạng thái khác nhau của luồng công việc, các trạng thái từ trái sang phải lần lƣợt là trạng thái sẵn sàng (To do), trạng thái đang thực hiện (In Progress), trạng thái hoàn thành (Done).
Hơn nữa, công cụ này còn hỗ trợ xác định công việc nào do ai đang thực hiện ở trạng thái nào.
