1. Tại sao cần quản lý dự án
Nhu cầu
- Xuất hiện thị trường toàn cầu (Global market) ⇒ Nếu không đổi mới sẽ bị đào thải
- Yêu cầu chất lượng sản phẩm ngày càng cao (High quality product) và thoả mãn nhu cầu khách hàng (Customer satisfaction)
- Quy trình sản xuất phức tạp (Complex technical)
- Vòng đời sản phẩm ngắn (Shorten product life cycles)
Quy trình quản lý Waterfall
Đặc tính của mô hình Waterfall
- Quy trình đi từ trên xuống dưới và không có chiều ngược lại
- Bị xung đột giữa các bộ phận
- Nhưng nếu một khi đã vận hành trơn tru thì lại rất hiệu quả ⇒ Vì tính chuyên môn hoá
Quy trình quản lý theo Agile
- Không bị ràng buộc bởi các hạn chế của Waterfall
- Phù hợp với các dự án có tính thay đổi cao nhưng các dự án CNTT
- Một nhóm scrum team phù hợp nhất với team size từ 6 - 10 người
| Waterfall | Agile | |
|---|---|---|
| Phạm vi | Xác định rõ ràng từ đầu và không thay đổi trong suốt quá trình dự án | Thường xuyên thay đổi và điều chỉnh phạm vi trong suốt quá trình dự án |
| Lập kế hoạch | Kế hoạch chi tiết được xác định từ đầu dựa trên các yêu cầu đã được xác định | Kế hoạch linh hoạt, chỉ xác định kế hoạch cho các chu kỳ ngắn, dựa trên ưu tiên và phản hồi liên tục |
| Tiến trình | Tuần tự, các giai đoạn được thực hiện một sau một, không có sự chồng chéo | Lặp lại và phát triển theo chu kỳ ngắn, các giai đoạn có thể chồng chéo và lặp lại |
| Rủi ro | Đánh giá và quản lý rủi ro từ đầu, ít khả năng thích ứng với rủi ro xuất hiện | Phát hiện và giải quyết rủi ro một cách linh hoạt trong suốt quá trình dự án |
| Kiểm soát | Kiểm soát tiến độ và kết quả dự án dựa trên kế hoạch ban đầu | Kiểm soát liên tục, phản hồi nhanh chóng và điều chỉnh để đạt được kết quả tốt nhất |
| Giao tiếp | Giao tiếp rõ ràng, tài liệu chi tiết và đánh giá cuối giai đoạn | Giao tiếp linh hoạt, liên tục và tương tác với khách hàng và thành viên nhóm |
| Phản hồi | Phản hồi chậm, thường xuyên chỉ sau khi hoàn thành một giai đoạn | Phản hồi nhanh chóng, liên tục trong suốt quá trình dự án |
| Sản phẩm | Giao hàng cuối cùng sau khi tất cả các giai đoạn hoàn thành | Giao hàng liên tục, có thể có sản phẩm chức năng sau mỗi chu kỳ |
Agile Manifesto
Agile là quy trình
- Individuals and interactions over processes and tools - Tập trung vào cá nhân và sự tương tác hơn là quy trình và công cụ
- Working software over comprehensive documentation - Một phần mềm chạy được quan trọng hơn tài liệu dễ hiểu
- Customer collaboration over contract negotiation - Cố gắng làm khách hàng hợp tác và cân đối để 2 bên đều có lợi thay vì tập trung vào hợp đồng
- Responding to change over following a plan - Chấp nhận sự thay đổi thay vì tập trung vào plan
Scrum
Scrum là khung làm việc (framework) giúp đội nhóm giải quyết các vấn đề phức tạp một các hiệu quả và tạo ra giá trị lớn nhất cho khách hàng. Scrum is lightweight and simple to understanding
Scrum 3 Pillars
- Transparency - Tính trong suốt: Mọi thông tin trong dự án đều là công khai và ai cũng có thể xem được cứ không bị phân tầng
- Inspection - Tính kiểm tra: Mọi thời điểm có thể kiểm tra được tiến độ dự án, còn bao lâu nữa đến mục tiêu và phải được kiểm tra thường xuyên
- Adaptation - Tính thích nghi: Thay đổi kế hoạch để thích nghi với sự thay đổi
Scrum 5 values
Scrum definition
Scrum team
Đơn vị cơ bản của Scrum là một đội nhỏ gọi là Scrum Team. Scrum Team bao gồm một Scrum Master, một Product Owner và các Developers. Trong Scrum Team không có phân cấp hay tổ chức con. Nó là đơn vị gắn kết những chuyên gia cùng tập trung vào một mục tiêu, đó là Product Goal. Scrum Team có tính đa năng, có nghĩa là các thành viên cộng lại sẽ có tất cả kỹ năng cần thiết để tạo nên giá trị sau mỗi Sprint. Họ cũng tự quản, nghĩa là họ tự quyết định ai làm gì, khi nào và như thế nào. Scrum Team nhỏ vừa phải để giữ sự linh hoạt và lớn vừa phải để có thể hoàn tất những công việc có ý nghĩa trong một Sprint, thường là 10 người hoặc ít hơn. Nhìn chung, chúng ta thấy rằng những đội nhỏ hơn sẽ giao tiếp tốt hơn và hiệu quả hơn. Nếu Scrum Team trở nên quá lớn, họ nên nghĩ tới việc tái cấu trúc thành các Scrum Teams nhỏ hơn, cùng tập trung vào một sản phẩm. Từ đó họ có thể chia sẻ cùng một Product Goal, Product Backlog và Product Owner.
Development team
Development team là những cá nhân trong Scrum Team cam kết tạo ra kết quả có giá trị sau mỗi Sprint.
Development team bao gồm: FE, BE, BA, Designer, Tester
Development team là một nhóm tự quản và không có người quản lý trực tiếp
Product Owner
Product Owner là cá thể tối ưu giá trị sản phẩm của developers team. Họ có trách nhiệm quản lý Product Backlog
Scrum master
Là người có kiến thức về scrum, tạo mô trường thực hành scrum trong scrum team. Họ có trách nghiệm tối ưu hoá tương tác các cá thể trong scrum team
Scrum Artifacts
Product backlog: Là một rổ tập hợp các User stories cần phải làm để hoàn thành dự án, các công việc trong product backlog sẽ có mức độ ưu tiên khác nhau.
User stories: Là các câu chuyện của người dùng (Một phần mềm là tập hợp của nhiều câu chuyện người dùng)
User stories bao gồm: tất cả các tính năng, yêu cầu, nâng cấp và sửa lỗi
Definition of Done - Là việc định nghĩa hoàn thành một công việc, tránh việc hiểu lầm những các thành phần trong scrum team.
Scrum Events (time-box event)
Sprints - chạy nước rút: Trái tim của scrum, là các khoảng thời gian kéo dài từ 1 tuần đến 4 tuần, có độ dài như nhau xuyên suốt từ lúc bắt đầu đến kết thúc dự án
Sprint Goal: Mục tiêu là mục tiêu chung của cả scrum team, trong quá trình thực hiện phải bám chặt lấy mục tiêu của sprint goal
Sprint Planning: Là sự kiện thảo luận giữa các thành viên trong scrum nhằm đưa ra được sprint goal
- Xác định sprint goal là gì? Và giải thích tầm quan trọng của nó để mọi người đều hiểu
- Làm những công việc gì trong Product Backlog để đạt được sprint goal
- Làm như thế nào?
Daily scrum: Sự kiện hàng ngày trong khoảng 15p - nhằm báo cáo công việc của ngày hôm trước và kế hoạch của ngày hôm nay.
Từng cá nhân sẽ nói những vấn đề thuận lợi, khó khăn và kế hoạch ngày tiếp theo
Giải quyết các vấn đề mất cân đối thông tin giữa PO, SM và Development team