Báo cáo bài tập tình huống hệ thống thông tin quản trị agile development methods

TRƯỜNG ĐẠI HỌC NGÂN HÀNG TP HỒ CHÍ MINH KHOA CƠNG NGHỆ THƠNG TIN BÁO CÁO BÀI TẬP TÌNH HUỐNG HỆ THỐNG THÔNG TIN QUẢN TRỊ ĐỀ TÀI: CASE STUDY 13.1: AGILE DEVELOPMENT METHODS GVHD : Nguyễn Dương Thuấn Lớp : T01 Nhóm sinh viên : Phạm Văn Trọng Nguyễn Tiến Thăng Bùi Thị Mỹ Hằng Nguyễn Hằng Ngọc Vũ Duy Hưng Nguyễn Ngọc Tú Trần Trọng Quyền TP.HCM – 2010 LớpT01 – Case study 13.1 DANH SÁCH PHÂN CƠNG NHĨM STT Mã SV Họ tên Nhiệm vụ 030124081019 Phạm Văn Trọng Tìm tài liệu, ứng dụng pp Agile, tổng hợp 030124080800 Nguyễn Tiến Thăng Tìm tài liệu, ứng dụng pp Agile Tìm tài liệu, khái quát, đặc điểm, nguyên tắc, so sánh Waterfall Agile Tìm tài liệu, khái quát, đặc điểm, nguyên tắc, so sánh Waterfall Agile 030124080236 Bùi Thị Mỹ Hằng 030124081177 Nguyễn Hằng Ngọc 030124080352 Vũ Duy Hưng Tìm tài liệu, ứng dụng pp Agile 030124081039 Đỗ Hồng Tú Tìm tài liệu, ứng dụng pp Agile 030124080739 Trần Trọng Quyền Tìm tài liệu, làm slide Ký tên LớpT01 – Case study 13.1 MỤC LỤC Khái quát chung mơ hình Waterfall phương pháp Agile 1.1 Mơ hình thác nước Waterfall 1.2 Phương pháp Agile Phương pháp phát triển linh hoạt (Agile Development method) 2.1 Đặc điểm 2.2 Nguyên tắc So sánh Agile Waterfall Áp dụng phương pháp Agile 4.1 Điều kiện áp dụng phương pháp Agile .9 4.2 Cơ cấu làm việc Agile .9 4.3 Quy trình thực 11 Kết luận .12 LớpT01 – Case study 13.1 BÀI DỊCH CASE STUDY AGILE DEVELOPMENT CĨ THỂ LÀM CƠNG VIỆC KINH DOANH TRỞ NÊN NHANH CHĨNG VÀ NHẸ NHÀNG Nhưng cơng nghệ thơng tin phải truyền đạt lợi ích nhà quản lý chấp nhận “Agile software development” giúp ngăn ngừa tổ chức khỏi bị giam hãm vào ý tưởng chiến lược kinh doanh lỗi thời, khiến số nhà quản trị lo lắng, theo lời chun gia nói với thành viên Hiệp hội máy tính New Zealand họp NZCS gần Theo lời nhà phát triển Shane Hastie:“Agile software development” cách mà IT bảo vệ khỏi việc trở thành gánh nặng trì trệ làm thay đổi doanh nghiệp Lối phân tích cứng rắn kỹ thuật phát triển khơng linh hoạt giam hãm tổ chức vào ý tưởng lỗi thời kìm hãm phát triển thương mại Quản lý đánh giá cao lợi ích kỹ thuật phát triển nhanh - với điều kiện lợi ích truyền đạt cách, ơng nói Hastie, kỹ sư trưởng Hiệp hội phần mềm giáo dục, hai nhà phát triển diễn thuyết giai đoạn “bird of the feather” phiên họp phát triển nhanh, tổ chức Wellington đầu tháng Giải trình viên Stephen Hilson, làm việc cho Telecom, cho biết nhà quản lý nói chung cơng nghệ thơng tin nói riêng lo lắng tính chất thiếu tự nhiên phương pháp nhanh, đặc biệt nói đến ngành quan trọng, chẳng hạn viễn thông Theo lời Hilson: “ngành viễn thông phù hợp với thử nghiệm nhanh xung quanh khung phát triển theo mơ hình thác nước nhiều thơng thường - bắt đầu với đặc điểm kỹ thuật đầy đủ làm việc thơng qua thiết kế, lập trình thử nghiệm giai đoạn tuyến tính” Bản chất việc phát triển nhanh việc tạo mảnh nhỏ chương trình, q trình mà đơi dẫn đến việc nhận thiết kế ban đầu chương trình khơng làm việc cần phải sửa đổi Điều dẫn đến thiết kế lại lặp lặp lại tái mã hóa, độc lập với phần khác phát triển Bề ngồi, q trình phi cấu trúc, yêu cầu "nổi sóng" thực ứng dụng thực tế sống phát triển, diễn giả nói Trong mơi trường linh hoạt, thực cơng việc thường xun theo dõi có nghĩa có cơng việc nhỏ bỏ đi, Hastie nói Ngược lại, thiết kế khơng đáng tin dựa đặc điểm kỹ thuật vững chắc, cho thấy việc vứt bỏ nhiều với tác động ảnh hưởng lớn đến tiến độ dự án Điều quan trọng nguồn lực hạn chế New Zealand, ơng nói Và, mục tiêu hồn thành khó nhìn thấy ngay, kỹ thuật nhanh nhẹn cung cấp đủ để giữ cho doanh nghiệp tiến xa Các diễn giả thừa nhận rằng, với phát triển nhanh, sản phẩm cuối khác với kế hoạch ban đầu Nhưng có xu hướng phù hợp với nhu cầu doanh LớpT01 – Case study 13.1 nghiệp thời điểm hoàn thành - nhu cầu bắt đầu, mà lỗi thời Nếu quản lý người sử dụng có liên quan, họ hiểu logic cách mà nhóm ICT lựa chọn để phát triển Hastie phát biểu: "Hai số yếu tố quan trọng trình độ cao tham gia khách hàng hỗ trợ giám đốc điều hành Nếu bạn có chúng, bạn thành công bạn sử dụng thứ cơng nghệ gì” Bản chất phát triển nhanh biết đến với 10 đến 15 năm, biết đến thử nghiệm tốt, theo lời Hastie Các yếu tố cần thiết lập trình với nhóm đồng nghiệp, chuyển tiếp nhanh chóng với đơn vị nhỏ, liên hệ chặt chẽ với khách hàng, tiếp xúc ngày, nơi nhà phát triển báo cáo công việc mà họ đạt kể từ họp cuối cùng, họ dự định làm trở ngại mà họ gặp phải Phương pháp Agile – biết vào khoảng 2001 – “Hãy kết hợp thử nghiệm hay vào với nhau” Câu hỏi: Những khác biệt mơ hình thác nước truyền thống phương pháp phát triển nhanh, đề xuất ứng dụng tương ứng họ để liên kết mục tiêu doanh nghiệp chiến lược IT ? TÓM TẮT TÌNH HUỐNG Agile development làm cơng việc kinh doanh nhanh chóng nhẹ nhàng hơn, giúp ngăn ngừa tổ chức không bị giam hãm vào ý tưởng chiến lược kinh doanh lỗi thời Nó khắc phục lối phân tích cứng rắn kỹ thuật phát triển không linh hoạt thiết kế không đáng tin ảnh hưởng đến tiến độ dự án Tuy nhiên, tính chất thiếu tự nhiên phương pháp nhanh mà có ý kiến cho khơng phù hợp với ngành viễn thông Bản chất agile development việc tạo mảnh nhỏ chương trình đơi thiết kế ban đầu cần không thực phải thay đổi, điều dẫn đến sản phẩm cuối khác với kế hoạch ban đầu phù hợp với nhu cầu doanh nghiệp thời điểm hoàn thành Hai số yếu tố quan trọng trình độ cao tham gia khách hàng hỗ trợ giám đốc điều hành, có bạn thành cơng bạn sử dụng thứ cơng nghệ “ Hãy kết hợp thứ công nghệ với nhau” LớpT01 – Case study 13.1 BÀI PHÂN TÍCH Ngày nay, cơng nghệ thơng tin (IT) có vai trị lớn hoạt động kinh tế, sản xuất kinh doanh, bán hàng, xúc tiến thương mại, quản trị doanh nghiệp…Việc áp dụng công nghệ IT trở thành phần thiếu đời sống hoạt động kinh tế nói chung doanh nghiệp nói riêng Đặc biệt việc phát triển hệ thống thông tin kinh doanh yếu tố quan trọng góp phần vào thành cơng doanh nghiệp Hiện có nhiều phương pháp phát triển hệ thống phương pháp đánh giá chiếm lĩnh ưu năm gần : phương pháp phát triển linh hoạt (Agile Development Methods) Khái qt chung mơ hình Waterfall phương pháp Agile 1.1 Mơ hình thác nước Waterfall Mơ hình thác nước (Waterfall) đời vào năm 70, mơ hình cổ điển áp dụng quy trình phát triển phần mềm phần lớn cơng ty Mơ hình Waaterfall chuỗi quy trình phát triển luồng đặn từ xuống họat động thác nước, bao gồm giai đoạn: phân tích yêu cầu khách hàng, thiết kế, cài đặt, kiểm tra, tích hợp bảo trì Mơ hình đề nghị hoạt động tiến hành cá giai đoạn tách biệt, giai đoạn sau không bắt đầu chừng giai đoạn trước chưa hoàn thành Sản phẩm đầu giai đoạn trước trở thành đầu vào giai đoạn sau Ưu điểm Waterfall dễ quản lý Tuy nhiên, nhược điểm cứng nhắc thiếu thực tế, việc thay đổi phần quy trình khơng thể việc làm lại giai đoạn ban đầu để đáp ứng thay đổi thường nhiều công sức phá vỡ cấu trúc phần mềm LớpT01 – Case study 13.1 Để khắc phục nhược điểm Waterfall, phương pháp Agile đời với mục tiêu phần mềm phải có khả biến đổi, phát triển tiến hóa theo thời gian mà khơng cần phải làm lại từ đầu Phương pháp tập trung vào tính đơn giản: tạo phần mềm thật đơn giản đáp ứng yêu cầu khách hàng hôm sẵn sàng cho thay đổi vào ngày mai 1.2 Phương pháp Agile Là phương pháp phát triển phần mềm trọng vào tiến hóa, phát triển theo thời gian (xây dựng bồi đắp thêm, mở rộng thêm) với kế thừa tối đa, hiệu chỉnh lại cho phù hợp tránh phải bắt đầu làm thành phần lại từ đầu Agile triết lý cho việc phát triển phần mềm Nói cách khác, cách “tư duy” dự án phần mềm Các triết lý Agile cụ thể hóa số phương pháp phát triển phần mềm, chẳng hạn Extreme Programming (XP) hay Scrum, gọi tắt phương pháp Agile Phương pháp phát triển linh hoạt (Agile Development method) Để khắc phục đặc điểm phương pháp Waterfall, vào đầu năm 90, phương pháp phát triển phần mềm đời Phương pháp cho phép phần mềm có khả biến đổi, sửa chữa dự án bắt đầu Đó phương pháp phát triển phần mềm linh hoạt 2.1 Đặc điểm Phương pháp phát triển linh hoạt cho phép dự án hồn thành nhanh chóng mà đảm bảo yêu cầu chất lượng dễ dàng việc sửa chữa, cập nhật yêu cầu thay đổi vào giai đoạn dự án dự án kết thúc sản phẩm giao cho khách hàng Phương pháp phát triển linh hoạt có đặc điểm sau:  Được phát triển dựa quy trình phát triển lặp (interative development) - dự án chia thành nhiều mảng nhỏ, dễ sử dụng dễ sửa đổi yêu cầu khách hàng thay đổi Dự án thực theo mảng nhỏ này, giống dự án nhỏ, hết dự án quy trình lại bắt đầu với dự án tất yêu cầu khách hàng đáp ứng dự án bàn giao  Với phương pháp phát triển linh hoạt, hai hay bốn tuần, nhóm lập trình viên giao cho khách hàng phần dự án, khách hàng kiểm tra khuyến khích đưa ý tưởng mới, yêu cầu thay đổi yêu cầu dự án Theo đó, nhóm lập trình viên cập nhật sửa đổi sản phẩm theo yêu cầu khách hàng thay vào hợp đồng làm việc Cần lưu ý không giống với phương pháp Waterfall, việc sửa đổi giúp cho ứng dụng tốt hơn, đẹp không phá hỏng nó, khơng buộc phải bắt đầu lại từ đầu  Với phương pháp phát triển linh hoạt, phần nhỏ dự án phần mềm test trình làm dự án việc lập trình viên làm thay phải có nhóm kiểm tra (tester) độc lập Bằng cách sử dụng công cụ “unit test” (kiểm tra phần) Từng phần dự án kiểm tra q trình phát triển trước tích hợp vào phần mềm  Phương pháp phát triển linh hoạt nhấn mạnh vào việc gặp mặt trao đổi hàng ngày thành viên nhóm dự án Khác với phương pháp phát triển truyền thống, thành viên nhóm dự án chia phát triển mảng riêng biệt, với phương pháp LớpT01 – Case study 13.1 Agile, thời điểm, nhóm tập trung phát triển mảng dự án Vì vậy, phương pháp Agile yêu cầu thành viên có tập trung địa lí, bàn bạc thảo luận hàng ngày để hoàn thành dự án hạn  Phương pháp phát triển Agile dựa vào việc phát triển nhóm nhỏ (10 thành viên trở xuống), thành viên phải người có kĩ cao hiểu biết dự án, nữa, thành viên cần tin tưởng lẫn nhau, chia sẻ thông tin với Với nhóm thành viên, thành viên cần có nhiều kĩ so với việc lập trình kiểm thử truyền thống  Với đặc điểm trên, phương pháp phát triển linh hoạt ngày ứng dụng rộng rãi với phần mềm trị giá hàg chục triệu, chí hàng trăm triệu đô la Mỹ 2.2 Nguyên tắc  Ưu tiên cao dự án thỏa mãn khách hàng việc bàn giao sản phẩm sớm liên tục  Hoan nghênh thay đổi từ phía khách hàng, kể thay đổi vào giai đoạn cuối  Bàn giao sản phẩm theo chu kỳ từ vài tuần đến vài tháng, chu kỳ ngắn tốt chu kỳ dài  Các nhân viên hiểu nghiệp vụ lập trình viên phải làm việc hàng ngày  Tổ chức dự án xoay quanh cá nhân tích cực, hỗ trợ tin tưởng họ  Phương pháp giao tiếp tốt đội dự án gặp mặt trực tiếp  Các chức hoạt động thước đo cho tiến độ dự án  Khuyến khích phát triển bền vững: lập trình viên, người dùng, nhà quản lý… phải có khả tham gia dự án cách liên tục  Liên tục cải tiến chất lượng thiết kế mã nguồn  Tính đơn giản giữ vai trị cốt yếu, làm tốt  Những yêu cầu thiết kế tốt nảy nở từ nhóm làm việc tự chủ  Sau khoảng thời gian định, đội dự án xem xét cách thức cải tiến hiệu công việc So sánh Agile Waterfall Agile hoạt động dựa nguyên tắc lặp, tức là, dự án chia thành nhiều module nhỏ, module thực chức giống lặp lặp lại: tập hợp yêu cầu, lập kế hoạch, phân tích, code, test… với trình tự Waterfall lại hướng đến cách tiếp cận cấu trúc có định trước, khơng có linh hoạt việc phân chia giai đoạn dự án, khâu phải đảm bảo hồn thành xác 100% trước chuyển sang khâu Đây coi khác dẫn đến khác hai phương pháp Thứ nhất, rủi ro hai phương pháp, theo phương thức hoạt động Waterfall, kiểm tra bước thực lần và cuối dự án, vậy, dự án có lỗi sai lỗi sai phát dự án hoàn thành, rủi ro gặp phải lớn, nữa, chi phí tìm kiếm sửa chữa tốn khâu trình cảu dự án có mắt xích với Tuy nhiên, Agile khắc phục điều Với module nhỏ hoạt động nhau, Agile cho phép dự án kiểm tra cách thường xuyên cuối giai đoạn thử nghiệm đưa kết Như đảm bảo phát loại bỏ LớpT01 – Case study 13.1 lỗi sai vùng phát triển, kết kiểm tra lại hai lần sau đợt sàng lọc lỗi đầu tiên, từ đó, giảm thiểu tối đa rủi ro cho khách hàng, tiết kiệm thời gian chi phí dành cho dự án Thực tế cho thấy, dự án làm theo phương pháp water từ tháng đến năm, đó, Agile khoảng 1-2 tháng để hoàn thành dự án Thứ hai, tính linh hoạt phù hợp với thực tế Waterfall gần bị triệt tiêu đến thời điểm bàn giao dự án cho khách hàng, đặc biệt ngành nghề mang tính chất nhạy cảm cao với thông tin thị trường, thường xuyên thay đổi tài ngân hàng Agile lại hoàn toàn ngược lại Với Waterfall, khách hàng phải gần phải đưa tất yêu cầu, thông tin từ ký kết hợp đồng, thay đổi khó ảnh hưởng đến hệ thống Từ đây, thấy, tháng trước, với thơng tin đưa phân tích xác thị trường, tháng sau, có nhiều yếu tố thay đổi khơng thể lường trước, thông tin đưa vào lúc đầu khơng cịn phù hợp Nếu muốn, quay lại lập trình lại hệ thống từ đầu, thời gian tốn Trong đó, khách hàng Agile lại thay đổi yêu cầu trước biến động bất thường thị trường, cuối giai đoạn Agile có chương trình hợp lý lập trình nhằm giải sửa chữa ý tưởng Thứ ba, yêu cầu mục tiêu phương pháp mà yêu cầu nguồn nhân lực hai phương pháp khác Phương pháp Agile trọng đến việc giao tiếp khách hàng thường xuyên thời gian thực hợp đồng nhằm đưa đến sản phẩm tốt nhất, phù hợp Mỗi cá nhân hoạt động theo phương pháp Agile khơng người lập trình viên viết code hay tester đơn thuần, họ phải biết tất khâu để hồn thành dự án đó: từ việc marketing, thỏa thuận với khách hàng, đến việc thiết kế, phân tích, bàn giao đưa sản phẩm thị trường Agile khuyến khích làm việc nhóm, hoạt động môi trường mở, giảm thiểu tối đa truyền đạt mang tính chất giấy tờ Đây coi phong cách làm việc giai đoạn Agile đối lập hoàn toàn với Waterfall điểm này, mà cá nhân Waterfall quan tâm đến khâu mà họ đảm nhiệm Thứ tư, Agile phù hợp với dự án nhỏ, có tính chất thay đổi thường xuyên, yêu cầu thời gian hoàn thành nhanh chóng rủi ro thấp thiết kế Web Waterfall lại phù hợp với dự án lớn, khơng có u cầu thay đổi nhiều Thêm vào đó, đặc tính tự điều chỉnh phương pháp Agile tận dụng tốt lập trình chương trình hướng đến đối tượng phù hợp, nghĩa phương pháp sở hữu mơ hình hoạt động đưa kết kịp thời phương pháp khơng phù hợp hồn tồn với định khách hàng Trong đó, phương pháp Waterfall đưa kết rắc rối hay trì hỗn khiến khách hàng thất vọng Cùng với việc phương pháp Agile chí cịn cải thiện chất lượng phần mềm chúng trọng vào việc thử nghiệm Phương pháp Agile khuyến khích lập trình viên tự thử nghiệm, thường xuyên yêu cầu họ đưa thử nghiệm trước đưa mã phát triển thói quen kiểm tra tự động cho chương trình họ đưa Cuối cùng, cần phải có nhiều hệ thống khác để tương tác với phương pháp Waterfall Đối với phương pháp Agile, điều không cần thiết Tuy nhiên, hai phương pháp cho phép thực phân khu, cụ thể phương pháp Waterfall việc phân khu thực vào giai đoạn Đối với phương pháp Agile, module mã hóa phân bổ cho nhóm lập trình khác LớpT01 – Case study 13.1 Điều cho phép nhiều phần dự án hoàn thành lúc nên việc phân khu sử dụng hiệu phương pháp Agile Áp dụng phương pháp Agile 4.1 Điều kiện áp dụng phương pháp Agile Agile phương pháp tốt, nhiên trường hợp áp dụng phương pháp Trước định áp dụng Agile cho dự án mình, bạn phải trả lời câu hỏi: dự án này, điều kiện cơng ty liệu phương pháp Agile có giúp bạn thành cơng áp dụng phương pháp khác hay không? Các dự án có đặc điểm sau phù hợp với Agile: 4.1.1 Mức độ rủi ro thấp Mức độ rủi ro dự án hiểu khả thực mức độ thành công dự án Dự án có tính khả thi thấp, tức mức độ rủi ro cao khơng nên áp dụng mơ hình 4.1.2 Thành viên nhóm có kinh nghiệm Vì Agile tập trung cho dự án nhỏ có thời gian hồn tất ngắn, phương pháp địi hỏi có cá nhân tài năng, người sẵn lịng làm chuyện có lực tổng quát hóa, làm qua nhiều cơng đoạn vịng đời truyền thống sản phẩm Phương pháp Agile cần có cá nhân đa năng, có động lực, biết nghiên cứu, biết phân tích, biết sáng tạo, có kỹ giao tiếp cần thiết để hiểu thấu vấn đề khách hàng Họ phải người làm việc nhóm có tính kỹ luật, kỹ sư phần mềm tài ba cho đời sản phẩm hạn thời gian cho phép 4.1.3 Nhu cầu thay đổi thường xuyên Khi thực phương pháp này, thành viên nhóm tiếp xúc thường xuyên với khách hàng, trao đổi thường xuyên để hoàn thiện dự án Do vậy, dự án có tính ổn định cao, thay đổi áp dụng phương pháp khơng cần thiết 4.1.4 Kích thước nhóm nhỏ, thành viên làm việc địa điểm Xuất phát từ yêu cầu trao đổi thông tin thường xuyên thành viên nhóm, nên phương pháp Agile địi hỏi nhóm khơng cần q nhiều thành viên, nhiều thành viên làm cho quản lý nhóm, trao đổi thành viên nhóm trở nên không hiệu Mặt khác, yêu cầu quan trọng thành viên phải làm việc địa điểm, trao đổi thơng tin có hiệu 4.1.5 Văn hóa cơng ty ưa thích “khơng trật tự” Bởi có thành viên mạnh dạn đưa kiến q trình làm việc nhóm Nhằm phát huy tính sáng tạo cao thành viên Trái lại, điều kiện sau vật cản cho việc áp dụng Agile:  Kích thước nhóm lớn  Các thành viên phân tán mặt địa lí (ví dụ dự án outsource)  Văn hóa làm việc theo mệnh lệnh 4.2 Cơ cấu làm việc Agile Phương pháp Agile thích hợp cho dự án có yêu cầu sản phẩm hay thay đổi nhanh chóng dự án Web hay sản phẩm cần hoàn tất khoảng thời gian ngắn Với phương pháp Agile, dự án chia thành nhiều phần nhỏ; phần hồn tất tuần hay tháng, gọi sprint Nhóm LớpT01 – Case study 13.1 phát triển gặp gỡ với người dùng trước sprint để ưu tiên hóa phần việc cần hoàn tất để lựa chọn phần việc nên hoàn tất sprint cụ thể Trong sprint, nhóm phát triển tổ chức nhiều họp nhóm ngày để thảo luận vai trị, trách nhiệm, phân cơng cụ thể Cuối sprint, nhóm “xuất xưởng” phần thành phẩm hoàn tất cho chức hay sản phẩm cuối Yếu tố then chốt phương pháp Agile kiến thức kỹ thành viên nhóm phát triển Agile loại bỏ khỏi dự án hoạt động không thiết yếu, dành thời gian cho thành viên nhóm tập trung phát triển phần mềm chất phương pháp việc cần diễn nhanh chóng Một nhóm giỏi thường triển khai dự án nhanh họ làm việc với mạch lạc, họ tự động đóng nhiều vai trị khác nhóm cần Nếu có u cầu thiết kế có người nhận lấy vai trị nhà thiết kế hồn thành phần việc đó, cần có lập trình viên người nhảy vào cơng việc lập trình ln Thực tế, có q nhiều người nhóm làm chậm lại cơng việc tất thành viên mối quan hệ trở nên phức tạp hay môi trường làm việc trở nên rối rắm Chính kinh nghiệm khả làm việc nhóm thiết yếu phương pháp Là thành viên nhóm, bạn phải làm việc tốt không muốn bị rơi rụng lại sau thành viên khác làm việc nhanh tốt Nên việc cẩn thận chọn lựa thành viên cho nhóm phát triển quan trọng ảnh hưởng đến thành cơng hay thất bại dự án Chọn nhầm người nhóm phải hứng chịu hậu họ phải nỗ lực tự điều chỉnh lại trước thái độ người hay ghen tức Chọn người có kỹ tương thích với thành viên khác nhóm khởi động tốt, dễ dàng vượt qua khó khăn Để nhóm thành cơng với phương pháp phát triển Agile, cần có tầm nhìn chung rõ ràng Tầm nhìn khơng chia sẻ thành viên nhóm mà cịn với người cơng ty Đa phần quy trình phát triển theo kế hoạch ủng hộ việc gây dựng tầm nhìn chung; nhiên, tầm nhìn khơng chia sẻ với nhiều người, dự án sa vào kế hoạch chi li với danh sách công việc quy trình Điều thường khơng xảy dự án áp dụng Agile thành viên dự án chia sẻ tầm nhìn cơng việc cần làm ngày Thường tầm nhìn cho dự án xuất phát từ khách hàng, người giám đốc hay lãnh đạo nhóm theo phương pháp Agile phải biến tầm nhìn thành kế hoạch có ý nghĩa cho người có liên quan cách tạo đối trọng mảng tầm nhìn khác với tập hợp hiểu biết kiến thức thành viên, vốn nguyên cho hòa hợp hợp tác thành viên Lập trình phần hoạt động phát triển phần mềm nào, cịn quan trọng quy trình Agile thành phẩm yếu Agile Các quy trình Agile ln ln khơng tách rời cơng đoạn lập trình với kiểm thử phương pháp phát triển theo kế hoạch Thay vào đó, code viết “đợt chạy nước rút” kiểm thử Các nhân viên kiểm thử lập trình làm việc chặt chẽ với nhau, thường họ đảm đương vai trò cần Đối với giám đốc phát triển, phương pháp phát triển theo kế hoạch tỏ có quy cũ tập trung đánh giá tiến độ sở kế hoạch ghi chép đầy đủ Người giám đốc phát triển theo dõi quy trình liên quan có đến số tài liệu cách hỏi (nhân viên) tài liệu có hay chưa Nếu cần có cấu hình cho u cầu, điều người giám đốc cần hỏi tài liệu cấu hình đâu, trước tập trung vào chất lượng nội dung 10 LớpT01 – Case study 13.1 Phương pháp Agile không tập trung vào việc thu thập lưu trữ tài liệu dự án để theo dõi tiến độ, giám đốc dự án thường phải kiểm tra báo cáo tình trạng sprint đó, vốn thường liệt kê ngày quan trọng, phần việc chưa hoàn thành sản phẩm, phần việc chưa hoàn thành sprint, xáo trộn công việc hàng ngày, đánh giá tình trạng dự án, biểu so sánh tiến độ với kế hoạch ban đầu, thông số đo lường số lượng lỗi, tỷ lệ phần trăm đạt yêu cầu lần kiểm thử, danh mục rũi ro dự án Nếu giám đốc dự án dân phần mềm, họ không thoải mái sử dụng thơng tin trên, chí, họ khơng biết cách định cách sử dụng thông tin 4.3 Quy trình thực 4.3.1 Lập kế hoạch Kế hoạch tổng thể dự án lập tuần Đại diện khách hàng lập trình viên chia dự án thành phần tăng trưởng nhỏ, ước lượng thời gian cơng sức thực chúng vạch lịch trình phát triển cho phần tăng trưởng Kế hoạch tổng thể điều chỉnh tùy theo tình hình phần sau dự án Mỗi phần tăng trưởng có kế hoạch thực cụ thể vạch vào đầu vòng lặp Đội dự án họp mặt hàng ngày để cập nhật tình hình cơng việc 4.3.2 Phân tích Agile khơng dành riêng khoảng thời gian cố định ban đầu cho việc phân tích yêu cầu Trái lại, đại diện khách hàng ngồi làm việc chung với đội dự án Người đại diện không thiết phải khách hàng thật, cần người hiểu rõ yêu cầu cho sản phẩm Khi cần thơng tin, lập trình viên việc đến trao đổi trực tiếp với người Đối với yêu cầu khó hiểu, đại diện khách hàng với tester tạo ví dụ chi tiết gọi “customer test” Đối với giao diện đồ họa, đại diện khách hàng đội dự án tạo phác thảo trước bắt tay vào lập trình Một số dự án thuê người thiết kế giao diện riêng 4.3.3 Thiết kế lập trình Trong dự án, thiết kế sản phẩm cải tiến liên tục Hoạt động thực nhờ phương pháp phát triển dựa test (test-driven development hay TDD) TDD gắn kết chặt chẽ công việc thiết kế, lập trình test Các lập trình viên phải làm việc theo cặp, hai người viết dòng lệnh cụ thể người suy nghĩ thiết kế chương trình Các lập trình viên tích hợp code vài lần đảm bảo phiên đủ tiêu chuẩn mặt kĩ thuật để bàn giao cho khách hàng Mã nguồn coi sở hữu tập thể Mọi người yêu cầu sửa lỗi lỗi gây 4.3.4 Test Tất thành viên dự án có trách nhiệm đảm bảo chất lượng sản phẩm Các lập trình viên thực unit test integration test Đại diện khách hàng kiểm tra cơng việc lập trình viên trợ giúp họ customer test Khi tester tìm lỗi, đội phân tích ngun nhân tìm cách cải tiến quy trình để ngăn ngừa lỗi tái diễn Tất regression test thực tự động (bởi code tích hợp vào hệ thống cách liên tục) chạy lập trình viên họ tích hợp code vào hệ thống Lập trình theo cặp góp phần làm tăng chất lượng công việc 4.3.5 Bàn giao sản phẩm Hệ thống trình diễn nội hàng tuần bàn giao cho khách hàng theo kế hoạch định trước theo nhu cầu khách hàng 11 LớpT01 – Case study 13.1 Kết luận Agile phương pháp hữu dụng Tuy nhiên, tất dự án áp dụng phương pháp dẫn tới thành công Các nhà quản lý dự án nên biết dự án sử dụng phương pháp Agile, sử dụng phải sử dụng thê cho cách Có việc sử dụng Agile thực mang lại hiệu 12 LớpT01 – Case study 13.1 TÀI LIỆU THAM KHẢO http://Jamesshore.com/Agile book/ http://www.workhabit.com http://agileintro.wordpress.com http://cmu.duytan.edu.vn 13