You are on page 1of 7

1. Trình bày về phương pháp phát triển phần mềm linh hoạt Agile.

Mô tả cụ thể về
framework scrum?
Agile là một triết lý và phương pháp tiếp cận trong quản lý dự án và phát triển sản phẩm, tập
trung vào linh hoạt, tương tác và thích nghi nhanh chóng. Mục tiêu chính của Agile là tạo ra giá
trị cho khách hàng bằng cách phát triển và cung cấp sản phẩm một cách hiệu quả và liên tục
trong môi trường thay đổi liên tục.
Khuyến khích việc: Lập kế hoạch thích ứng, Phát triển tăng dần, Chuyển giao sớm, Cải tiến liên
tục.
Phương pháp phát triển phần mềm linh hoạt Agile là một hướng tiếp cận linh hoạt trong quản lý
dự án và phát triển sản phẩm. Nó tập trung vào sự tương tác liên tục giữa các thành viên trong
nhóm phát triển, phản hồi linh hoạt từ khách hàng, và khả năng thích ứng với sự biến động
trong quá trình phát triển. Một trong những framework nổi tiếng và thường được sử dụng trong
phương pháp Agile là Scrum.
Agile:
Tập trung vào Người Dùng: Agile đặt người dùng lên trên hết, hỗ trợ sự tương tác thường xuyên
giữa nhóm phát triển và người dùng để đảm bảo rằng sản phẩm đáp ứng đúng nhu cầu của họ.
Quy Trình Linh Hoạt: Agile tập trung vào sự linh hoạt và có khả năng thích ứng nhanh chóng
với thay đổi. Các yêu cầu có thể thay đổi trong suốt quá trình phát triển, và Agile hỗ trợ quy
trình linh hoạt để đáp ứng những thay đổi này.
Phát triển Tiến Triển Từng Đợt (Iterative Development): Agile thường sử dụng mô hình phát
triển theo đợt, trong đó sản phẩm được xây dựng từng phần nhỏ, có thể triển khai và sử dụng
ngay sau mỗi đợt.
Quản lý Rủi Ro và Điều Chỉnh Linh Hoạt: Phương pháp Agile cho phép nhóm phát triển nhận
biết rủi ro sớm và điều chỉnh kế hoạch để đối mặt với thách thức.
Scrum là một khung làm việc trong Agile, tập trung vào việc tổ chức và quản lý quá trình phát
triển sản phẩm một cách linh hoạt. Scrum giúp các nhóm làm việc tạo ra các phần mềm hoặc
sản phẩm có giá trị thông qua các chu kỳ phát triển ngắn gọi là "sprints," đồng thời thúc đẩy
tương tác thường xuyên với khách hàng và việc điều chỉnh dự án dựa trên phản hồi thực tế.
Roles (Vai Trò):
Product Owner (Chủ Sở Hữu Sản Phẩm): Đại diện cho khách hàng, quyết định về nội dung của
sản phẩm.
- Tối ưu giá trị của product
- Phải có tầm nhìn về product và truyền đạt lại cho team
- Có trách nhiệm tối ưu hóa lợi nhuận, làm sao để product có thể hoàn trả lại lượng tiền được
đầu tư vào (ROI)
- Người trả lời những câu hỏi liên quan đến requirement của product
- Quản lý product backlog
- Tập trung vào WHAT hơn là HOW
- Chịu trách nhiệm về sự thành công của dự án
- Chỉ có duy nhất 1 người làm PO
Scrum Master (Quản Lý Scrum): Hỗ trợ và giúp đỡ nhóm phát triển thực hiện Scrum hiệu
quả.
- Bảo vệ nhóm bằng cách ngắn các phiền nhiễu từ bên ngoài
- Loại bỏ các trở ngại cho nhóm, để họ có thể tập trung vào công việc
- Quản lý quy trình không phải lãnh đạo nhóm
- Hành động như một người biện hộ của nhóm trước công ty
- Huấn luyện PO, Mem trong nhóm về Scrum practices
- Hỗ trợ và tham gia vào Retrospective meeting
Development Team (Nhóm Phát Triển): Thực hiện công việc để sản xuất sản phẩm.
- Người thực hiện biến yêu cầu của khách thành sản phẩm
- Tạo ra giá trị thực sự cho khách hàng thông qua việc phát triển và cung cấp tính năng hoặc
sản phẩm
Artifacts (Tác Phẩm): Product Backlog (Danh Sách Yêu Cầu): Danh sách ưu tiên các yêu cầu
của sản phẩm.
Sprint Backlog (Danh Sách Yêu Cầu Sprint): Các yêu cầu được chọn để thực hiện trong một
Sprint.
Ceremonies (Nghi Lễ):
Sprint Planning (Kế Hoạch Sprint): Lập kế hoạch cho một Sprint cụ thể.
Daily Scrum (Họp Hằng Ngày): Cuộc họp ngắn hằng ngày để cập nhật tiến độ và định kỳ nhóm.
Mỗi ngày, nhóm họp hàng ngày trong khoảng thời gian ngắn để chia sẻ tiến độ, thông báo về
công việc đang làm và thảo luận về các rào cản.
Trả lời 3 câu hỏi:
- Hôm qua đã làm gì?
- Hôm nay định làm gì?
- Có vấn đề gặp phải không?
Sprint Review (Xem Xét Sprint): Đánh giá và thu thập phản hồi từ khách hàng sau mỗi Sprint.
Ở cuối mỗi sprint, nhóm tổ chức cuộc họp Sprint Review để trình bày những gì đã hoàn thành
trong sprint và thu thập phản hồi từ khách hàng hoặc người sử dụng.
Sprint Retrospective (Tổng Kết Sprint): Học từ kinh nghiệm và cải thiện quy trình làm việc sau
mỗi Sprint.
Ngay sau cuộc họp Sprint Review, nhóm tổ chức cuộc họp Sprint Retrospective để đánh giá
cách thức làm việc và xác định cơ hội cải thiện.
Scrum, như một phần của phương pháp Agile, cung cấp một cấu trúc linh hoạt và có khả năng
thích ứng cho quá trình phát triển sản phẩm, giúp tăng cường hiệu suất và chất lượng của sản
phẩm.
Transparency (minh bạch): Các thông tin liên quan đến quá trình phát triển, tiến độ, tình hình và
rủi ro nên được chia sẻ một cách mở cửa trong cả nhóm làm việc và với khách hàng. Điều này
giúp mọi người hiểu rõ tình hình và có thể tương tác dựa trên thông tin thực tế.
Inspection(Kiểm tra): Scrum khuyến khích việc kiểm tra và đánh giá thường xuyên về sản phẩm
và quá trình làm việc. Điều này giúp phát hiện sự cố, rủi ro và cơ hội cải thiện sớm hơn để đảm
bảo sản phẩm luôn đáp ứng yêu cầu và tiêu chuẩn.
Adaptation (Thích nghi): Dựa trên thông tin từ quá trình kiểm tra, nhóm Scrum cần linh hoạt và
dám đưa ra các điều chỉnh cần thiết. Việc thích nghi đồng nghĩa với việc thay đổi kế hoạch, ưu
tiên, hoặc phương pháp làm việc để tạo điều kiện tốt nhất cho sự phát triển.
2. Nêu các hình thức rà soát đảm bảo chất lượng phần mềm ? Đưa ra ví dụ cụ thể áp dụng
trong thực tế?
Code Review (Rà Soát Mã Nguồn): Nhóm phát triển thường tiến hành rà soát mã nguồn để
đảm bảo rằng mã nguồn đáp ứng các quy tắc lập trình, tuân thủ các hướng dẫn và được viết theo
các tiêu chí chất lượng.
Unit Testing (Kiểm Thử Đơn Vị): Kiểm thử đơn vị được thực hiện để đảm bảo rằng các phần
nhỏ nhất của mã nguồn (hàm, phương thức) hoạt động đúng và không có lỗi.
Integration Testing (Kiểm Thử Tích Hợp): Kiểm thử tích hợp kiểm tra tính tương tác giữa các
phần của hệ thống khi chúng được kết hợp lại với nhau.
System Testing (Kiểm Thử Hệ Thống): Kiểm thử hệ thống kiểm tra toàn bộ hệ thống để đảm
bảo rằng nó hoạt động đúng theo yêu cầu và đáp ứng được các kịch bản thử nghiệm.
Acceptance Testing (Kiểm Thử Chấp Nhận): Kiểm thử chấp nhận được thực hiện để đảm bảo
rằng sản phẩm cuối cùng đáp ứng các yêu cầu của khách hàng.
VD cụ thể: Dự án phần mềm đang phát triển một ứng dụng web dùng để quản lý thông tin sản
phẩm. Một phần quan trọng của ứng dụng là chức năng tìm kiếm sản phẩm. Nhóm phát triển sử
dụng unit testing để kiểm tra hàm tìm kiếm sản phẩm.
Ví dụ về một test case unit testing
# Tạo một đối tượng tạm thời để tìm kiếm
temp_product = Product(name="Test Product", price=100)
# Thêm sản phẩm tạm vào cơ sở dữ liệu
db.session.add(temp_product)
db.session.commit()
# Gọi hàm tìm kiếm sản phẩm với tên "Test Product"
found_product = search_product("Test Product")
# Kiểm tra xem sản phẩm đã tìm thấy có đúng là sản phẩm vừa được thêm vào không
assert found_product.name == "Test Product"
assert found_product.price == 100
# Xóa sản phẩm tạm khỏi cơ sở dữ liệu
db.session.delete(temp_product)
db.session.commit()
 Trong ví dụ này, chúng ta kiểm tra hàm search_product() để đảm bảo rằng nó trả về đúng
