Học Agile Development trên Coursera

Update sáng chủ nhật (đang học, sẽ update thêm vào buổi chiều)

Thấy tuyên ngôn của Agile đã lâu, nhưng chưa bao giờ đọc, hôm nay đọc kỹ mới thấy rất đúng, rất đơn giản.

Manifesto for Agile Software Development

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Thêm hình minh họa cho dễ nhớ

Pasted image702x488 239 KB

Bắt đầu thấy thích khóa học này vì Đạt đang định viết review về quyển Đắc nhân tâm, tức “How to win Friends and Influence People”. Khóa học này cũng đưa quyển sách này vào để nhấn mạnh tầm quan trọng của việc tương tác giữa người với người, team với team để đưa dự án thành công.

Pasted image930x452 76.7 KB

Không phải cứ làm theo 100% yêu cầu của khách hàng là sẽ có được sản phẩm tốt.

Pasted image1313x622 311 KB

Một câu hỏi đơn giản mà lâu nay Đạt cứ không biết nên chọn câu trả lời nào.

Nên tạo ra một sản phẩm không tốt lắm, nhưng không tệ. Hay tao ra sản phẩm rất tốt, hoặc rất tệ.

Pasted image857x249 89.7 KB

Câu trả lời là nên chọn tạo ra sản phẩm cụ thể, có thể rất tốt hoặc rất tệ. Bởi vì khi rất tệ thì mình sẽ biết mà sửa lại cho nó tốt.

Một ví dụ: Khi thiết kế một trang web, ta có thể đặt lên đó mọi nút bấm, mọi chức năng mà trang web có. Người dùng không thể nói là web này thiếu tính năng, nhưng mà họ sẽ không thích trang web bởi trang quá rối, có quá nhiều tính năng họ không biết cách dùng hoặc đơn giản là không cần dùng tới.

Thay vì đó hãy chọn những tính năng cực kỳ cần thiết đưa lên, xem thử người dùng nhận xét ra sao, dựa vào feedback mình có thể thêm hoặc bớt.

Tổng kết tuần 1 khóa học:

Getting Started: Agile Meets Design Thinking

Tuyên ngôn của Agile

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Chương này cho thấy Agile ủng hộ làm việc nhóm, các stakeholders của một dự án phải làm việc với nhau. Tôn trọng và lắng nghe team.

Core của Agile chính là User Stories, User story tức là ta phải hiểu được khách hàng là ai, họ muốn làm gì và đạt được gì.

Cụ thể như sau

Cách release sản phẩm của Agile

Sau đó ta cho User Stories vào Backlogs, sắp xếp theo thứ tự ưu tiên, chia nhỏ để có thể hoàn thành được trong một Iteration, một Iteration có thể kéo dài từ 2 đến 4 tuần.

Có thể release sau một hoặc nhiều Iteration

Pasted image612x602 119 KB

Ngoài ra Agile còn sử dụng Daily Standup bằng cách hỏi 3 câu hỏi mỗi ngày:

• Hôm qua làm gì?
• Hôm nay định làm gì?
• Có vấn đề gì vướng mắc hay không?

Và Burn down để track progress

Pasted image790x398 64.2 KB

Scrum, XP vaf Kanban là 3 cách thể hiện của Agile.

• Scrum là phương pháp phổ biến nhất, có nhiều công cụ hay.
• XP tập trung vào code nhiều hơn
• Kaban hướng tới giảm số lượng việc dang dở( Work in progress)

Pasted image779x281 71.4 KB

Agile hướng tới cách làm việc linh hoạt bằng cách thử nghiệm liên tục, release một tính năng mà team cho là hút khách nhất rồi xem thử phản ứng của khách hàng, nếu thấy tốt thì ta làm tiếp, nếu thấy dở thì sửa lại hoặc đổi sang hướng khác. Cách tiếp cận kiểu thông thường là lên kế hoạch và làm liên tục cho tới khi hoàn thành sản phẩm nhưng chưa chắc khách hàng thích sản phẩm đó.

Agile khó áp dụng là bởi vì bản năng con người ít “hợp tác” với nhau

Để làm được Agile thì ta không chỉ để ý tới đầu ra sản phẩm có đúng hạn hay không mà còn phải để ý tới chất lượng, liệu khách hàng có thích sản phẩm hay không?

Trong quá trình làm, phải để cho dev thoải mái “phát huy” trí tưởng tượng và ý kiến cá nhân. Đưa ra các mệnh lệnh ép buộc sản phẩm phải thế này thế kia có thể phản tác dụng. * Chú ý, đây là tóm tắt, để hiểu được cụ thể vấn đề cần phải đi sâu học khóa này.

Một công cụ giải quyết vấn đề của Agile là Phân tách và tập hơn. Bắt đầu bằng một loạt các ý tưởng, brainstorming, sau đó gom lại, chọn cái nào có lý, khả thi nhất.

Tìm ra vấn đề trước, sau đó mới tìm ra giải pháp để chữa trị vấn đề.

Nên tạo ra một sản phẩm không tốt lắm, nhưng không tệ? Hay tao ra sản phẩm rất tốt, hoặc rất tệ?

Một câu hỏi đơn giản mà lâu nay Đạt cứ không biết nên chọn câu trả lời nào. Nên tạo ra một sản phẩm không tốt lắm, nhưng không tệ. Hay tao ra sản phẩm rất tốt, hoặc rất tệ. [image] Câu trả lời là nên chọn tạo ra sản phẩm cụ thể, có thể rất tốt hoặc rất tệ. Bởi vì khi rất tệ thì mình sẽ biết mà sửa lại cho nó tốt. Một ví dụ: Khi thiết kế một trang web, ta có thể đặt lên đó mọi nút bấm, mọi chức năng mà trang web có. Người dùng không thể nói là web này thiếu tính năng, nhưng mà họ sẽ không…

Khóa này hay ghê, nhưng dạo này em cũng không sắp xếp được thời gian. EM cũng đang học 1 kháo khác trên coursera, có lẽ em cũng làm review như anh Đạt để tự tăng thêm động lực cho bản thân vậy

Anh Đạt cho em hỏi là học xong khóa này kiến thức thực tế áp dụng ở các công ty Việt Nam dùng nhiều không ạ. Em thấy ở Việt Nam nhiều công ty không áp dụng quy trình aglie cho phát triển phần mềm do khó đánh giá tiêu chuẩn CMMI.
Theo em biết thì fpt, TMA, Global cyber… mấy doanh nghiệp cntt thường không dùng aglie.
Chỉ có axon box và 1 vài doanh nghiệp dùng.

có lẽ em cũng làm review như anh Đạt để tự tăng thêm động lực cho bản thân vậy

Nên

Anh Đạt cho em hỏi là học xong khóa này kiến thức thực tế áp dụng ở các công ty Việt Nam dùng nhiều không ạ.

Các công ty VN có áp dụng hay không thì khó mà trả lời được, việc áp dụng tùy thuộc vào team, project. Nhưng Đạt nghĩ Agile tốt, nên áp dụng.

Thông báo là Đạt đã chọn được khóa học phù hợp, sẽ close topic này và làm một topic khác để review khóa học đấy.