Bài giảng Nhập môn Công nghệ phần mềm - Chương 9: Phát triển phần mềm linh hoạt - Nguyễn Thị Minh Tuyền

Nội dung text: Bài giảng Nhập môn Công nghệ phần mềm - Chương 9: Phát triển phần mềm linh hoạt - Nguyễn Thị Minh Tuyền

1. Phát triển phần mềm linh hoạt Nguyễn Thị Minh Tuyền Nội dung của slide này dựa vào các slide của Ian Sommerville
2. Nội dung v Các phương pháp linh hoạt v Phát triển hoạch định sẵn và linh hoạt v Extreme programming v Quản trị dự án linh hoạt v Mở rộng quy mô các phương pháp linh hoạt Nguyễn Thị Minh Tuyền 2 Nhập môn CNPM
3. Nội dung v Các phương pháp linh hoạt v Phát triển hoạch định sẵn và linh hoạt v Extreme programming v Quản trị dự án linh hoạt v Mở rộng quy mô các phương pháp linh hoạt Nguyễn Thị Minh Tuyền 3 Nhập môn CNPM
4. Phát triển phần mềm linh hoạt v Phát triển và phân phối phần mềm nhanh thường là yêu cầu quan trọng nhất đối với hệ thống phần mềm hiện nay § Tác vụ thương mại thực hiện nhanh – yêu cầu luôn thay đổi và không thực tế nếu định nghĩa trước một tập các yêu cầu phần mềm ổn định. § Phần mềm phải cải tiến nhanh chóng để đáp ứng được sự thay đổi nhanh về nhu cầu của tác vụ thương mại. v Phát triển phần mềm nhanh § Đặc tả, thiết kế và cài đặt đan xen nhau. § Hệ thống được phát triển như là một chuỗi các phiên bản trong đó stakeholder tham gia vào việc đánh giá các phiên bản. § Giao diện người dùng thường được phát triển sử dụng IDE và các công cụ đồ họa. Nguyễn Thị Minh Tuyền 4 Nhập môn CNPM
5. Các phương pháp linh hoạt v Vào những năm 80 và 90, việc không thỏa mãn với các phụ phí trong các phương pháp thiết kế phần mềm dẫn đến việc tạo ra các phương pháp linh hoạt: § Tập trung vào mã nguồn hơn là thiết kế. § Dựa vào phương pháp phát triển phần mềm theo kiểu vòng lặp. § Với mục đích phân phối sản phẩm phần mềm nhanh và cải tiến nhanh để đáp ứng các yêu cầu thay đổi. v Mục tiêu: giảm các phụ phí trong quy trình phần mềm § Bằng việc hạn chế việc viết tài liệu và cho phép trả lời nhanh các thay đổi về yêu cầu mà không cần làm lại quá nhiều. Nguyễn Thị Minh Tuyền 5 Nhập môn CNPM
6. Tuyên ngôn của phương pháp linh hoạt v Chúng tôi đang tìm ra những cách tốt hơn để phát triển phần mềm bằng cách tự tay phát triển nó và giúp đỡ người khác làm việc đó. Thông qua việc này, chúng tôi đã đi đến chỗ đánh giá cao: § Các cá nhân và tương tác hơn là quy trình và công cụ § Phần mềm hoạt động được hơn là tài liệu đầy đủ § Sự cộng tác của khách hàng hơn là thương lượng hợp đồng § Trả lời nhanh sự thay đổi hơn là làm theo kế hoạch v Đó là, dù là các điểm bên phải có giá trị, nhưng chúng tôi đánh giá cao các điểm bên trái hơn. Nguyễn Thị Minh Tuyền 6 Nhập môn CNPM
7. Nguyên lý của phương pháp linh hoạt Nguyên lý Mô tả Sự tham gia của khách Khách hàng nên tham gia trực tiếp vào quy trình phát triển. hàng Vai trò: - cung cấp và phân độ ưu tiên cho các yêu cầu mới của hệ thống và - đánh giá các vòng lặp của hệ thống. Phân phối dần dần Phần mềm được phát triển từng phần (increment) trong đó khách hàng chỉ ra yêu cầu trong mỗi phần đó. Chú trọng vào con Kỹ năng của nhóm phát triển nên được nhận diện và khai thác. người hơn là quy trình Các thành viên của nhóm nên được tự do làm việc theo cách của họ mà không cần đến các quy trình định trước. Chấp nhận thay đổi Hiểu rằng yêu cầu hệ thống sẽ thay đổi, vì vậy thiết kế hệ thống sao cho có thể chấp nhận các thay đổi đó. Duy trì sự đơn giản Tập trung vào tính đơn giản của cả phần mềm được phát triển và quy trình phát triển. Bất cứ khi nào có thể, nên chủ động nỗ lực loại bỏ những điểm phức tạp khỏi hệ thống. Nguyễn Thị Minh Tuyền 7 Nhập môn CNPM
8. Tính ứng dụng của phương pháp linh hoạt v Phát triển các sản phẩm nhỏ và vừa để bán. v Phát triển các sản phẩm đặt hàng trong đó § việc khách hàng chấp nhận tham gia vào quy trình phát triển được xác nhận rõ ràng và § không có nhiều quy tắc và quy định bên ngoài ảnh hưởng lên phần mềm. v Vì trọng tâm tập trung vào các nhóm phát triển nhỏ, gắn kết chặt chẽ với nhau, do đó có nhiều vấn đề xảy ra khi mở rộng phương pháp linh hoạt cho các hệ thống lớn. Nguyễn Thị Minh Tuyền 8 Nhập môn CNPM
9. Các vấn đề gặp phải với phương pháp linh hoạt v Có thể khó khăn trong việc giữ được mối quan tâm của khách hàng khi họ tham gia vào quy trình. v Các thành viên của nhóm có thể không phù hợp với cường độ làm việc đặc thù của phương pháp linh hoạt. v Nếu hệ thống có nhiều stakeholder thì việc xếp độ ưu tiên cho các thay đổi có thể khó khăn. v Duy trì tính đơn giản đòi hỏi công sức. v Hợp đồng có thể là một vấn đề tương tự các phương pháp vòng lặp khác. Nguyễn Thị Minh Tuyền 9 Nhập môn CNPM
10. Phương pháp linh hoạt và bảo trì phần mềm v Hầu hết các tổ chức dành nhiều thời gian để bảo trì hệ thống đang tồn tại hơn là họ phát triển mới hoàn toàn. § Vì vậy nếu phương pháp linh hoạt thành công, họ phải hỗ trợ việc bảo trì cũng như phát triển bản gốc. v Hai vấn đề chính: § Các hệ thống được phát triển sử dụng phương pháp linh hoạt có bảo trì được không, nhấn mạnh rằng trong quy trình phát triển ta giảm thiểu tài liệu mang tính hình thức? § Các phương pháp linh hoạt có được dùng hiệu quả cho việc cải tiến một hệ thống để trả lời việc khách hàng thay đổi yêu cầu không? v Các vấn đề có thể nảy sinh nếu nhóm phát triển ban đầu không được duy trì. Nguyễn Thị Minh Tuyền 10 Nhập môn CNPM
11. Nội dung v Các phương pháp linh hoạt v Phát triển hoạch định sẵn và linh hoạt v Extreme programming v Quản trị dự án linh hoạt v Mở rộng quy mô các phương pháp linh hoạt Nguyễn Thị Minh Tuyền 11 Nhập môn CNPM
12. Phát triển linh hoạt và hoạch định sẵn v Phát triển hoạch định sẵn § Phương pháp hoạch định sẵn dựa vào các giai đoạn phát triển tách biệt với các đầu ra được tạo ra ở mỗi giai đoạn đã được lên kế hoạch trước. § Không nhất thiết phải là mô hình thác nước, có thể là phương pháp phát triển dần dần. § Vòng lặp xảy ra bên trong các hoạt động. v Phát triển linh hoạt § Đặc tả, thiết kế, cài đặt và kiểm thử đan xen nhau và § Đầu ra từ quy trình phát triển được quyết định thông qua quá trình thương lượng trong suốt quá trình phát triển phần mềm. Nguyễn Thị Minh Tuyền 12 Nhập môn CNPM
13. Đặc tả linh hoạt và hoạch định sẵn Plan-based development Requirements Requirements Design and engineering specification implementation Requirements change requests Agile development Requirements Design and engineering implementation Nguyễn Thị Minh Tuyền 13 Nhập môn CNPM
14. Các vấn đề về kỹ thuật, con người và tổ chức 1. Có cần đặc tả và thiết kế rất chi tiết trước khi chuyển sang cài đặt hay không? • Nếu có, ta cần sử dụng phương pháp hoạch định sẵn. 2. Chiến lược chuyển giao tăng dần có thực tế không? • Nếu có, xem xét việc sử dụng phương pháp linh hoạt. 3. Hệ thống cần phát triển lớn đến đâu? • Các phương pháp linh hoạt hiệu quả nhất khi hệ thống được phát triển với một đội ngũ nhỏ làm việc cùng một nơi và giao tiếp thân mật với nhau. • Hệ thống lớn đòi hỏi đội ngũ phát triển lớn hơn, do đó có thể sử dụng phương pháp hoạch định sẵn. Nguyễn Thị Minh Tuyền 14 Nhập môn CNPM
15. Các vấn đề về kỹ thuật, con người và tổ chức 4. Loại hệ thống nào được phát triển? • Các phương pháp hoạch định sẵn thích hợp với các hệ thống đòi hỏi một lượng phân tích lớn trước khi cài đặt ( ví dụ hệ thống thời gian thực với yêu cầu định thời phức tạp). 5. Thời gian sử dụng hệ thống? • Các hệ thống được mong đợi sử dụng càng lâu thì có thể yêu cầu nhiều tài liệu thiết kế để truyền đạt được ý định ban đầu của người phát triển hệ thống cho nhóm hỗ trợ. 6. Công nghệ nào sẵn có để hỗ trợ sự phát triển hệ thống? • Phương pháp linh hoạt dựa vào các công cụ tốt để ghi lại dấu vết của việc thiết kế liên tục thay đổi. 7. Đội ngũ phát triển được tổ chức như thế nào? • Nếu đội ngũ phát triển phân tán hoặc một phần của việc phát triển được gia công bên ngoài thì ta cần phát triển các tài liệu thiết kế để giao tiếp giữa các nhóm phát triển với nhau. Nguyễn Thị Minh Tuyền 15 Nhập môn CNPM
16. Các vấn đề về kỹ thuật, con người và tổ chức 8. Các vấn đề về văn hóa và tổ chức có ảnh hưởng đến sự phát triển hệ thống hay không? • Các tổ chức công nghệ truyền thống có văn hóa của việc phát triển hoạch định sẵn, và đây là chuẩn của công nghệ. 9. Trình độ của người thiết kế và người lập trình trong nhóm phát triển tốt đến đâu? • Phương pháp linh hoạt đòi hỏi kỹ năng cao hơn phương pháp hoạch định sẵn. Trong phương pháp hoạch định sẵn, người lập trình chỉ việc chuyển các thiết kế chi tiết thành mã nguồn. 10. Hệ thống có chịu sự chi phối bởi các quy định từ bên ngoài không? • Nếu một hệ thống phải được duyệt bởi một nhân tố bên ngoài thì nó cần đến các tài liệu chi tiết. Nguyễn Thị Minh Tuyền 16 Nhập môn CNPM
17. Nội dung v Các phương pháp linh hoạt v Phát triển hoạch định sẵn và linh hoạt v Extreme programming v Quản trị dự án linh hoạt v Mở rộng quy mô các phương pháp linh hoạt Nguyễn Thị Minh Tuyền 17 Nhập môn CNPM
18. Các phương pháp linh hoạt v Agile Modeling v Agile Unified Process (AUP) v Dynamic Systems Development Method (DSDM) v Essential Unified Process (EssUP) v Extreme Programming (XP) v Feature Driven Development (FDD) v Open Unified Process (OpenUP) v Scrum v Velocity tracking Nguyễn Thị Minh Tuyền 18 Nhập môn CNPM
19. Extreme programming v Được xem là phương pháp linh hoạt nổi tiếng và được sử dụng rộng rãi nhất. v Extreme Programming (XP) có một cách tiếp cận “cực đoan” đối với việc phát triển vòng lặp. § Các phiên bản mới có thể được xây dựng vài lần mỗi ngày; § Các phần được phân phối đến khách hàng hai tuần một lần; § Tất cả các test phải được chạy ở mỗi phiên bản và phiên bản đó chỉ được chấp nhận nếu các test đều thành công. Nguyễn Thị Minh Tuyền 19 Nhập môn CNPM
20. XP và các phương pháp linh hoạt v Việc phát triển từng phần được hỗ trợ thông qua các bản release nhỏ, thường xuyên. v Sự tham gia của khách hàng đồng nghĩa với việc cam kết tham gia toàn thời gian với đội ngũ phát triển. v Đặt nặng yếu tố con người hơn là quy trình thông qua lập trình cặp, sở hữu tập thể và một quy trình hạn chế làm việc nhiều giờ. v Các thay đổi được hỗ trợ thông qua các bản release thường xuyên. v Duy trì tính đơn giản thông qua việc cải thiện thường xuyên mã nguồn. Nguyễn Thị Minh Tuyền 20 Nhập môn CNPM
21. Vòng lặp tạo ra các bản release trong phương pháp XP Select user Break down stories for this Plan release stories to tasks release Evaluate Release Develop/integrate/ system software test software Nguyễn Thị Minh Tuyền 21 Nhập môn CNPM
22. Các nguyên tắc của XP Nguyên tắc Mô tả Lập kế hoạch tăng dần Các yêu cầu được ghi lại trên các story card, việc quyết định xem các story nào được nằm trong một bản release là tùy thuộc vào thời gian và mức độ ưu tiên tương đối giữa chúng. Người phát triển chia các story thành các tác vụ. Các bản release nhỏ Một tập tối thiểu các chức năng hữu ích mang lại giá trị công việc được phát triển đầu tiên. Các bản release của hệ thống được đưa ra thường xuyên và thêm tính năng dần dần vào bản release đầu tiên. Thiết kế đơn giản Chỉ thiết kế vừa đủ để thỏa mãn các yêu cầu hiện tại và không hơn. Phát triển test trước Sử dụng một framework cho unit test để viết các test cho một chức năng trước khi cài đặt tính năng đó. Cải tiến mã nguồn Mong muốn cả nhóm phát triển tham gia vào việc cải thiện liên tục mã nguồn bất cứ khi nào có điểm cần cải tiến. Việc này làm cho mã nguồn trở nên đơn giản và dễ bảo trì. Nguyễn Thị Minh Tuyền 22 Nhập môn CNPM
23. Các nguyên tắc của XP Lập trình cặp Người phát triển làm việc theo cặp, người này kiểm tra công việc của người kia và hỗ trợ để đảm bảo công việc luôn luôn tốt. Sở hữu tập thể Các cặp phát triển làm việc trong mọi lĩnh vực của hệ thống, để không xảy ra tình trạng mỗi người chỉ thông thạo một vùng và tất cả các thành viên của nhóm phát triển chịu trách nhiệm cho toàn bộ mã nguồn. Bất cứ ai cũng có thể sửa bất cứ cái gì. Tích hợp liên tục Mỗi khi một tác vụ được hoàn thành, nó được tích hợp ngay vào hệ thống. Sau mỗi lần tích hợp như vậy, tất cả các unit test phải được chạy thành công. Tiến độ bền Làm việc quá giờ quá nhiều không được chấp nhận do hệ vững quả thường là giảm chất lượng mã nguồn và giảm năng suất trung hạn. Khách hàng tại Một người đại diện của người dùng cuối (khách hàng) sẽ chỗ luôn luôn sẵn sàng tham gia. Trong một quy trình XP, khách hàng là một thành viên của nhóm phát triển và có trách nhiệm đưa ra các yêu cầu để nhóm cài đặt. Nguyễn Thị Minh Tuyền 23 Nhập môn CNPM
24. Kịch bản yêu cầu v Trong XP, người khách hàng hoặc người dùng là một phần của nhóm XP và có trách nhiệm đưa ra các quyết định về yêu cầu. v Yêu cầu người dùng được biểu diễn dưới dạng các kịch bản hoặc user story. § Được viết trên các story card và § Chia nhỏ các story thành các tác vụ để cài đặt. Đây là cơ sở để lập kế hoạch và ước lượng chi phí. v Khách hàng chọn các story cần được đáp ứng trong bản release tiếp theo § Dựa vào độ ưu tiên và ước lượng về kế hoạch. Nguyễn Thị Minh Tuyền 24 Nhập môn CNPM
25. Một story về kê đơn thuốc Prescribing medication The record of the patient must be open for input. Click on the medication field and select either ‘current medication’, ‘new medication’ or ‘formulary’. If you select ‘current medication’, you will be asked to check the dose; If you wish to change the dose, enter the new dose then confirm the prescription. If you choose, ‘new medication’, the system assumes that you know which medication you wish to prescribe. Type the first few letters of the drug name. You will then see a list of possible drugs starting with these letters. Choose the required medication. You will then be asked to check that the medication you have selected is correct. Enter the dose then confirm the prescription. If you choose ‘formulary’, you will be presented with a search box for the approved formulary. Search for the drug required then select it. You will then be asked to check that the medication you have selected is correct. Enter the dose then confirm the prescription. In all cases, the system will check that the dose is within the approved range and will ask you to change it if it is outside the range of recommended doses. After you have confirmed the prescription, it will be displayed for checking. Either click ‘OK’ or ‘Change’. If you click ‘OK’, your prescription will be recorded on the audit database. If you click ‘Change’, you reenter the ‘Prescribing medication’ process. Nguyễn Thị Minh Tuyền 25 Nhập môn CNPM
26. Các ví dụ về card tác vụ cho việc kê đơn thuốc Task 1: Change dose of prescribed drug Task 2: Formulary selection Task 3: Dose checking Dose checking is a safety precaution to check that the doctor has not prescribed a dangerously small or large dose. Using the formulary id for the generic drug name, lookup the formulary and retrieve the recommended maximum and minimum dose. Check the prescribed dose against the minimum and maximum. If outside the range, issue an error message saying that the dose is too high or too low. If within the range, enable the ‘Confirm’ button. Nguyễn Thị Minh Tuyền 26 Nhập môn CNPM
27. XP và sự thay đổi v Tri thức truyền thống cho CNPM là thiết kế cho sự thay đổi § Đó là dành thời gian và nỗ lực cho việc dự đoán các thay đổi vì điều này sẽ làm giảm chi phí sau này. v Tuy nhiên, XP khẳng định rằng việc đó sẽ không có giá trị nếu các thay đổi không được dự đoán một cách đáng tin. § Thay vào đó, cải tiến mã nguồn liên tục để thay đổi sau này dễ dàng hơn. Nguyễn Thị Minh Tuyền 27 Nhập môn CNPM
28. Cải tiến mã nguồn v Nhóm lập trình tìm kiếm các cải tiến có thể thực hiện được và thực hiện cải tiến § Ngay cả khi những cải tiến này không cần ngay. § Làm tăng tính dễ hiểu của phần mềm, vì vậy giảm được tài liệu. § Các thay đổi dễ thực hiện hơn do mã nguồn có cấu trúc và rõ ràng. v Tuy nhiên, các thay đổi này yêu cầu phải cải tiến kiến trúc và điều này đòi hỏi chi phí lớn. Nguyễn Thị Minh Tuyền 28 Nhập môn CNPM
29. Ví dụ về cải tiến mã nguồn v Tổ chức lại cây phân cấp lớp để loại bỏ các đoạn mã bị lặp lại. v Dọn dẹp và đổi tên các thuộc tính và phương pháp để làm cho chúng dễ hiểu hơn. v Việc thay thế các inline code bằng việc gọi các phương thức đã có sẵn trong thư viện chương trình. Nguyễn Thị Minh Tuyền 29 Nhập môn CNPM
30. Kiểm thử trong XP v Kiểm thử là điểm chính của XP và XP đã phát triển một phương pháp trong đó chương trình được kiểm thử cho mỗi thay đổi. v Đặc điểm của kiểm thử trong XP: § Phát triển test trước. § Phát triển test tăng dần từ các kịch bản. § Có sự tham gia của người dùng trong phát triển test và thẩm định. § Sử dụng test tự động để chạy tất cả các component test mỗi khi tạo ra một bản release mới. Nguyễn Thị Minh Tuyền 30 Nhập môn CNPM
31. Phát triển theo hướng test v Việc viết test trước khi viết mã làm rõ các yêu cầu cần cài đặt. v Các test được viết như là các chương trình hơn là dữ liệu để có thể chạy tự động. § Thường sử dụng một framework test như Junit chẳng hạn. v Tất cả các test cũ và mới được chạy tự động khi một tính năng mới được cài đặt § vì vậy kiểm tra được rằng tính năng mới không gây ra lỗi. Nguyễn Thị Minh Tuyền 31 Nhập môn CNPM
32. Sự tham gia của khách hàng v Vai trò của khách hàng trong quy trình kiểm thử là để hỗ trợ phát triển các acceptance test cho các kịch bản sẽ được cài đặt trong bản release tiếp theo. v Khách hàng viết test cho nhóm phát triển. Tất cả các mã nguồn mới vì vậy phải được thẩm định để đảm bảo rằng nó đáp ứng được nhu cầu của khách hàng. v Tuy nhiên, những người đóng vai trò khách hàng thường có ít thời gian rỗi và họ không thể hoàn toàn tham gia vào nhóm phát triển. Họ có thể cảm thấy việc cung cấp yêu cầu là đủ và có thể sẽ không hào hứng với việc tham gia quy trình test. Nguyễn Thị Minh Tuyền 32 Nhập môn CNPM
33. Mô tả test case cho Dose checking Test 4: Dose checking Input: 1. A number in mg representing a single dose of the drug. 2. A number representing the number of single doses per day. Tests: 1. Test for inputs where the single dose is correct but the frequency is too high. 2. Test for inputs where the single dose is too high and too low. 3. Test for inputs where the single dose * frequency is too high and too low. 4. Test for inputs where single dose * frequency is in the permitted range. Output: OK or error message indicating that the dose is outside the safe range. Nguyễn Thị Minh Tuyền 33 Nhập môn CNPM
34. Test tự động v Test tự động nghĩa là các test được viết dưới dạng các component chạy được trước khi tác vụ được cài đặt § Các component này nên đứng độc lập, mô phỏng đầu vào được test và nên kiểm tra rằng đầu ra thỏa mãn đặc tả. Một framework tự động (JUnit) là một hệ thống làm cho việc viết các test chạy được dễ dàng hơn. v Vì test tự động nên các test được thực thi dễ dàng và nhanh chóng § Mỗi khi một chức năng được thêm vào hệ thống, các test phải được chạy và vấn đề xảy ra thường là do mã nguồn mới gây ra. Nguyễn Thị Minh Tuyền 34 Nhập môn CNPM
35. Khó khăn của kiểm thử trong XP v Người lập trình thích lập trình hơn là kiểm thử § Do đó thường đi tắt trong việc viết test § Ví dụ, nó có thể viết các test không hoàn chỉnh hoặc không kiểm tra tất cả các ngoại lệ. v Một số test khó có thể viết theo kiểu tăng dần. § Ví dụ, trong một giao diện người dùng phức tạp, thường khó viết các unit test cho mã nguồn để cài đặt ‘display logic’ và các luồng chuyển tiếp giữa các màn hình. v Khó đánh giá được tính đầy đủ của bộ test § Bộ test cũng không thể bao phủ hết được tất cả. Nguyễn Thị Minh Tuyền 35 Nhập môn CNPM
36. Lập trình cặp v Trong XP, người lập trình làm việc theo cặp, ngồi cùng nhau tại một nơi để phát triển mã nguồn. § Điều này giúp cho việc phát triển mã nguồn chung và mở rộng kiến thức của cả đội. § Được dùng như là một quy trình duyệt không hình thức vì mỗi dòng mã nguồn được xem xét bởi nhiều hơn 1 người. v Khuyến khích cải tiến vì toàn bộ nhóm có thể hưởng lợi từ việc này. v Việc đo đạt cho thấy năng suất của việc lập trình cặp tương đương với năng suất của hai người làm việc độc lập. Nguyễn Thị Minh Tuyền 36 Nhập môn CNPM
37. Lập trình cặp v Các cặp được tạo ra một cách linh động sao cho tất cả các thành viên đều có thể làm việc với nhau trong suốt quy trình phát triển. v Việc chia sẻ kiến thức xảy ra khi làm việc cặp là quan trọng vì nó giảm đi các nguy cơ cho dự án khi có thành viên rời khỏi nhóm. Nguyễn Thị Minh Tuyền 37 Nhập môn CNPM
38. Lợi ích của lập trình cặp v Nó hỗ trợ ý tưởng sở hữu nhóm và trách nhiệm chung đối với hệ thống. § Các cá nhân không phải chịu trách nhiệm cho các vấn đề về mã nguồn. Thay vào đó, cả nhóm chịu trách nhiệm giải quyết các vấn đề này. v Nó hoạt động như một quy trình review không chính thức vì mỗi dòng lệnh được xem xét bởi ít nhất 2 người. v Hỗ trợ cải tiến mã nguồn § Khi áp dụng lập trình cặp và sở hữu tập thể, những người khác có lợi trực tiếp từ việc cải tiến vì vậy họ sẽ dễ hỗ trợ quá trình này. Nguyễn Thị Minh Tuyền 38 Nhập môn CNPM
39. Nội dung v Các phương pháp linh hoạt v Phát triển hoạch định sẵn và linh hoạt v Extreme programming v Quản trị dự án linh hoạt v Mở rộng quy mô các phương pháp linh hoạt Nguyễn Thị Minh Tuyền 39 Nhập môn CNPM
40. Scrum v Là phương pháp tổng quát. v Tập trung vào quản lý việc phát triển vòng lặp hơn là các nguyên lý về phương pháp linh hoạt. Nguyễn Thị Minh Tuyền 40 Nhập môn CNPM
41. Quy trình Scrum Assess Select Outline planning and architectural Project closure design Review Develop Sprint cycle Nguyễn Thị Minh Tuyền 41 Nhập môn CNPM
42. Chu trình Sprint v Độ dài Sprint cố định, thường từ 2-4 tuần. § Tương ứng với sự phát triển của một bản release của hệ thống. v Điểm bắt đầu cho kế hoạch là product backlog, là danh sách các công việc phải làm trong dự án. v Pha chọn gồm cả nhóm phát triển dự án làm việc với khách hàng để chọn ra các đặc tính và chức năng được cài đặt trong sprint. Nguyễn Thị Minh Tuyền 42 Nhập môn CNPM
43. Chu trình Sprint v Một khi các chức năng được lựa chọn, nhóm tự tổ chức để phát triển phần mềm. § Trong suốt giai đoạn này, người khách hàng bị tách ra khỏi nhóm và tất cả các liên lạc đều thông qua ‘Scrum master’. v Vai trò của Scrum master là để bảo vệ nhóm phát triển khỏi sự phân tán bên ngoài. v Vào cuối sprint, công việc đã thực hiện được duyệt lại và giới thiệu cho stakeholder. Chu trình sprint tiếp theo lại bắt đầu. Nguyễn Thị Minh Tuyền 43 Nhập môn CNPM
44. Nhóm làm việc trong Scrum v ‘Scrum master’ là người tổ chức họp hàng ngày, theo dõi tiến độ công việc, giao tiếp với khách hàng và quản lý bên ngoài nhóm. v Toàn đội tham dự một cuộc họp ngắn hàng ngày trong đó các thành viên chia sẻ thông tin, mô tả tiến độ của họ, các vấn đề phát sinh và lên kế hoạch cho ngày tiếp theo. § Nghĩa là mọi người biết cái gì đang diễn ra, vấn đề phát sinh và lên kế hoạch ngắn hạn để đáp ứng sự thay đổi. Nguyễn Thị Minh Tuyền 44 Nhập môn CNPM
45. Lợi ích của Scrum v Sản phẩm được chia thành cách phần nhỏ dễ hiểu và dễ quản lý. v Các yêu cầu không ổn định sẽ không làm chậm trễ tiến độ. v Toàn đội thấy được mọi thứ và vì vậy giao tiếp nhóm được cải thiện. v Khách hàng nhận từng phần đúng hạn và gởi phản hồi về sản phẩm. v Niềm tin giữa khách hàng và đội phát triển tăng lên và một văn hóa tích cực được tạo ra trong đó mỗi người đều mong muốn dự án thành công. Nguyễn Thị Minh Tuyền 45 Nhập môn CNPM
46. Nội dung v Các phương pháp linh hoạt v Phát triển hoạch định sẵn và linh hoạt v Extreme programming v Quản trị dự án linh hoạt v Mở rộng quy mô các phương pháp linh hoạt Nguyễn Thị Minh Tuyền 46 Nhập môn CNPM
47. Mở rộng quy mô v Các phương pháp linh hoạt được chứng minh là một phương pháp thành công cho các dự án vừa và nhỏ được phát triển bởi nhóm nhỏ làm việc tại cùng một nơi. v Sự thành công của các phương pháp này do việc cải thiện giao tiếp giữa các thành viên khi mọi người làm việc cùng nhau. v Việc mở rộng quy mô các phương pháp linh hoạt gồm § thay đổi các phương pháp này để phù hợp với những dự án lớn hơn, § các tổ chức lớn sử dụng phương pháp này để phát triển ứng dụng. Nguy ễn Thị Minh Tuyền 47 Nhập môn CNPM
48. Việc phát triển các hệ thống lớn v Các hệ thống lớn thường là tập hợp các hệ thống rời rạc, tương tác với nhau. v Có các nhóm phát triển riêng cho từng hệ thống con. Các nhóm này thường được phân tán ở nhiều địa điểm khác nhau. v Các hệ thống lớn này thường là ‘brownfield systems’ § Gồm có một số các hệ thống con đang tồn tại và tương tác với các hệ thống này. § Nhiều yêu cầu hệ thống liên quan đến tương tác và vì vậy không thật sự cần tính linh động và phát triển tăng dần. v Vài hệ thống con được tích hợp để tạo ra một hệ thống lớn, do đó việc phát triển liên quan nhiều đến cấu hình hệ thống hơn là phát triển mã nguồn mới. Nguyễn Thị Minh Tuyền 48 Nhập môn CNPM
49. Việc phát triển các hệ thống lớn v Các hệ thống lớn và quy trình phát triển của chúng thường ràng buộc bởi các yếu tố và quy định bên ngoài làm hạn chế cách chúng được phát triển. v Các hệ thống lớn có thời gian phát triển và sử dụng dài. § Khó có thể duy trì các nhóm phát triển trong một thời gian dài vì tất nhiên các thành viên có thể thay đổi công việc và dự án. v Các hệ thống lớn thường có một tập đa dạng các stakeholder. Sẽ không thực tế nếu đưa tất cả các stakeholder này vào trong quy trình phát triển. Nguyễn Thị Minh Tuyền 49 Nhập môn CNPM
50. Scaling out và scaling up v ‘Scaling up’ liên quan đến việc sử dụng các phương pháp linh hoạt để phát triển các hệ thống phần mềm lớn mà nó không thể được phát triển bởi các nhóm nhỏ. v ‘Scaling out’ liên quan đến cách các phương pháp linh hoạt được giới thiệu đến các tổ chức đã có nhiều năm kinh nghiệm về sản xuất phần mềm. v Khi mở rộng quy mô các phương pháp linh hoạt cần giữ lại các nền tảng linh hoạt § Kế hoạch linh động, các bản release ra thường xuyên, tích hợp liên tục, phát triển theo hướng kiểm thử và giao tiếp nhóm tốt. Nguyễn Thị Minh Tuyền 50 Nhập môn CNPM
51. Scaling up cho các hệ thống lớn v Đối với việc phát triển các hệ thống lớn, không thể chỉ tập trung vào mã nguồn của hệ thống. Ta cần thêm nhiều thiết kế và tài liệu hệ thống. v Cơ chế giao tiếp giữa các nhóm phải được thiết kế và sử dụng. § Có thể sử dụng liên lạc qua điện thoại hoặc video conference thường xuyên giữa các nhóm và các cuộc họp “điện tử” ngắn, thường xuyên trong đó các nhóm cập nhật tiến độ của mình. v Tích hợp thường xuyên, trong đó toàn bộ hệ thống được build lại mỗi khi người phát triển kiểm tra một thay đổi, trên thực tế thì khó thực hiện. § Tuy nhiên, việc build hệ thống thường xuyên và tạo ra các bản release thường xuyên là cần thiết. Nguyễn Thị Minh Tuyền 51 Nhập môn CNPM
52. Scaling out cho các công ty lớn v Người quản trị dự án không có kinh nghiệm với phương pháp linh hoạt có thể sẽ miễn cưỡng chấp nhận phương pháp mới. v Các tổ chức lớn thường có các thủ tục và chuẩn về chất lượng cần phải tuân theo. Vì bản chất này, các tổ chức thường khó tương thích với các phương pháp linh hoạt. v Các phương pháp linh hoạt được xem là hiệu quả khi các thành viên có kỹ năng tương đối cao. Tuy nhiên, trong các tổ chức lớn, kỹ năng và khả năng thường không đồng đều. v Có thể văn hóa của công ty sẽ cản trở việc sử dụng phương pháp linh hoạt, đặc biệt là những tổ chức có một thời gian dài sử dụng các quy trình công nghệ truyền thống. Nguyễn Thị Minh Tuyền 52 Nhập môn CNPM