sản phẩm khi được tìm kiếm.
3. Danh sách các tiêu chuẩn áp dụng trong ngành công nghệ thông tin. Giới thiệu chi
tiết các tiêu chuẩn cụ thể
ISO/IEC 9001:2015 - Hệ Thống Quản Lý Chất Lượng:
Xác định các yêu cầu cho hệ thống quản lý chất lượng, áp dụng cho mọi loại tổ chức và
sản phẩm.
CMMI (Capability Maturity Model Integration):
Mô hình đánh giá và quản lý chất lượng và hiệu suất của quy trình phát triển, bảo trì và
quản lý.
CMMI (Capability Maturity Model® Integration) là một mô hình quản lý chất lượng cho
các tổ chức. Nó có thể được sử dụng để định hướng quản lý, định hướng phát triển cho
một dự án, một bộ phận của tổ chức hoặc toàn bộ tổ chức đó.
Đánh giá mức độ hoàn thiện của các quy trình của tổ chức và cung cấp hướng dẫn cải
tiến các quy trình, với mục tiêu cải tiến sản phẩm
CMMI là một mô hình quản lý rủi ro và cung cấp cách đo lường khả năng quản lý rủi ro
của tổ chức. Khả năng quản lý các yếu tố rủi ro tạo nên khả năng của tổ chức trong việc
cung cấp sản phẩm chất lượng cao.
CMMI LEVELS: 5 levels : initial , managed, defined , quantitatively managed,
optimizing
Cấp 1: Initial(Khởi đầu)
Cách tiếp cận ban đầu để đáp ứng mục đích của khu vực xử lý
Không phải là một bộ xử lý hoàn chỉnh để đáp ứng mục đích đầy đủ của Khu vực xử lý.
Chỉ ra được các vấn đề về hiệu suất.
Cấp 2: Managed (được quản lý)
Bao gồm các xử lý cấp 1.
Bộ thực hành đơn giản nhưng đầy đủ nhằm chỉ ra toàn bộ mục đích của Khu vực xử lý.
Không yêu cầu sử dụng tài sản của tổ chức.
Xác định và giám sát tiến độ hướng tới các mục tiêu hiệu suất của dự án.
Cấp 3: Defined(Được xác định)
Được xây dựng dựa trên thực hành cấp 2.
Sử dụng tiêu chuẩn của tổ chức và điều chỉnh để chỉ ra các đặc điểm của dự án và công
việc.
Các dự án sử dụng và đóng góp vào tài sản của tổ chức.
Tập trung vào việc đạt được cả mục tiêu hoạt động của dự án và tổ chức.
Cấp 4: Quantitatively Managed(Được quản lý định lượng)
Quá trình được kiểm soát bằng cách sử dụng các kỹ thuật thống kê và định lượng.
Hiệu suất và chất lượng của quá trình được hiểu theo thuật ngữ và số liệu thống kê.
Các mục tiêu định lượng về chất lượng và hiệu suất quá trình được thiết lập
Cấp 5: Optimizing(Tối ưu hoá)
Tập trung vào việc cải tiến liên tục hiệu suất của quá trình.
Hiệu suất được cải thiện theo cả hai cách - gia tăng và đổi mới.
Nhấn mạnh vào việc nghiên cứu kết quả thực hiện trên toàn tổ chức để đảm bảo rằng các
nguyên nhân hoặc vấn đề chung được xác định và khắc phục.
Maturity Levels: Thước đo năng lực cả tổ chức hay công ty.
Cao hay thấp là tùy thuộc bạn đã có bao nhiêu quy trình đạt được các mức Capability
Levels phù hợp. Năng lực quy trình của cả tổ chức phải được thể hiện bằng năng lực của
nhiều quy trình cộng lại

