055.1 Bài 1

Quản lý dự án là một nhiệm vụ cực kỳ phức tạp. Một số tình huống thoạt nhìn có vẻ rất dễ dàng — nhưng để khiến chúng đi đúng hướng thì cần có một bề dày kinh nghiệm cũng như một sự cẩn trọng đúng mực. Người thực hiện việc này chính là quản lý dự án.

Trách nhiệm của người quản lý dự án bao gồm việc đảm bảo dự án được hoàn thành đúng thời hạn trong phạm vi ngân sách và đạt được mức chất lượng cho phép. Ngay cả khi họ không viết một dòng mã nào, người quản lý dự án vẫn sẽ là người chịu trách nhiệm và trả lời về kết quả của nhóm. Họ sẽ phải thống nhất với khách hàng về thời hạn cũng như trao đổi với những người khác để đảm bảo mọi thứ đều sẽ tuân theo đúng trình tự.

Trong phát triển phần mềm không có chỗ quản lý vi mô — ít nhất là trong một môi trường làm việc lành mạnh. Các chuyên viên phân tích kinh doanh (Business analysts - BA) và các kỹ sư phân tích yêu cầu (Requirement Engineer - RE) — dù là trong nội bộ hoặc nằm ngoài nhóm dự án — là cánh tay phải đắc lực của các nhà quản lý dự án. Họ chịu trách nhiệm tạo ra nguồn tài liệu phong phú và rõ ràng về các yêu cầu. Họ cũng là cầu nối giữa khách hàng và các nhà phát triển. Khách hàng sẽ giao tiếp thông qua ngôn ngữ thông thường; BA/RE sẽ đảm bảo việc cung cấp tài liệu một cách rõ ràng và minh bạch để các nhà phát triển có thể thực hiện công việc của họ một cách hiệu quả.

Hãy tưởng tượng bạn được yêu cầu mang một chiếc “bánh lớn” đến một bữa tiệc. “Bánh lớn” có nghĩa là gì? Mười lát hay hai mươi lát? Có thể đó là bánh dùng cho một đám cưới lớn và nó phải có tới một trăm lát. BA/RE sẽ phải xác định các yêu cầu — ví dụ như về số lượng — một cách chính xác để các nhà phát triển biết được rằng một ứng dụng cần đáp ứng những nhu cầu như thế nào (ví dụ như một số lượng người dùng cụ thể).

Dù mới chỉ ở giai đoạn đầu của việc xác định các yêu cầu nhưng chúng ta đã có thể thấy được tầm quan trọng của việc giao tiếp rõ ràng. Giao tiếp là điều cần thiết đối với bất kỳ một công việc chung nào, nhưng có lẽ nó còn quan trọng hơn cả đối với một dự án mã nguồn mở vì các nhà phát triển hoạt động trên từng phần của dự án có thể có các xuất phát điểm rất khác nhau. Một số người có thể là sinh viên hoạt động trên danh nghĩa cộng tác viên, một số khác lại là phụ huynh, một người đã nghỉ hưu hoặc đang làm nhiều công việc khác nhau, v.v. Mặc dù vậy, tiến độ phải diễn ra một cách suôn sẻ trong môi trường này — vì vậy, giao tiếp không được kìm hãm tiến độ.

Để triển khai các yêu cầu, một dự án phần mềm cần các nhà phát triển (developer) tạo ra sản phẩm dựa trên các tài liệu và quyết định thiết kế. Công việc của họ được đánh giá bởi các kiến trúc sư (architect) với lượng kiến ​​thức chuyên môn và lĩnh vực sâu rộng nhất trong số những người tham gia dự án. Mỗi nhà phát triển — đặc biệt là các nhà phát triển cao cấp — đều sẽ chịu trách nhiệm về mã của riêng họ; tuy nhiên, các quyết định lớn sẽ được đưa ra hoặc phê duyệt bởi các kiến ​​trúc sư.

Đôi khi, một số cá nhân sẽ được chỉ định cụ thể với danh nghĩa là kiểm thử viên (tester). Những người này sẽ chịu trách nhiệm với mọi loại thử nghiệm, việc ghi chép kết quả và tạo phiếu lỗi.

Trong giai đoạn đầu này, tất cả các yêu cầu của dự án sẽ được thu thập và ghi chép lại. Công việc này bao gồm các cuộc thảo luận sâu rộng giữa quản lý dự án và các bên liên quan để hiểu được nhu cầu và kỳ vọng của họ. Kết quả của quá trình này sẽ là một tài liệu đặc tả yêu cầu toàn diện phác thảo những gì hệ thống nên làm.

