WAY TO ENTERPRISE
Lesson 2
Mô hình phát triển phần mềm
Agenda
I. Mô hình phát triển phần mềm II. Agile Mindset
III. Mô hình Scrum
I. Mô hình phát triển phần mềm
Yêu cầu khách
hàng
Ứng dụng/Hệ
thống Quy trình phát triển phần mềm
Mô hình phát triển phần mềm
I.I Mô hình thác nước – Waterfall model
I.I Mô hình thác nước – Waterfall model
- Mô hình phát triển phần mềm đầu tiên được sử dụng.
- Mô hình sẽ áp dụng tuần tự các giai đoạn của phát triển phần mềm, đầu ra của giai đoạn này là đầu vào của giai đoạn sau.
- Không quay lại giai đoạn trước để xử lý các yêu cầu khi muốn thay đổi.
Ứng dụng:
- Dự án nhỏ, ngắn hạn
- Dự án ít thay đổi và yêu cầu phải rõ ràng
I.I Mô hình thác nước – Waterfall model
Ưu điểm:
- Dễ sử dụng, dễ tiếp cận, dễ quản lý.
- Các giai đoạn phát triển được xác định rõ ràng
- Xác nhận ở từng giai đoạn, đảm bảo phát hiện lỗi sớm
Nhược điểm:
- Ít linh hoạt
- Không phù hợp với dự án dài, phức tạp, có nhiều thay đổi - Khó quay lại giai đoạn trước khi nó đã kết thúc.
- Giai đoạn test chỉ được triển khai sau khi đã code xong => phát hiện lỗi muộn
I.II Mô hình chữ V – V model
I.II Mô hình chữ V – V model
- Mở rộng của mô hình thác nước và được dựa trên sự kết hợp của một giai đoạn thử nghiệm cho từng giai đoạn phát triển tương ứng.
- Đối với mỗi giai đoạn trong chu kỳ phát triển, có một giai đoạn thử nghiệm liên quan trực tiếp. Đây là một mô hình có tính kỷ luật cao và giai đoạn tiếp theo chỉ bắt đầu sau khi hoàn thành giai đoạn trước.
- Công việc test được tham gia ngay từ đầu Có 4 mức độ kiểm thử:
- Kiểm thử thành phần (Component testing) - Kiểm thử tích hợp (Integration testing) - Kiểm thử hệ thống (System testing)
- Kiểm thử chấp nhận (Acceptance testing)
I.II Mô hình chữ V – V model
Nhược điểm:
- Không phù hợp cho các dự án dài, đang diễn ra và phức tạp
- Không phù hợp cho các dự án có nguy cơ thay đổi yêu cầu trung bình đến cao - Khi ứng dụng đang ở giai đoạn thử nghiệm, rất khó quay lại và thay đổi chức năng Ưu điểm:
- Mô hình có tính kỷ luật cao, các giai đoạn hoàn thành cùng 1 lúc - Hoạt động cho các dự án nhỏ, khi các yêu cầu được hiểu rõ - Đơn giản, dễ hiểu và dễ sử dụng
- Dễ quản lý
II. Agile mindset
Agile là một phương pháp phát triển phần mềm linh hoạt để làm sao đưa sản phẩm đến tay người dùng càng nhanh càng tốt, càng sớm càng tốt.
II.I Tuyên ngôn Agile
Cá nhân và sự tương tác hơn là quy trình và công cụ Phần mềm chạy tốt hơn là tài liệu đầy đủ
Cộng tác với khách hàng hơn là đàm phán hợp đồng Phản hồi với các thay đổi hơn là bám sát kế hoạch
II.II Nguyên lý Agile
1. Ưu tiên cao nhất của chúng tôi là thỏa mãn khách hàng thông qua việc chuyển giao sớm và liên tục các phần mềm có giá trị.
2. Chào đón việc thay đổi yêu cầu, thậm chí rất muộn trong quá trình phát triển. Các quy trình linh hoạt tận dụng sự thay đổi cho các lợi thế cạnh tranh của khách hàng.
3. 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 các khoảng thời gian ngắn hơn.
4. Nhà kinh doanh và nhà phát triển phải làm việc cùng nhau hàng ngày trong suốt dự án.
5. Xây dựng các dự án xung quanh những cá nhân có động lực. Cung cấp cho họ môi trường và sự hỗ trợ cần thiết, và tin tưởng họ để hoàn thành công việc.
6. Phương pháp hiệu quả nhất để truyền đạt thông tin tới nhóm phát triển và trong nội bộ nhóm phát triển là hội thoại trực tiếp.
II.II Nguyên lý Agile
7. Phần mềm chạy tốt là thước đo chính của tiến độ.
8. 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, và người dùng có thể duy trì một nhịp độ liên tục không giới hạn.
9. Liên tục quan tâm đến các kĩ thuật và thiết kế tốt để gia tăng sự linh hoạt.
10. Sự đơn giản – nghệ thuật tối đa hóa lượng công việc chưa xong – là căn bản.
11. Các kiến trúc tốt nhất, yêu cầu tốt nhất, và thiết kế tốt nhất sẽ được làm ra bởi các nhóm tự tổ chức.
12. Đội sản xuất sẽ thường xuyên suy nghĩ về việc làm sao để trở nên hiệu quả hơn. Sau đó họ sẽ điều chỉnh và thay đổi các hành vi của mình cho phù hợp.
II.II Nguyên lý Agile
II.III Áp dụng Agile
“Being” Agile vs “Doing Agile”
III Mô hình Scrum
Scrum là một quy trình phát triển phần mềm theo phương pháp Agile. Chính vì thế, Scrum tuân thủ các nguyên tắc của Agile
III.I Vai trò trong Scrum
III.I Vai trò trong Scrum
Product Owner (chủ sản phẩm): Là người chịu trách nhiệm về sự thành công của dự án, người định nghĩa các yêu cầu và đánh giá cuối cùng đầu ra của các nhà phát triển phần mềm. Là người tạo ra các Product Backlog và đưa backlog vào từng Sprint
III.I Vai trò trong Scrum
Scrum Master: Là người có hiểu biết sâu sắc về Scrum và đảm bảo nhóm có thể làm việc hiệu quả với Scrum.
III.I Vai trò trong Scrum
Development Team (Đội sản xuất, hay Nhóm phát triển): Một nhóm liên chức năng (cross-functional) tự quản lý để tiến hành chuyển đổi các yêu cầu được tổ chức trong Product Backlog thành chức năng của hệ thống.
III.II Quy trình Scrum
III.II Sprint planning (Họp kế hoạch Sprint)
Mọi thành viên trong team sẽ tham gia và thảo luận về việc sẽ bàn giao những gì trong sprint này.
Hoạt động:
– Product owner trình bày bản product backlog mới nhất.
– Product owner và Team thảo luận để đảm bảo họ có thể chia sẻ những gì mà họ hiểu biết.
– Team dự tính những gì có thể bàn giao trong sprint.
– Team đưa ra mục tiêu.
– Team kên kế hoạch để đạt được mục tiêu đề ra
III.II Daily Scrum (Họp Scrum hàng ngày)
Chỉ được diễn ra đúng 15 phút Cập nhật nhanh chóng:
– Cùng 1 thời gian – Cùng địa điểm
– Cùng những người đó – Cùng câu hỏi
Câu hỏi:
– Bạn đã làm gì ngày hôm qua?
– Bạn sẽ làm gì ngày hôm nay?
– Bạn có gặp trở ngại gì không?
III.II Sprint review (Họp sơ kết Sprint)
Cùng với Product owner xác nhận xem phần nào đã Hoàn thành trong Sprint.
Những phần chưa Hoàn thành có thể trao đổi để sang Sprint tiếp theo.
Team sẽ nhận những Feedback đóng góp từ Product owner về sản phẩm bàn giao.
Xác định những điều sẽ làm để tối ưu hóa sản phẩm
III.II Sprint Retrospective
Là cuộc họp cởi mở, trung thực mục đích để cải thiện chất lượng chứ không phải để đổ lỗi cho ai.
Mỗi cá nhân sẽ đưa ra những suy nghĩ của bản thân về dự án:
- Keep: Những phần nào tốt, cần giữ lại
- Problem: Những vấn đề nào chưa tốt, gây lỗi
- Try: Cần làm gì để cải thiện Sau buổi Retrospective, ”Try” sẽ
III.III Các công cụ trong Scrum
Product backlog: Đây là danh sách ưu tiên các tính năng (feature) hoặc đầu ra khác của dự án. Có thể hiểu như là danh sách yêu cầu (requirement) của dự án.
Product Owner chịu trách nhiệm sắp xếp độ ưu tiên cho từng hạng mục (Product Backlog Item) trong Product Backlog dựa trên các giá trị do Product Owner định nghĩa
Sprint backlog: Đây là bản kế hoạch cho một Sprint; là kết quả của buổi họp lập kế hoạch (Sprint Planning).
III.III Các công cụ trong Scrum
Burn Down Chart:
- Đây là biểu đồ hiển thị xu hướng của dự án dựa trên lượng thời gian cần thiết còn lại để hoàn tất công việc.
- Burndown Chart có thể được dùng để theo dõi tiến độ của Sprint (được gọi là Sprint Burndown Chart) hoặc của cả dự án (Project Burndown Chart).
