Please enable JavaScript.
Coggle requires JavaScript to display documents.
Phương pháp phát triển linh hoạt - Coggle Diagram
Phương pháp phát triển linh hoạt
Lập trình cực đoan
Nguyên tắc của lập trình cực đoan
Đơn giản
Phản hồi
Giao tiếp
Sự can đảm
Một số thực tiễn của lập trình cực đoan
Lập kế hoạc gia tăng
Yêu cầu người dùng được biểu thị bằng kịch bản hoặc câu chuyện người dùng
Khách hàng chọn các câu chuyện được thực thi ở phiên bản tiếp theo
Đội phát triển phân chia yêu cầu thành các nhiệm vụ
Phát hành nhỏ
Nhận được giá trị kinh doanh sớm, khiến khách hàng cảm thấy tự tin và hài lòng hơn
Nhận được phản hồi sớm hơn
Khiến cho nhà phát triển có được một thành tựu ý nghĩa sớm
Giảm thiểu rủi ro
Dễ dang thích ứng và thay đổi mã nguồn nếu yêu cầu thay đổi
Thiết kê dơn giản
Thiết kế đơn giản để đáp ứng được yêu cầu
Không có chức năng trùng lặp
Các phương thức và lớp là ít nhất có thể
Phát triển kiểm thử trước
Tạo ra các bài kiểm tra đơn vị cho mỗi một phần chức năng ngay cả khi nó chưa được thực hiện
Tái cấu trúc
Các nhà phát triển mong muốn sẽ cấu trúc lại mã liên tục ngay khi mã có thể cải thiện được để tạo ra mã nguồn đơn giản và duy trì
Lập trình theo cặp
Các nhà phát triển lập trình theo cặp, kiểm tra công việc của nhau cung cấp những hỗ trợ để cùng nhau hoàn thành tốt công việc
Tích hợp liên tục
Khi nhà phát triển hoàn thành một đoạn chương trình, họ sẽ chạy các kiểm thử cục bộ, nếu kiểm thử thất bại các nhà phát triển sẽ quay lại sửa đổi mã nguồn. Vòng lặp nhỏ này sẽ được thực hiện đến khi kiểm thử thành công, sau đó họ sẽ tích hợp mã với các đoạn mã của các nhà phát triển khác và chạy các kiểm thử tích hợp, một vòng lặp nhỏ khác lại được thực hiện cho đến khi kiểm thử tích hợp thành công
Làm việc ở địa điểm của khách hàng
Khách hàng hoặc người dùng là 1 phần của đội phát triển
Kỹ thuật yêu cầu trong XP
Kịch bản hoặc câu chuyện người dùng được khách hàng viết trên thẻ, đọi ngũ phát triển chia nhỏ chúng thành các nhiệm vụ thực hiện
Dựa vào chi phí và độ ưu tiên khách hàng sẽ lựa chọn câu chuyện tiếp theo được đua vào phiên bản tiếp theo
Các nhà phát triển sẽ lấy những thẻ nhiệm vụ và thực hiện chúng
Chiến lược kiểm thử
Có hai loại kiểm thử: - Kiểm thử đơn vị: kiểm tra các chức năng dựa vào các thẻ nhiệm vụ
Kiểm thử hệ thống: dựa vào khách hàng, khách hàng đưa ra những bài kiểm tra cho câu chuyện của họ
Scrum
Khách hàng đưa ra yêu cầu dưới dạng product back log
Đội phát triển ngồi với nhau lập kế hoạch cho Sprint
Kết quả của cuộc họp (Sprint backlog), những việc cần làm trong Sprint tới
Scrum hàng ngày: họp nội bộ nắm tiến độ, phát hiện trở ngại; cập nhật kế hoạch
Hết thời gian của 1 Sprint (2 - 4 tuần) đánh giá hoạt động của đội và tìm ra điều cần cải tiến
Sau nhiều Sprint sản phẩm chạy tốt ra đời
Chi phí thay đổi bằng phẳng, chi phí truyền thống giảm bằng cách tuân theo một số nguyên tắc:
Tập trung vào mã
Tập trung vào con người trong quá trình
Dựa trên phương pháp lặp
Cần có sự tham gia cuae khách hang trong suốt quá trinhg phát triển
Kỳ vọng các yêu cầu sẽ thay đổi
Sự đơn giản