Tài liệu Tìm hiểu mô hình phát triển agile

ĐẠI HỌC QUỐC GIA – HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ BÁO CÁO MÔN HỌC: QUẢN LÝ DỰ ÁN PHẦN MỀM ĐỀ TÀI: TÌM HIỂU MÔ HÌNH PHÁT TRIỂN AGILE Giảng viên: TS. Trương Anh Hoàng - TS. Phạm Ngọc Hùng Khóa: K18 CNPM - Nhóm 1 Học viên: Phạm Minh Tuấn Phạm Hữu Bằng Nguyễn Thúy Hồng Trần Thị Hiên Phạm Thị My Mục lục I. Giới thiệu................................................................................................................5 1. Đặt vấn đề...........................................................................................................5 2. Giá trị khách hàng...............................................................................................6 II. Phương pháp quản lý dự án..................................................................................6 1. Tiếp cận truyền thống.........................................................................................7 2. PRINCE2............................................................................................................8 3. CCPM.................................................................................................................9 4. Quản lý dự án linh hoạt (Agile)..........................................................................9 III. Cách tiếp cận theo phương pháp Agile...............................................................9 1. Bản tuyên ngôn cho phương pháp phát triển phần mềm linh hoạt Agile...........9 a. Lịch sử ra đời của tuyên ngôn..........................................................................9 b. 12 nguyên tắc của mô hình Agile....................................................................9 2. Cơ sở phương pháp Agile.................................................................................10 3. Quản lý dự án linh hoạt....................................................................................12 4. Quy tắc APM....................................................................................................13 IV. Đánh giá............................................................................................................23 a. Giới thiệu về mô hình phát triển Scrum.........................................................23 b. So sánh mô hình phát triển Agile và một số mô hình phát triển kinh điển. . .25 V. Kết luận...............................................................................................................26 Tài liệu tham khảo...................................................................................................28 2 Danh mục hình vẽ Hình 1 - Phương pháp quản lý dự án Agile...............................................................5 Hình 2 - Mô hình phát triển thác nước......................................................................8 Hình 3 - Dự án như những hệ thống thích nghi phức hợp.......................................13 Hình 4 - Ba tiêu chí đánh giá thành công của một dự án phần mềm.......................14 Hình 5 - Sơ đồ tổ chức nhóm làm việc....................................................................16 Hình 6 - Tầm nhìn người lãnh đạo..........................................................................18 Hình 7 - Các quy tắc đơn giản.................................................................................20 Hình 8 - Thông tin mở trong phát triển dự án.........................................................21 Hình 9 - Quản lý theo hình thức nới lỏng................................................................22 Hình 10 - Mô hình lãnh đạo trong quản lý dự án....................................................23 Hình 11 - Quá trình thực hiện mô hình phát triển Scrum........................................24 Danh mục bảng Bảng 1- So sánh ưu, nhược điểm của các mô hình phát triển phần mềm...............26 3 TÌM HIỂU MÔ HÌNH PHÁT TRIỂN AGILE Tóm tắt– “Phương pháp quản lý dự án Agile là một trong những phương pháp quản lý dự án đang ngày một trở nên phổ biến và được nhiều người quan tâm. Thay vì cách tiếp cận của nhiều phương pháp quản lý dự án khác, Agile là phương pháp tiếp cận hướng tới giá trị khách hàng, bao gồm chuyển giao một sản phẩm đúng yêu cầu khách hàng với một mức giá “hợp lý” tại thời điểm đúng như khách hàng mong muốn.” Từ khóa – Agile project management, project management methodology. 4 I. Giới thiệu 1. Đặt vấn đề Quản lý dự án là một vấn đề khó và quản lý dự án phần mềm cũng luôn phải đối mặt với những vấn đề chung và vấn đề đặc thù trong phạm trù của các dự án phần mềm. Trong môi trường phát triển và biến động như hiện nay, các dự án phần mềm luôn phải trả các chi phí lớn trong những vấn đề liên quan đến quản trị dự án.Nếu trước kia nói đến dự án phần mềm thì người ta thường nghĩ đến quy trình phức tạp và nhiều giai đoạn trải qua khoảng thời gian khá dài từ vài tháng đến vài năm để hoàn thành dự án. Việc này dẫn đến chi phí phát triển các phần mềm bị đội lên rất cao và thiếu tính cạnh tranh nên các phương pháp cũ dần dần chỉ còn được áp dụng cho các dự án cụ thể, yêu cầu rõ ràng và dễ bảo trì. Hình 1 - Phương pháp quản lý dự án Agile Ngày nay, cùng với việc yêu cầu phát triển sản phẩm ngày càng chất lượng nhưng cũng cần có tính cạnh tranh về thời gian và chi phí, các phương pháp mới ra đời phải đáp ứng được tiêu chí là: nhanh chóng bàn giao được sản phẩm, tiếp xúc thường xuyên để ghi nhận ý kiến khách hàng và quan trọng nhất là tạo ra sản phẩm có tính cạnh tranh cao. Một trong các phương pháp quản lý dự án được đưa ra đó cần kể đến phương pháp Agile. Mô hình phát triển phần mềm linh hoạt Agile là một phương pháp Agile chủ trương hướng tới một cách tiếp cận nhằm mục đích tránh việc lãng phí thời gian, chi phí trong phát triển phần mềm và tăng cường sự đáp ứng với vấn đề thay đổi trong quá trình phát triển phần mềm.Nó bao gồm nhiều rất nhiều phương pháp luận, quy trình và thực nghiệm để hỗ trợ cho việc phát triển phần mềm trở nên 5 nhanh chóng và dễ dàng. Mục tiêu quan trọng nhất mà phương pháp Agile hướng đến là “giá trị khách hàng”. Khi mà phương pháp Agile đã định ra rõ ràng khái niệm “giá trị khách hàng” là gì thì tất cả các phương pháp luận hay quy trình bao hàm trong nó sẽ được xây dựng để xoay quanh làm sao để đạt được nó. Báo cáo được chia làm 5 phần:  Phần được tiếp theo đây bằng cách làm rõ khái niệm “giá trị khách hàng” và sự linh hoạt trong quản lý dự án mà phương pháp Agile hướng đến.  PhầnII trình bày tổng quan về triết lý và phương pháp luận của một số phương pháp quản lý dự án khác nhau.  Phần III sẽ đi sâu hơn vào hướng tiếp cận cũng như chi tiết của phương pháp Agile.  Đưa ra ví dụ về mô hình phát triển Scrum và kết thúc đánh giá phương pháp Agile so với một số phương pháp khác trong Phần IV.  Kết luận của nhóm trong Phần V. 2. Giá trị khách hàng Giá trị khách hàng luôn là mục tiêu quan trọng nhất xuyên suốt phương pháp luận và cách tiếp cận theo phương pháp quản lý Agile. Đối với mọi mô hình quản lý dự án theo phương pháp Agile, giá trị khách hàng có thể hiểu là khách hàng luôn muốn nhận được một sản phẩm như mong muốn với một giá cả hợp lý trong một khoảng thời gian như mong đợi.Đối với phương pháp Agile, sản phầm như khách hàng mong muốn là sản phẩm bao gồm một cách chính xác các thuộc tính như khách hàng đưa ra.Giá cả hợp lý có thể được hiểu là một giá cả mà khách hàng nghĩ rằng nó là một giá cả xứng đáng với sản phẩm được bàn giao.Cuối cùng, khoảng thời gian cho phép cũng chính là điều khách hàng mong đợi. Đó là khái niệm rõ ràng về “giá trị khách hàng” đối với phương pháp Agile. II. Phương pháp quản lý dự án Quản lý dự án là một khái niệm liên quan đến việc lập kế hoạch, tổ chức, thúc đẩy và kiểm soát nguồn lực nhằm đạt được một mục tiêu cụ thể nào đó. Có hai thách thức quan trọng nhất đối với quản lý dự án.Thách thức đầu tiên chính là làm sao để đạt được tất cả mục tiêu của dự án với những ràng buộc của môi trường và hoàn cảnh. Thách thức này bao gồm phạm vi của dự án, thời gian, chất lượng và 6 kinh phí. Thách thức thứ hai chính là làm sao để có thể tối ưu những cung cấp đầu vào (có thể là giảm thiểu chi phí) và kết hợp chúng với những mục tiêu được định sẵn. Có rất nhiều cách tiếp cận đối với việc quản lý các hoạt động của dự án như lặp, gia tăng, chia pha... Trong phần này, nhóm chúng tôi sẽ điểm qua một số cách tiếp cận hay được sử dụng trong thực tế. 1. Tiếp cận truyền thống Cách tiếp cận theo dạng chia pha truyền thống hay gặp nhất (xuất hiện trong rất nhiều các biến thể khác) chỉ ra một chuỗi các bước thực hiện dự án cần được hoàn thành để hoàn thành dự án. Các bước đó có thể được liệt kê ra dưới đây: - Bước 1: Khởi đầu Bước 2: Lập kế hoạch và thiết kế Bước 3: Thực thi và xây dựng / triển khai Bước 4: Giám sát và điều khiển hệ thống Bước 5: Kết thúc dự án Tuy nhiên, trong thực tế, mỗi dự án có thể có những tiến hóa khác nhau. Đối với các dự án không thành công thì có thể sẽ được hủy trước cả bước kết thúc dự án. Nhiều dự án khác lại có thể thực hiện Bước 2, 3, 4 lặp đi lặp lại đến khi dự án thành công (đạt được những mục tiêu đã đặt ra của dự án).Phụ thuộc vào những lĩnh vực khác nhau, cách tiếp cận này có thể có những tên gọi cũng như nội dung tương ứng thích hợp khác nhau. Đối với các dự án phần mềm, cách tiếp cận này thường được biết đến với tên gọi mô hình thác nước (waterfall). 7 Hình 2 - Mô hình phát triển thác nước Tuy nhiên, đã có nhiều nghiên cứu cũng như thống kê gần đây đã chỉ ra mô hình thác nước thường chỉ thành công đối với những dự án cỡ nhỏ, hoặc những dự án được đề xuất với một hiểu biết sâu sắc từ phía khách hàng cũng như đơn vị triển khai. Còn đối với những dự án có kích thước lớn, mô hình thác nước thường thất bại hoặc đem lại chi phí quản lý dự án rất lớn. Nhược điểm lớn nhất của mô hình thác nước chính là không cho phép có sự thay đổi trong quá trình thực hiện dự án, những thay đổi càng xuất hiện muộn trong vòng đời dự án thì càng phải trả giá lớn về tiền bạc và thời gian. 2. PRINCE2 PRINCE2 là cách tiếp cận có cấu trúc được giới thiệu vào năm 1996.PRINCE2 là sự kết hợp giữa phương pháp PROMPT và MITP.Ưu điểm của PRINCE2 là cung cấp một bộ khung tiêu chuẩn để quản lý các dự án. PRINCE2 mô tả những quy trình để phối hợp giữa con người và các hoạt động dự án, hay nói cách là là phương pháp để thiết kế và giám sát dự án. Tuy nhiên, mô hình PRINCE2 cũng gặp nhược điểm khi đề cao vai trò của giám sát trong dự án nhằm đạt được các mục tiêu đề ra của dự án. Con người tham gia trong dự án có thể sẽ chịu nhiều áp lực khi dự án được thực hiện. Chính điều này đôi khi làm các dự án sa đà quá nhiều vào vấn đề giám sát, chi phí của dự án sẽ được đưa nhiều vào hoạt động giám sát trong khi giá trị khách hàng mới là điều nên được quan tâm nhiều nhất. 8 3. CCPM Quản lý Chuổi dự án quan trọng (CCPM) là một phương pháp lập kế hoạch và quản lý dự án đặt trọng tâm chính trên các nguồn lực cần thiết để thực hiện nhiệm vụ dự án. Được phát triển bởi Eliyahu M. Goldratt. Một chuỗi mạng dự án quan trọng sẽ có xu hướng giữ nguồn tài nguyên quá tải, nhưng sẽ đòi hỏi họ phải được linh hoạt trong thời gian bắt đầu của họ và để nhanh chóng chuyển đổi giữa các tác vụ và các chuỗi công việc để giữ cho toàn bộ dự án đúng tiến độ. 4. Quản lý dự án linh hoạt (Agile) Quản lý dự án linh hoạt dựa trên cơ sở các nguyên tắc về quản lý tương tác con người. Phương pháp Agile thường được sử dụng nhiều trong môi trường công nghiệp phần mềm, website, công nghệ, sáng tạo hoặc quảng cáo – những môi trường thường có sự thay đổi liên tục, đòi hỏi sự thích ứng liên tục và đạt được những giá trị cho khách hàng tốt nhất có thể. III. Cách tiếp cận theo phương pháp Agile 1. Bản tuyên ngôn cho phương pháp phát triển phần mềm linh hoạt Agile a. Lịch sử ra đời của tuyên ngôn Tháng 2 năm 2001 , 17 nhà phát triển phần mềm đã họp mặt tại khu trượt tuyết Snowbird , Utah và đưa ra Tuyên ngôn Phương pháp phát triển phần mềm linh hoạt (Agile Manifesto). Tuyên ngôn gồm 4 điểm : o Cá nhân và các tương tác quan trọng hơn quy trình và công cụ. o Tập trung làm cho phần mềm chạy được thay vì viết tài liệu. o Cộng tác trực tiếp với khách hàng thay vì dựa trên hợp đồng. o Phản ứng với các thay đổi thay vì tuân theo một kế hoạch định sẵn. b. 12 nguyên tắc của mô hình Agile o Ưu tiên cao nhất của dự án là thỏa mãn khách hàng bằng việc bàn giao sản phẩm sớm và liên tục. o Hoan nghênh các thay đổi từ phía khách hàng, kể cả các thay đổi vào giai đoạn cuối. o Bàn giao sản phẩm theo chu kì từ vài tuần đến vài tháng. Chu kì ngắn tốt hơn chu kì dài. 9 o Các nhân viên hiểu nghiệp vụ và các lập trình viên phải làm việc cùng nhau o o o o hàng ngày. Tổ chức dự án xoay quanh những cá nhân tích cực. Hỗ trợ và tin tưởng họ. Phương pháp giao tiếp tốt nhất trong đội dự án là gặp mặt trực tiếp. Các chức năng đã họat động là thước đo chính cho tiến độ dự án. Khuyến khích phát triển bền vững: Lập trình viên, người dùng, nhà quản lí…phải có khả năng tham gia dự án một cách liên tục. o Liên tục cải tiến chất lượng thiết kế và mã nguồn. o Tính đơn giản giữ vai trò cốt yếu. Làm càng ít càng tốt. o Những yêu cầu và thiết kế tốt nhất được nảy nở từ những nhóm làm việc tự chủ. o Sau những khoảng thời gian nhất định, đội dự án xem xét cách thức cải tiến hiệu quả công việc. 2. Cơ sở phương pháp Agile Để hiểu hơn về phương pháp Agile, dưới đây là một số kỹ thuật cơ bản được sử dụng xuyên suốt trong phương pháp luận cũng như quy trình của Agile.  Phát hành các phiên bản nhỏ của chương trình (hoặc hệ thống). Dự án được chia làm nhiều thành phần nhỏ với mục đích dễ quản lý về độ phức tạp cũng như làm sao để nhận được phản hồi từ khách hàng và người dùng cuối nhanh nhất có thể. Các phiên bản thường được bàn giao trong khoảng 1 đến 3 tháng.  Đây là phương pháp phát triển lặp và tăng dần. Các dự án được quản lý theo phương pháp Agile được chia làm nhiều vòng lặp nhỏ. Mỗi vòng lặp đều bao gồm đầy đủ các bước như lập kế hoạch, đặc tả yêu cầu, thiết kế, viết mã nguồn và kiểm thử. Như vậy, phương pháp Agile sẽ gồm nhiều vòng lặp, trong đó mỗi vòng lặp đã có đầy đủ các pha như mô hình “thác nước” (waterfall). Tùy theo đặc thù của các dự án phần mềm và theo yêu cầu của khách hàng, mỗi vòng lặp có thể tương ứng với một hoặc một vài chức năng mới hoặc chức năng được cải tiến.  Tùy theo tính chất của dự án, khoảng thời gian của một vòng lặp trong các dự án sử dụng phương pháp Agile có thể là từ 2 tuần đến 1 tháng. Người 10 quản trị dự án có thể cân nhắc dựa trên nhiều yếu tố khác nhau như thời gian lặp càng ngắn thì số phiên bản của chương trình (hoặc hệ thống) sẽ càng nhiều và đồng thời sẽ có càng nhiều phản hồi (góp ý) từ khách hàng và người dùng cuối. Nhưng ngược lại thời gian lặp càng ngắn thì áp lực lên tất cả các thành viên dự án cũng như việc lập kế hoạch tổng thể dự án sẽ phức tạp hơn. Chính vì thế, đối với phương pháp Agile, việc cân đối thời gian lặp là một trong những nhiệm vụ quan trọng của người quan trị dự án.  Khác với nhiều mô hình khác như mô hình thác nước, phương pháp Agile đòi hỏi sự tập trung cao độ của tất cả thành viên dự án, các bên liên quan đến dự án, khách hàng và đôi khi là cả người dùng cuối. Bởi mỗi vòng lặp có thể chỉ diễn ra trong vỏn vẹn 2 tuần, trong 2 tuần đó sẽ luôn đòi hỏi sự có mặt của tất cả các cá nhân liên quan. Việc kết nối qua thư điện tử, điện thoại, gặp mặt, tổ chức họp sẽ liên tục được thúc đẩy để tăng tính tương tác với tất cả thành viên liên quan đến dự án.  Thích hợp với những dự án phần mềm mà bản thân khách hàng đôi khi cũng chưa hoàn toàn hiểu về ý tưởng và mong muốn. Sản phẩm của họ sẽ được tiến hóa và ngày một hoàn thiện hơn thông qua từng vòng lặp của dự án. Theo thời gian, ý tưởng ban đầu của khách hàng sẽ ngày một rõ ràng và gần với mong muốn hơn. Như vậy, phương pháp Agile có thể giúp tối ưu sự thỏa mãn và hài lòng của khách hàng (bởi mỗi phiên bản tương ứng với mỗi vòng lặp sẽ chỉ được thực hiện khi nhận được sự đồng ý của khách hàng) với những chi phí ít tốn kém và sự thực thi đơn giản hiệu quả.  Việc lựa chọn tính năng nào để phát triển là hoàn toàn tùy theo mong muốn của khách hàng. Những tính năng được yêu cầu và được xếp loại mức độ ưu từ cao xuống thấp. Việc xếp loại mức độ ưu tiên được thực hiện bởi sự cộng tác với các nhà phát triển và khách hàng dựa trên lý thuyết trò chơi (mục đích là tối đa hóa lợi ích của cả 2 bên và tối thiểu hóa rủi ro của đối tác). Các nhà phát triển dự tính khả năng cố gắng của họ để hoàn thành chức năng cần thiết trong khi khách hàng quyết định độ cần thiết trong nghiệp vụ của chức năng. 11  Do đó, mô hình Agile yêu cầu tính hợp tác trong nhóm làm việc rất cao và rất cần sự đóng góp, chia sẻ giữa các thành viên vì mục đích hoàn thành dự án. Mô hình làm việc theo cặp được áp dụng theo nguyên lý các nhà phát triển và cả các người khác thực hiện công việc theo nhóm 2 người để tăng sự cộng tác cũng như chia sẻ kiến thức và nâng cao chất lượng sản phẩm.  Phát triển phần mềm dựa trên phát triển hướng kiểm thử (test-driven development). Các nhà phát triển viết các kịch bản kiểm thử trước khi họ viết mã nguồn và thay đổi, tiến hóa mã nguồn để sao cho mã nguồn thỏa mãn được các test case. Thay vì thẩm định tính hợp lệ của mã nguồn thì thực hiện các kịch bản kiểm thử sẽ nâng cao chất lượng và độ tin cậy đối với sản phẩm. Quá trình này gồm các bước sau: o Viết một test case đơn giản nhất trước. o Cài đặt class/method ở mức tối giản nhất để có thể vượt qua test case đó. o Tối ưu hóa mã nguồn. o Bổ sung test case mới và lặp lại quá trình cho đến khi tất cả các yêu cầu được thỏa mãn. 3. Quản lý dự án linh hoạt Quản lí dự án linh hoạt (Agile Project Management – APM) là công việc tiếp thêm năng lượng, nâng cao vị thế và cho phép các đội dự án bằng cách nhanh nhất và đáng tin cậy nhất để chuyển giao những sản phẩm thương mại thông qua việc tương tác khách hàng và liên tục học hỏi và thích ứng với những thay đổi về yêu cầu và môi trường của khách hàng. Phương pháp Agile coi các dự án như những hệ thống sống hay còn gọi là những hệ thống thích nghi phức hợp (Complex Adaptive Systems - CAS). Trong đó sẽ bao gồm nhiều tác nhân tự động, tương tác qua lại lẫn nhau theo nhiều cách khác nhau. Sự tương tác của mỗi tác nhân riêng lẻ được giám sát bởi các quy tắc đơn giản và nội tại và đặc tả bởi các phản hồi cố định. Trật tực phức hợp phát sinh từ chính nội tại của hệ thống chứ không phải do sự áp đặt từ phía ngoài. Những hệ thống thích nghi phức hợp này có khả năng thích nghi đối với những hoàn cảnh khác nhau và với những môi trường khác nhau. 12 Hình 3 - Dự án như những hệ thống thích nghi phức hợp Thực hiện dự án theo phương pháp Agile vai trò của người quản lí dự án cũng thay đổi, thay vì bảo các thành viên trong đội làm gì thì họ phải tổ chức hướng dẫn đội đáp ứng với những thay đổi. Họ có trách nhiệm cá nhân hơn với các thành viên khác trong đội, có vai trò giám sát. Người quản lí là người chủ sản phẩm là người làm việc chặt chẽ với khách hàng để quyết định cái gì sẽ được dựng và theo trật tự nào. Người chủ sản phẩm xác định tính năng của sản phẩm, chọn khi nào phần mềm sẽ được đưa ra và điều chỉnh các tính năng và ưu tiên khi cần. 4. Quy tắc APM Cũng như mọi phương pháp khác, APM được xây dựng trên hai quan điểm quan trọng: ở mức cơ bản thì APM cần đơn giản nhưng kiên định về mặt nguyên tắc và giá trị, ở mức ứng dụng thì APM đưa ra một cách thực hiện linh hoạt trong thực tiễn, có khả năng thích nghi tốt với sự thay đổi của môi trường và trong mọi trường hợp. Với những quan điểm đó, APM dựa trên cơ sở các khái niệm về CAS được nghiên cứu và đưa ra những nguyên tắc cơ bản cốt lõi như dưới đây: - Thúc đẩy sự liên kết và hợp tác. Con người được coi là tác nhân chính ảnh hưởng đến giá trị, sự thay đổi, học tập và thích nghi. Được chia sẻ tầm nhìn giúp mọi người được liên kết và hành động vì mục tiêu chung. Khi mọi người được liên kết chặt chẽ, sự cạnh tranh không lành mạnh sẽ được giảm thiểu và sự hợp tác làm việc với nhau để cùng có lợi sẽ được đẩy mạnh. - Khuyến khích sự xuất hiện và tự tổ chức. Quy trình và thực hành được làm tối thiểu đơn giản. Con người tự tổ chức cung cấp giá trị kinh doanh lớn 13 nhất. Mô hình phức tạp bao gồm cả hành vi tự tổ chức và cấu trúc tối ưu, xuất hiện từ tương tác gần giữa nhiều người theo các quy tắc đơn giản. - Học tập và thích ứng. Thông tin phản hồi được sử dụng liên tục cho học tập, thay đổi thích ứng và cải tiến. 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. 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. Ngoài các yếu tố truyền thống nói trên, một dự án phần mềm chỉ được coi là thành công khi 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. Thành công ở mức cá nhân giúp kích thích các thành viên trong nhóm. Thành công về kĩ thuật đảm bảo khả năng bảo trì và tiến hóa của sản phẩm. Vị trí của nhóm sẽ được bảo đảm nhờ các 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 được ba thành công này. Hình 4 - Ba tiêu chí đánh giá thành công của một dự án phần mềm Thành công ở mức công ty: Agile nhằm đến việc tạo ra giá trị cho công ty trong khi làm giảm chi phí. Đồng thời, Agile giúp sớm xác định các kì vọng đối với sản phẩm đang được phát triển. Nhờ đó, những dự án không mang lại giá trị như mong đợi sẽ được phát hiện sớm, tiết kiệm chi phí cho công ty. Theo phương pháp Agile, các chuyên gia về nghiệp vụ (business) sẽ làm việc trực tiếp cùng với 14 đội dự án. Các chức năng quan trọng nhất của sản phẩm được tập trung phát triển trước và được đưa vào vận hành sớm nhất có thể. Các phiên bản mới với các tính năng mới sẽ lần lượt được đưa thêm vào. Ngoài ra, Agile giúp tăng cường khả năng giao tiếp giữa các thành viên trong nhóm. Chất lượng mã nguồn được cải tiến liên tục. Tiến độ dự án cũng được xem xét và đánh giá một cách thường xuyên. Thành công về mặt kĩ thuật: Trong Extreme Programming, một phương pháp tuân theo triết lí Agile, các lập trình viên làm việc cùng nhau. Nhờ vậy, các chi tiết quan trọng sẽ không bị bỏ sót, mỗi đoạn code sẽ được kiểm tra bởi ít nhất hai người. Các lập trình viên liên tục tích hợp những đoạn code vừa viết vào hệ thống, cho phép một phiên bản mới của phần mềm được phát hành bất cứ khi nào nó góp thêm một giá trị đáng kể. Hơn nữa, toàn bộ đội dự án tập trung hoàn thành một chức năng trước khi chuyển sang chức năng tiếp theo. Bởi vậy, tiến độ công việc được kiểm soát tốt hơn và dự án có thể dễ dàng “chuyển hướng” khi có những thay đổi từ phía khách hàng. Ngoài ra, Extreme Programming cũng đề xuất những quy tắc giúp tạo ra các thiết kế và các đọan mã tốt. Chẳng hạn, quy tắc “phát triển dựa trên kiểm thử” (test-driven development) trợ giúp lập trình viên viết các chương trình thực hiện đúng chức năng mong muốn. Thành công về mặt cá nhân: Mỗi thành viên trong dự án Agile, dù ở bất kì cương vị nào, cũng đều cảm nhận được một cách rõ ràng sự thành công của bản thân. Các lập trình viên nhận thấy trình độ kĩ thuật cũng như tầm ảnh hưởng của mình đối với dự án được nâng cao, chẳng hạn trong việc ước lượng và lập kế hoạch. Quyền tự chủ của đội dự án cũng được 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 các công việc lặp lại một cách nhàm chán. Nhà quản lí dự án hài lòng vì kiểm soát được tiến độ công việc, dự án thực hiện đúng các cam kết và làm thỏa mãn khách hàng. Khách hàng, người sử dụng, các chuyên gia nghiệp vụ cảm thấy hài lòng vì điều kiển được hướng đi của dự án và các ý kiến được lắng nghe.Các nhà lãnh đạo cao cấp sẽ cảm thấy hài lòng vì dự án mang lại lợi nhuận lớn cho công ty. Để đạt được ba thành công như vậy, chúng ta phải kể đến tập các quy tắc trong phương pháp quản lý dự án phần mềm Agile. Kiểu quản lý dự án mềm dẻo, linh hoạt Agile đã đưa ra một tập các quy tắc và các nhà quản lý dự án phải luôn luôn tuân thủ các quy tắc đồng thời phải lựa chọn, sửa đổi cách thức thực hiện sao cho phù hợp với vị trí cũng như quy mô của dự án. Các quy tắc đó là: 15 1. Các quy tắc tổ chức nhóm APM (The APM practices Organic Teams). 2. Tầm nhìn người lãnh đạo (Guiding Vision). 3. Các quy tắc đơn giản (Simple Rules). 4. Thông tin mở (Open Information). 5. Kiểm soát nới lỏng (Light Touch). 6. Sự lãnh đạo thích nghi (Adaptive Leadership). Quy tắc 1: Tổ chức nhóm (Organic Teams): Quy tắc này cho phép kết nối và phối hợp thông qua mối quan hệ chặt chẽ trên các nhóm nhỏ, linh hoạt. Nhóm là một nhóm người làm việc chung với nhau nhằm mục đích điều hành hay quản lý một công việc nào đó. Nhóm hoạt động có mục đích, có phối hợp, có kế hoạch. Hình 5 - Sơ đồ tổ chức nhóm làm việc Sự tự tổ chức và thứ tự sắp xếp một phần là do kiểu tương tác đa dạng hoặc sự phối hợp giữa thành viên trong dự án. Sự tự tổ chức dự án trong các nhóm nhỏ được hiểu ngầm định là hình thức tương tác thấp và cũng có thể là nguyên nhân gây ra các kiểu tương tác đa dạng của thành viên trong dự án. Thông thường các nhóm được xây dựng theo một cấu trúc đặc biệt phụ thuộc vào nhiều yếu tố như quy mô dự án, tính chất công việc của từng nhóm, nguồn nhân lực, chi phí, thời gian…Theo đó, các nhóm này tự thực hiện lấy việc phân công công việc mà không dựa trên các mô tả cứng về chức danh (title) hay làm việc dựa trên một sự phân cấp 16 rõ ràng trong tổ chức. Các nhóm này cộng tác với nhau để ra quyết định, theo dõi tiến độ, giải quyết các vấn đề mà không chờ mệnh lệnh của các cấp quản lý. Họ không làm việc theo cơ chế “mệnh lệnh và kiểm soát” (command and control). Nhóm tự tổ chức có nghĩa là nó đã đủ các kĩ năng (competency) cần thiết cho việc phát triển phần mềm, do vậy nó có thể được trao quyền để tự ra quyết định, tự quản lí và tổ chức lấy công việc của chính mình để đạt được hiệu quả cao nhất. Ví dụ, nhóm phát triển phần mềm bao gồm người phát triển phần mềm và các nhà phân tích kinh doanh được lựa chọn theo chuyên môn của họ (J2EE, các dịch vụ tài chính,…). Nếu cần nhiều công sức thì cần thêm nhiều nhân lực. Đây là cách quản lý dự án máy móc, chắc chắn với cách quản lý này thì sẽ dẫn đến tình trạng dư thừa một số bộ phận. Mỗi bộ phận được thiết kế ra để thực hiện một chức năng riêng, và các bộ phận mở rộng được thêm vào hệ thống để tăng thêm khả năng hoặc để khôi phục các bộ phận đang tồn tại. Với các dự án APM, các nhà quản lý linh hoạt tìm kiếm để đưa ra chức năng dư thừa. Thay vì thêm các bộ phận dự phòng (người phát triển, nhà phân tích kinh doanh…), các thành viên trong nhóm đang tồn tại sẽ đảm nhận thêm các chức năng mở rộng. Như vậy, những thành viên này không chỉ có kỹ năng trong lĩnh vực chuyên môn của họ mà còn giỏi trong các lĩnh vực khác. Agile còn cho phép các thành viên được quay vòng hoặc cho phép nhóm phối hợp tổ chức nhóm thành phần để thích ứng với sự thay đổi điều kiện bên ngoài. Khi dự án yêu cầu kích thước nhóm lớn, sự tổ chức dự án tập trung vào các nhóm nhỏ, bằng cách tổ chức các nhóm con làm việc đồng thời, đây là chiến lược tốt nhất để đảm bảo cho việc mở rộng quy mô dự án. Quy tắc 2: Tầm nhìn chỉ đạo (Guiding Vision): Tổ chức nhóm liên kết và chỉ đạo với mô hình chia sẻ tinh thần 17 Hình 6 - Tầm nhìn chỉ đạo Các nhà lãnh đạo phải là những người có tầm nhìn xa, những người có khả năng dự báo trước những xu thế lớn, biến tầm nhìn trở thành hiện thực và luôn phát triển các chiến lược và chiến thuật mới. Một tầm nhìn xa sẽ giúp người lãnh đạo vạch trước những chiến lược hoạt động dài hạn, dự đoán trước những biến động có thể xảy ra trong tương lai để chuẩn bị, tìm cách thích nghi và đón đầu cơ hội. Để làm được điều này, họ cần phải có hiểu biết về các xu hướng hay các nghiên cứu và kỹ năng mới nhất. Ngoài ra, người lãnh đạo phải xác định được tương lai, nhiệm vụ và mục tiêu cụ thể của dự án đang cần triển khai. Tóm lại, khả năng lãnh đạo là đỉnh điểm của nghệ thuật và khoa học lãnh đạo, vì nó làm cho những môn nghệ thuật và tất cả công việc khác trở nên hữu dụng. Một trong những tố chất của nó ngoài “tầm nhìn” là “trí thông minh xúc cảm”, đây là một kỹ năng có thể rèn luyện được. Kỹ năng này được hiểu như là khả năng nhận biết, xác định thấu hiểu và quản lý thành công cảm xúc của bản thân và của người khác, người lãnh đạo thấu hiểu các tầng nấc cảm xúc và cách biểu hiện của họ thì mới có khả năng hiểu được cảm xúc của người khác cũng như nhân viên dưới quyền. Kỹ năng này sẽ giúp ích cho việc truyền cảm hứng, thúc đẩy, và định hướng mọi người thực hiện những công việc, những điều mà họ mong muốn. Một người lãnh đạo thực sự phải biết động viên, khuyến khích để nhân viên đạt được mục tiêu của tổ chức bằng chính niềm say mê của mình. Mô hình tinh thần (mental model) của con người chính là cơ chế của sự dự đoán và thích ứng với những thay đổi. Một tầm nhìn phải thỏa mãn được câu hỏi “Chúng ta muốn đạt được gì”. Do vậy, khi tầm nhìn của một dự án được chuyển sang kiểu trình bày mục đích của dự án và truyền đạt tới tất cả các thành viên trong 18 nhóm, thì điều này sẽ giúp cho việc chia sẻ mô hình tinh thần cũng như chi phối lớn đến hành vi của các thành viên trong khi họ thực hiện các nhiệm vụ của dự án. Người lãnh đạo là người truyền cảm hứng cho nhân viên để nhân viên biết như thế nào là tốt nhất và làm thế nào để đẩy nhanh tiến độ dự án. Nếu mọi người hào hứng với ý tưởng của người lãnh đạo thì đó chính là bởi họ đã được người lãnh đạo truyền cảm hứng. Một ví dụ thực tế của quy tắc này đó là, tầm nhìn của Chủ tịch Hồ Chí Minh đã đưa dân tộc Việt Nam chúng ta đi đến thành công trong công cuộc cách mạng giải phóng dân tộc, giải phóng đất nước thoát khỏi cảnh nô lệ lầm than. Để làm được điều này, Bác Hồ kính yêu của chúng ta phải có tầm nhìn xa trông rộng và ngoài ra Người đã thành công trong việc chia sẻ mục tiêu chung của dân tộc tới những trái tim và khối óc của mọi người dân. Một ví dụ khác của quy tắc này là sự lãnh đạo của người chỉ huy trong quân đội Mỹ. Người lính đều biết rằng lãnh đạo của họ không thể lúc nào cũng có mặt khắp nơi. Vì vậy, các nhà lãnh đạo quân đội thiết lập rõ ràng nội dung chỉ đạo để dẫn đường chỉ lối cho người lính giúp họ có thể thực hiện các hành động và các quyết định trong khi mất phương hướng. Chính vì vậy, ngay cả khi nhiệm vụ đặt trên vai của người cấp bậc thấp nhất thì người đó vẫn có thể gánh vác được nhiệm vụ. Thông thường các kỹ thuật quản lý dự án yêu cầu phải tạo ra một kế hoạch chi tiết cho từng đối tượng chuyên môn đối với mục đích của dự án. Không nhất thiết phải đầu tư thời gian và công sức vào lập kế hoạch chi tiết nâng cao vì điều đó sẽ thay đổi theo giả thiết và đầu vào thay đổi, các nhà quản lý năng động duy trì một hướng đi đủ tốt. Điều đó có nghĩa là thay vì bố trí chi tiết kế hoạch dự án với các nhiệm vụ chủ chốt, họ tập trung vào kết quả đầu ra mong muốn, và cho phép kế hoạch và các nhiệm vụ liên quan của họ cần phải đạt được kết quả xuất hiện theo thời gian. Quy tắc 3: Các quy tắc đơn giản (Simple Rules): Thiết lập một tập quy tắc đơn giản, tạo ra các quy tắc xử lý đối với nhóm. 19 Hình 7 - Các quy tắc đơn giản Các phương pháp luận thường đi kèm với một tập đầy đủ các thành phần xử lý, khuôn mẫu, chuyển giao và các quy tắc. Thông thường, các quy tắc thường quá nghiêm khắc đến nỗi mà mọi người không thể tuân theo được tất cả các quy tắc đó. Có một số quy tắc muốn có hiệu lực để mọi người bắt buộc phải tuân thủ thì thường liên quan đến vấn đề tài chính. Đây thực sự là điều phản tác dụng. Đối với các dự án APM, các thành viên trong nhóm tuân theo các quy tắc cơ bản (Simple Rules). Ví dụ về phương pháp luận linh động, các tiêu chuẩn thực tế của XP (Lập trình cực hạn - Extreme programming) là một tập tốt các quy tắc cơ bản cho các dự APM. Tập các quy tắc này được bắt đầu và được sự chấp thuận của tất cả các thành viên trong nhóm, mặc dù nhóm có khả năng để thích nghi với các thực tế mà không đang hoạt động hoặc phát sinh thêm các thực tế mới. Trong suốt dự án, nhà quản lý linh động nhận biết các thực tế mà không tuân theo, cố gắng tìm kiếm nguyên nhân tại sao không tuân theo được để từ đó có biện pháp khắc phục và loại bỏ các rào cản thực tế để thực hiện. Thông tin mở (Open Information): Thông tin được cung cấp và truy cập tự do (không bị ràng buộc). Ở các dự án linh động, thông tin là chất xúc tác cho sự thay đổi và thích ứng. Tương tác giữa con người liên quan đến việc trao đổi thông tin liên tục. Sự phong phú đa dạng của những tương tác giữa con người phụ thuộc phần lớn vào sự cởi mở của thông tin.Đối với một đội ngũ linh động thì thông tin được mở và không bị 20