ƯU ĐIỂM CỦA CMMI: tăng cường chất lượng, nâng cao tính cạnh tranh, đảm bảo sự
tin tưởng của khách hàng
Nhược điểm : Chi phí cao, phức tạp , Thời gian áp dụng
4. Bạn nghĩ sao về quan điểm : thực hiện các hoạt động rà soát đảm bảo chất lượng chỉ làm
tối thời gian và nguồn lực của đội dự án.
Thuận Lợi:
Chất Lượng Sản Phẩm: Rà soát chất lượng giúp phát hiện và loại bỏ lỗi sớm, đảm bảo rằng sản phẩm
cuối cùng là chất lượng và đáp ứng các yêu cầu của khách hàng.
Giảm Chi Phí Sửa Lỗi: Bằng cách phát hiện và sửa lỗi ngay từ giai đoạn phát triển, bạn giảm thiểu
chi phí và thời gian cần thiết để sửa lỗi sau khi sản phẩm đã được triển khai.
Xây Dựng Niềm Tin Khách Hàng: Việc có một sản phẩm chất lượng giúp xây dựng niềm tin từ phía
khách hàng, tăng khả năng duy trì và mở rộng doanh nghiệp.
Tăng Hiệu Suất: Chất lượng là một yếu tố quan trọng ảnh hưởng đến hiệu suất hệ thống và sự ổn định
của ứng dụng.
Nhược Điểm:
Tốn Thêm Thời Gian: Rà soát chất lượng có thể tốn thêm thời gian, đặc biệt là trong giai đoạn đầu
của dự án, có thể ảnh hưởng đến tiến độ phát triển.
Yêu Cầu Nguồn Lực: Cần phải đầu tư nguồn lực, đặc biệt là nguồn nhân sự, để thực hiện các hoạt
động rà soát đảm bảo chất lượng.
Khả Năng Mắc Phải "Phân Chủ":
Nếu quá mức, việc thực hiện quá nhiều hoạt động rà soát có thể dẫn đến hiện tượng "phân chủ" (over-
engineering), khiến công việc trở nên phức tạp và tốn kém mà không đồng nghĩa với việc tăng chất
lượng thực sự.
Giải Pháp:
Tích Hợp Rà Soát vào Quy Trình Phát Triển: Tích hợp các hoạt động rà soát vào quy trình phát
triển để giảm thiểu ảnh hưởng đến tiến độ và làm cho chúng trở thành một phần tự nhiên của quá trình.
Áp Dụng Rà Soát Theo Tầng (Layered Review): Thực hiện rà soát ở các tầng khác nhau của quy
trình để phân chia công việc và ngăn chặn tình trạng "phân chủ".
Tự Động Hóa Rà Soát: Sử dụng các công cụ tự động hóa để thực hiện rà soát, giảm thiểu công sức
thủ công và tăng hiệu suất.
Đánh Giá Hiệu Quả Của Rà Soát: Đánh giá và theo dõi hiệu quả của các hoạt động rà soát để đảm
bảo rằng chúng đóng góp đúng mức vào chất lượng tổng thể của sản phẩm.
Mặc dù có thách thức, nhưng việc thực hiện các hoạt động rà soát đảm bảo chất lượng có thể mang lại
nhiều lợi ích quan trọng cho dự án và tổ chức trong thời gian dài.
5. Quá trình thực hiện rà soát chất lượng dự án bạn làm rà soát pha nào? Bài học kinh
nghiệm rút ra sau khi rà soát là gì?
Quá trình thực hiện rà soát chất lượng dự án em làm rà soát pha lập trình kiểm thử phần User
Acceptance Testing
Quá trình thực hiện rà soát chất lượng dự án em làm rà soát pha lập trình coding phần Chuẩn bị
lập trình
Bài học rút ra:
Pha lập trình
 Đã đạt được
