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

  • Số trang: 67 |
  • Loại file: PDF |
  • Lượt xem: 1233 |
  • Lượt tải: 0
nhattuvisu

Đã đăng 26946 tài liệu

Mô tả:

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. 1 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ý 2 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 3 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 4 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 5 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ễ 6 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ạ điể m lấ y hàng, điạ đ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 7 Đề 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. 8 - 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 9 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. 10 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. 11 Chƣơng 2. MỘT SỐ KIẾN THỨC NỀN TẢNG 2.1 Phƣơng pháp phát triển phần mềm linh hoạt 2.1.1 Lịch sử Phƣơng pháp linh hoạt là một sự đối lập với các phƣơng pháp truyền thống trong phát triển phần mềm và “là sự cần thiết để thay thế cho quy trình hƣớng tài liệu, một hƣớng nặng trong quy trình phát triển phần mềm” [3]. Trong việc thực hiện các phƣơng pháp truyền thống, công việc bắt đầu với việc đặc tả các yêu cầu, tiếp theo là thiết kế kiến trúc, phát triển, và kiểm thử. Bắt đầu vào những năm 1990, một vài nhà phát triển nhận 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ô 12 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]: 13  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: 14 “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. 15 Ở đâ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 16 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. 17 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 18 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. 19 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:  Những gì đã làm đƣợc từ lần họp trƣớc.  Dự định làm gì cho tới lần họp tiếp theo.  Có gặp vƣớng mắc gì không. Việc tiến hành họp hàng ngày sẽ giúp cho việc nắm bắt rõ hiện trạng công việc, đồng thời tăng cƣờng việc liên hệ giữa các thành viên trong nhóm. Để giảm tác động của việc thay đổi, Scrum đƣa ra nguyên tắc là mọi thay đổi trong một Sprint đƣợc ghi nhận nhƣng không đƣợc áp dụng ngay. Điều này có nghĩa là trong một vòng lặp, các công việc chỉ ra trong Sprint Backlog đƣợc cố định. Mặc dù điều này có vẻ không phù hợp với tiêu chí đáp ứng thay đổi nhanh của các phƣơng pháp phát triển nhanh, nhƣng là cần thiết vì mọi thứ thay đổi liên tục, nếu thay đổi ngay lập tức theo yêu cầu có thể dẫn đến tình trạng lộn xộn. 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. 20
- Xem thêm -