Tiểu luận môn công nghệ phần mềm Tìm hiểu về Agile software development

1 Tổng quan Agile 0.1 Agile giới thiệu chung 0.1.1 Giới thiệu chung Phát triển phần mềm linh hoạt (agile software development – gọi tắt agile) nhóm phương pháp phương pháp luận phát triển phần mềm dựa nguyên tắc phát triển phân đoạn lặp (iterative) tăng trưởng (incremental), theo nhu cầu giải pháp tiến hóa thông qua hợp tác nhóm tự quản liên chức Agile thường sử dụng cách lập kế hoạch thích ứng (adaptive planning), việc phát triển chuyển giao theo hướng tiến hóa; sử dụng khung thời gian ngắn linh hoạt để dễ dàng phản hồi lại với thay đổi trình phát triển Thuật ngữ agile thức sử dụng rộng rãi theo cách thống kể từ “Tuyên ngôn Agile” giới thiệu công chúng năm 2001 nhóm gồm nhà sáng tạo Scrum, Extreme Programming (XP), Dynamic Systems Development Method (DSDM - Phương pháp Phát triển Hệ thống Linh động), Crystal; đại diện phát triển hướng-tính-năng (feature-driven); vài nhà lãnh đạo khác lĩnh vực công nghiệp phần mềm Nhờ tính linh hoạt, đa dạng hiệu cao, phương pháp agile ngày trở thành lựa chọn hàng đầu khách hàng, nhà phát triển, công ty phát triển phần mềm Theo khảo sát hãng nghiên cứu thị trường Forrester, mức độ phổ biến agile mức cao nhất, gấp nhiều lần so với phương pháp truyền thống thác nước hay CMMi (xem Hình 1.1) Hơn , số phương pháp agile có xuất xứ sử dụng hiệu phạm vi phát triển phần mềm 2 Có nhiều phương pháp agile với hướng tiếp cận khác Bên cạnh cách thức tổ chức công việc, thiết lập quy trình, phương pháp agile nghiên cứu đưa vào sử dụng công cụ kĩ thuật đặc thù công cụ tích hợp liên tục (continuous integration), kiểm thử đơn vị, mẫu thiết kế, tái cấu trúc, phát triển hướng kiểm thử (TDD), phát triển hướng hành vi (BDD), hay lập trình theo cặp v.v để đảm bảo gia tăng tính linh hoạt Tuy phương pháp chia sẻ nhiều đặc trưng giống cộng tác nhóm chặt chẽ, tổ chức nhóm tự quản, liên chức năng, tính đáp ứng cao suốt vòng đời dự án 3 0.1.2 Vì cần Agile Theo quan niệm truyền thống, dự án phần mềm coi thành công sản phẩm giao hạn, ngân sách cho phép làm yêu cầu khách hàng Trên thực tế, nhiều dự án thỏa mãn tất tiêu chí rút bị coi thất bại phần mềm làm không người dùng ưa thích, không mang lại nhiều lợi ích cho cá nhân, tổ chức sử dụng chúng Ngoài yếu tố truyền thống nói trên, dự án phần mềm coi thành công thỏa mãn ba tiêu chí: Thành công mức cá nhân, thành công mặt kĩ thuật thành công mức công ty Thành công mức cá nhân giúp kích thích thành viên nhóm Thành công kĩ thuật đảm bảo khả bảo trì tiến hóa sản phẩm Vị trí nhóm bảo đảm nhờ thành công mà nhóm mang lại cho công ty Các phương pháp Agile giúp cho dự án phần mềm đạt ba thành công 1) Thành công mức công ty Agile nhắm đến việc tạo giá trị cho công ty làm giảm chi phí Đồng thời, Agile giúp sớm xác định kì vọng sản phẩm phát triển Nhờ đó, dự án không mang lại giá trị mong đợi phát sớm, tiết kiệm chi phí cho công ty Theo phương pháp Agile, chuyên gia nghiệp vụ (business) làm việc trực tiếp với đội dự án Các chức quan trọng sản phẩm tập trung phát triển trước đưa vào vận hành sớm Các phiên với tính đưa thêm vào Agile giúp tăng cường khả giao tiếp thành viên nhóm Chất lượng mã nguồn cải tiến liên tục Tiến độ dự án xem xét đánh giá cách thường xuyên 2) Thành công mặt kĩ thuật Trong Extreme Programming, phương pháp tuân theo triết lí Agile, lập trình viên làm việc Nhờ vậy, chi tiết quan trọng không bị bỏ sót, đoạn code kiểm tra hai người Các lập trình viên liên tục tích hợp đoạn code vừa viết vào hệ thống, cho phép phiên phần mềm “ra lò” góp thêm giá trị đáng kể Hơn nữa, toàn đội dự án tập trung hoàn thành chức trước chuyển sang chức Bởi vậy, tiến độ công việc kiểm soát tốt dự án dễ dàng “chuyển hướng” có thay đổi từ phía khách hàng Ngoài ra, Extreme Programming đề xuất quy tắc giúp tạo thiết kế đoạn mã tốt Chẳng hạn, quy tắc “phát triển dựa kiểm thử” (test-driven development) trợ giúp lập trình viên viết chương trình thực chức mong muốn 3) Thành công mặt cá nhân Mỗi thành viên dự án Agile, dù cương vị nào, cảm nhận cách rõ ràng thành công thân Các lập trình viên nhận thấy trình độ kĩ thuật tầm ảnh hưởng dự án nâng cao, chẳng hạn việc ước lượng lập kế hoạch Quyền tự chủ đội dự án tăng cường Các tester nhận thấy họ có ảnh hưởng lớn đến chất lượng sản phẩm, đồng thời giảm công việc lặp lại cách nhàm chán Nhà quản lí dự án hài lòng kiểm soát tiến độ công việc, dự án thực cam kết làm thỏa mãn khách hàng Khách hàng, người sử dụng, chuyên gia nghiệp vụ cảm thấy hài lòng điều kiển hướng dự án ý kiến lắng nghe Các nhà lãnh đạo cao cấp cảm thấy hài lòng dự án mang lại lợi nhuận lớn cho công ty 0.2 Đặc trưng Agile Đặc trưng Agile biểu qua số thuộc tính sau: 0.2.1 Tính lặp(Interative) Dự án thực phân đoạn lặp lặp lại Các phân đoạn (được gọi Iteration Sprint) thường có khung thời gian ngắn (từ đến bốn tuần) Trong phân đoạn này, nhóm phát triển thực đầy đủ công việc cần thiết lập kế hoạch, phân tích yêu cầu, thiết kế, triển khai, kiểm thử (với mức độ khác nhau) phần nhỏ sản phẩm Các phương pháp agile thường phân rã mục tiêu thành phần nhỏ với trình lập kế hoạch đơn giản gọn nhẹ có thể, không thực việc lập kế hoạch dài hạn Có phương pháp Scrum chí sử dụng phương pháp lập kế hoạch just-in-time trình phát triển Khi đó, chí công việc lập kế hoạch, làm mịn kế hoạch thực liên tục suốt trình làm việc 6 Hình 2: Các phân đoạn lặp lặp lại agile 0.2.2 Tính tiệp tiến(Incremental) tiến hóa (Evolutionary) Cuối phân đoạn, nhóm phát triển thường cho phần nhỏ sản phẩm cuối Các phần nhỏ thường đầy đủ, có khả chạy tốt, kiểm thử cẩn thận sử dụng Theo thời gian, phân đoạn tiếp nối phân đoạn kia, phần chạy tích lũy, lớn dần lên toàn yêu cầu khách hàng thỏa mãn Khác với mô hình phát triển Thác nước – vốn cho phép nhìn thấy toàn chức thời điểm kết thúc dự án, sản phẩm dự án agile lớn dần lên theo thời gian, tiến hóa đạt trạng thái đủ để phát hành 0.2.3 Tính thích ứng(hay thích nghi – adaptive) Do phân đoạn kéo dài khoảng thời gian ngắn, việc lập kế hoạch điều chỉnh liên tục, nên thay đổi trình phát triển (yêu cầu thay đổi, thay đổi công nghệ, thay đổi định hướng mục tiêu v.v.) đáp ứng theo cách thích hợp Ví dụ, Scrum – phương pháp phổ biến – nhóm phát triển sản xuất gói phần mềm, khách hàng đưa thêm yêu cầu mới, chủ sản phẩm (Product Owner) đánh giá yêu cầu đưa vào làm việc phân đoạn (được gọi Sprint Scrum) Theo đó, quy trình agile thường thích ứng tốt với thay đổi 0.2.4 Nhóm tự tổ chức liên chức Cấu trúc nhóm agile thường liên chức tự tổ chức Theo đó, nhóm tự thực lấy việc phân công công việc mà không dựa mô tả cứng chức danh (title) hay làm việc dựa phân cấp rõ ràng tổ chức Các nhóm cộng tác với để định, theo dõi tiến độ, giải vấn đề mà không chờ mệnh lệnh cấp quản lý Họ không làm việc theo chế “mệnh lệnh kiểm soát” (command and control) 0.2.5 Quản lý tiến trình thực nghiệm(Empirical Process Control) Các nhóm agile định dựa liệu thực tiễn thay tính toán lý thuyết hay giả định Việc phân nhỏ dự án thành phân đoạn ngắn góp phần gia tăng điểm mốc để nhóm phát triển thu thập kiện cho phép điều chỉnh chiến lược phát triển Theo thời gian, chiến lược tiến gần đến trạng thái tối ưu, nhờ nhóm kiểm soát tiến trình, nâng cao suất lao động 0.2.6 Giao tiếp trực diện Một số mô hình phát triển phần mềm dựa nhiều vào công việc giấy tờ, từ việc thu thập yêu cầu người dùng, viết đặc tả hệ thống, thiết kế hệ thống v.v Agile không phản đối công dụng công việc tài liệu hóa, đánh giá cao việc giao tiếp trực diện thay gián tiếp thông qua giấy tờ Về yêu cầu khách hàng, agile khuyến khích nhóm phát triển trực tiếp nói chuyện với khách hàng để hiểu rõ khách hàng thực cần, thay phụ thuộc nhiều vào loại văn Trong giao tiếp nội nhóm phát triển với nhau, thay lập trình viên (thực việc mã hóa) kĩ sư (thực việc thiết kế) giao tiếp với thông qua thiết kế, agile khuyến khích hai người trực tiếp trao đổi thống với thiết kế hệ thống triển khai thành chức theo yêu cầu Bản thân nhóm agile thường nhỏ (ít mười hai người) để đơn giản hóa trình giao tiếp, thúc đẩy việc cộng tác hiệu Các dự án lớn muốn dùng agile thường phải phân thành nhóm nhỏ đồng thời làm việc với hướng đến mục tiêu chung Việc đòi hỏi số nỗ lực đáng kể việc điều phối mức ưu tiên nhóm Các nhóm phát triển thường tạo thói quen trao đổi trực diện cách thường xuyên Một chế thường thấy họp tập trung ngày (daily meeting) Tại đây, tất thành viên yêu cầu nói rõ cho nhóm biết làm gì, làm gì, làm gặp phải khó khăn trình làm việc Khi chế thực hiệu quả, nhóm luôn nắm tình hình công việc mình, có hành động thích hợp để vượt qua trở lực để thực thành công mục tiêu dự án 0.2.7 Phát triển dựa giá trị (value-base) Một nguyên tắc agile “phần mềm chạy tốt thước đo tiến độ” Nguyên tắc giúp nhóm dám loại bỏ công việc dư thừa không trực tiếp mang lại giá trị cho sản phẩm Ví dụ, nhóm thấy không cần phải viết tất thiết kế hệ thống, mà họ cần phác thảo thiết kế lên bảng, triển khai chức hệ thống Nhưng chủ sản phẩm định rằng, chuyển giao sản phẩm, nhóm phát triển phải kèm theo thiết kế chi tiết hệ thống chúng chiếm 20% giá trị dự án theo yêu cầu khách hàng, khách hàng cần để chứng minh tính đắn chức năng, để phát triển tiếp phân hệ sản phẩm; nhóm phát triển phải thực việc tài liệu hóa đầy đủ Để vận hành chế “làm việc dựa giá trị”, nhóm agile thường làm việc trực tiếp thường xuyên với khách hàng (hay đại diện khách hàng), cộng tác trực tiếp với họ để biết yêu cầu có độ ưu tiên cao hơn, mang lại giá trị cho dự án Nhờ dự án agile thường giúp khách hàng tối ưu hóa giá trị dự án Một cách gần trực tiếp, agile gia tăng đáng kể độ hài lòng khách hàng 0.3 Các thuật ngữ Agile Để cung cấp cho bạn đầy đủ thuật ngữ agile tiếng Việt, thống đưa thuật ngữ giải thích chúng Hanoi Scrum mong nhận đóng góp ý kiến thắc mắc bạn thuật ngữ 4) Agile software Development – Phát triển phần mềm linh hoạt Một họ phương pháp phát triển phần mềm dựa theo giá trị nguyên tắc định nghĩa AgileAlliance.org 5) Burndown Chart – Biểu đồ Burndown Là biểu đồ thể xu hướng công việc lại theo thời gian Sprint, phát hành (Release), sản phẩm Dữ liệu cho Biểu đồ Burndown lấy từ Sprint Backlog Product Backlog, với công việc lại theo dõi trục tung khoảng thời gian (các ngày Sprint, nhiều Sprint) theo dõi trục hoành Biểu đồ Burndown dùng cho Bản phát hành (khi gọi Release Burndown) cho Sprint (gọi Sprint Burndown) 6) Chicken – Gà Một người quan tâm đến dự án trách nhiệm dự án (không giữ vai trò Nhóm Phát triển, Product Owner hay Scrum Master) 7) Daily Scrum – Buổi họp hàng ngày (hay Họp Scrum hàng ngày) Một họp ngắn tổ chức hàng ngày Nhóm Phát triển, thời gian thành viên nhóm kiểm tra công việc họ, đồng hóa công việc tiến độ báo cáo vấn đề để giải Nhóm Scrum Master phải tiến hành hoạt động Daily Scrum để thích ứng với công việc tới tối tưu hóa Sprint Với Scrum, để giải mâu thuẫn kể trên, đồng thời để đảm bảo tiến độ đội, Scrum đưa ý tưởng Daily Scrum Daily Scrum buổi họp nhằm điều hướng công việc nhóm lập trình buỗi họp diễn ngày Để giữ cho buổi họp diễn nhanh chóng, lập trình viên trả lời ba câu hỏi sau: a) Bạn làm ngày hôm qua? b) Bạn định làm hôm nay? c) Có cản bước bạn không? Trong suốt họp Daily Scrum, lập tình viên không phép nói 10 chuyện vấn đề không liên quan, trình diễn họ làm, hay nói kinh nghiệm giải vấn đề lập trình Buổi họp phải diễn nhanh gọn, thường 15 phút Các vấn đề nêu Daily Scrum thảo luận kỹ meeting khác, lúc không cần thiết phải có có mặt toàn đội 8) Done - Hoàn thành Định nghĩa hoàn thành (Done Definition - Định nghĩa Hoàn thành) đồng thuận tất bên phù hợp với tiêu chuẩn, quy ước tổ chức dẫn khác Khi công việc ghi nhận "Done" họp Sơ kết Sprint , phải phù hợp với định nghĩa hoàn thành 9) Estimated Work Remaining – Công việc ước tính lại Số mà thành viên nhóm ước lượng để thực công việc Ước lượng cập nhật ngày thành viên thực công việc Sprint Backlog Đây số ước tính tổng số lại để hoàn thành công việc, không kể đến số lượng người thực công việc hay số bỏ cho công việc khứ 10) Empirical Process Control – Quản lý tiến trình thực nghiệm Đây phương pháp quản lý tiến trình (process) không dựa giả định tính toán lý thuyết (Predictive management) mà dựa khảo sát kĩ lưỡng thích nghi với biến động thực tiễn 11)Increment – Tăng trưởng Là phần tăng trưởng sản phẩm phát triển Nhóm Phát triển Sprint Đôi increment dịch gần “gói phần mềm”, hay đơn giản gói 12) Increment of Potentially Shippable Product Functionality Một phần nhỏ hoàn chỉnh sản phẩm tổng thể hệ thống sử dụng chủ sở hữu sản phẩm bên liên quan 11 13) Iteration – Phân đoạn Trong phương pháp phát triển linh hoạt, iteration phân đoạn với khoảng thời gian ngắn nhằm phát triển phần nhỏ hệ thống Một dự án gồm nhiều phân đoạn lặp lặp lại 14) Sprint – Phân đoạn nước rút scrum Một phân đoạn (iteration), chu kỳ lặp lặp lại công việc tương tự nhằm tạo phần tăng trưởng (increment) cho hệ thống Sprint thường kéo dài từ tuần tới tháng.Trong suốt dự án, thời gian cho Sprint cố định Từ “sprint” có nghĩa giai đoạn nước rút, ám gấp gáp tập trung cao độ khoảng thời gian ngắn để làm việc 15) Pig – Lợn Một người thực ba vai trò Scrum (Team, Product Owner Scrum Master), người có cam kết có quyền để thực cam kết 16) Product Backlog Một danh sách ưu tiên yêu cầu với thời gian ước tính để biến chúng thành tính hoàn chỉnh sản phẩm Các hạng mục ưu tiên Product Backlog ước lượng cẩn thận hơn, thường xác phần khác Danh sách thay đổi có thay đổi điều kiện kinh doanh công nghệ Trong tiếng Anh, 'backlog' có nghĩa phần việc tồn đọng, cần phải giải 17) Product Backlog Item – Hạng mục Product Backlog Một yêu cầu chức hay phi chức năng, vấn đề độ ưu tiên Độ xác ước lượng phụ thuộc vào tầm quan trọng độ chi tiết hạng mục Phần có độ ưu tiên cao chọn Sprint để làm việc 18) Product Owner – Chủ sản phẩm Người chịu trách nhiệm quản lý Product Backlog để tối đa hóa giá trị dự án Chủ sở hữu sản phẩm có trách nhiệm đại diện cho lợi ích tất 12 người có quyền lợi dự án sản phẩm tạo sau dự án 19) Release – Bản phát hành Là sản phẩm đầy đủ chức theo yêu cầu chủ sản phẩm, có khả bán thị trường hay chuyển tới người dùng 20) Scrum Đây không từ viết tắt, mà chế trò chơi bóng bầu dục để đưa “bóng chết” vào chơi Từ “scrum” có nghĩa chen lấn, hàm ý hỗn độn, liên chức tự quản cao độ tình thực tiễn 21) Scrum Master Người chịu trách nhiệm cho quy trình Scrum, bao gồm việc triển khai quy tắc, tối hóa lợi ích từ Scrum 22) Scrum Team – Nhóm Scrum Đây nhóm liên chức gồm Product Owner, Scrum Master Development Team (Nhóm Phát triển) Nhóm Scrum cộng tác với theo khung làm việc Scrum để thực hóa mục tiêu Product Owner 23) Sprint Backlog Danh sách nhiệm vụ xác định công việc nhóm Sprint Danh sách cập nhật suốt Sprint Nhóm tự quản lý Sprint Backlog việc cập nhật trạng thái thực thi nhiệm vụ với người chịu trách nhiệm thời gian lại để hoàn tất công việc tính tới thời điểm cập nhật 24) Sprint Backlog Task – Tác vụ Sprint Backlog Một nhiệm vụ mà nhóm thành viên xác định theo yêu cầu để chuyển đổi yêu cầu Product Backlog thành chức hệ thống 25) Sprint Planning Meeting – Họp lập kế hoạch cho Sprint Cuộc họp diễn phạm vi tám đồng hồ để khởi động Sprint Họp lập kế hoạch chia thành hai phân đoạn bốn giờ.Trong bốn Product Owner trình bày yêu cầu có độ ưu tiên cao cho nhóm phát 13 triển Nhóm Product Owner kết hợp để xác định số lượng hạng mục chọn để tiến hành phát triển Sprint tới Sau bốn đầu tiên, Nhóm Product Owner xác định mục tiêu Sprint tới Trong suốt bốn thứ hai họp, Nhóm lập kế hoạch để đạt mục đích Sprint kĩ thuật phân tích thiết kế cần thiết, sau ghi lại chi tiết công dạng kế hoạch có tên Sprint Backlog 26) Sprint Review Meeting – Họp sơ kết Sprint Đội sản xuất với Product Owner đánh giá lại công việc Sprint vừa kết thúc Trong đánh giá, Đội sản xuất trình bày phần việc hoàn tất, chức hoàn thành; lắng nghe phản hồi từ Product Owner thảo luận chỉnh sửa (nếu có) thực Sprint 27) Sprint Retrospective Meeting – Họp cải tiến Sprint Trong phạm vi ba giờ, ScrumMaster tổ chức cho nhóm thực công việc khảo sát lại toàn quy trình làm việc Sprint vừa qua để tìm cải tiến Sprint tới, nhằm mang lại hiệu suất cao cho nhóm 28) Team (hay Development Team) – Nhóm phát triển Một nhóm liên chức (cross-functional) gồm nhà phát triển (developers) tự quản lý để tiến hành chuyển đổi Product Backlog item thành chức hệ thống Đây ba vai trò tạo nên Nhóm Scrum (còn gọi Đội hình Scrum) 29) Time Box – Khung thời gian Là khoảng thời gian tối đa dành cho hoạt động Scrum Khi nói Daily Scrum đóng hộp mười lăm phút có nghĩa Đội dự án dùng mười lăm phút cho họp ngày Daily Scrum Các Hộp thời gian Scrum kể đến Release Planning, Sprint Planning, Sprint, Daily Scrum, Sprint Review Sprint Retrospective 30) Stakeholder – Người liên quan Người có quan tâm đến kết dự án (có tài trợ cho nó, sử dụng, bị ảnh hưởng sản phẩm tạo từ dự án) 14 0.4 Tuyên ngôn Agile (Agile Manifesto) Vào tháng 2/2001, mười bảy nhà phát triển phần mềm gặp gỡ Snowbird, Utah Resort để thảo luận phương pháp phát triển phần mềm gọn nhẹ linh hoạt Họ công bố “Tuyên ngôn Phát triển phần mềm linh hoạt” (“Manifesto for Agile Software Development” – gọi tắt “Tuyên ngôn Agile”) để định nghĩa cách hiểu Phát triển phần mềm linh hoạt Đây cột mốc quan trọng agile Dù trước đó, phương pháp agile XP, Scrum, v.v sử dụng thành công nhiều nơi, phải tới có xuất “Tuyên ngôn Agile”, với đời hiệp hội chuyên ngành agile Agile Alliance hay Scrum Alliance, phương pháp agile có phát triển vượt bậc Văn ngắn, dễ hiểu, quan trọng đưa giá trị cốt lõi mà toàn nhà lý thuyết người thực hành Agile tuân thủ; phương pháp họ đề xuất sử dụng thực tiễn khác Toàn văn Tuyên ngôn Agile sau: Tuyên ngôn Phát triển phần mềm linh hoạt Chúng phát cách phát triển phần mềm tốt cách thực giúp đỡ người khác thực Qua công việc này, đến việc đánh giá cao: Cá nhân tương tác quy trình công cụ; Phần mềm chạy tốt tài liệu đầy đủ; Cộng tácvới khách hàng đàm phán hợp đồng; Phản hồi với thay đổi bám sát kế hoạch Mặc dù điều bên phải giá trị, đánh giá cao mục bên trái Các giá trị cốt lõi hỗ trợ 12 nguyên tắc Những giá trị không thứ mà tác giả Tuyên ngôn Agile dự định cung cấp để phục vụ cho tuyên ngôn để sau vào quên lãng Chúng giá trị vào để làm việc Bản thân phương pháp linh hoạt tiếp cận giá trị theo cách thức khác nhau, tất 15 phương pháp có tiến trình thực hành cụ thể để nuôi dưỡng nhiều số giá trị 1) Cá nhân tương tác quy trình công cụ Người có quan tâm đến kết dự án (có tài trợ cho nó, sử dụng, bị ảnh hưởng sản phẩm tạo từ dự án) Cá nhân tương tác họ cốt yếu để nhóm đạt hiệu suất cao Các nghiên cứu “bão hòa truyền thông” dự án cho thấy rằng, vấn đề truyền thông, nhóm thực công việc tốt 50 lần so với mức trung bình lĩnh vực Để tạo điều kiện cho truyền thông, phương pháp linh hoạt thường xuyên sử dụng chu trình thanhtra-và-thích-nghi Chu trình diễn phút với lập trình cặp (pairprogramming), với tích hợp liên tục (continuos integration), ngày với standup metting (đứng họp), phân đoạn với buổi họp sơ kết cải tiến Tuy nhiên, tăng tần suất phản hồi giao tiếp không đủ để loại bỏ vấn đề truyền thông Chu kỳ thanh-tra-và-thích-nghi làm việc tốt thành viên nhóm thể hành vi quan trọng sau: a) Tôn trọng giá trị cá nhân b) Trung thực truyền thông c) Minh bạch liệu, hoạt động, định d) Tin tưởng vào hỗ trợ cá nhân với nhóm e) Cam kết với nhóm mục tiêu nhóm Để thúc đẩy hành vi này, nhà quản lý linh hoạt phải cung cấp môi trường hỗ trợ, nhà huấn luyện phải tạo điều kiện thuận lợi, thành viên nhóm phải thể chúng Chỉ nhóm phát huy hết tiềm Đạt tới hành vi khó khăn nhiều so với việc hình thành chúng Hầu hết nhóm tránh lé thật, minh bạch, tin tưởng vào chuẩn mực văn hóa có kinh nghiệm tiêu cực từ xung đột xuất 16 phát từ truyền thông trung thực trước Để chống lại khuynh hướng này, ban lãnh đạo thành viên nhóm phải tạo điều kiện cho xung đột tích cực Làm không giúp tạo hành vi sinh lợi mà đem lại lợi ích khác: a) Cải tiến quy trình phụ thuộc vào nhóm việc tạo danh sách trở ngại vấn đề tổ chức, đối mặt với chúng cách trung thực, sau loại bỏ chúng cách có hệ thống tùy theo độ ưu tiên b) Đổi xảy với việc tự trao đổi ý tưởng mâu thuẫn lẫn nhau, tượng nghiên cứu viết thành tài liệu Takeuchi Nonaka, người cha đỡ đầu Scrum c) Việc hướng nhóm tới mục tiêu chung đòi hỏi nhóm phải đối mặt giải vấn đề xung đột d) Cam kết làm việc xảy người đồng ý với mục tiêu chung sau đấu tranh cho tiến thân nhóm Ý cuối nói cam kết đặc biệt quan trọng Đó mà cá nhân nhóm cam kết mà họ cảm thấy có trách nhiệm với việc cung cấp giá tr ị cao, điểm mấu chốt nhóm phát triển phần mềm Các phương pháp linh hoạt tạo điều kiện cho việc cam kết cách khuyến khích nhóm đưa danh sách công việc ưu tiên hóa, để họ tự quản lý công việc mình, tập trung vào cải tiến cách thực công việc Thực hành tảng tự-tổ-chức (self-organization), động lực để đạt kết nhóm agile Để tạo nhóm có hiệu suất cao, phương pháp linh hoạt coi trọng cá nhân tương tác quy trình công cụ Thực tế cho thấy rằng, tất phương pháp linh hoạt tìm kiếm gia tăng truyền thông cộng tác thông qua việc kiểm tra thường xuyên chu trình thanh-tra-và-thích-nghi Tuy nhiên, chu trình thực làm việc tốt mà nhà lãnh đạo agile khuyến khích xung đột tích cực, thứ cần thiết để xây dựng tảng vững cho trung thực, tính minh bạch, lòng tin, tôn trọng, cam kết từ nhóm agile họ 17 2) Phần mềm chạy tốt tài liệu đầy đủ Phần mềm chạy tốt khác biệt lớn mà phát triển linh hoạt mang lại Tất phương pháp linh hoạt thể Tuyên ngôn Agile cách nhấn mạnh việc cung cấp phần nhỏ phần mềm chạy tốt tới khách hàng sau khoảng thời gian định Tất nhóm agile phải xác lập họ muốn nói “phần mềm chạy tốt”, thường biết định nghĩa hoàn thành Ở mức độ cao, phần chức hoàn thành tính chúng vượt qua tất kiểm thử vận hành người dùng cuối Ở mức thấp nhất, nhóm phải vượt qua kiểm thử đơn vị (unit test) kiểm thử hệ thống Các nhóm tốt bao gồm việc kiểm thử tích hợp, kiểm thử hiệu năng, kiểm thử chấp nhận khách hàng định nghĩa hoàn thành phần chức Thông qua nguồn liệu phong phú từ dự án, công ty CMMI Cấp độ cho thấy việc xác định kiểm thử chấp nhận với tính năng, triển khai loạt tính theo độ ưu tiên, chạy kiểm thử chấp nhận với tính năng, sửa lỗi có độ ưu tiên cao tăng gấp đôi tốc độ sản xuất giảm sai sót đến 40% Điều có từ công ty có tỷ lệ sai sót thấp giới Tuyên ngôn Agile khuyến nghị nhóm cung cấp phần mềm chạy tốt sau khoảng thời gian định Đồng thuận với định nghĩa hoàn thành cách thực tế để nhóm agile mang lại hiệu suất chất lượng cao, cần thiết để hoàn thành mục tiêu 3) Cộng tác với khách hàng đàm phán hợp đồng Trong hai thập kỷ qua, tỉ lệ thành công dự án tăng hai lần toàn giới Điều cho dự án nhỏ mức độ chuyển giao thường xuyên cho phép khách hàng cung cấp thông tin phản hồi phần mềm hoạt động cách đặn Các tác giả Tuyên ngôn làm sáng tỏ điều họ nhấn mạnh việc để khách hàng tham gia vào trình phát triển phần mềm cần thiết để dẫn tới thành công 18 Các phương pháp phát triển linh hoạt thúc đẩy giá trị cách đưa vào đồng minh tích cực khách hàng làm việc sát cánh với đội phát triển Lấy ví dụ, nhóm Scrum có hàng ngàn khách hàng Sẽ không khả thi cho phép tất khách hàng tham gia vào trình phát triển sản phẩm, họ chọn vị đại sứ khách hàng, gọi Product Owner (chủ sản phẩm), để đại diện cho không tất khách hàng trường hợp mà bao gồm quản lý, dịch vụ khách hàng, bên liên quan khác Chủ sản phẩm có trách nhiệm cập nhật danh sách yêu cầu sản phẩm sau bốn tuần thời điểm mà nhóm Scrum phát hành phiên sản phẩm chạy tốt, có tính đến yếu tố thực tế phản hồi khách hàng bên liên quan Điều cho phép khách hàng giúp định hình sản phẩm phần mềm tạo Một nhóm XP bắt đầu với dự án CNTT nội Họ có sẵn người sử dụng đầu cuối công ty nhóm làm việc với họ hàng ngày Khoảng 10% thời gian, tư vấn viên nhóm nội tìm người dùng cuối làm việc với nhóm ngày 90% thời gian lại, họ phải cử người đại diện cho khách hàng Người này, nhóm XP gọi Customer (khách hàng), làm việc trực tiếp với người dùng cuối để cung cấp danh sách tính rõ ràng độ ưu tiên cho phép đội phát triển thực Cộng tác với khách hàng (hoặc đại diện khách hàng) sở hàng ngày lý lý giải liệu ngành công nghiệp cho thấy dự án linh hoạt có tỉ lệ thành công cao gấp đôi so với dự án truyền thống tính trung bình toàn giới Các phương pháp phát triển linh hoạt nhận điều đó, vậy, chúng tạo vị trí đặc biệt đội hình phát triển để dành riêng cho vị khách hàng đại diện 4) Phản hồi với thay đổi bám sát kế hoạch Phản hồi với thay đổi điều cần thiết cho việc tạo sản phẩm làm hài lòng khách hàng mang lại giá trị kinh doanh Dữ liệu ngành 19 công nghiệp cho thấy 60% yêu cầu sản phẩm hay dự án bị thay đổi suốt trình phát triển phần mềm Ngay dự án truyền thống kết thúc thời gian, kinh phí, với tất tính theo kế hoạch, khách hàng thường không hài lòng họ thấy không thật họ muốn Luật Humphrey nói khách hàng họ muốn họ thấy phần mềm hoạt động Nếu khách hàng không nhìn thấy phần mềm hoạt động kết thúc dự án, muộn cho việc kết hợp thông tin phản hồi họ thời điểm Các phương pháp phát triển linh hoạt tìm kiếm phản hồi khách hàng suốt dự án để kết hợp thông tin phản hồi thông tin sản phẩm phát triển Tất phương pháp phát triển linh hoạt tích hợp sẵn tiến trình thay đổi kế hoạch khoảng thời gian đặn dựa thông tin phản hồi từ phía khách hàng bên đại diện khách hàng Các kế hoạch thiết kế để cho cung cấp giá trị kinh doanh cao trước hết Bởi 80% giá trị nằm 20% tính năng, dự án phát triển linh hoạt chạy tốt có xu hướng kết thúc sớm, hầu hết dự án truyền thống thường kết thúc trễ Kết là, khách hàng vui vẻ hơn, nhà phát triển thích thú với công việc họ Các phương pháp phát triển linh hoạt dựa hiểu biết đó, để thành công chúng phải có kế hoạch để thay đổi Đó lý chúng thiết lập quy trình, chẳng hạn Sơ kết Cải tiến, thiết kế đặc biệt để thay đổi ưu tiên thường xuyên dựa thông tin phản hồi khách hàng giá trị kinh doanh 0.5 Các nguyên tắc giá trị Agile Bên cạnh tuyên ngôn, nhà phát triển nhấn mạnh mười hai nguyên lý phía sau Tuyên ngôn Agile để giúp nhà phát triển có gợi ý thực hành vận dụng phương pháp agile thực tiễn Các nguyên lý liệt kê sau đây: 1) Ưu tiên cao thỏa mãn khách hàng thông 20 qua việc chuyển giao sớm liên tục phần mềm có giá trị 2) Chào đón việc thay đổi yêu cầu, chí muộn trình phát triển Các quy trình linh hoạt tận dụng thay đổi cho lợi cạnh tranh khách hàng 3) Thường xuyên chuyển giao phần mềm chạy tốt tới khách hàng, từ vài tuần đến vài tháng, ưu tiên cho khoảng thời gian ngắn 4) Nhà kinh doanh nhà phát triển phải làm việc hàng ngày suốt dự án 5) Xây dựng dự án xung quanh cá nhân có động lực Cung cấp cho họ môi trường hỗ trợ cần thiết, tin tưởng họ để hoàn thành công việc 6) Phương pháp hiệu để truyền đạt thông tin tới nhóm phát triển nội nhóm phát triển hội thoại trực tiếp 7) Phần mềm chạy tốt thước đo tiến độ 8) Các quy trình linh hoạt thúc đẩy phát triển bền vững Các nhà tài trợ, nhà phát triển, người dùng trì nhịp độ liên tục không giới hạn 9) Liên tục quan tâm đến kĩ thuật thiết kế tốt để gia tăng linh hoạt 10) Sự đơn giản – nghệ thuật tối đa hóa lượng công việc chưa xong – 11)Các kiến trúc tốt nhất, yêu cầu tốt nhất, thiết kế tốt làm nhóm tự tổ chức 12) Đội sản xuất thường xuyên suy nghĩ việc để trở nên hiệu hơn, sau họ điều chỉnh thay đổi hành vi cho phù hợp 21 Các nguyên lý này, với năm điểm cốt lõi "Tuyên ngôn Agile" dẫn đường cho nhà thực hành agile (agile practictioner) vận dụng tốt phương pháp agile vào thực tiễn 0.6 Một số phương pháp triển khai theo mô hình Agile Phát triển linh hoạt thân phương pháp Nó thuật ngữ chung mô tả nhiều phương pháp linh hoạt Tại thời điểm ký kết Tuyên ngôn Agile năm 2001, phương pháp bao gồm: Scrum, XP (Extreme Programming), Crystal, FDD (Feature Driven Development), DSDM (Dynamic systems development method) Kể từ thời điểm đó, Lean lên phương pháp linh hoạt có giá trị đưa vào ô phương pháp Agile hình minh họa Có vài phương pháp luận xây dựng dựa nguyên lý Agile Và viết giới thiệu ba cách tiếp cận bật Tuy nhiên bạn cần phải nhớ rằng, phương pháp luận tốt cho tất Hãy chọn phương pháp mà bạn cảm thấy đáp ứng tốt nhu cầu bạn nhất, chí lựa chọn điều chỉnh để phù hợp với yêu cầu bạn Mỗi phương pháp phát triển linh hoạt có cách tiếp cận khác để thực giá trị cốt lõi tuyên ngôn Agile, giống ngôn ngữ máy tính có biểu tính cốt lõi lập trình hướng đối tượng theo cách khác Một khảo sát gần cho thấy rằng, khoảng 50% học viên theo học phương pháp phát triển linh hoạt nói đội họ làm Scrum, 20% khác nói họ làm Scrum với thành phần 22 XP Khoảng 12% nói họ áp dụng XP Do có 80% áp dụng phát triển linh hoạt toàn giới sử dụng Scrum XP Scrum khung làm việc (framework) cho quy trình phát triển linh hoạt Nó không bao gồm vấn đề thực hành, kỹ thuật cụ thể Ngược lại, XP lại tập trung vào kỹ thuật thực hành cụ thể khung làm việc tổng thể cho trình phát triển Điều nghĩa Scrum khuyên bạn không nên áp dụng phương pháp thực hành cụ thể XP quy trình Ví dụ, ban đầu Scrum áp dụng tất phương pháp thực hành mà biết đến XP Tuy nhiên, khung làm việc Scrum cho việc phát triển phần mềm thiết kế để có nhóm nghiên cứu bắt đầu hai ba ngày, thực hành kỹ thuật phải nhiều tháng để thực Vì vậy, để lại câu hỏi (hay không) để thực thực hành cụ thể đội Hai đồng tác giả Scrum Jeff Sutherland Ken Schwaber khuyến nghị Nhóm Scrum bắt đầu tạo danh sách trở ngại kế hoạch cải tiến quy trình Khi việc thực hành kỹ thuật xác định trở ngại, nhóm nên xem xét phương pháp thực hành XP cách để cải tiến Các nhóm tốt sử dụng Scrum bổ sung với thực hành XP Scrum giúp XP mặt quy mô, XP giúp Scrum làm việc tốt 0.7 Kết chương Tôi, người lược dịch, biên tập có điều chỉnh nội dung để dễ hiểu phù hợp với văn phong người Việt, có chút quen thuộc với SCRUM, nghe nói nhiều XP Lean Còn bạn sao? Cá nhân cho rằng, Agile giúp cho lập trình viên có bước phát triển xa, để đáp ứng nguyên lý Agile đòi hỏi lập trình viên phải nâng cao trình độ lực thân, tự tin vào vào lực người đội, giúp đỡ phát triển, thực làm việc tinh thần teamwork hết, gia tăng hài lòng cho khách hàng Mặc dù người áp dụng Agile không lâu, với tinh thần 23 học để chia sẻ, hy vọng mang lại kiến thức dễ đọc dễ hiểu cho bạn Không phải dự án nên áp dụng Agile Nếu mục tiêu bạn tăng suất lao động, làm cho lập trình viên làm việc nhanh Agile không phù hợp quy tắc không nhằm tăng suất đội dự án.Trước định áp dụng Agile cho dự án mình, bạn phải trả lời câu hỏi: liệu Agile có giúp bạn thành công hay không? Các dự án có đặc điểm sau phù hợp với Agile: 1) Mức độ rủi ro thấp 2) Thành viên nhóm có kinh nghiệm 3) Yêu cầu thay đổi thường xuyên 4) Kích thước nhóm nhỏ Các thành viên làm việc địa điểm 5) Văn hóa công ty ưa thích “không trật tự” (thrive on chaos) Trái lại, điều kiện sau vật cản cho việc áp dụng Agile: 1) Kích thước nhóm lớn ( 20 thành viên bao gồm lập trình viên, tester,…) 2) Các thành viên phân tán mặt địa lí (ví dụ dự án outsource) 3) Văn hóa làm việc theo mệnh lệnh  ... bảo đảm nhờ thành công mà nhóm mang lại cho công ty Các phương pháp Agile giúp cho dự án phần mềm đạt ba thành công 1) Thành công mức công ty Agile nhắm đến việc tạo giá trị cho công ty làm giảm... Phát triển phần mềm linh hoạt” (“Manifesto for Agile Software Development – gọi tắt “Tuyên ngôn Agile ) để định nghĩa cách hiểu Phát triển phần mềm linh hoạt Đây cột mốc quan trọng agile Dù trước... Tuyên ngôn Agile (Agile Manifesto) Vào tháng 2/2001, mười bảy nhà phát triển phần mềm gặp gỡ Snowbird, Utah Resort để thảo luận phương pháp phát triển phần mềm gọn nhẹ linh hoạt Họ công bố “Tuyên