Tài liệu Tiểu luận môn họcquản lý dự án phần mềm tìm hiểu về managing agile project

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ -------------------------- TIỂU LUẬN MÔN HỌC: QUẢN LÝ DỰ ÁN PHẦN MỀM CHUYÊN ĐỀ: TÌM HIỂU VỀ Managing Agile Project Giáo viên hướng dẫn: TS. Trương Anh Hoàng TS. Phạm Ngọc Hùng Nhóm học viên: 1. Trần Thị Hiền 2. Nguyễn Anh Khiêm* 3. Phan Thị Luân 4. Phạm Đức Mạnh 5. Nguyễn Thị Yến Hà Nội 04/2013 LỜI CẢM ƠN Lời đầu tiên chúng em xin cảm ơn thầy TS. Trương Anh Hoàng và TS. Phạm Ngọc Hùng, thầy đã nhiệt tình giảng dạy và hướng dẫn chúng em làm bài tập lớn môn Quản lý dự án phần mềm trong học kỳ này. Chúng tôi cũng gửi lời cảm ơn tới các bạn học viên lớp Quản lý dự án đã có những ý kiến đóng góp giá trị cùng những lời động viên khích lệ khi thực hiện tiểu luận này. Hà Nội, ngày 31 tháng 03 năm 2013 Học viên nhóm 2 Trần Thị Hiền Nguyễn Anh Khiêm* Phan Thị Luân Phạm Đức Mạnh Nguyễn Thị Yến TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN BẢNG PHÂN CÔNG CÔNG VIỆC STT Họ và tên Nội dung công việc Trần Thị Hiền 11 Tìm hiểu các kiến thức chung về Agile Viết báo cáo 22 Nguyễn Anh Khiêm Tổng hợp các kiến thức chung về Agile Viết báo cáo và thiết kế Slide Tìm hiểu các kiến thức chung về Agile 33 Phan Thị Luân Viết báo cáo Tìm hiểu về sự phát triển của Agile 44 Phạm Đức Mạnh Thiết kế Slide Tổng hợp các kiến thức chung về Agile 55 Nguyễn Thị Yến Viết và chỉnh sửa báo cáo 4 TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN MỤC LỤC 1. Giới thiệu phát triển lặp:........................................................................................6 2. Agile Development................................................................................................11 2.1 Khái niệm:........................................................................................................11 2.2 Quá trình vận hành Agile:.................................................................................12 2.3 Quản lý dự án theo phương pháp Agile............................................................13 2.4 Vai trò của người quản lý Agile........................................................................14 2.5 Chia sẻ trách nhiệm quản lý..............................................................................17 2.6 Vai trò khác của quản lý...................................................................................18 2.7 Hồ sơ của người quản lý dự án.........................................................................19 2.8 Kỹ năng lãnh đạo - Đối phó với sự thay đổi ....................................................21 2.9 Kỹ năng quản lý – Xử lý phức tạp....................................................................22 3. Các đặc điểm của phương pháp Agile.................................................................23 KẾT LUẬN ...............................................................................................................29 TÀI LIỆU THAM KHẢO..........................................................................................30 5 TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN DANH MỤC CÁC HÌNH VẼ Hình 1: Mô hình thác nước.................................................................................. 7 Hình 2: Mô hình thác nước mở rộng ....................................................................8 Hình 3: Mô hình chữ V........................................................................................ 8 Hình 4: Mô hình Prototype ..................................................................................8 Hình 5: Mô hình xoắn ốc..................................................................................... 9 Hình 6: Mô hình lãnh đạo và quản lý .................................................................17 6 DANH MỤC TỪ VIẾT TẮT Từ viết tắt Giải thích Agile Agile software development APM Agile Project Management ID Interative Development BDD Behavior Driven Development TDD Test Driven Development DDD Domain Driven Design 5 TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN XÁC ĐỊNH VAI TRÒ & TRÁCH NHIỆM CỦA QUẢN LÝ AGILE Với phương pháp phát triển phần mềm truyền thống là “waterfall” hay “RUP”, thời gian hoàn thiện hay nâng cấp một phiên bản phần mềm thường kéo dài gần một năm trời như Windows hay nhiều phần mềm khác, thường một năm thậm chí hơn, các công ty mới cho ra một bản nâng cấp. Với phần mềm được phát triển theo Agile tiêu biểu như Chrome, một năm, trình duyệt này cho ra vài ba bản nâng cấp. Thậm chí chỉ mất một tuần để cho ra sản phẩm đầu tiên rồi một tuần sau lại ra một bản cập nhật, cứ liên tục như vậy. Với xu hướng mobile hóa như hiện nay, phát triển phần mềm ứng dụng theo Agile là rất phù hợp để nhanh có sản phẩm đưa ra thị trường. Quy trình quản lý dự án phần mềm: 7 bước. B1: Định nghĩa bài toán. B2: Phân tích B3: Thiết kế B4: Lập trình. B5: Tích hợp hệ thống. B6: Nghiệm thu. B7: Vận hành. 1. Giới thiệu phát triển lặp: Là một kiểu phát triển phần mềm mà chu trình sống của phần mềm được chia thành các vòng lặp liên tiếp nhau. Ví dụ: Giả sử sau khi nghiên cứu yêu cầu từ phía khách hàng, ta thống kê được phần mềm có tổng cộng 50 chức năng. Giả sử ta chọn 2 trong số 50 chức năng trên, ước lượng thời gian thực hiện 2 chức năng đó trong vòng khoảng 2 tuần chẳng hạn, để thực hiện hoàn chỉnh. Ta xây dựng phần mềm hoàn chỉnh phần mềm với chỉ 2 chức năng đó, rồi chuyển cho khách hàng sử dụng và đánh giá. Sau đó, khách hàng sẽ đưa ra đánh giá về 2 chức năng mà ta đã làm. Giả sử trong 2 chức năng đó, có 1 chức năng chưa hoàn chỉnh hoặc chưa 6 TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN đáp ứng đúng yêu cầu khách hàng, ta giữ lại chức năng đó cùng với những đánh giá của khách hàng. Tiếp theo trong 48 chức năng còn lại, ta lại chọn ra 3 chức năng nữa, cộng với chức năng cũ là thành 4 chức năng và ước lượng thời gian hoàn thành trong vòng 2 tuần. Ta lại xây dựng phần mềm hoàn thiện với chỉ 4 chức năng đó. Sau khi xây dựng xong, ta lại đưa cho khách hàng chạy thử và xem phản hồi, đánh giá từ khách hàng. Tiếp tục ta lại chọn ra thêm 10 chức năng nữa để xây dựng, và ước lượng thời gian hoàn thành trong vòng cũng 2 tuần. Càng ngày ta có thể xây dựng phần mềm càng nhanh vì ta đã gần như nắm bắt được hệ thống, càng ngày càng có kinh nghiệm xây dựng các chức năng cho hệ thống đó. Theo đó, ta sẽ chọn thời gian cho mỗi vòng lặp là cứ 2 tuần. Hệ thống của chúng ta từ nhỏ, sẽ to dần to dần cho đến khi hoàn tất tất cả chức năng mà khách hàng yêu cầu. Mục tiêu của mỗi vòng lặp là một hệ thống được xây dựng, kiểm thử cẩn thận, chạy ổn định và có thể đưa vào sử dụng. Mỗi vòng lặp đều gồm các bước phân tích yêu cầu, thiết kế, phát triển, tích hợp (có thể ban đầu chúng ta chưa cần thực hiện bước này), kiểm thử và vận hành, chuyển giao cho khách hàng sử dụng và nhận phản hồi. Kết quả của mỗi vòng lặp là một release hoàn chỉnh, và release sau phải bao gồm cả release trước đó chứ không phải là release độc lập. Điểm khác biệt so với những mô hình cổ điển (water fall, V model…) Hình 1 : Mô hình thác nước 7 TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN Hình 2 : Mô hình thác nước mở rộng Hình 3 : Mô hình chữ V Hình 4: Mô hình Prototype 8 TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN Hình 5: Mô hình xoắn ốc Chẳng hạn ta có phần mềm phát triển trong vòng 2 năm: - Nếu phát triển theo water fall: ta có thể thực hiện việc phân tích yêu cầu trong vòng 3 tháng, thiết kế hệ thống trong vòng 3 tháng, phát triển trong vòng 1 năm và bảo trì trong vòng 6 tháng còn lại. - Nếu phát triển theo phát triển lặp: 3 tuần đầu thực hiện phân tích yêu cầu của 2 chức năng, sau đó thiết kế hệ thống và phát triển hoàn thiện 2 chức năng đó, kiểm thử và chuyển cho khách hàng sử dụng và đánh giá. Trong 3 tuần tiếp theo, ta thực hiện phân tích yêu cầu của 5 chức năng khác, sau đó thiết kế hệ thống và phát triển 5 chức năng này, kiểm thử và lại chuyển giao cho khách hàng sử dụng và đánh giá. Quá trình này cứ lặp đi lặp lại, công việc trong mỗi vòng lặp tương tự nhau. 3 tuần đầu chúng ta vẫn có phần phân tích yêu cầu, 3 tuần kế tiếp vẫn có phần phân tích yêu cầu,… cho đến 3 tuần cuối cùng của 2 năm ta vẫn có phần phân tích yêu cầu. Đối với water fall, việc phân tích yêu cầu chỉ xảy ra ở 3 tháng đầu tiên, qua thời gian này là đã chuyển sang bước khác. Khái niệm “time-boxed” trong phát triển lặp: có nghĩa là chúng ta cố định thời gian kết thúc 1 vòng lặp. Khái niệm trên nghe có vẻ đơn giản nhưng chúng ta cần lưu ý như sau. Quay trở lại “tam giác chất lượng”, ta có 4 thành phần ảnh hưởng đến dự án, đó là yêu cầu của khách hàng, thứ 2 là chất lượng của dự án, thứ 3 là nguồn lực mà chúng ta có, và cuối cùng là thời gian. Vậy “time-boxed” ở đây có ý nghĩa gì? Ở đây, nó có nghĩa rằng chúng ta cố định phần thời gian thực 9 TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN hiện (chẳng hạn như 5 ngày, sau 5 ngày yêu cầu phải cho ra 1 hệ thống nhỏ), ta có thể thay đổi các yếu tố khác. Chẳng hạn, trong 5 ngày yêu cầu thực hiện 20 tính năng của phần mềm, nhưng vào thời điểm đó, các yếu tố khác không đủ để đáp ứng yêu cầu này, và ta phải giảm 1 đỉnh của tam giác lại, chẳng hạn ta đề xuất giảm xuống còn 10 tính năng để làm sao sau 5 ngày cho ra được hệ thống. Hoặc là với 20 tính năng đó, với nguồn nhân lực hiện tại không đủ đáp ứng được, có thể đề xuất thêm người vào làm để đảm bảo sau 5 ngày cho ra được hệ thống. 3 cạnh của tam giác có thể thay đổi nhưng đỉnh thời gian không thay đổi, cố định. Khái niệm phát triển tiến hóa và thích nghi trong phát triển lặp: Chẳng hạn ta chia dự án ra thành 10 vòng lặp, mỗi vòng lặp 3 tuần, yêu cầu khách hàng đưa ra là 100 chức năng. Ở vòng lặp đầu tiên, giả sử ta hiểu được 20% yêu cầu và phát triển được hệ thống hoàn thiện đáp ứng 20% yêu cầu đó với 2 chức năng. Đến vòng lặp tiếp theo, giả sử ta hiểu được thêm 10% yêu cầu và phát triển được thêm 3 chức năng (cộng với 2 chức năng đã làm ở vòng lặp trước nữa là thành 5 chức năng, tức 5%). Đến vòng lặp sau, ta hiểu được thêm 20% yêu cầu và phát triển được thêm 3 chức năng nữa. Đến vòng lặp thứ 4, giả sử ta hiểu được thêm 40% yêu cầu và làm được thêm 2 chức năng nữa. Sang vòng lặp thứ 5, ta dừng việc phân tích yêu cầu, mặc dù còn 10% yêu cầu ta chưa hiểu nó ra sao, ta tập trung phát triển thêm 10 chức năng nữa cho hệ thống. Khi đó, hệ thống hiện tại có 20 chức năng. Sau đó, giả sử ở vòng lặp thứ 6, ta không phát triển hệ thống nữa mà tập trung phân tích 10% yêu cầu còn lại của khách hàng, khi đó ta đã hiểu hết các yêu cầu mà khách hàng đưa ra. Sang những vòng lặp tiếp theo, ta cứ việc phát triển hệ thống để hoàn thiện các chức năng còn lại. 10 TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN * Điểm đặc trưng của phát triển lặp: - Ban đầu yêu cầu cùa khách hàng không phải lúc nào cũng rõ ràng, khó mà xác định “đúng” được. Thay vì bỏ ra một khoảng thời gian để xác định hết yêu cầu của khách hàng, chúng ta có thể phát triển dần dần, từ từ hiểu yêu cầu của khách hàng. Khi áp dụng phát triển lặp, đối với khách hàng đó là điều tốt vì nó làm tăng độ tin cậy của khách hàng đối với sản phẩm (sau mỗi vòng lặp, sản phẩm đưa ra đó là hệ thống, phần mềm hoàn chỉnh cho dù chức năng còn ít và khách hàng có thể biết được sản phầm của mình nó như thế nào). - Khách hàng có thể thay đổi yêu cầu bất cứ lúc nào, và phát triển lặp được đưa ra để đáp ứng việc này. - Trở ngại lớn nhất của phát triển lặp đó là việc ước lượng, định giá cho dự án, bởi vì chúng ta sẽ không có yêu cầu từ đầu, do đó cũng sẽ không có thiết kế ngay từ đầu. Ở những vòng lập đầu tiên, việc ước lượng có thể cho sai số gấp 3 lần bình thường . Nhưng càng về sau, sai số sẽ ngày càng nhỏ đi. 2. Agile Development Agile là một mô hình phát triển phần mềm kế thừa từ phát triển lặp. 2.1 Khái niệm: là phương pháp phát triển lặp cố định thời gian của từng vòng lặp, đưa ra các sản phẩm (release) theo hướng tiến hóa dần, có kế hoạch thích hợp (không phải cố định), sẵn sàng cho mọi sự thay đổi nếu có xảy ra. (P/S: phát triển lặp có thể không cần cố định về thời gian.) * Bốn khái niệm (đặc điểm) quan trọng trong phát triển Agile: 11 TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN - Con người và sự tương tác giữa người với người đặt lên trên quy trình và công cụ sử dụng: có nghĩa là quy trình hiện tại là như vậy nhưng ta hoàn toàn có thể thay đổi nó một chút (thêm phần này, bớt phần kia). - Phần mềm làm việc thay cho tài liệu phức tạp: trọng tâm của phát triển Agile đó là sản phẩm đưa ra (có thể nhảy vào coding vẫn được miễn là code đúng, code chạy; không cần thiết kế vẫn được). - Việc tương tác với khách hàng đặt lên trên các hợp đồng, thương thảo: như đã nói ở phần trên, thì sau mỗi vòng lặp chúng ta sẽ chuyển giao cho khách hàng sản phẩm để nhận phản hồi, đánh giá từ khách hàng. - Sẵn sàng cho sự thay đổi thay vì theo như kế hoạch nhất định. 2.2 Quá trình vận hành Agile: Đầu tiên là phải xác định vấn đề phải giải quyết cho phần mềm, sau đó đưa ra các khái niệm, ý tưởng để giải quyết vấn đề đó. Tiếp theo, chúng ta đưa ra chứng minh cho khách hàng xem là ta có thể thực hiện được (proof of concept) – không nên thiên về kỹ thuật nên hướng về phần nghiệp vụ nhiều hơn. Đây là bước quan trọng bắt buộc khi phát triển theo Agile. Sau khi 2 bên đã đồng ý và ký kết hợp đồng xong, chúng ta sẽ bắt đầu đi vào quy trình phát triển phần mềm. Quy trình phát triển phần mềm trong Agile tương tự như khi phát triển lặp nhưng không hoàn toàn là phát triển lặp. Như đã trình bày ở trên thì Agile không tập trung vào các yêu cầu, tài liệu. Vậy làm sao chúng ta biết và nắm yêu cầu của khách hàng? Trong Agile có 1 khái niệm đó là Story. Một dự án bao gồm rất nhiều story được xếp theo thứ tự mức độ ưu tiên. Khi phát triển phần mềm, chúng ta phải lấy theo thứ tự độ ưu tiên giảm dần. Phương pháp quản trị dự án Agile đang được nhiều doanh nghiệp phần mềm Việt Nam nghiên cứu triển khai. Tại Việt Nam, hai năm gần đây, nhiều công ty phần mềm bắt đầu chú ý tới phương pháp này vì giúp rút ngắn quá trình phát triển một phần mềm, nhanh có sản phẩm đưa ra thị trường, tối ưu hóa đầu tư. Khái niệm phát triển phần mềm linh hoạt (agile software development - gọi tắt là agile) là một nhóm các phương pháp và phương pháp luận phát triển phần mềm dựa trên 12 TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN các nguyên tắc, theo đó nhu cầu và giải pháp thông qua sự hợp tác giữa các nhóm với nhau. Theo quan niệm truyền thống: một dự án phần mềm được coi là thành công khi sản phẩm được giao đúng hạn, trong ngân sách cho phép và làm đúng yêu cầu của khách hàng. Tuy nhiên trên thực tế nhiều dự án thỏa mãn tất cả các tiêu chí này nhưng rút cuộc vẫn bị coi là thất bại bởi phần mềm làm ra không được người dùng ưa thích hoặc không mang lại nhiều lợi ích cho các cá nhân, tổ chức sử dụng chúng. Phương pháp Agile là phương pháp quản trị dự án linh hoạt, giúp một dự án ngoài việc đạt các yếu tố truyền thống nói trên còn thỏa mãn ba tiêu chí: Thành công ở mức cá nhân, thành công về mặt kĩ thuật và thành công ở mức công ty. Triết lí Agile gồm 4 điểm:  Cá nhân và các tương tác quan trọng hơn quy trình và công cụ.  Tập trung làm cho phần mềm chạy được thay vì viết tài liệu.  Cộng tác trực tiếp với khách hàng thay vì dựa trên hợp đồng.  Phản ứng với các thay đổi thay vì tuân theo một kế hoạch định sẵn. Dự án phát triển phần mềm tiêu biểu trên thế giới theo phương pháp Agile là Chrome với khả năng cập nhật phiên bản mới liên tục. Trước năm 2011, Agile ở Việt Nam chưa được quan tâm nhiều. Các công ty khó tìm kiếm các chuyên gia am hiểu Agile để phát triển các sản phẩm của riêng họ hoặc đáp ứng yêu cầu của khách hàng về mặt phương pháp luận. Hiện nay, càng nhiều doanh nghiệp Việt Nam có xu hướng phát triển phần mềm theo phương pháp này. 2.3 Quản lý dự án theo phương pháp Agile Lãnh đạo và quản lý là hai hệ thống hành động đặc biệt và bổ xung cho nhau. Mỗi hoạt động có chức năng và đặc trưng riêng. Cả hai đều cần thiết cho sự thành công trong môi trường kinh doanh ngày nay. Như đã nêu trong chương 1 “Định nghĩa quản lý dự án Agile”, ngoài Scum, phương pháp Agile không xác định rõ vai trò của quản lý dự án. Có lẽ sự thiếu rõ ràng phát sinh từ thực tế không có thỏa thuận chung (phổ biến) trong ngành công nghiệp như những gì ý nghĩa của tiêu đề “Quản lý dự án”. Tôi đã thấy nó được sử dụng khác nhau bao gồm cả hai và loại trừ chức năng cũng như kiến trúc kỹ thuật, quá trình phát triển quản lý, quản lý nhân sự, quản lý dự án, quản lý thay đổi, đánh giá hiệu quả, theo dõi dự án, kế toán và ngân sách. Mặc dù sự mâu thuẫn này nó đã được kinh nghiệm của tôi mà quản lý dự án được định nghĩa là những cá nhân chịu trách nhiệm xây dựng và nhóm 13 TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN lãnh đạo chịu trách nhiệm cho thành công hay thất bại của họ- nó đóng vai trò quan trọng trong việc cung cấp giá trị kinh doanh. Chương này giới thiệu vai trò như vậy của một cá nhân – người quản lý Agile – người chịu trách nhiệm cho việc cung cấp giá trị kinh doanh. Các dự án sử dụng phương pháp phát triển phần mềm Agile. Nó cũng có vai trò yêu cầu và các kỹ năng và giá trị cơ bản. 2.4 Vai trò của người quản lý Agile Vai trò của người quản lý Agile là để lãnh đạo việc cung cấp các giá trị kinh doanh dự án Agile bằng cách thiết lập các nguyên tắc và thực hành APM (Agile Project Management) và các cá nhân thể hiện giá trị APM (được mô tả sau trong chương này). Bảng 2-4 cho thấy trách nhiệm khác nhau cần thiết để thực hiện vai trò này có liên quan đến các nguyên tắc và thực hành APM. Bảng 2-4. Vai trò và trách nhiệm của người quản lý Agile QUẢN LÝ DỰ ÁN AGILE Thực hành APM Lãnh đạo Quản lý Hướng dẫn nguyên tắc 1: Thúc đẩy sự liên kết và hợp tác  Đội hữu cơ Hướng dẫn tầm nhìn Thúc đẩy sự khéo léo của phần  Xác định các nhóm dự án mềm.  Thiết kế cấu trúc hình thức ba chiều  Bồi dưỡng đội ngũ cộng tác  Nhóm người làm việc có tính kỷ luật  Hình thức là hướng dẫn hợp tác  Triển khai chính thức  Các nhóm làm việc  Phát triển tầm nhìn của đội  Khám phá kết quả kinh doanh  Giới hạn đội  Phân chia phạm vi dễ dàng  Hình dung một tương lai tốt  Ước tính mức độ cố gắng(nỗ lực) đẹp  Thiết kế một hộp tầm nhìn Tạo và duy trì các mong đợi  Xây dựng một trạng thái thang máy  tự giác  Đề xuất một doanh nghiệp đáp ứng công nghệ. được chia sẻ. Hướng dẫn nguyên tắc 2: Khuyến khích sự xuất hiện và tự tổ chức Quy luật đơn giản  Tranh thủ đội ngũ cho sự thay đổi  Tập trung vào kinh doanh  Đánh giá thực trạng  Điều chỉnh các phương pháp  Xây dựng một bản kế hoạch/các chức 14 TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN năng còn tồn đọng.  Xây dựng kế hoạch lặp lặp lại/ những việc còn tồn đọng.  Tạo điều kiện thuận lợi cho phần mềm phát triển, mã lệnh, kiểm thử, và triển khai.  Tích cực thực hiện cuộc họp  Tiến hành chấp nhân thử nghiệm.  Quản lý phát hành phần mềm  Cái chung giữa các thành viên trong hàng ngày.  Thông tin mở Khuyến khích thông tin phản nhóm.  hồi trên trang web.  Xây dựng niềm tin  Ghép nối các phần lại với nhau  Liên kết ngôn ngữ với thành  Khuyến khích sử dụng các thông tin viên.  Phù hợp với tình hình phong cách của bạn.  tản nhiệt  Sơ đồ dòng giá trị của dự án  Kiểm soát phân cấp.  Thiết lập một nhiệm vụ kéo quản lý Hỗ trợ việc di chuyển của lãnh đạo. Ánh sáng cảm ứng Đàm phán với khách hàng đại diện  Tìm hiểu để đi với dòng chảy  Duy trì chất lượng làm việc hệ thống.  Quản lý các dòng chảy  Sử dụng hành động chạy nước rút. cuộc sống  Xây dựng trên thế mạnh của cá nhân  Quản lý các cam kết thông qua tương tác cá nhân. Hướng dẫn nguyên tắc 3: Việc nghiên cứu (học tập) và thích ứng (thiết lập)  Trau dồi một sự hiện diện  được thể hiện Thiết lập lãnh đạo  Thực hành việc học đã được Nhận cộng đồng bằng thông tin phản hồi hàng ngày.  thể hiện. Giám sát và thích ứng các quy tắc đơn giản.  Giám sát các thực hành APM  Thường xuyên tiến hành phản ánh về dự án 15 TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN  Thực hiện kịch bản lập kế hoạch Trách nhiệm của người quản lý Agile được thể hiện trong bảng 2-4: được chia làm hai loại trách nhiệm lãnh đạo và trách nhiệm quản lý. Tại sao lại có sự khác biệt này? Mặc dù lãnh đạo và quản lý đôi khi được sử dụng để thay thế cho nhau, họ tham khảo khác nhau như bên mô tả. Người lãnh đạo hay quản lý họ mất gì? Lãnh đạo là vẽ hoặc hướng dẫn người khác bằng ảnh hưởng của họ. Mục đích chính của lãnh đạo là đối phó với sự thay đổi. Các nhà lãnh đạo có ảnh hưởng đến hành vi bằng nhiều phong cách khác tùy thuộc vào các tính riêng của họ. Lãnh đạo tốt mang lại những điều tốt nhất với mọi người bằng cách đối xử với họ như những cá nhân đầy đủ, sau đó thay vì chỉ đơn thuần là nhân viên , mặt khác , quản lý đề cập đến chính phủ hoặc quản lý các công việc của dự án. Mục đích chính của quản lý là đối phó với sự phức tạp. Theo dõi tiến độ, báo cáo tình trạng, tiến hành các cuộc họp, duy trì ngân sách, thiết lập mục tiêu, và cung cấp đánh giá hiệu suất là ví dụ về các nhiệm vụ được định hướng của quản lý. Quản lý tốt nhấn mạnh các tính hợp lý và kiểm soát trong việc đưa kỹ thuật và trật tự phức tạp vốn có trong kinh doanh môi trường toàn cầu hiện nay. Mặc dù quản lý và lãnh đạo là khác nhau, chúng bổ xung một cách khác nhau: Lãnh đạo cho phép người quản lý Agile có ảnh hưởng đến mọi người về chỉ đạo hành vi của họ đến những kết quả mong muốn và quản lý cho phép mình tổ chức dự án và quản lý sự phức tạp của nó. Hình 6 minh họa sự bổ xung cân bằng này. Kỹ năng quản lý và lãnh đạo cả hai đều quan trọng đối với người quản lý Agile để tu luyện. Nếu không có quản lý, lãnh đạo mất một thành viên quan trọng. Có lãnh đạo mà không có quản lý dẫn đến đội của họ sẽ thiếu sự phối hợp thích hợp như thủ tục báo cáo không đầy đủ, và lập kế hoạch không đầy đủ. Có quản lý mà không có lãnh đạo sẽ dẫn đến mất mát về tâm hồn của đội, quản lý không thể hình thành rõ rệt đội của họ, giao tiếp hiệu quả với họ, và kết nối đủ với cá nhân ở mức độ khuyến khích họ. 16 TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN Hình 6. Lãnh đạo và quản lý (trích từ Bellinger 2004) Cùng với nhau, các yêu cầu được kết hợp với vai trò lãnh đạo và quản lý có vẻ cực kỳ khó khăn. May mắn thay mặc dù vai trò của người quản lý là quan trọng, những không có nghĩa họ là lãnh đạo duy nhất của dự án. 2.5 Chia sẻ trách nhiệm quản lý Để phù hợp với các đặc tính bình đẳng của phương pháp Agile, trách nhiệm của cả lãnh đạo và quản lý được chia sẻ giữa người quản lý Agile, nhân viên kỹ thuật, khách hàng và tất cả các thành viên khác trong đội dự án. Điều này chia sẻ trách nhiệm quản lý dịch để được chia sẻ trách nhiệm cho việc thiết lập nguyên tắc APM và thực hành, minh họa bảng 2-4 Bảng 2-5. Trách nhiệm quản lý được chia sẻ Nguyên tắc APM Thực hành APM  Tổ chức các đội Trách nhiệm  Thúc đẩy sự liên kết và hợp tác chính  Hướng dẫn các  phiên bản  Người quản lý Agile, huấn luận viên kỹ thuật, khách hàng, đội. Các quy luật đơn  giản Khuyến khích sự xuất hiện và tự tổ chức Người quản lý Agile chịu trách nhiệm Người quản lý Agile, huấn luận viên kỹ thuật, khách hàng, đội.  Thông tin mở  Light Touch  Người quản lý Agile chịu trách nhiệm chính  Người quản lý Agile chịu trách nhiệm chính Việc nghiên cứu học tập và thiết lập  Thiết đạo lập lãnh  Người quản lý Agile chịu trách nhiệm chính Như đã thể hiện trong kiểu chữ in đậm, người quản lý Agile có trách nhiệm chính về các thực hành: Các tổ chức nhóm, thông tin mở, Light Touch và thiết lập lãnh đạo. Đỗi với các thực hành khác, người lãnh đạo Agile là người có trách nhiệm được xác định và giao tiếp yêu cầu cụ thể cho các thành viên khác tong nhóm và chịu trách nhiệm với họ để thực hiện công việc, vai trò của người quản lý được thảo luận trong phần tiếp theo. 17 TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN 2.6 Vai trò khác của quản lý APM quy định ba vai trò đó cũng là trách nhiệm quản lý và bổ xung hỗ trợ người quản lý Agile. Đó là vai trò cá nhân cho khách hàng, chủ sở hữu sản phẩm và huấn luyện viên kỹ thuật và vai trò tập thể cho mỗi đội. Khách hàng/ chủ sở hữu sản phẩm thường chịu trách nhiệm hướng dẫn kinh doanh trong hình thức định nghĩa kết quả kinh doanh và tính năng định nghĩa và chấp nhận. Người này có thẩm quyền cuối cùng và chịu trách nhiệm cho kế hoạch đã thực hiện hoặc chức năng này còn lại bao gồm: - Chủ sở hữu các chức năng còn lại/ kế hoạch đã thực hiện - Xác định các yêu cầu chức năng cũng như các tính năng - Làm việc với huấn luận viên kỹ thuật và các nhà phát triển các tính năng, nhiệm vụ ưu tiên - Cung cấp làm rõ và cuối cùng nói về các yêu cầu - Chấp nhận tính năng cung cấp vào cuối mỗi lần lặp Các huấn luyện viên kỹ thuật đưa ra các khía cạnh kỹ thuật của sản phẩm hoặc thiết kế sản phẩm và phát triển. Người này có trách nhiệm liên quan chủ yếu đến việc áp dụng các kỹ thuật thực hành, xây dựng kỷ luật về kỹ thuật và tư vấn các nhà phát triển khác bao gồm: - Chỉ đạo thiết kế và phát triển ứng dụng - Thực hành phần mềm thủ công và huấn luyện và cố vấn các nhà phát triển khác. - Chỉ đạo việc thực hiện thực hành kỹ thuật (tức là lập trình cặp, thiết kế đơn giản, tái cấu trúc, kiểm tra- điều khiển phát triển…). - Cung cấp tiếng nói cuỗi cùng về kiến trúc kỹ thuật. - Sở hữu trách nhiệm cuối cùng cho việc phần mã mỗi lần lặp. Tất cả các thành viên trong đội được dự kiến là kỷ luật tự giác và tự hướng đến một mức độ lớn. Họ có trách nhiệm thực hiện các hoạt động của họ với sự giám sát tối thiểu và tự tối đa như: - Mở rộng các kỹ năng của họ, bên ngoài chuyên môn của họ để đảm nhận nhiều vai trò. - Áp dụng kỷ luật tự giác để hoàn thành công việc một cách kịp thời. - Phối hợp với các thành viên khác trong tinh thần đồng đội. - Kéo nhiệm vụ mới từ kế hoạch còn tồn đọng/ kế hoạch lặp lại khi họ hoàn thành nhiệm vụ. - Nâng cao các vấn đề trong lĩnh vực hàng ngày và sự phản ánh của dự án - Duy trì về sự liên tục thông báo tiến độ làm việc của nhóm. 18