mô hình linh hoạt,Agile,mô hình agile,cong nghe thong tin,ki thuat phan mem,mo hinh scum,agile scum, Khái niệm,hoạt động,các quy tắc,ví dụ điển hình Ưu điểm nhược điểm , tuyên ngôn,cac dac diem,cac mo hinh ap dụng
BỘ CÔNG THƯƠNG TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP HÀ NỘI KHOA CÔNG NGHỆ THÔNG TIN BÀI BÁO CÁO MÔN HỌC: NHẬP MÔN CÔNG NGHỆ PHẦN MỀM Đề tài: MÔ HÌNH LINH HOẠT ( AGILE ) Nhóm số: 13 – Lớp KTPM3 – K13 THÀNH VIÊN: Nguyễn Đắc Dũng Nguyễn Mạnh Dũng Trần Trung Dũng Bùi Văn Duy Nguyễn Đức Duy I.Tổng quan về Agile 1.1 Khái niệm đặc điểm Agile Khái niệm Mơ hình phát triển linh hoạt -Agile loại mơ hình gia tăng, phát triển dựa quy trình phát triển lặp Đặc điểm Mỗi dự án chia thành nhiều mảng nhỏ để dễ sử dụng thay đổi khách hàng yêu cầu thay đổi Từng phần nhỏ dự án test trình làm dự án Yêu cầu gặp mặt trao đổi thường xuyên Agile thời điểm nhóm phải tập trung phát triển mảng dự án 1.2 Mức độ phổ biến của phương pháp Hinh 1.1: Biều đồ mức độ phổ biến 1.2.1: Sơ lược vê sự đời của Agile Tháng năm 2001, 17 nhà phát triển gặp Snowbird, Utah, để chia sẻ ý tưởng họ Sutherland người đề xướng tranh luận khác cũng nằm số Nhưng nhóm cũng bao gồm người ủng hộ số phương pháp khác mang tính cạnh tranh với nhau, bao gồm lập trình XP (extreme programming); phát triển phần mềm thích ứng (ASD - adaptive software development); phát triển theo đặc tính (FDD - feature-driven development); phương pháp phát triển hệ thống (DSDM - dynamic-systems-development method) Tất phương pháp dễ hiểu dễ áp dụng chúng ngun lý, điều cho phép thích ứng nhanh chóng với thay đổi từ môi trường xung quanh Nhưng người cảm thấy “dễ hiểu dễ dùng” bước tiến Mặc dù họ bất đồng quan điểm nhiều phương diện, cuối cùng họ thống tên chung: Agile Từ đề xuất người tham dự đọc sách “Agile Competitors and Virtual Organizations: Strategies for Enriching the Customer” 1.3 Tuyên ngôn quy tắc Agile 1.3.1 Bốn tuyên ngôn cua Agile Cá nhân tương tác quan trọng quy trình cơng cụ Ý tưởng đặt trọng tâm vào người tương hỗ thành viên nhóm Cơ dự án có thành viên có lực, chịu làm việc cùng mang đến thành cơng cho dự án Nếu dự án bạn có quy trình làm việc tốt, hỗ trợ công cụ tốt thành viên khơng “cùng nhìn về hướng” khả dự án thất bại lớn Nói điều khơng có nghĩa phủ nhận tầm quan trọng quy trình cơng cụ Agile đặt sau yếu tố người Phần mềm chạy tốt tài liệu đầy đủ Trong số quy trình phát triển phần mềm, việc tạo cập nhật tài liệu về sản phẩm bắt buộc Nhóm Dev khơng thể khơng đồng ý tiến hành cơng việc khơng có tài liệu đặc tả về yêu cầu, thiết kế hệ thống Nhóm Test yêu cầu tài liệu về sản phẩm để viết trường hợp kiểm thử kiểm thử Nhóm QA đòi tất tài liệu phải viết trước sản phẩm giao cho khách hàng khơng khơng đủ điều kiện, chuẩn để giao sản phẩm cho khách hàng Thực đứng với góc độ khách hàng khách hàng quan tâm đến sản phẩm có hoạt động tốt hay không Trong việc tạo cập nhật tài liệu nhiều thời gian cho buồn tẻ Vậy tại phải tập trung nhiều cho việc khơng cần thiết mà khơng dành thời gian để trao đổi để hiểu thêm về công việc phải làm Mọi người đừng hiểu lầm làm Agile không viết tài liệu Ý tưởng viết mà người cần đọc Cộng tác với khách hàng đàm phán hợp đồng “Khách hàng thượng đế” hay “khách hàng luôn đúng” Tuy nhiên khách hàng có đủ loại khách hàng Có khách hàng am hiểu về cơng nghệ, có người khơng Có người suy nghĩ qn có người thay đởi xồnh xoạch, có người lạnh lùng có người cười nói suốt ngày, v.v cách để làm việc tốt phải cộng tác với khách hàng để hiểu khách hàng muốn cần để tư vấn điều chỉnh thay dựa vào điều quy định hợp đồng Phản hồi thay đổi bám sát kế hoạch Hầu hết dự án, khơng có dự án khơng có thay đởi điều chỉnh thực thi Sự thay đởi thay đổi về yêu cầu, thay đổi công nghệ, thay đổi nhân sự, thay đổi deadline, thay đổi phương thức làm việc, v.v mặc dù kế hoạch định rõ ràng từ đầu Agile khơng khuyến khích cho thay đởi khuyến khích tập thích nghi với thay đổi 1.3.2 Các nguyên tắc Agile 12 ngun lí phía sau tun ngơn Agile: Ưu tiên cao thỏa mãn khách hàng thông qua việc chuyển giao sớm liên tục phần mềm có giá trị Chào đón việc thay đởi u cầu, chí muộn q 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 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 Nhà kinh doanh nhà phát triển phải làm việc cùng hàng ngày suốt dự án 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 Phương pháp hiệu để trù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 Phần mềm chạy tốt thước đo tiến độ 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 Liên tục quan tâm đến kĩ thuật thiết kế tốt để gia tăng linh hoạt Sự đơn giản – nghệ thuật tối đa hóa lượng cơng việc chưa xong – 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 Đội sản xuất thường xuyên suy nghĩ về việc để trở nên hiệu hơn, sau họ điều chỉnh thay đổi hành vi cho phù hợp Sau 12 nguyên lý, xin mời bạn xem video sau tự hiểu theo ý nhé: https://www.youtube.com/watch?v=dk435-sHj8c&feature=youtu.be 1.4 Ưu điểm nhược điểm của mơ hình Agile 1.4.1 Ưu điểm Agile lựa chọn tốt cho dự án nhỏ dự án nhỏ thường có u cầu khơng xác định rõ ràng thay đởi thường xun Với Agile khách hàng xem trước phần dự án suốt trình phát triển Agile phát triển phần mềm theo hướng tăng dần, đưa cho khách hàng xem phần thực hồn thành Từ bám sát dự án sẵn sàng cho thay đổi từ phía khách hàng yêu cầu về dự án Agile chia dự án thành phần nhỏ giao cho người, hàng ngày tất người phải họp với khoảng thời gian ngắn để thảo luận về tiến độ giải vấn đề nảy sinh có nhằm đảm bảo quy trình phát triển dự án Tỉ lệ thành công dự án sử dụng Agile thường cao quy trình khác 1.4.2 Nhược điểm Thiếu nhấn mạnh về thiết kế tài liệu cần thiết Quy mô nhân lực thường giới hạn từ đến 10 người, có trở ngại lớn nguồn nhân lực yêu cầu vượt số ví dụ họp trao đổi Số lượng yêu cầu nhiều khó quản lý bao gồm nhiều khía cạnh khác về dự án Số lượng nhân lực tăng, chất lượng khó kiểm sốt Việc kiểm tra mã thường xuyên thiết lập tiêu đánh giá lực lập trình viên cho phép giảm thiểu nhược điểm II Quy trình phát triển Agile Thăm Lên kế hoạch Lặp lặp lại bản phát hành đầu tiên Hồn thiện sản phẩm Bảo trì Mơ hình : Hình 2.1: Mô hình phát triển III Hoạt động bản của Agile Có hoạt đọng bản : Coding Testing Listening Designing 3.1.1 Coding Viết mã (coding) hoạt động khơng thể thiếu Q trình bao gồm : suy nghĩ, viết mã, kiểm tra xem liệu suy nghĩ có hợp lý khơng Mã sử dụng để truyền đạt ý tưởng không rõ ràng Khi nhìn vào đoạn mã, có ý tưởng Mã nguồn sở cho hệ thống 3.1.2 Testing Kiểm thử (testing) hoạt động quan trọng phát triển phần mềm Kiểm thử phải thực liên tục suốt q trình phát triển dự án Có loại kiểm thử : dài hạn ngắn 3.1.3 Listening Các nhà phát triển sử dụng chủ động lắng nghe (listening) đối tác họ Mơ hình Agile phụ thuộc vào hình thức, giao tiếp văn bản, nên lắng nghe trở thành kỹ quan trọng Các nhà phát triển giả định khơng biết về chức mà họ xây dựng, họ phải lắng nghe cách cẩn thận 3.1.4 Designing Thiết kế (designing) cách xây dựng cấu hợp lý cho hệ thống Thiết kế cần phải đơn giản, linh hoạt, dễ dàng mở rộng hệ thống 3.2 Biến điều khiển tài nguyên Thời gian Chi phi Chất lượng Phạm vi IV Đặc Trưng Có đặc trưng bản : Tính lặp (Iterative) Tính tiệm tiến (Incremental) tiến hóa (Evolutionary) Tính thích ứng (hay thích nghi – adaptive) Nhóm tự tổ chức liên chức Quản lý tiến trình thực tiễn (Empirical Process Control) Giao tiếp trực diện(face-to-face communication) Phát triển dựa giá trị (value-based development) 4.1 Tinh lặp (Iterative) 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 chia 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 4.2 Tính tiệm 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ùng Các phần nhỏ thường đầy đủ, có khả chạy tốt, kiểm thử cẩn thận sử dụng (gọi potentially shippable product increment of functionality) 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 tại 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 4.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 cũng điều chỉnh liên tục, nên thay đởi q trình phát triển (yêu cầu thay đổi, thay đổi công nghệ, thay đổi định hướng về mục tiêu v.v.) đều đá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 10 sử dụng tiếp cận lặp (iterative), tăng trưởng (incremental) để tối ưu hóa tính khả đoán (predictability) kiểm soát rủi ro Ba yếu tố nòng cốt tạo thành mơ hình quản lý tiến trình thực nghiệm gồm: minh bạch (transparency), tra (inspection) thích nghi (adaptation) Minh bạch(transparency): Muốn thành cơng với Scrum, thơng tin liên quan tới q trình phát triển phải minh bạch thông suốt Các thông tin là: tầm nhìn(vision) về sản phẩm, yêu cầu khách hàng, tiến độ công việc, khúc mắc rào cản Từ người vai trò khác có đủ thơng tin cần thiết để tiến hành định có giá trị để nâng cao hiệu công việc Các công cụ họp Scrum đảm bảo thông tin minh bạch cho bên 16 Các khía cạnh quan trọng tiến trình phải hiển thị rõ ràng cho người có trách nhiệm với thành tiến trình Sự minh bạch u cầu yếu tố cần định nghĩa theo tiêu chuẩn để người quan sát hiểu họ thấy theo cùng cách Ví dụ: Một ngơn ngữ chung về quy trình cần phải chia sẻ cho tất bên tham gia Một định nghĩa chung về “Hoàn thành” phải chia sẻ người đảm đương công việc người tiếp nhận sản phẩm cơng việc Thanh tra(inspection): Người sử dụng Scrum phải thường xuyên tra tạo tác tiến độ đến đích để phát bất thường không theo ý muốn Tần suất tra không nên dày để khỏi ảnh hưởng đến cơng việc Cơng tác tra có ích thực người có kĩ tại điểm quan trọng công việc Công tác tra liên tục hoạt động Scrum đảm bảo cho việc phát lộ vấn đề cũng giải pháp để thơng tin đa dạng hữu ích đến với bên tham gia dự án Truy xét kỹ liên tục chế khởi đầu cho việc thích nghi cải tiến liên tục Scrum Thich nghi(adaptation): Nếu người tra xác định có vấn đề vượt giới hạn cho phép hậu vấn đề sản phẩm khơng thể chấp nhận được, quy trình vật liệu xử lý (processed material) phải điều chỉnh Sự điều chỉnh phải tiến hành sớm tốt để giảm thiểu sai sót khác xảy Scrum linh hoạt phương pháp Agile khác Nhờ mang lại tính thích nghi cao Dựa thơng tin minh bạch hóa từ q trình tra làm việc, Scrum phản hồi lại thay đởi cách tích cực, nhờ mang lại thành cơng cho dự án 6.3: Ba vai tro 17 Trong Scrum, đội ngũ tham gia phát triển phần mềm chia làm ba vai trò với trách nhiệm rõ ràng để đảm bảo tối ưu hóa cơng việc đặc thù sau: Product Owner (chủ sản phẩm): PO : người chịu trách nhiệm về thành công dự án, người định nghĩa yêu cầu đánh giá cuối cùng đầu nhà phát triển phần mềm Cách thức để đạt điều khác tở chức, Nhóm Scrum cá nhân Product Owner người chủ yếu chịu trách nhiệm về việc quản lý Product Backlog Đây công cụ quản lý chứa: Mô tả hạng mục Product backlog 18 Trình tự hạng mục Product Backlog để đạt mục đích hồn thành nhiệm vụ Sự đảm bảo giá trị cơng việc Nhóm Phát triển Sự đảm bảo cho Product Backlog luôn hữu, thông suốt rõ ràng tới tất người mà Nhóm Scrum làm việc Sự đảm bảo cho Nhóm Phát triển hiểu rõ hạng mục Product Backlog với mức độ cần thiết Product Owner tự thực cơng việc để Nhóm Phát triển làm Tuy nhiên, Product Owner phải chịu trách nhiệm Product Owner người, ủy ban Product Owner cần tới ủy ban tham gia vào Product Backlog, người ủy ban muốn thay đởi trình tự hạng mục Product Backlog phải thuyết phục Product Owner Để Product Owner thành công, tổ chức phải tôn trọng định người Các định hiển thị nội dung thứ tự Product Backlog Khơng ngồi Product Owner phép u cầu Nhóm Phát triển làm khác Nhóm Phát triển cũng khơng phép làm theo lời bất cứ người khác Link: https://www.youtube.com/watch?v=3eljozEWpf8&feature=youtu.be Nhóm phát triển (Development Team): Nhóm Phát triển (Development Team) gồm chuyên gia làm việc phần tăng trưởng phát hành (potentially releasable) cuối Sprint Chỉ thành viên Nhóm Phát triển tạo phần tăng trưởng (Increment) Nhóm Phát triển cấu trúc trao quyền để tổ chức quản lý công việc họ Sự hợp lực tối ưu hóa nỗ lực hiệu tởng thể Nhóm Phát triển Nhóm Phát triển có đặc trưng sau: Đó nhóm tự tở chức Khơng (kể Scrum Master) có quyền yêu cầu Nhóm Phát triển làm để chuyển Product Backlog thành phần tăng trưởng chuyển giao 19 Đó nhóm liên chức năng, với tất kĩ cần thiết để tạo phần tăng trưởng sản phẩm Scrum khơng ghi nhận chức danh Nhóm Phát triển ngồi Nhà phát triển (Developer), theo tính chất cơng việc người này, khơng có ngoại lệ cho quy tắc Các thành viên Nhóm phát triển có kĩ chun biệt chun mơn đặc thù, họ phải chịu trách nhiệm thể thống Nhóm Phát triển Nhóm Phát triển khơng chứa nhóm khác với chức đặc thù ‘nhóm kiểm thử’ hay ‘phân tích nghiệp vụ’ Độ lớn tối ưu Nhóm Phát triển đủ nhỏ để giữ linh hoạt đủ lớn để hồn thành cơng việc Ít ba người làm giảm tương tác dẫn đến suất thấp Các Nhóm Phát triển nhỏ phải đối mặt với ràng buộc kĩ suốt Sprint, dẫn đến Nhóm Phát triển khó chuyển giao gói tăng trưởng phát hành Một nhóm nhiều chín người cần nhiều điều phối Các Nhóm Phát triển lớn phát sinh nhiều phức tạp để thực việc kiểm soát tiến trình thực nghiệm Các vai trò Product Owner Scrum Master khơng tính vào kích thước Nhóm Phát triển, trừ họ cũng kiêm ln vai trò thành viên Nhóm Phát triển Link: https://www.youtube.com/watch?v=vLqCkj0PvtE&feature=youtu.be Scrum Master: Scrum Master chịu trách nhiệm đảm bảo người hiểu dùng Scrum Scrum Master thực việc cách đảm bảo Nhóm Scrum tuân thủ lý thuyết, kĩ thuật thực hành quy tắc Scrum Scrum Master lãnh đạo, cũng người phục vụ Nhóm Scrum Scrum Master giúp đỡ người ngồi Nhóm Scrum hiểu cách phải tương tác với nhóm cho hiệu Scrum Master giúp đỡ tất người cải tiến mối tương tác để tối đa hóa giá trị mà Nhóm Scrum tạo 20 Scrum Master phục vụ cho Product Owner? Scrum Master phục vụ Product Ower theo nhiều cách, bao gồm: Tìm kiếm kĩ thuật để quản lý hiệu Product Backlog Giao tiếp tích cực với Nhóm Phát triển về tầm nhìn, mục đích hạng mục Product Backlog Huấn luyện cho Nhóm Phát triển biết cách tạo hạng mục Product Backlog thật rõ ràng đơn giản Hiểu rõ việc lập kế hoạch dài hạn sản phẩm môi trường thực nghiệm Hiểu rõ thực hành linh hoạt (agility) Thúc đẩy kiện Scrum theo yêu cầu cần thiết Scrum Master phục vụ cho Nhóm Phát triển? Scrum Master phục vụ Nhóm Phát triển theo nhiều cách, bao gồm: Huấn luyện Nhóm Phát triển cách tự tổ chức làm việc liên chức Giúp đỡ Nhóm Phát triển để tạo sản phẩm có giá trị cao Loại bỏ trở lực q trình tác nghiệp Nhóm Phát triển Thúc đẩy kiện Scrum theo yêu cầu cần thiết Huấn luyện Nhóm Phát triển trường hợp tở chức chưa có hiểu biết ứng dụng đầy đủ về Scrum Scrum Master phục vụ cho Tở chức? Scrum Master phục vụ Tở chức theo nhiều cách, bao gồm: Lãnh đạo huấn luyện tổ chức việc áp dụng Scrum Lập kế hoạch triển khai Scrum phạm vi tổ chức Giúp đỡ nhân viên bên hữu quan hiểu sử dụng Scrum cũng trình phát triển sản phẩm thực nghiệm (emprical product development) 21 Tạo thay đổi làm tăng suất Nhóm Scrum Làm việc với Scrum Master khác để gia tăng hiệu việc áp dụng Scrum tở chức Link: https://www.youtube.com/watch?v=eNe0UEsBalA&feature=youtu.be 6.4 Bốn c̣c họp Khi áp dụng Scrum, có họp (Meetings or Ceremonies) quan trọng tạo nên cấu trúc Sprint sau: Sprint planning: Cuộc họp lên kế hoạch đội dự án, nhằm xác định cần hồn thành Spring sắp tới Daily stand-up: Cũng biết đến “Daily Scrum”, họp nhỏ 15 phút ngày để trao đổi công việc đội phát triển Sprint demo: Một họp chia sẻ, nơi mà thành viên họ làm Sprint Sprint retrospective: Sự đánh giá, nhìn lại điều làm chưa làm Sprint tại, đưa giải pháp hành động cho Sprint tốt hồn thiện 6.5 Các cơng cụ Scrum Scrum sử dụng công cụ đơn giản hiệu để trợ giúp công việc Product Backlog: Đây danh sách ưu tiên tính (feature) đầu khác dự án, hiểu danh sách yêu cầu(requirement) dự án PO chịu trách 22 nhiệm sắp xếp độ ưu tiên cho hạng mục (Product backlog Item) Product backlog dựa giá trị PO định nghĩa (thường giá trị thương mại business value) Sprin Backlog: Đây kế hoạch cho sprint; kết cho buổi họp lập kế hoạch (Sprint Planning) Với kết hợp PO, nhóm phân tích yêu cầu theo độ ưu tiên từ cao xuống thấp để thực hóa hạng mục Product Backlog dạng danh sách công việc (TODO list) Burndown Chart: Đây biểu đồ thể xu hướng dự án dựa lượng thời gian cần thiết lại để hồn tất cơng việc Burndown Chart dùng để theo dõi tiến độ Sprint (được gọi Sprint Burndown Chart) dự án (Project Burndown Chart) Biểu đồ Burndown thành tố tiêu chuẩn Scrum theo định nghĩa mới, sử dụng rộng rãi tính hữu ích Những doanh nghiệp sử dụng mơ hình Scrum: Scrum phương pháp được áp dụng phổ biến được áp dụng nhiều doanh nghiệp : 23 Hình 6.2: Doanh nghiệp sử dụng VII Ứng dụng của Agile quản li thời gian công việc 7.1 Đánh giá thời gian độ ưu tiên của cơng việc Chúng ta khơng thể có đủ thời gian để làm hết tất việc cần xác định mục tiêu mang lại giá trị nhiều chứ làm nhiều việc cùng lúc Nguyên tắc Agile nghệ thuật tối đa hóa cơng việc chưa hồn thành Dựa thời gian có sẵn dự án khối lượng công việc, phân chia công việc theo mức độ ưu tiên: Làm ngay, không cần làm chưa làm hay giao việc cho người khác (cấp th ngồi) Có cơng cụ hiệu để làm bước này: ma trận Eisenhower đánh giá độ ưu tiên dựa vào ROI (giá trị thu / chi phí bỏ ra) mức độ khẩn cấp công việc 24 Công cụ 1: Ma trận ưu tiên Eisenhower Ít khẩn cấp Khẩn cấp Quan trọng I Đặt deadline tự làm II Tự làm Ít quan trọng III Bỏ qua IV Giao cho người khác Công cụ 2: Đánh độ ưu tiên dựa vào ROI (giá trị thu / chi phí bỏ ra) mức độ khẩn cấp Công việc Giá trị Khẩn cấp Ưu tiên Sửa code website 5 Làm landing page 21 SEO 100 từ khóa 10 20 Test phần mềm 11 33 Thiết kế phần mềm 4 16 7.2 Lập khung thời gian thực Lập khung thời gian cho công việc để dễ dàng quản lý, tạo kỹ luật hoàn thành công việc cho thân Thực nguyên tắc Agile về việc trì nhịp độ làm việc liên tục, thúc đẩy phát triển bền vững Ví dụ: Mỗi phiên làm việc tập trung không 25 phút để tránh tình trạng căng thẳng cạn kiệt lượng Duy trì khoảng cách lần nghỉ ngơi khoảng phút để nghỉ liên tục không chiếm nhiều thời gian Đưa công việc cụ thể cho kế hoạch ngày, tuần tháng để quản lý tập trung dễ dàng, trì lịch làm việc liên tục không gián đoạn 25 7.3 Quản lý theo luồng Bảng Kanban công cụ để thực phương pháp Agile hiệu quả, gia tăng suất tránh tình trạng q tải cơng việc cùng lúc Mỗi cá nhân/nhóm xây dựng bảng cơng việc cụ thể phân chia theo phần: List cần làm, làm hồn thành Bạn sử dụng Trello để quản lý công việc trực tuyến cách dễ dàng Cần làm (5) Gửi mail giới thiệu sản phẩm cho đối tác Đang làm (2) Làm thủ tục hành cho chi nhánh Biên dịch hồ sơ thầu cho công ty Biên dịch 100 trang tài liệu kỹ thuật Chuẩn bị thông tin về sản chuyên ngành phẩm Soạn email tốn gửi khách hàng Hồn thành (2) Kế hoạch phát triển sản phẩm m Thuyết trình kế hoạch marketing giám đốc Đón tiếp khách hàng VIP 7.4 Điều chỉnh hành vi để loại bỏ lãng phi Do giới hạn về lượng thời gian làm việc nên tập trung vào việc tăng chất lượng thời gian Một số cách để tránh lãng phí thời gian làm việc: 26 Việc làm xong tới đâu đánh giá chất lượng theo tiêu chuẩn đề để kịp thời điều chỉnh cải thiện hiệu công việc Bắt đầu kết thúc công việc luôn, không đề dang dở Aglile trọng làm việc tới đâu hồn thành tới Tập trung làm việc hướng đến mục tiêu, tránh đa nhiệm cùng lúc Ví dụ: Không vừa họp vừa nghe điện thoại, vừa làm SEO vừa thiết kế poster, vừa check mail vừa viết báo cáo, Câu hỏi dành cho nhóm: Câu hỏi 1: Tại sử dụng phương pháp Agile? Những phương pháp Agile tập trung vào phân đoạn (iterations) ngắn hơn, phần mềm thường xuyên mang tới mức độ chất lượng với “khả phát hành” (releasable), thường hàng tuần đến hàng tháng Những phân đoạn ngắn cũng cung cấp nhiều lợi ích về mặt công nghệ quản lý Về mặt công nghệ, lợi ích giảm thiểu rủi ro tích hợp số lượng phần mềm tích hợp thường giữ mức nhỏ Những phân đoạn nhỏ cũng giúp việc kiểm soát chất lượng cách thường xuyên hướng tới trạng thái “khả phát hành”, ngăn cản dự án khỏi việc tích luỹ số lượng lớn cơng việc sửa lỗi Về mặt quản lý, phân đoạn thường xuyên liên tục cung cấp chứng tiến triển, có xu hướng dẫn đến khả thể tốt trạng thái, mối quan hệ tốt với khách hàng tinh thần nhóm tốt Những phương pháp Agile cũng thường xử lý yêu cầu linh động phương pháp truyền thống Trong số môi trường, điểm cộng, số khác, điểm trừ Nếu bạn làm việc môi trường không cần nhiều khả dự báo tầm xa về nhóm chức năng, việc xử lý yêu cầu linh động tiết kiệm nhiều cơng việc đặc tả chi tiết yêu cầu tránh “yêu cầu hỏng” (requirements spoilage), thường cùng với công việc tồn đọng kéo dài yêu cầu chi tiết Câu hỏi 2: Thách thức lớn thực thi phương pháp Agile? 27 Thách thức lớn chúng tơi nhìn thấy qua việc kinh doanh tư vấn đào tạo tiến bước Bạn khơng thể nói bạn làm Agile Bạn phải tiếp tục qua hành động cụ thể Tất nhiên, cũng vấn đề thấy nhiều năm trước với phương pháp lập trình hướng đối tượng, trước với phương pháp lập trình có cấu trúc, khơng vấn đề riêng Agile Như thấy, thách thức cụ thể lớn đơn giản “xoay chuyển chiến hạm” tổ chức lớn để vượt qua qn tính cố hữu cơng việc thực tế kỳ vọng; và, định hướng việc thực kỳ vọng theo cách khác Bạn phải hội tụ tâm để thực làm việc với phân đoạn ngắn Bạn phải build (dựng thành phần mềm) thường xuyên, hàng ngày, bạn phải phát triển kỷ luật để đảm bảo build tốt Bạn phải đẩy nhanh phân đoạn tới mức độ chất lượng với “khả phát hành” điều khó thực lần đầu tiên Như tiền lệ, vấn đề không riêng Agile Nếu làm việc tổ chức nhận thấy nhu cầu lớn thực tốt công việc xác định yêu cầu phía trước (điều khơng linh hoạt lắm), “xoay chuyển chiến hạm” để định nghĩa yêu cầu phía trước tốt cơng việc khó khăn Câu hỏi 3: Agile thành công môi trường nào? Một cách tồn diện, tơi thấy Agile phù hợp với mơi trường có ngân sách cố định hàng năm, quy mơ nhóm cố định hàng năm (theo ngân sách), sứ mệnh nhân viên dự án mang lại chức nghiệp vụ có giá trị nhất, mà họ mang lại thời gian năm với quy mơ nhóm cố định Môi trường thường mô tả tổ chức phát triển hệ thống nghiệp vụ nội (in-house) Linh hoạt toàn diện (đặc biệt với yêu cầu linh động) thường phù hợp với cơng ty bán phần mềm, việc trì linh hoạt nhiều chức ngược lại với mục tiêu cung cấp khả dự báo trung dài hạn Chúng thấy nhiều tổ chức đánh giá khả dự báo cao yêu cầu linh động Nghĩa là, họ đánh giá khả thực cam kết với khách hàng hay thị trường trọng điểm đánh giá khả “phản hồi với thay đổi” Tuy nhiên, với môi trường không linh hoạt tồn diện, chúng tơi cũng thấy nhiều thực hành Agile phù hợp với đại đa số môi trường Những phân đoạn phát triển ngắn gần giá trị, cho dù bạn định nghĩa 5% hay 95% yêu cầu sắp 28 tới Luôn giữ phần mềm gần tới mức độ chất lượng với “khả phát hành” tất phần đoạn gần ln có giá trị Scrum dường áp dụng rộng rãi phong cách quản lý kỷ luật Những đội nhỏ trao qùn thường ln hữu ích Tơi thể chi tiết về điểm mạnh điểm yếu chi tiết thực hành phát triển linh hoạt trình bày về điều hành tại Kế thừa Phát triển Agile Câu hỏi 4: Tương lai Agile? Agile trở thành từ đồng nghĩa với “thực hành phần mềm đại” (“modern software practices that work”) rộng rãi, tơi nghĩ tương lai Agile với chữ hoa “A” (tác giả phân biệt “agile” – linh hoạt, “Agile” – phương pháp Agile) cũng giống Object Oriented hay Structured trước Chúng ta gần khơng nói về lập trình Object Oriented nữa; đơn giản lập trình Tương tự, tơi nghĩ Agile cũng theo dòng chảy chung, vài năm tới khơng nói thêm về Agile nữa, bất cứ thích hợp, nói lập trình, giả định người đều hiểu Agile Link tham khảo: https://resources.base.vn/productivity/tong-quanve-phuong-phap-agile-trong-quan-ly-cong-viec-vadu-an-200 http://apmp.vn/quy-trinh-scrum-trong-phat-trienphan-mem/ https://viblo.asia/p/scrum-va-quy-trinh-phat-trienphan-mem-truyen-thong-sdlc-WAyK8MneZxX https://itviec.com/blog/agile-la-gi-scrum-la-gi/ 29 https://123doc.org/document/1103550-de-tai-tim-hieu-ve-quytrinh-phat-trien-phan-mem-theo-agile-pptx.htm 30