- Đã lựa chọn được công nghệ, công cụ để sử dụng cho việc lập trình và quản lý cơ sở dữ liệu.
- Đã xác định được kiến trúc phần mềm.
- Có unit test một nhóm chức năng xác định trước.
- Có thông báo khi người dùng nhập sai định dạng dữ liệu
- Đã phân quyền thao tác với từng nhóm chức năng.
- Đã xây dựng được một bản chương trình chạy được và có thể thao tác và quản lý dữ liệu.
 Chưa đạt được
 Về tính bảo mật chưa đạt dựa trên mục tiêu nhóm đã đề ra là mật khẩu phải được mã hóa.
 Nhóm chưa có quy trình làm việc trong đội ngũ phát triển phần mềm (ví dụ:
o Chưa có quy trình quản lý source code
o Chưa có quy trình review, đánh giá
o Chưa có quy định thời gian họp cụ thể của nhóm phát triển).
 Chưa hoàn thành hết các chức năng đã được đề cập, còn 11 chức năng về quản lý nghiệp vụ bán
hàng và quản lý kho.
Pha kiểm thử:
 Đã đạt được
- Đã có tài liệu đặc tả chi tiết hệ thống sau khi khảo sát với khách hàng
- Mục tiêu và phạm vi chi tiết, rõ ràng
- Kế hoạch kiểm thử chi tiết, có yêu cầu đầu vào, đầu ra với mỗi loại kiểm thử
- Tài liệu kiểm thử đã nêu được các giai đoạn kiểm thử: Unit test, integration test, system test,
acceptance test
- Có sử dụng tool để kiểm soát lỗi, sử dụng phương pháp kiểm thử hộp trắng, kiểm thử hộp đen, kiểm
thử động và tĩnh
- Các test case được thiết kế và mô tả chi tiết rõ ràng
 Chưa đạt được:
- Chưa thống kê được mức độ nghiêm trọng của lỗi, lỗi đang còn nhiều ở chức năng nào để các lập
trình viên có thể nhanh chóng khắc phục các lỗi
- Các tester không thực hiện kiểm thử lại ở 3 mức độ kiểm thử: Unit test, System test và Integration
test để đảm bảo được tính chính xác và không còn thiếu sót gì sau lần đầu kiểm thử

You might also like