Bài viết này mình muốn chia sẻ một chút góc nhìn cũng như những kinh nghiệm thực tế khi làm việc trong môi trường sử dụng Agile làm triết lý phát triển phần mềm.
Lượn vài vòng trên các kênh tuyển dụng thì các bạn có thể thấy, có kinh nghiệm làm trong những dự án sử dụng Agile/Scrum là một điểm cộng trong quá trình tìm kiếm các cơ hội việc làm mới, tất nhiên thì đó là một điểm cộng thôi còn bạn sẽ cần phải có nhiều những kĩ năng chuyên môn cũng như những kĩ năng mềm khác nữa.
Được rồi, trước tiên chúng ta cần làm rõ khái niệm một vài từ khóa quan trọng.
Mục Lục
Agile là gì
Theo lý thuyết, Agile là một tư duy và cách tiếp cận lặp đi lặp lại để phát triển phần mềm cũng như quản lý dự án trong môi trường có sự thay đổi nhiều, mơ hồ, không rõ ràng. Giúp triển khai các sản phẩm tới tay người dùng một cách nhanh nhất.
Có bốn giá trị của Agile đã được đúc kết và mô tả trong Agile Manifesto:
Cá nhân và sự tương tác hơn là quy trình và công cụ
: Agile đặt sự chú trọng vào mối quan hệ giữa các cá nhân và tương tác giữa họ hơn là tuân thủ các quy trình và công cụ. Điều này khuyến khích sự giao tiếp, cộng tác và đồng lòng trong một nhóm làm việc.Phần mềm chạy tốt hơn là tài liệu đầy đủ
: Thay vì đầu tư quá nhiều vào việc tạo ra tài liệu dự án chuẩn chỉnh, Agile thúc đẩy việc tạo ra sản phẩm thực tế và thu được phản hồi từ khách hàng càng sớm càng tốt.Hợp tác với khách hàng hơn là thương thảo hợp đồng
: Qua việc liên tục tương tác và phản hồi với khách hàng, Agile giúp đảm bảo rằng dự án đáp ứng đúng nhu cầu của khách hàng.Đáp ứng sự thay đổi hơn là tuân thủ kế hoạch
: Thay vì tuân thủ kế hoạch ban đầu một cách cứng nhắc, Agile linh hoạt và sẵn lòng thay đổi để tối ưu hóa giá trị sản phẩm và đáp ứng yêu cầu mới.
Scrum là gì
Scrum là một trong những phương pháp phát triển phần mềm phổ biến nhất trong Agile, vì ngoài scrum còn có nhiều phương pháp khác nữa. Scrum cung cấp một khuôn khổ và quy trình cho việc tổ chức và quản lý các dự án phát triển phần mềm.
Các doanh nghiệp áp dụng Agile như thế nào
Việc áp dụng thực tế trong các doanh nghiệp có vẻ như là không phải doanh nghiệp nào cũng áp dụng đúng, nhiều doanh nghiệp có áp dụng nhưng chỉ nửa mùa, không đạt được hiệu quả cao.
Tuy nhiên thì có những công ty áp dụng khá là chuẩn chỉnh và bài bản, ví dụ như ở công ty mình thì quá trình này diễn ra thực tế như sau:
Bước 1
: Product Backlog sẽ được truyền thông tới team trước 1 hoặc 2 quý, cái này các PO thu thập nhu cầu từ các stakeholder và định nghĩa ra được một cái roadmap tổng thể.
Bước 2
: Tùy vào scope dự án mà sprint sẽ được triển khai theo 2 tuần, hoặc 3 tuần(rất ít khi), thông thường thì là 2 thôi, còn nếu 3 thì là đính kèm thêm một vài story nữa.
Bước 3
: Trước mỗi sprint cả team sẽ cùng nhau họp Grooming, mục đích để làm rõ những yêu cầu chung về dự án, tài liệu, những thứ cần làm và có thể sẽ làm trong sprint. Ở buổi grooming thì cả team cũng sẽ nhìn lại OKR hiện tại đã đạt được những gì, và giai đoạn sắp tới cần phải đi theo lộ trình nào cũng sẽ được làm rõ.
Bước 4
: Sau buổi họp Grooming sẽ là buổi họp Planning, ở buổi này sau khi mọi người đã nghiên cứu giải pháp, nghiên cứu tài liệu thì sẽ tiến hành vạch ra những thứ cần làm, những thứ cần giải quyết một cách chi tiết, đồng thời sẽ tiến hành estimate nguồn lực chung cho từng story.
Ở buổi này sẽ chốt sprint goal (tức là kiểu mục tiêu đạt được cuối cùng sau khi kết thúc sprint)
Bước 5
: Sau khi estimate xong nguồn lực, tiến hành break sub-task và assgin task, thường sẽ estimate qua đơn vị point, sau khi break xong thì cả team ngồi lại và review về khối lượng công việc cũng như nguồn lực trong dự án để điều chỉnh lại cho phù hợp,
Điều chỉnh ở đây có thể là: cắt bỏ scope chưa quan trọng, ưu tiên những phần scope quan trọng, hoặc các thành viên có người có lịch nghỉ nên cần backup, hoặc ti tỉ thứ khác nữa cũng quan trọng cần ưu tiên.
Bước 6
: Sau khi mọi thứ ở trên đã diễn ra xong, thì việc tiến hành sprint bắt đầu, hằng ngày sẽ có daily meeting tối đa là 15p để cả nhóm cùng nhau báo cáo công việc của ngày hôm trước, thường mỗi người báo cáo sẽ theo format sau:
- Hôm qua đã làm những gì, xử lý những gì
- Có gặp issue, blocker gì không
- Hôm nay xử lý những gì
Với những bạn đã quen làm việc với kiểu trong môi trường mà cả tuần mới báo cáo 1 lần, hoặc có khi cả tháng mới phải báo cáo 1 lần thì có vẻ khi vào môi trường sử dụng scrum thì sẽ hơi ngợp chút, nhưng sẽ không sao đâu, các bạn sẽ làm quen rất nhanh thôi.
Bước 7
: Cuối mỗi sprint sẽ diễn ra buổi review, cả team ngồi lại với nhau để thực hiện demo, review lại những thứ đã làm để đánh giá kết quả, thành tựu đạt được trong sprint.
Bước 8
: Buổi retrospective có thể diễn ra cùng buổi review luôn cũng được nếu có nhiều thời gian, hoặc không thì tách ra thành buổi riêng cũng được, cơ bản thì buổi retro cũng không quá lâu, chủ yếu để các thành viên trong nhóm đánh giá những điều đã làm tốt , những điều chưa tốt cần cải thiện và đưa ra các biện pháp cải tiến cho những sprint tiếp theo.
Team Agile của mình bao gồm những vị trí nào
Scrum Master
: vị trí này có thể gọi là người chủ xị team Agile, tùy tình huống hoặc thời điểm mà cả PO sẽ kiêm vai trò này, mình đánh giá vị trí này khá quan trọng, vì nếu team có SM giỏi+tốt thì team Agile nhận được rất nhiều lợi ích cũng như quyền lợi xứng đáng.Product Owner
: hay được gọi là PO, người này sẽ nhận những yêu cầu từ các khách hàng, stakeholder, người sử dụng sản phẩm cuối và biên dịch Business Requirement.Technical Owner
: hiểu đơn giản là người chịu trách nhiệm chính về Tech trong team Agile, thông thường vị trí TO sẽ gắn với dự án và có tính thời điểm.BackEnd Engineer
: các kĩ sư BackEnd chịu trách nhiệm chính xử lý core, logic, apiFrontEnd Engineer:
các kĩ sư FrontEnd chịu trách nhiệm chính về mặt UI người dùng của những trang liên quan giao diệnMobile Engineer
: các kĩ sư Mobile chịu trách nhiệm chính xử lý nghiệp vụ của MobileQC Engineer
: các kĩ sư QC, phụ trách kiểm thử chất lượng sản phẩm đầu ra của tất cả các ông Engineer ở trên.
Trên đây là cấu trúc team hiện tại mình đang làm việc, và những team khác cũng đều tuân theo cấu trúc này, có một vài team đặc thù hơn sẽ lo về một mặt nhất định như là: hạ tầng, security, devops thì sẽ không được đầy đủ các vị trí nên mình không đề cập.
Agile thích hợp trong những tình huống nào?
Agile là một phương pháp phát triển linh hoạt và nhạy bén, tuy nhiên thì không phải tất cả các dự án phần mềm đều phù hợp với nó. Agile sẽ phù hợp trong những tình huống sau:
Yêu cầu thay đổi thường xuyên
: khi yêu cầu của khách hàng thường xuyên thay đổi hoặc chưa được định rõ từ đầu, Agile cho phép thích ứng và điều chỉnh dự án dễ dàng theo sự thay đổi.Phần mềm có tính tương tác cao
: Nếu dự án yêu cầu sự tương tác chặt chẽ và phản hồi liên tục từ khách hàng hoặc người dùng cuối, Agile giúp tăng cường quá trình tương tác và đảm bảo sự phản hồi nhanh chóng.Đội ngũ phát triển tự quản và có khả năng làm việc nhóm tốt
: các thành viên trong nhóm Agile tương tác chặt chẽ, có khả năng làm việc độc lập, làm việc nhóm tốt, tham gia tích cực vào trong quy trình chung của cả team.Dự án có phạm vi có thể phân chia thành các phần nhỏ
: Agile phù hợp với các dự án có khả năng phân chia thành nhiều phần nhỏ, mỗi phần có thể hoàn thành trong một thời gian ngắn. Việc này có thể giúp tạo ra được kết quả sớm để delivery tới người dùng nhanh hơn, giúp sớm đo thị trường, giúp quản lý rủi ro tốt hơn.
Có phải cứ làm phần mềm là phải áp dụng Agile?
Thực ra không phải môi trường nào áp dụng Agile cũng hợp lý, còn tùy thuộc vào rất nhiều biến số khác nữa: bối cảnh môi trường, dự án, quy mô sản phẩm, tiến độ,… ti tỉ những thứ khác sẽ quyết định đến việc có hoặc không áp dụng một cách chuẩn chỉnh.
Đơn cử như hồi mình ở công ty cũ, đó là một công ty Product be bé, team Tech tính cả CTO thì khoảng 7 người, kiêm nhiệm rất nhiều nhiệm vụ khác nhau.
Mỗi người sẽ là PIC chính cho mỗi đầu dự án, có thể người này hỗ trợ người kia hoặc không, nếu áp dụng Scrum vào thì sẽ khiến quá trình làm việc lúc đó trở nên rất rườm rà, nhiều quy trình và có thể sẽ không đạt được hiệu quả cao được.
Còn ở quy mô công ty to, cỡ tập đoàn thì nên áp dụng, sẽ đạt được nhiều hiệu quả đặc biệt, tuy nhiên thì sẽ phải đánh đổi nhiều thứ khác, dễ nhìn thấy nhất là: “Tiến Độ Dự Án
“.
Nói chung là được tiếp cận, làm việc trong môi trường sử dụng Agile, Scrum hay bất kì phương pháp phát triển phần mềm nào khác cũng sẽ đều đem lại cho các bạn những trải nghiệm, kinh nghiệm và những góc nhìn khác nhau.
Xem thêm một số bài viết nổi bật
- Crack Intellij IDEA Ultimate version 2022
- Phỏng vấn dạo kĩ sư phần mềm 2023
- Kĩ năng quản lý căng thẳng cho Developer
- Bạn không giỏi lắng nghe như bạn nghĩ đâu
- Biết sử dụng git cherry-pick để làm việc hiệu quả hơn
- Git stash giúp bạn trở nên chuyên nghiệp như thế nào?
- Shortcut Intellij hữu ích để làm việc được hiệu quả hơn
- How to build Rate Limit with Hazelcast and Spring Boot
- Hazelcast Distributed Cache with Spring Boot
- How to build Cron Job for multiple instances with ShedLock
- Distributed Lock with Hazelcast and Spring
- How to using Cassandra with Spring boot
- Ba luồng thực hiện tuần tự, có những cách triển khai nào?