Tiểu luận hệ thống thông tin quản trị AGILE DEVELOPMENT CÓ THỂ LÀM CÔNG VIỆC KINH DOANH TRỞ NÊN NHANH CHÓNG VÀ NHẸ NHÀNG

Lớp IT003_111_T19- Nhóm 15- Case study 13.1 DANH SÁCH THÀNH VIÊN NHÓM STT Mã SV Họ và tên Nhiệm vụ Ký tên 1 030125090600 Nguyễn Thị Thùy Ni Dịch bài, tìm tài liệu, làm powerpoint,trả lời câu hỏi. 2 030125090615 Đặng Thị Kim Phi Tìm tài liệu, tổng hợp bài,chỉnh sữa word, thuyết trình. 3 030125090756 Lê Thị Thu Thủy Tìm tài liệu, làm powerpoint, trả lời câu hỏi. 4 030125090883 Phạm Thị Tiện Tìm tài liệu, tổng hợp, thuyết trình,viết lời mở. 5 030125090910 Thái Nguyễn Hạnh Trang Tìm tài liệu, trả lời câu hỏi,tóm tắt nội dung. 6 030125090963 Ngô Thị Thanh Trúc Tìm tài liệu, dịch bài, trả lời câu hỏi, viết lời kết. 1 Lớp IT003_111_T19- Nhóm 15- Case study 13.1 MỤC LỤC Mục lục 2 Bài dịch case study 3 Tóm tắt tình huống 5 Bài phân tích 6 1.Khái quát chung về mô hình Waterfall và mô hình Agile 6 1.1Mô hình thác nước Waterfall 6 1.2Phương pháp phát triển linh hoạt Agile 7 2.Phương pháp phát triển linh hoạt (Agile development method) 8 2.1Đặc điểm 8 2.2Nguyên tắc 9 3.So sánh mô hình Agile và mô hình thác nước 9 3.1.Mức độ rủi ro 9 3.2.Tính linh hoạt của mô hình 9 3.3.Thời gian và chi phí. 10 3.4.Giao tiếp 10 3.5.Giai đoạn sau khi hoàn thành sản phẩm 11 4.Áp dụng phương pháp Agile 11 4.1.Điều kiện áp dụng 11 4.2.Cơ cấu làm việc trong Agile 12 4.3.Quy trình thực hiện. 14 5.Thực trạng, giải pháp ứng dụng Agile ở Việt Nam 15 6.Kết luận 16 TÀI LIỆU THAM KHẢO 18 BÀI DỊCH CASE STUDY AGILE DEVELOPMENT CÓ THỂ LÀM CÔNG VIỆC KINH DOANH 2 Lớp IT003_111_T19- Nhóm 15- Case study 13.1 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 của nó nếu các nhà quản lý chấp nhận nó “Agile software development” có thể giúp ngăn ngừa các tổ chức bởi những ý tưởng và chiến lược kinh doanh lỗi thời, nhưng nó có thể khiến một số nhà quản trị lo lắng, theo lời của các chuyên gia nói với thành viên Hiệp hội máy tính New Zealand tại một cuộc họp NZCS gần đây. Theo lời nhà phát triển Shane Hastie: “Agile software development” là một trong những cách mà các IT có thể bảo vệ khỏi việc trở thành một gánh nặng trì trệ làm thay đổi các doanh nghiệp. Lối phân tích cứng rắn và kỹ thuật phát triển không linh hoạt có thể giam hãm các tổ chức vào những ý tưởng lỗi thời và cũng có thể kìm hãm sự phát triển thương mại. Quản lí có thể đánh giá cao những lợi ích của kỹ thuật phát triển nhanh, nhưng với điều kiện những lợi ích này được truyền đạt đúng cách, ông nói. Hastie, kỹ sư trưởng ở Hiệp hội phần mềm giáo dục, là một trong hai nhà phát triển đã diễn thuyết về giai đoạn “bird of the feather” trong phiên họp về phát triển nhanh, tổ chức tại Wellington vào đầu tháng này. Giải trình viên Stephen Hilson, hiện đang làm việc cho Telecom, cho biết các nhà quản lí nói chung và công nghệ thông tin nói chung đang lo lắng về tính chất thiếu tự nhiên của các phương pháp nhanh, đặc biệt là khi nói đến các ngành quan trọng, chẳng hạn như viễn thông. Theo lời Hilson: “ngành viễn thông phù hợp với công nghệ nhanh xung quanh một khung của sự phát triển theo mô hình thác nước nhiều hơn thông thường- bắt đầu với một đặc điểm kỹ thuật đầy đủ và làm việc thông qua thiết kế, lập trình và thử nghiệm giai đoạn tuyến tính”. Bản chất của Agile development là việc tạo ra các mảnh nhỏ của chương trình và đôi khi dẫn đến việc nhận ra rằng sự thiết kế ban đầu của chương trình hoặc là sẽ không làm việc hoặc là cần được sửa đổi. Điều này dẫn đến thiết kế lại lặp đi lặp lại và tái mã hóa, độc lập với các phần khác của sự phát triển. Bề ngoài, quá trình này có vẻ phi cấu trúc, nhưng yêu cầu “nổi sóng” có lẽ là thực sự thực tế với yêu cầu của cuộc sống phát triển. Trong một môi trường linh hoạt, thực hiện công việc thường xuyên theo dõi có nghĩa là chỉ có một công việc nhỏ được bỏ đi, Hastie nói. Ngược lại, một thiết kế không đáng tin dựa trên những đặc điểm kỹ thuật vững chắc, có thể cho thấy việc vứt bỏ nhiều hơn với những tác động chính ảnh hưởng lớn đến tiến độ dự án. Điều này rất quan trọng trong nguồn lực hạn chế ở New Zealand, ông 3 Lớp IT003_111_T19- Nhóm 15- Case study 13.1 nói. Và nếu các mục tiêu hoàn thành là khó nhìn thấy ngay, thì các kỹ thuật nhanh nhẹn có thể ít nhất là cung cấp đủ để các doanh nghiệp tiến xa hơn. Các diễn giả thừa nhận rằng, với sự phát triển nhanh, các sản phẩm cuối cùng có thể khác với yêu cầu ban đầu. Nhưng nó có xu hướng phù hợp hơn với nhu cầu của doanh nghiệp tại thời điểm hoàn thành- hơn là nhu cầu của mình khi bắt đầu, mà bây giờ có lẽ đã lỗi thời. Nếu quản lý và người sử dụng có liên quan, họ sẽ hiểu được logic của cách mà nhóm ICT lựa chọn để phát triển. Hastie phát biểu: “Hai trong số những yếu tố quan trọng nhất là trình độ cao về sự tham gia của khách hàng và hỗ trợ giám đốc điều hành. Nếu bạn có được chúng, bạn sẽ thành công bất kể bạn đang sử dụng thứ công nghệ gì”. Bản chất của phát triển nhanh đã được biết đến từ 10 đến 15 năm, và được biết đến như một thử nghiệm tốt, theo lời Hastie. Các yếu tố cần thiết đang được lập trình với các nhóm đồng nghiệp, chuyển tiếp nhanh chóng với những đơn vị nhỏ, liên hệ chặt chẽ với khách hàng, và sự tiếp xúc hằng ngày, nơi các nhà phát triển báo cáo về công việc mà họ đã đạt được từ cuộc họp cuối cùng, cũng như những gì họ dự định làm tiếp theo và bất kì trở ngại nào mà họ gặp phải. Phương pháp Agile đã được biết đến từ năm 2001- “Hãy kết hợp những thử nghiệm hay vào với nhau”. Câu hỏi: Những khác biệt giữa mô hình thác nước truyền thống và mô hình phát triển nhanh, đề xuất những ứng dụng tương ứng giữa chúng để liên kết mục tiêu của doanh nghiệp và chiến lược IT? TÓM TẮT TÌNH HUỐNG 4 Lớp IT003_111_T19- Nhóm 15- Case study 13.1 Agile development có thể làm công việc kinh doanh nhanh chóng và nhẹ nhàng hơn, giúp ngăn ngừa các tổ chức khỏi bị giam hãm vào những ý tưởng và chiến lược kinh doanh lỗi thời. Nó khắc phục được lối phân tích cứng rắn và kỹ thuật phát triển không linh hoạt cũng như những thiết kế không đáng tin ảnh hưởng đến tiến độ dự án. Tuy nhiên, vì tính chất thiếu tự nhiên của phương pháp nhanh mà có ý kiến cho rằng nó không phù hợp với ngành viễn thông. Bản chất của Agile development là việc tạo ra các mảnh nhỏ của chương trình và đôi khi những thiết kế ban đầu cần sẽ không được thực hiện hoặc sẽ được thay đổi, điều này có thể dẫn đến sản phẩm cuối cùng không giống với yêu cầu ban đầu nhưng nó phù hợp hơn với nhu cầu doanh nghiệp tại thời điểm hoàn thành. Hai trong số những yếu tố quan trọng nhất là trình độ cao về sự tham gia của khách hàng và sự hỗ trợ của giám đốc điều hành, nếu có được bạn sẽ thành công bất kể bạn đang sử dụng công nghệ gì. “Hãy kết hợp những thứ công nghệ này với nhau”. BÀI PHÂN TÍCH 5 Lớp IT003_111_T19- Nhóm 15- Case study 13.1 Ngày nay, công nghệ thông tin đóng một vai trò quan trọng trong các 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ác ứng dụng của công nghệ IT đã trở thành một phần không thể thiếu của đời sống cũng như các hoạt động của nền kinh tế nói chung và các doanh nghiệp nói riêng. Đặc biệt là việc phát triển hệ thống thông tin kinh doanh là yếu tố quan trọng góp phần vào sự thành công của doanh nghiệp. Hiện nay, có rất nhiều phương pháp phát triển hệ thống và một trong những phương pháp chiếm lĩnh ưu thế nhất, đáp ứng kịp thời nhu cầu của khách hàng là phương pháp phát triển Agile. Để hiểu rõ hơn về phương pháp này, sau đây là bài nghiên cứu mà nhóm chúng tôi đã thực hiện. 1. Khái quát chung về mô hình Waterfall và mô hình Agile 1.1. Mô hình thác nước Waterfall Mô hình thác nước (Waterfall) ra đời vào những năm 70, là một mô hình cổ điển và được áp dụng trong quy trình phát triển phần mềm tại phần lớn các công ty. Mô hình Waterfall là một chuỗi quy trình phát triển như một luồng đều đặn từ trên xuống giống như một thác nước, bao gồm các 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 và bảo trì. Mô hình này đề nghị các hoạt động được tiến hành như các giai đoạn tách biệt, giai đoạn sau sẽ không bắt đầu chừng nào giai đoạn trước chưa hoàn thành. Sản phẩm đầu ra của giai đoạn trước trở thành sản phẩm đầu vào của giai đoạn sau. . Trước hết, giai đoạn "xác định yêu cầu" phải được hoàn tất, kết quả nhận được sẽ là danh sách các yêu cầu đối với phần mềm. Sau khi các yêu cầu đã hoàn toàn được xác định, sẽ chuyển sang giai đoạn thiết kế, ở giai đoạn này người ta sẽ tạo ra các tài liệu dành cho lập trình viên, trong đó mô tả chi tiết các phương pháp và kế hoạch thực hiện các yêu cầu đã được làm rõ ở giai đoạn trước. Sau khi giai đoạn thiết kế hoàn tất, lập trình viên sẽ triển khai thực hiện (mã hóa, viết mã) đồ án họ nhận được. Giai đoạn tiếp theo là liên kết các thành phần riêng lẻ đã được những đội lập trình viên khác nhau thực hiện thành một sản phẩm hoàn chỉnh. Sau khi triển khai và liên kết hoàn tất, sẽ diễn ra việc kiểm thử và chỉnh sửa sản phẩm; ở giai đoạn này những khiếm khuyết ở các giai đoạn trước đó sẽ bị loại bỏ. Sau đó, sản phẩm phần mềm sẽ được đưa vào sử dụng; phần bảo trì phần mềm cũng sẽ được bảo đảm bằng cách bổ sung chức năng mới và loại trừ các lỗi. Ưu điểm của Waterfall là dễ quản lý. Tuy nhiên, nhược điểm của nó là quá cứng nhắc và thiếu thực tế bởi việc thay đổi của bất kỳ phần nào của quy trình cũng là không thể, vì việc làm lại các giai đoạn ban đầu để đáp ứng sự thay đổi thường mất rất nhiều công sức và phá vỡ cấu trúc phần mềm. Để khắc phục nhược điểm này của Waterfall, phương pháp Agile ra đời với mục tiêu là phần mềm phải có khả năng biến đổi, phát triển và tiến hóa theo thời 6 Lớp IT003_111_T19- Nhóm 15- Case study 13.1 gian mà không cần phải làm lại từ đầu. Phương thức này tập trung vào tính đơn giản: Tạo ra một phần mềm thật đơn giản đáp ứng đúng yêu cầu của khách hàng ngày hôm nay và sẵn sàng cho những thay đổi vào ngày mai. 1.2. Mô hình phát triển linh hoạt Agile. Agile là một triết lí cho việc phát triển phần mềm. Nói cách khác, đó là một cách “tư duy” về các dự án phần mềm. Các triết lí của Agile được cụ thể hóa bởi một số phương pháp phát triển phần mềm, chẳng hạn như Exetreme Programming (XP) hay Scrum, gọi tắt là các phương pháp Agile. Mỗi phương pháp Agile bao gồm tập hợp các quy tắc về sử dụng công cụ quản lí mã nguồn, quy tắc về các chuẩn lập trình hay quy tắc trình diễn sản phẩm hàng tuần cho khách hàng. Có thể nói, phương pháp phát triển linh hoạt Agile là một nhóm các phương pháp luận phát triển phần mềm dựa trên các nguyên tắc phát triển phân đoạn lặp và tiên tiến, theo đó nhu cầu và giải pháp tiến hóa thông qua sự hợp tác giữa các nhóm tự quản và liên chức năng. Agile thường sử dụng cách lập kế hoạch thích ứng, việc phát triển và chuyển giao theo hướng tiến hóa, sử dụng các khung thời gian ngắn và linh hoạt để dễ dàng phản hồi lại với các thay đổi trong quá trình phát triển. Nhờ tính linh hoạt, đa dạng và hiệu quả cao, các phương pháp Agile ngày càng trở thành sự lựa chọn hàng đầu của các khách hàng, nhà phát triển, các công ty phát triển phần mềm. 2. Phương pháp phát triển linh hoạt (Agile development method): Để khắc phục những đặc điểm của phương pháp Waterfall, vào đầu những năm 90, một phương pháp phát triển phần mềm mới đã ra đời. Phương pháp này cho phép các phần mềm có khả năng biến đổi, sửa chữa ngay cả khi dự án đã bắt đầu. Đó là 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 các dự án được hoàn thành nhanh chóng mà vẫn đảm bảo được yêu cầu về chất lượng và dễ dàng trong việc sửa chữa, cập nhật khi những yêu cầu thay đổi vào bất cứ giai đoạn nào của dự án cho đến khi dự án kết thúc và sản phẩm được giao cho khách hàng. Phương pháp phát triển linh hoạt có những đặc điểm sau:  Được phát triển dựa trên quy trình phát triển lặp (interative development) - mỗi dự án sẽ được chia ra thành nhiều mảng nhỏ, dễ sử dụng và dễ sửa đổi khi yêu cầu của khách hàng thay đổi. Dự án sẽ được thực hiện theo từng mảng nhỏ này, giống như những dự án nhỏ, hết dự án này quy trình sẽ lại bắt đầu với dự án tiếp theo cho đến khi tất cả những yêu cầu của khách hàng được đáp ứng và dự án được bàn giao.  Với phương pháp phát triển linh hoạt, cứ mỗi hai hay bốn tuần, nhóm lập trình viên sẽ giao cho khách hàng một phần của dự án, khách hàng sẽ kiểm tra và được khuyến khích đưa ra những ý kiến, nếu khách hàng muốn có sự thay đổi nào thì nhóm lập trình viên sẽ sửa đổi. Cần lưu ý là không giống phương pháp 7 Lớp IT003_111_T19- Nhóm 15- Case study 13.1 Waterfall, việc sửa đổi này giúp cho ứng dụng tốt hơn, đẹp hơn và 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, từng phần nhỏ của dự án phần mềm sẽ được test ngay trong quá trình làm dự án và việc này do chính các lập trình viên làm thay vì phải có cá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 từng phần). Từng phần của dự án sẽ được kiểm tra ngay trong quá trình phát triển trước khi 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 giữa các thành viên trong nhóm dự án. Khác với phương pháp phát triển truyền thống, các thành viên của nhóm dự án được chia ra phát triển từng mảng riêng biệt, với phương pháp Agile, tại mỗi thời điểm, cả nhóm cùng tập trung phát triển một mảng dự án. Vì vậy, phương pháp Agile yêu cầu các thành viên có sự tập trung về địa lí, cùng bàn bạc thảo luận hàng ngày để hoàn thành dự án đúng hạn.  Phương pháp phát triển Agile dựa vào việc phát triển trên từng nhóm nhỏ (10 thành viên trở xuống), các thành viên phải là những người có kĩ năng cao và hiểu biết về dự án, hơn nữa, các thành viên cần tin tưởng lẫn nhau, chia sẻ thông tin với nhau. Với nhóm ít thành viên, các thành viên cũng cần có nhiều kĩ năng hơn so với việc lập trình và kiểm thử truyền thống.  Với những đặc điểm như trên, hiện nay phương pháp phát triển linh hoạt đang ngày càng được ứng dụng rộng rãi với những phần mềm trị giá hàng chục triệu, thậm chí hàng trăm triệu đô la Mỹ. 2.2. Nguyên tắc: - Ưu tiên cao nhất của dự án là thỏa mãn khách hàng bằng việc bàn giao sản phẩm sớm và linh hoạt. - Hoan nghênh các thay đổi từ phía khách hàng, kể cả các 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 hơn chu kỳ dài. - Các nhân viên hiểu nghiệp vụ và các lập trình viên phải làm việc cùng nhau hằng ngày. - Tổ chức dự án xoay quanh những cá nhân tích cực, hỗ trợ và tin tưởng họ. - Phương pháp giao tiếp tốt nhất trong đội dự án là gặp mặt trực tiếp. - Các chức năng đã hoạt động là thước đo chính 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ả năng tham gia dự án một cách liên tục. - Liên tục cải tiến chất lượng thiết kế và mã nguồn. - Tính đơn giản giữ vai trò cốt yếu, làm càng ít càng tốt. - Những yêu cầu và thiết kế tốt nhất được nảy nở từ những nhóm làm việc tự chủ. Sau những khoảng thời gian nhất định, đội dự án xem xét cách thức cải tiến hiệu quả công việc. 3. So sánh mô hình Agile và mô hình thác nước 8 Lớp IT003_111_T19- Nhóm 15- Case study 13.1 Phương pháp phát triển linh hoạt đôi khi bị đánh giá là thiếu tính kỷ luật. Nhưng hiểu vấn đề một cách đúng đắn thì phương pháp phát triển linh hoạt có khả năng thích ứng cao, nhanh chóng thích nghi với những thay đổi thực tế. 3.1. Mức độ rủi ro: Mô hình thác nước thực hiện bước kiểm tra dự án chỉ một lần cuối cùng sau khi tổng hợp kết quả làm việc của các nhóm. Vì vậy nếu như có lỗi hay sai sót gì trong dự án thì rất khó để sửa được. Vấn đề chỉ có thể giải quyết bằng cách sửa lại và thiết kế một hệ thống hoàn toàn mới. Và như thế thì sẽ nâng cao chi phí kiểm tra và sửa lỗi. Mô hình Agile cố gắng cực tiểu hoá rủi ro bằng cách phát triển phần mền trong những khung thời gian ngắn. Mỗi bước lặp giống như phát triển một phần mềm hoàn chỉnh cũng gồm có lấy yêu cầu, làm phân tích thiết kế, viết code, test, viết tài liệu. Cho nên khi lỗi sẽ được phát hiện sau mỗi giai đoạn chứ không phải là khi hoàn thành sản phẩm nên sẽ ít tốn kém thời gian và chi phí hơn. 3.2. Tính linh hoạt của mô hình Mô hình Agile rất hoan nghênh những đóng góp của khách hàng để hoàn thiện sản phẩm hơn. Có nghĩa là mặc dù đã tiến hành dự án nhưng phương pháp Agile vẫn có thể thay đổi hoặc thêm vào theo yêu cầu của khách hàng. Mô hình thác nước thì đòi hỏi tất cả các thông tin về sản phẩm và yêu cầu đặt ra phải hoàn hảo ngay từ đầu và chỉ một thay đổi nhỏ hoặc sai sót sẽ ảnh hưởng đến toàn hệ thống. Cho nên một khi dự án bắt đầu thì rất khó để thay đổi theo yêu cầu mới của khách hàng. 3.3. Thời gian và chi phí Mô hình thác nước ngay từ ban đầu đã hoạch định được rõ ràng thời gian hoàn thành và số vốn đầu tư cho dự án. Thường mức độ sai lệch rất thấp. Còn mô hình Agile có thể thay đổi theo yêu cầu của khách hàng nên khó để xác định được thời gian hoàn thành sản phẩm và số tiền cần thiết sử dụng khi bắt đầu dự án. Theo phương pháp này thì chỉ có thể trả lời câu hỏi cho từng giai đoạn ngắn. 3.4. Giao tiếp Phương pháp Agile nhấn mạnh tầm quan trọng của giao tiếp thời gian thực, giao tiếp mặt đối mặt được đánh giá cao hơn là các tài liệu viết. Hầu hết các đội phát triển theo kiểu Agile đều được tập trung trong một môi trường có điều kiện thuận lợi cho việc giao tiếp và các đội này phải bao gồm các lập trình viên và các khách hàng của họ. Mô hình thác nước thì ít có sự liên kết với nhau, sau khi được chia nhóm để thực hiện từng phần của dự án thì họ làm việc riêng lẻ và không có sự trao đổi với nhau, về phía khách hàng thì như đã nói phương pháp này ít có sự thay đổi nên vai trò của khách hàng không được phát huy trong quá trình thực hiện dự án. Chỉ cho 9 Lớp IT003_111_T19- Nhóm 15- Case study 13.1 đến khi các giai đoạn hoàn thành và tạo ra sản phẩm cuối cùng thì họ mới gặp gỡ nhau để kiểm tra sản phẩm và tìm lỗi sai. 3.5. Giai đoạn sau khi hoàn thành sản phẩm Mô hình thác nước không thể tiêp tục phát triển được sản phẩm của mình nữa. Nhưng mô hình Agile thì khác, trong khi thực hiện dự án họ có thể tạo ra những sản phẩm có những tính chất cơ bản mà khách hàng yêu cầu để đáp ứng một cách sớm nhất và dựa trên sản phẩm đó họ có thể nâng cấp sản phẩm để có thêm những tính năng mới mà khách hàng mong muốn. 4. Áp dụng phương pháp Agile 4.1. Điều kiện áp dụng Agile ra đời là sự cách tân, khắc phục những hạn chế mà các phương pháp truyền thống không thực hiện được. Tuy nhiên, có phải lúc nào sử dụng phương pháp Agile cũng là tốt hay không? Ví dụ, nếu mục tiêu của bạn là nhằm tăng năng suất lao động, làm cho các lập trình viên làm việc nhanh hơn thì Agile không phù hợp vì nguyên tắc của nó không nhằm làm tăng năng suất. Một phương pháp bất kì nào cũng đều có những ưu, nhược điểm riêng. Do vậy, để có thể lựa chọn được phương pháp phù hợp với dự án của mình, trước hết bạn phải trả lời được những câu hỏi sau: Với dự án này, điều kiện công ty như thế này thì việc áp dụng phương pháp này hay phương pháp kia thì mang lại hiệu quả cho doanh nghiệp, cho công ty của bạn nhiều hơn ?; lợi ích và những thiệt hại mà công ty có thể gặp phải khi áp dụng mô hình đó? Theo như những đặc điểm đã phân tích ở trên thì doanh nghiệp có những đặc điểm sau sẽ phù hợp với việc áp dụng mô hình Agile: Thứ nhất, mức độ rủi ro thấp. Mức độ rủi ro của dự án có thể hiểu là khả năng thực hiện và mức độ thành công của dự án. Bất kì một dự án nào, nếu mức độ rủi ro cao và khả năng thành công của dự án thấp thì hiếm khi hoặc không được thực hiện. Thứ hai, kích thước nhóm nhỏ, các thành viên cùng làm việc tại một địa điểm. Từ đặc điểm thường xuyên trao đổi thông tin giữa các thành viên trong nhóm với nhau, phương pháp Agile rất thích hợp với những dự án có nhóm nhỏ từ hai đến tám người, vì nếu đông người quá thì việc trao đổi thông tin sẽ kém hiệu quả, các thành viên trong nhóm có thể sẽ đùn đẩy trách nhiệm cho nhau, môi trường làm việc sẽ không thân thiện. Ngoài ra, trong phương pháp Agile, một thành viên trong nhóm có thể làm nhiều công việc, từ giao tiếp với khách hàng, thu nhận yêu cầu, thiết kế, bàn giao….nên không cần quá nhiều người trong cùng một nhóm. Bên cạnh đó, các thành viên trong nhóm phải cùng làm việc tại một địa điểm thì việc trao đổi thông tin mới được thuận lợi. Thứ ba, thành viên trong nhóm có kinh nghiệm. Vì Agile tập trung cho các dự án nhỏ và có thời gian hoàn tất ngắn nên đòi hỏi có những cá nhân tài năng, 10 [...]... sẵn lòng làm mọi chuyện và có năng lực tổng quát hóa, có thể làm nhiều công việc trong quá trình sản xuất sản phẩm Phương pháp Agile cần có cá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, và có các kỹ năng giao tiếp cần thiết để hiểu được những yêu cầu của khách hàng Họ cũng phải là những người làm việc nhóm có tính kỹ luật, và là những kỹ sư phần mềm tài ba có thể cho... mặt các thành viên trong nhóm để thảo luận, xem xét ý kiến và phân công công việc cụ thể Cuối mỗi sprint, cả nhóm sẽ họp mặt và đưa ra sản phẩm cuối cùng của mỗi giai đoạn Yếu tố then chốt của phương pháp Agile là trách nhiệm và kỹ năng làm việc của các thành viên Do vậy, Agile chỉ tập trung vào giải quyết những công việc then chốt Công việc sẽ được hoàn thành nhanh, chất lượng tốt nếu được thực hiện... viên giỏi và có tinh thần trách nhiệm cao Nếu bạn không cố gắng trong công việc, bạn sẽ bị bỏ lại sau lưng Việc lựa chọn thành viên nhóm đặc biệt quan trọng trong phương pháp này, nếu bạn lựa người không kĩ, hậu quả là công việc nhóm bạn sẽ bị ngưng trệ và ảnh hưởng đến công việc chung của cả quá trình sản xuất Để một nhóm có thể thành công với phương pháp Agile thì cần có một tầm nhìn chung và tổng... liên doanh hoặc văn hóa của doanh nghiệp gia đình Hạt nhân văn hóa doanh nghiệp bao gồm triết lý, niềm tin, các chuẩn mực làm việc và hệ giá trị Thứ ba, phát triển văn hóa giao lưu của các doanh nghiệp Các doanh nghiệp thường có xu hướng liên doanh, liên kết với nhau Để tồn tại trong môi trường kinh doanh phức tạp, đa văn hóa, các doanh nghiệp không thể duy trì văn hóa doanh nghiệp mình giống như những... trình làm việc, đại diện của khách hàng sẽ cùng tham gia vào quá trình làm việc của các lập trình viên, có thể thay đổi yêu cầu ban đầu trong quá trình làm việc của các lập trình viên Người đại diện này không nhất thiết phải là khách hàng thật, chỉ cần họ nắm rõ và hiểu những yêu cầu về sản phẩm để có thể trao đổi với các lập trình viên khi cần thiết Khi các lập trình viên có thắc mắc gì có thể trao... Vũ (2011); Hệ thống thông tin quản trị 2 Slide Hệ thống thông tin quản trị, trường Đại học Ngân Hàng TPHCM, 2011 II Nguồn từ Internet: 3 Trang chủ Tailieu.vn, lấy về lúc 19h04 ngày 20/11/2011, tại http://tailieu.vn/xem-tai-lieu/phuong-phap-phat-trien-linh-hoat-agiledevelopment-methods-.176508.html 4 Trang chủ Niku, lấy về lúc 19h48 ngày 20/11/201, tại http://my.opera.com/lenamduytuan/blog /agile, Phương... thời gian ngắn Một sản phẩm trong Agile có thể được chia thành nhiều phần, mỗi phần có thể được hoàn thành trong một khoản thời gian ngắn, một tuần, một tháng chẳng hạn Mỗi phần như vậy được gọi là một “sprint” Trước mỗi sprint, nhóm phát triển gặp gỡ người dùng và thảo luận xem phần công việc nào nên được ưu tiên hoàn thành trước và sprint đó bao gồm những công việc cụ thể nào 11 Lớp IT003_111_T19- Nhóm... chung, Việt Nam nói riêng đã trở thành một rào cản cho việc áp dụng phương pháp Agile Với tâm lý làm việc cá nhân, hoạt động nhóm không hiệu quả và sự cạnh tranh không lành mạnh giữa các cá thể trong một doanh nghiệp khiến cho những người có năng lực không được làm việc đúng với khả năng của mình, đồng nghĩa với việc vi phạm nguyên tắc áp dụng phương pháp Agile Phương pháp Agile chỉ đạt hiệu quả khi... hóa doanh nghiệp từ đó giúp phương pháp Agile được áp dụng ngày càng rộng rãi và hiệu quả tại Việt Nam: Thứ nhất, xây dựng văn hoá doanh nghiệp trên cơ sở nào? Khi xây dựng văn hóa doanh nghiệp cần phải có những biện pháp cụ thể Biện pháp đầu tiên là phải xây dựng một hệ thống định chế của doanh nghiệp, bao gồm: Chính danh, tự kiểm soát, phân tích các công việc, các yêu cầu Sau đó xây dựng các kênh thông. .. sẽ không thích thú khi đọc những thông tin trên, thậm chí sẽ không biết cách để đưa ra những quyết định từ những thông tin đó 4.3 Quy trình làm việc a) Lập kế hoạch 12 Lớp IT003_111_T19- Nhóm 15- Case study 13.1 Đại diện khách hàng và các lập trình viên công ty sẽ gặp và trao đổi với nhau về dự án, lập lịch trình cho quá trình làm việc, giai đoạn nào gồm những công việc nào, thời gian dự kiến là bao . 18 BÀI DỊCH CASE STUDY AGILE DEVELOPMENT CÓ THỂ LÀM CÔNG VIỆC KINH DOANH 2 Lớp IT003_111_T19- Nhóm 15- Case study 13.1 TRỞ NÊN NHANH CHÓNG VÀ NHẸ NHÀNG Nhưng công nghệ thông tin phải truyền đạt. Case study 13.1 Agile development có thể làm công việc kinh doanh nhanh chóng và nhẹ nhàng hơn, giúp ngăn ngừa các tổ chức khỏi bị giam hãm vào những ý tưởng và chiến lược kinh doanh lỗi thời nền kinh tế nói chung và các doanh nghiệp nói riêng. Đặc biệt là việc phát triển hệ thống thông tin kinh doanh là yếu tố quan trọng góp phần vào sự thành công của doanh nghiệp. Hiện nay, có rất