Tại nhiều cuộc phỏng vấn, có thể bạn sẽ được hỏi về phương pháp luận. Đây không phải là câu hỏi quan trọng nhất hay khó nhất, nhưng có một cheat sheet sẽ rất tuyệt. Trong bài viết này, chúng tôi sẽ cố gắng truyền đạt phương pháp phát triển là gì và so sánh chúng. Phương pháp phát triển phần mềm là một quy trình được sử dụng để phát triển một sản phẩm cụ thể, nghĩa là nó là một cách để tổ chức phát triển bởi một nhóm các nhà phát triển. Có nhiều mô hình phát triển khác nhau, mỗi mô hình xác định cách tiếp cận riêng. Không thể nói rằng bất kỳ ai trong số họ nên được sử dụng cho mọi dự án. Cách tiếp cận đúng phụ thuộc hoàn toàn vào tình huống. Tôi dự định xem xét ba trong số chúng một cách chi tiết hơn.
Thuận lợi:
Tôi sẽ cố gắng giải thích ngắn gọn bản chất của phương pháp này bằng những từ đơn giản, nhưng có rất nhiều thuật ngữ. Tôi nghĩ điều quan trọng nhất là phải hiểu bản chất. Bạn sẽ nhớ các thuật ngữ với kinh nghiệm. Tất cả quá trình phát triển được chia thành các lần chạy nước rút (thường kéo dài 2-3 tuần). Có một tồn đọng(danh sách các nhiệm vụ) cho toàn bộ giai đoạn phát triển và cho mỗi lần chạy nước rút riêng biệt. Mỗi nhiệm vụ có điểm câu chuyện riêng (xếp hạng độ khó). Mỗi người tham gia trong quá trình có một vai trò:
thác nước
Phương pháp thác nước là một trong những phương pháp lâu đời nhất và liên quan đến việc triển khai tuần tự nghiêm ngặt: mỗi giai đoạn phải được hoàn thành trước khi bắt đầu giai đoạn tiếp theo. Nói cách khác, chuyển sang giai đoạn tiếp theo có nghĩa là công việc của giai đoạn trước đã hoàn thành 100%. Bức tranh cho thấy cách nó hoạt động: đầu tiên, chúng tôi phân tích vấn đề (ghi lại các nhiệm vụ, thảo luận về các thách thức), sau đó chúng tôi thiết kế (cấu trúc của dự án hình thành ở giai đoạn này), sau đó chúng tôi viết mã và kiểm tra. Quay trở lại các giai đoạn trước đó là không được phép. Cách tiếp cận này được khuyến nghị cho các dự án nhỏ khi các yêu cầu được biết trước và không có khả năng thay đổi.
- Tài liệu đầy đủ và nhất quán ở từng giai đoạn
- Dễ sử dụng
- Yêu cầu ổn định
- Ngân sách và thời hạn được xác định trước
- Một lượng lớn tài liệu
- Không linh hoạt lắm
- Khách hàng không thể xem phiên bản demo của sản phẩm
- Không có tùy chọn để di chuyển lùi
Scrum
Scrum là một phương pháp phát triển phần mềm chia toàn bộ quy trình thành các lần lặp lại. Vào cuối mỗi lần tương tác, nhóm sẵn sàng cung cấp phiên bản demo của sản phẩm. Hình ảnh cho thấy rằng nhóm tiến hành song song tất cả các giai đoạn phát triển, giúp có thể hoàn thành một phần của dự án vào cuối mỗi lần lặp lại.
- Nhóm scrum bao gồm các chuyên gia (nhà phát triển, người thử nghiệm, nhà thiết kế) làm việc trong một dự án.
- Scrum master là người đảm bảo rằng các nguyên tắc của scrum được tôn trọng.
- Chủ sở hữu sản phẩm là khách hàng.
- Đứng lên – Đây là một cuộc họp ngắn, được tổ chức hàng ngày, trong đó tất cả các thành viên trong nhóm đều tham gia. Mỗi người tham gia trả lời 3 câu hỏi: Tôi đã làm gì? Tôi sẽ làm gì? Và những vấn đề chặn là gì?
- Họp lập kế hoạch – Cuộc họp này được tổ chức vào đầu Sprint. Các nhiệm vụ phải được thực hiện trong lần chạy nước rút tiếp theo được xác định tại cuộc họp này.
- Cải tiến - Cuộc họp này được tổ chức vào cuối Sprint và mục đích của nó là xác định những gì đã được thực hiện tốt và những gì có thể được cải thiện.
- Khách hàng có thể thấy kết quả trong quá trình phát triển
- Giám sát hàng ngày quá trình phát triển
- Khả năng điều chỉnh trong quá trình phát triển
- Thiết lập thông tin liên lạc với tất cả các thành viên trong nhóm
- Một lượng nhỏ tài liệu
- Khó đánh giá lao động và các chi phí khác cần thiết cho phát triển
- Khó xác định tắc nghẽn trước khi bắt đầu phát triển
- Sự cần thiết phải lôi kéo mọi người tham gia vào công việc của các thành viên khác trong nhóm.
Kanban
Kanban là một phương pháp dựa trên việc hình dung tiến độ đạt được trong việc hoàn thành nhiệm vụ của nhóm. Ý tưởng chính là giảm số lượng tác vụ hiện đang được thực hiện (trong cột "Đang tiến hành"). Trong scrum, nhóm tập trung vào việc hoàn thành thành công các Sprint. Trong Kanban, nhiệm vụ chiếm vị trí ưu việt. Điều này tốt cho các dự án đang trong giai đoạn bảo trì, khi chức năng cơ bản đã được triển khai và vẫn còn những cải tiến và sửa lỗi tối thiểu. Trong Kanban, các nhiệm vụ được giao riêng lẻ. Một nhiệm vụ trải qua tất cả các giai đoạn trên bảng, độc lập với các nhiệm vụ khác và sau khi hoàn thành, nó có thể được hiển thị cho khách hàng. Bảng Kanban bao gồm các cột, mỗi cột đại diện cho một quy trình phát triển riêng biệt. Một số cột (ví dụ: "Đang xử lý" ) giới hạn số lượng nhiệm vụ họ có thể nắm giữ. Điều này giúp nhanh chóng và dễ dàng tìm thấy các khu vực có vấn đề trong quá trình phân bổ nhiệm vụ. Hình ảnh cho thấy một ví dụ về một bảng như vậy. Số lượng cột và tên của chúng có thể khác nhau. Tôi sẽ trình bày phổ biến nhất:
- To Do – Danh sách các nhiệm vụ phải được thực hiện
- Đang tiến hành - Các nhiệm vụ hiện đang được thực hiện
- Đánh giá mã – Các tác vụ được thực hiện và đã được gửi để xem xét
- Đang thử nghiệm – Các tác vụ đã sẵn sàng để thử nghiệm
- Done – Hoàn thành nhiệm vụ
- Dễ sử dụng
- Khả năng hiển thị (giúp xác định vị trí tắc nghẽn, đơn giản hóa sự hiểu biết)
- Sự tham gia của nhóm cao trong chính quá trình
- Phát triển linh hoạt cao
- Một danh sách nhiệm vụ không ổn định
- Khó áp dụng cho các dự án dài hạn
- Thiếu thời hạn khó khăn
GO TO FULL VERSION