CHAPTER 3 AGILE METHODS 1
CHAPTER 3: AGILE METHODS Phương pháp phát triển linh động - Agile Methods Agile Manifesto Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others it These are our values and principles https://agilemanifesto.org/ Individuals and interactions (Cá nhân hóa tương tác): over processes and tools (Hướng đến cá nhân tương tác) Working software (Phần mềm chạy được): over comprehensive documentation (Viết mã nguồn tập trung vào tài liệu) Customer collaboration (Cộng tác người dùng/khách hàng): over contract negotiation (Cộng tác với khách hàng để lấy tin tưởng khách hàng từ ký hợp đồng) Responding to change (Sự đáp ứng thay đổi): over following a plan (Phản hồi nhanh chóng với thay đổi làm theo kế hoạch) CHAPTER 3: AGILE METHODS ⇒ Phương pháp trọng việc đề bên trái nhiều Ưu tiên hàng đầu dự án phần mềm theo phương pháp agile thỏa mãn khách hàng thông qua việc phát triển phân phối liên tục phần mềm có chất lượng Chấp nhận thay đổi cho dù qua q trình phát triển Giúp cho sản phẩm mạnh việc cạnh tranh Chuyển giao phần mềm hoạt động tốt cách thường xuyên (hàng tuần hàng tháng) Xây dựng môi trường khuyến khích người có động lực cao phát triển Trao đổi trực tiếp mặt đối mặt (Thay thơng qua tài liệu phương pháp truyền thống) Các phần mềm hoạt động tốt độ đo tiến độ phần mềm Đây phương pháp giúp tăng mức độ phát triển bền vững dự án Các nhà tài trợ, đội ngũ phát triển phần mềm người dùng trì phần mềm với khoảng dài hạn Tiếp tục tập trung vào kỹ thuật tốt thiết kế đẹp Simplicity - đơn giản hóa khối lượng độ công việc Các kiến trúc tốt, yêu cầu thiết kế đưa nhóm tự tổ chức (Self-organizing team) Nhóm tự kiểm điểm lại thường xuyên để điều chỉnh thức làm việc ⇒ Agile tư tưởng có nhiều phương pháp sinh theo tư tưởng Extreme Programming - Phương pháp lập trình cực đoan “Take known good practices and push them to extremes.”: Cái làm tốt phải làm tốt The planning game: Cách lên kế hoạch trò chơi CHAPTER 3: AGILE METHODS Small Release: Chuyển giao phần mềm liên tục (Nhiều phương pháp agile) Thiết kế đơn giản (Thiết kế thấy trước mắt) Refactoring (Thay đổi mã nguồn chức không thay đổi) Lập trình song song Liên tục hội nhập Làm việc 40 tiếnng tuần On - site Customer Coding standards The 12 Practices The planning game: cách lên kế hoạch trò chơi Đưa yêu cầu dạng câu chuyện mang tính thực tế Đặt định cho người có kiến thức tốt Yêu cầu nghiệp vụ → KH Yêu cầu phần mềm → Developer Lên kế hoạch tầm hiểu biết Có trò chơi Planning Poker Small Releases: chuyển giao sản phẩm nhỏ lẻ Lấy phản hồi người dùng nhanh Có stories hồn thành giai đoạn → biết tiến độ dự án Metaphor: mượn hình ảnh thực tế Thơng qua thảo luận Cung cấp nhìn Kết nối chương trình với bên để dễ hiểu Simple Design: thiết kế đơn giản Không cần phức tạp sau Dễ chỉnh sửa, bảo trì mơ tả CHAPTER 3: AGILE METHODS Testing Kiểm thử đơn vị: hàm, lớp, thành phần làm Làm thường xuyên, liên tục → Phải kiểm thử tự động tự động hoá nhiều tốt để giảm chi phí Kiểm thử hệ thống → thực khách hàng → Kiểm tra lại yêu cầu phần mềm (User stories) Refactoring: thay đổi mã nguồn chức không đổi Phải làm liên tục thường xuyên Thiết kế liên tục → Tiết kiệm chi phí 💡 Trong phương pháp truyền thống có Refactoring hay khơng? Phương pháp thực Refactoring nhiều hơn? Vì sao? Phương pháp truyền thống phải làm tuần tự, thiết kế đầy đủ, nhu cầu thay đổi khơng nhiều Cịn lại xu hướng thay đổi nhiều khơng có kế hoạch từ trước kế hoạch ngắn hạn, dẫn đến phải thay đổi nhiều Pair Programming: lập trình đơi Driver and navigator Sau thời gian đổi vai trò lại Truyền đạt kinh nghiệm lẫn hai người Chất lượng phần mềm tốt hơn, phát lỗi tốt Giảm giai đoạn kiểm thử Trong thực tế dùng pair programming Collective Ownership: làm chủ tập thể Mọi người sở hữu mã nguồn Có thể thay đổi code đâu Khơng thiết lập modules cá nhân Giảm rủi ro người bị ảnh hưởng, hỗ trợ cơng việc lẫn Continuous Integration: tích hợp liên tục CHAPTER 3: AGILE METHODS Tất chạy liên tục Có releases thường xuyên nhanh Giảm thiểu trường hợp đợi lâu chênh lệch, dẫn đến lỗi (”big bang integration disasters”) 40-hour Week Không làm việc liên tục → Chất lượng công việc giảm On-site Customer: KH đến làm việc Trao đổi trực tiếp với LTV LTV thứ Coding Standards Đảm bảo mã nguồn theo tiêu chuẩn mã nguồn Mọi người hiểu mã nguồn The planning game Mô tả phần mềm dạng câu chuyện người dùng Giao công việc phù hợp cho người có chun mơn Lên kế hoạch phù hợp với khả kiến thức Small Release Chuyển giao phiên nhỏ để nhận phản hồi nhanh khách hàng Từ biết tiến độ phát triển dự án Metaphor - Ẩn dụ Mượn hình ảnh thực tế để diễn đạt dự án Kết nối chương trình với tiến độ công việc Simple Design Thiết kế cho yêu cầu đơn giản Những phức tạp để lại sau ⇒ Dễ dàng chỉnh sửa, trì Testing - Kiểm thử đơn vị Kiểm thự hàm, lớp, thành phần tạo để CHAPTER 3: AGILE METHODS Được thực thường xuyên liên tục (Kể với chức làm rồi) Việc kiểm thử thực khách hàng Refactoring Là trình chỉnh sửa mã nguồn mà không đổi chức mã nguồn (thay đổi tên hàm, di chuyển qua vị trí khác,…) Được làm thường xuyên Thiết kế quan trọng giữ vững suốt trình trình phát triển 💡 ⇒ giảm chi phí Giữa phương pháp phát triển phần mềm truyền thống phương pháp đại, phương pháp cần refactoring nhiều hơn? Trong phương pháp phát triển phần mềm truyền thống thay đổi vạch chi tiết từ trước, khó thay đổi q trình phát triển Cịn phương pháp thay đổi đưa suốt trình phát triển phần mềm Việc Refactoring nhiều ⇒ Pair Programming Giúp truyền đạt kinh nghiệm lẫn người Làm cho chất lượng phần mềm tốt ⇒ Tiết kiệm thời gian chi phí Về lâu dài tổng thời gian phát triển giảm xuống 💡 Thực tế Pair Programming dùng thực tế Bởi việc tương tác người có nhiều trục trặc (bất đồng quan điểm, lớn, …) Collective Ownership - Làm chủ tập thể Mỗi người sở hữu mã nguồn nhóm Có thể cập nhật người team Làm giảm thiểu rủi ro người sở hữu người rịi nhóm hay nghỉ việc → người khác truy cập CHAPTER 3: AGILE METHODS 💡 Mọi người hiểu tổng thể mã nguồn chia sẻ công việc với Continuous Intergration Hệ thống hoạt động liên tục để bảo bảo mã nguồn ln chạy khơng có lỗi Mỗi người phải up lên Github đảm bảo mã nguồn chạy trước rời văn phịng 40-hour week Khơng làm việc liên tục → Chất lượng công việc bị giảm On-site Customer Những người có kiến thức nghiệp vụ, khách hàng làm việc trực tiếp với lập trình viên để chia sẻ kinh nghiệm quy tắc cần môi trường làm việc Coding Standards Phải đảm bảo mã nguồn theo tiêu chuẩn đề sửa bảo trì ⇒ Dễ dàng cho việc chỉnh Tùy theo ngơn ngữ có tiêu chuẩn khác CHAPTER 3: AGILE METHODS Scrum Là quy tắc phương pháp Agile sử dụng tập hợp quy tắc thực hành đơn giản để bước phát triển phần mềm Một số khái niệm Scrum: Daily Scrum: Một họp ngắn (ít 30 phút) giúp nhóm giám sát trạng thái trao đổi vấn đề phát sinh Sprint: chu kỳ phát triển phần mềm (thường 30 ngày) Backlog: Product backlog: danh sách ưu tiên sản phẩm yêu cầu Sprint backlog: danh sách ưu tiên yêu cầu phân bổ cho trình sprint Impediments backlog: danh sách vấn đề phát sinh Burndown chart: biểu đồ biểu diễn tiến độ Artifacts Product backlog Overall product requirements (Yêu cầu tổng thể sản phẩm) Items are estimated and prioritized (Các mục ước tính ưu tiên) Sprint backlog CHAPTER 3: AGILE METHODS Requirement items allocated for one sprint (Các mục yêu cầu phân bổ cho sprint) Items are estimated prioritized (Các mục ước tính ưu tiên) Scrum Roles Scrum master: Facilitate Scum practices Enforce Scrum principles Team: Estimate product backlog Create sprint backlog Implement backlog items Product Owner: Create vision and requirements Contact point Create releases plan Manager: Ensure resources available Resources management Team building Activities Release planning: Ưu tiên phân bổ tính cho release Sprint planning: Đưa mục tiêu phân bổ hạng mục tồn đọng cho trình Sprint Daily Scrum: Có câu hỏi cần đặt thành viên team What had been done since the last meeting? What will be done by the next meeting? CHAPTER 3: AGILE METHODS What issue we have now? ⇒ Giúp người nhóm tập trung cho dự án Sprint review: Tổ chức cuối sprint Xem lại chức hoàn thiện Quyết định hướng chưa Where Agile Methods Work Best? Nhóm nhỏ (2-20 người) Q trình lặp lại ngắn (1-2 tuần) Những hệ thống không yêu cầu cao độ an toàn Strengths and Weaknesses of Agile Methods Thế mạnh: Phù hợp với môi trường linh động Thay đổi nhanh chóng, hỗ trợ tốt với yêu cầu khẩn cấp Tránh chi phí tài liệu (tốn thời gian nhân lực soạn tài liệu) Trao quyền/khuyến khích người làm việc Điểm yếu: Địi hỏi trình độ động lực cá nhân cao Khó thực hệ thống quan trọng độ an toàn Thường gặp cố áp dụng với dự án lớn CHAPTER 3: AGILE METHODS 10