Các chuyên gia phân tích kinh doanh sẽ xem xét các yêu cầu từ góc độ kinh doanh để đảm bảo chúng phù hợp với các mục tiêu của tổ chức. Các BA sẽ thực hiện các nghiên cứu khả thi, đánh giá rủi ro và phân tích chi phí-lợi ích để xác định xem dự án có khả thi và đáng giá hay không. Những hiểu biết thu được sẽ được sử dụng để tinh chỉnh phạm vi và mục tiêu của dự án.

Thiết kế phần mềm là bước mà kiến ​​trúc sư tạo ra bản thông số kỹ thuật thiết kế chi tiết để các nhà phát triển tuân theo. Với thông số kỹ thuật này, nhóm có thể bắt đầu triển khai các yêu cầu — nói cách khác là bắt đầu giai đoạn tiếp theo: phát triển dự án.

Giai đoạn phát triển là nơi phép thuật xảy ra — chính là thời điểm mã được viết. Thực hiện theo tài liệu và các quyết định thiết kế một cách cần mẫn, các nhà phát triển sẽ xây dựng nên công trình của họ. Sau khi các nhà phát triển rà soát và kiểm tra mã của họ cùng với các nhà phát triển hoặc kiến ​​trúc sư khác, giai đoạn này có thể được coi là đã hoàn thành.

Theo sau giai đoạn Phát triển sẽ là giai đoạn kiểm thử/thử nghiệm do kiểm thử viên quản lý. Có nhiều loại kiểm thử nghiệm khác nhau (được mô tả trong bài học khác) như kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống và kiểm thử chấp nhận.

Mục tiêu của những cuộc kiểm thử này là phát hiện ra các vấn đề trước khi phát hành và cho phép các nhà phát triển khắc phục chúng kịp thời — để tránh việc phát hiện sau khi dự án được triển khai và công bố và khiến cho người dùng cảm thấy khó chịu và thất vọng vì lỗi.

Sau khi các cuộc kiểm thử được thông qua và lỗi đã được sửa, dự án có thể được phát hành — tức là triển khai vào môi trường sản xuất. Giai đoạn này có thể bao gồm việc cài đặt, cấu hình và đôi khi thậm chí là đào tạo người dùng. Sau khi dự án đã sẵn sàng sử dụng, nó sẽ tiến vào giai đoạn bảo trì nơi nhóm có thể xử lý các vấn đề từ người dùng và cung cấp các bản cập nhật nếu cần.

Chúng ta có thể nhận thấy điều gì khi đọc về mô hình này? Liệu nó có hiệu quả hoặc có thiếu sót gì không? Hãy cùng tìm hiểu về các ưu và nhược điểm của mô hình này.

Mô hình thác nước có những lợi ích sau:

Cấu trúc rõ ràng: Quy trình tuyến tính dễ hiểu, dễ quản lý và dễ theo dõi.

Mô hình thác nước có những nhược điểm sau:

Scrum là một trong những khuôn khổ phổ biến nhất — cũng có thể là phổ biến nhất — trong phát triển phần mềm linh hoạt. Scrum được xây dựng dựa trên các khối sau:

Nhưng ai là chuyên gia scrum và ai là chủ sở hữu sản phẩm? Danh mục Công việc và Phiên tăng tốc là gì? Hãy cùng tìm hiểu sâu hơn.

Kanban là một khuôn khổ linh hoạt phổ biến khác nhấn mạnh vào việc trực quan hóa công việc, quản lý luồng và cải tiến quy trình. Một trong những điểm khác biệt lớn giữa Scrum và Kanban là Kanban không yêu cầu các phiên lặp có độ dài cố định. Do đó, nó khiến cho việc phân phối liên tục trở nên linh hoạt hơn, việc cân bằng các ưu tiên công việc khác trở nên dễ dàng hơn.

Hãy cùng xem các nhóm phát triển sẽ cần phải chuẩn bị những gì cho một dự án Kanban trong các tiểu mục sau đây.

Mặc dù DevOps được khuyến khích sử dụng cho nhiều loại dự án phần mềm hiện đại nhưng chúng ta vẫn cần phải cân nhắc đến các ưu và nhược điểm của nó.

Mô hình DevOps có các điểm lợi sau:

Mô hình DevOps gặp phải những vấn đề sau: