Agile và Scrum cho sinh viên sắp đi làm

CHUYỆN NGHỀNo Comments

You Are Here:Agile và Scrum cho sinh viên sắp đi làm

 

Trong công ty phần mềm, việc quản lý dự án đóng vai trò then chốt. Và một trong các bước đầu tiên khi bắt đầu dự án là xác định phương thức quản lý dự án. Lúc chưa đi làm mỗi khi nhắc đến phát triển phần mềm mình chỉ biếtwaterfall. Đi làm rồi lúc join dự án mọi người có nói dự án đang phát triền Agile ?? 😀 ?? Lúc đầu vào cũng hơi bỡ ngỡ nhưng làm 1, 2 tuần rồi cũng quen. Hi vọng bài viết sẽ giúp nhiều bạn sinh viên chưa đi làm hiểu được phần nào. Qua bài viết mình cũng muốn gửi lời cảm ơn đến anh Doãn
Văn Toản(Framgia Education)
đã cho em hiểu biết thêm về Agile thông qua các buổi học tại Lab 434 Trần Khát Chân.

1. Agile là gì?

Agile là một tập hợp các nguyên lý dành cho phát triển phần mềm, trong đó 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, và cải tiến liên tục. Agile cũng chủ trương thích ứng nhanh chóng với các thay đổi. Những nguyên lý này được chia sẻ trong Tuyên ngôn Phát triển Phần mềm Linh hoạt và 12 Nguyên lý phía sau.

Agile không định nghĩa một phương pháp cụ thể để đạt được những điều này, nhưng lại có nhiều phương pháp phát triển phần mềm khác nhau thỏa mãn và hướng theo các tiêu chí đó.

Mục đích của các phương pháp Agile là giúp các doanh nghiệp đạt được sự linh hoạt (Agility), từ đó nâng cao sức cạnh tranh và phát triển bền vững. Các phương pháp Agile đã thay đổi diện mạo thế giới không chỉ trong Phát triển phần mềm mà còn đang thể hiện giá trị trong các lĩnh vực khác như Marketting (Agile Marketting), giáo dục (EduScrum, Lean Edu, v.v.), thiết kế (Lean UX, Design Thinking), khởi nghiệp (Lean Startup) và Phần cứng.

2. Tại sao lại là Agile?

Nhắc lại một chút về waterfall. Waterfall là một mô hình của quy trình phát triển phần mềm, trong đó quy trình phát triển trông giống như một dòng chảy, với các pha được thực hiện theo trật tự nghiêm ngặt và không có sự quay lui hay nhảy vượt pha, cụ thể:

Như vậy, waterfall (mô hình thác nước) ngụ ý rằng, việc chuyển từ pha phát triển này sang pha khác sẽ diễn ra chỉ sau khi các pha trước đó đã kết thúc hoàn toàn thành công, và không thể quay lui về pha trước đó hay nhảy vượt pha.

Ta thấy mô hình này khá đơn giản, từ đó dẫn đến dễ hiểu, ngoài ra nó khá ổn định (một khi đã quyết định specs của sản phẩm thì hầu như sẽ không thay đổi nữa), chất lượng cao (ưu tiên cho chất lượng sản phẩm chứ không phải thời gian).

Thế nhưng cũng như cái tên thác nước vậy, nếu như công đoạn ở trên gặp lỗi thì toàn bộ công đoạn phía dưới sẽ gặp lỗi theo, tính linh hoạt là khá thấp, trước khi bắt tay vào công việc phải nghiên cứu thật kỹ các chú ý phát triển hay yêu cầu thiết kế …

Do vậy, Waterfall phù hợp với những dự án có yêu cầu đơn giảnrõ ràng ngay từ đầu.

Thế đối với những dự án phức tạp, đòi hỏi công nghệ cao hoặc yêu cầu không rõ ràng, đôi khi chỉ là một idea thì sao ? Đất dụng võ cho Agile đây rồi.

3. 4 Core Values và 12 Principles trong Agile

Nhắc đến Agile là nhắc đến 4 core values và 12 principles .

4 core values bao gồm:

  • Cá nhân và sự tương tác hơn là quy trình và công cụ
  • Phần mềm chạy tốt hơntài liệu đầy đủ
  • Cộng tác với khách hàng hơnđàm phán hợp đồng
  • Phản hồi với các thay đổi hơnbám sát kế hoạch


12 principles:

  1. Thỏa mãn yêu cầu của khách hàng thông qua việc giao hàng sớm và liên tục
  2. Giao phần mềm chạy được cho khách hàng một cách thường xuyên (giao hàng tuần hơn là hàng tháng)
  3. Chào đón việc thay đổi yêu cầu, thậm chí là những thay đổi yêu cầu muộn
  4. Nhà kinh doanh và kỹ sư lập trình phải làm việc cùng nhau hàng ngày trong suốt dự án
  5. Các dự án được xây dựng xung quanh những cá nhân có động lực. Cung cấp cho họ môi trường và sự hỗ trợ cần thiết, và tin tưởng họ để hoàn thành công việc
  6. Trao đổi trực tiếp mặt đối mặt là phương pháp hiệu quả nhất để truyền đạt thông tin
  7. Phần mềm chạy được là thước đo chính của tiến độ
  8. Phát triển bền vững và duy trì được nhịp độ phát triển liên tục
  9. Liên tục quan tâm đến kĩ thuật và thiết kế để cải tiến sự linh hoạt
  10. Sự đơn giản là cần thiết – nghệ thuật tối đa hóa lượng công việc chưa hoàn thành
  11. Nhóm tự tổ chức
  12. Thích ứng thường xuyên với sự thay đổi

4. Scrum – Framework của Agile

Như tiêu đề Scrum là một thành viên của họ Agile. Scrum được xây dựng dựa trên lý thuyết quản lý tiến trình thực nghiệm (empirical process control), hay còn gọi là thực nghiệm luận (empiricism). Lý thuyết này chỉ ra rằng tri thức đến từ kinh nghiệm và việc ra quyết định được dựa trên những gì đã biết. Điều này sẽ giúp giảm thiểu rủi ro và tăng tính chính xác đặc biệt là trong môi trường phát triển phần mềm nhiều biến động.

Nhắc đến Scrum là nhắc đến 3 giá trị cốt lõi 3 vai trò 4 cuộc họp ngoài ra còn một số từ khóa như User Story, Story Point, Product Backlog, Sprint (Iteration), Sprint Backlog, Definition of Done (Định nghĩa hoàn thành).

User Story: Đây là tóm tắt một chức năng của sản phẩm đứng từ góc nhìn của người dùng. User story thường được viết trong một hai câu ngắn gọn, đơn giản, ví dụ như:
– Là khách hàng mua sách, tôi có thể xem toàn bộ sách có trong cửa hàng
– Là quản lý, tôi có thể thay đổi số lượng sách trong kho.
Story Point: Là một đơn vị được dùng để đánh giá công sức phải bỏ ra để thực hiện một user story. Story point càng nhiều thì user story đó càng lớn và tốn nhiều thời gian thực hiện.
Product Backlog: Đây là danh sách những việc mà team cần phải làm để có thể hoàn thành sản phẩm. Mỗi việc này có thể là việc technical (tạo database, tích hợp API) hoặc là user stories.
Sprint (Iteration): Có thể hiểu là một chu kì làm việc kéo dài từ 1 đến 2 tuần. Trong một sprint, team thực hiện các quá trình như thiết kế, code, test để tạo ra sản phẩm vào cuối sprint.
Sprint Backlog: Ở đầu mỗi sprint, cả team sẽ có một cuộc họp để lựa chọn những user story quan trọng mà team phải hoàn thành trong sprint này. Những user story này sẽ được bỏ vào Sprint Backlog. Ví dụ ở sprint đầu, team cần một bản demo để người mua sách sử dụng, họ sẽ chọn những user story liên quan đến người mua để thêm vào backlog.
Definition of Done (Định nghĩa hoàn thành): Trước khi bắt đầu, cả nhóm phải thống nhất thế nào là “hoàn thành” một công việc. Hoàn thành có thể là user stories đó đã được code và test xong, hoặc module đó đã demo cho khách hàng và được khách hàng duyệt. Định nghĩa này tùy thuộc vào mỗi team.

Chúng ta cùng bắt đầu đi tìm hiểu từng chủ đề được nhắc đến trong Scrum nhé.

4.1 Ba giá trị cốt lỗi

Ba yếu tố nòng cốt tạo thành một mô hình quản lý tiến trình thực nghiệm gồm: sự minh bạch (transparency), thanh tra (inspection)thích nghi (adaptation).

Minh bạch: Các khía cạnh quan trọng của tiến trình phải được hiển thị rõ ràng cho những người có trách nhiệm với thành quả của tiến trình đó. Sự minh bạch yêu cầu các yếu tố này cần được định nghĩa theo một tiêu chuẩn để những người quan sát có thể hiểu những gì họ thấy theo cùng một cách.
Thanh tra: Người sử dụng Scrum phải thường xuyên thanh tra các tạo tác và tiến độ đến đích để phát hiện các bất thường không theo ý muốn. Tần suất thanh tra không nên quá dày để khỏi ảnh hưởng đến công việc. Công tác thanh tra có ích nhất khi được thực hiện bởi người có kĩ năng tại các điểm quan trọng của công việc.
Thích nghi: Nếu một người thanh tra xác định được rằng có vấn đề nào đó vượt quá giới hạn cho phép, và hậu quả của vấn đề đó đối với sản phẩm là không thể chấp nhận được, thì quy trình hoặc các vật liệu được xử lý (processed material) phải được điều chỉnh. Sự điều chỉnh phải được tiến hành càng sớm càng tốt để giảm thiểu các sai sót khác có thể xảy ra.Để đảm bảo việc triển khai Scrum mang lại lợi ích cao nhất thì bạn phải đảm bảo cả ba trụ cột trên trong một thể thống nhất. Thiếu một trong số đó sẽ gây ra hậu quả nghiệm trọng và dễ dẫn đến thất bại.

4.2 Ba vai trò

Scrum Master: Đây là người đảm bảo mọi người hiểu và thực hiện đúng qui trình Scrum. Họ cũng có trách nhiệm huấn luyện các thành viên trong nhóm về qui trình, tổ chức các cuộc họp.

Product Owner: Là người quản lý Product Backlog. Với Taka.vn, product owner là người quyết định những chức năng nào nên được thêm vào, những chức năng nào nên bị bỏ đi, giải thích từng chức năng cho các thành viên trong nhóm làm việc.

Development Team: Dựa theo các user story trong product backlog, team tạo ra sản phẩm. Trong team không chia ra các vị trí như team leader, tester,… mà tất cả đều là developer ngang hàng nhau. Cả team sẽ tự phân chia công việc, tự dự đoán thời gian hoàn thành (trong thực tế làm việc, mình thấy các nhóm Scrum vẫn có vị trí leader, hỗ trợ các thành viên chọn công việc và ước đoán).

4.3 Bốn cuộc họp

Trong qui trình Scrum, thành viên thường phải tham gia các cuộc họp sau:

Sprint Planning Meeting: Cuộc họp này được bắt đầu mỗi Sprint, kéo dài khoảng 2 tiếng. Cuộc họp giúp xác định mục tiêu cần đạt được trong Sprint và những công việc (user story) cần làm. Trong cuộc họp này, cả nhóm cũng ước đoán story point cho mỗi user story.

Daily Meeting: Xuyên suốt Sprint, mỗi ngày cả team sẽ bỏ ra khoảng 15 phút để tổ chức một cuộc họp ngắn. Việc họp này giúp các thành viên nắm được tình hình dự án. Trong cuộc họp, mỗi thành viên trả lời 3 câu hỏi:

Hôm qua tôi đã làm được gì?

Hôm nay tôi sẽ làm gì?

Tôi đang gặp trở ngại, vướng mắc gì?

Sprint Review Meeting: Cuộc họp này diễn ra sau khi kết thúc Sprint. Cả nhóm sẽ xem xét lại những việc đã hoàn thành, chưa hoàn thành, sau đó demo những phần đã hoàn thành cho Product Owner. Product Backlog sẽ được cập nhật lại.

Retrospective Meeting: Trong buổi họp này, cả nhóm cùng ngồi nhìn lại và đánh giá những điểm được và chưa được trong Sprint vừa qua, đồng thời đề xuất các biện pháp cải tiến.

 

5. Tổng kết

Agile là một phương phát phát triển phầm mềm rất tốt giúp cho iron ra có một vài nếp nhăn của qua trình waterfall truyền thống. Nhưng Agile không phải lá bài chủ chốt cho sự thành công của dự án. Đó là con người đồng nhất phải làm việc và thể hiện.Khi nó đến với con người, nó là thử thách phải đối mặt. Thế giới này (kể từ đây là con người) đầy những vấn đề và không hoàn hảo. Nhà khoa học cố gắng giúp xã hội bằng kỹ thuật sáng tạo. Đơn giản, nhà quản lý là một chuyên gia giúp con người thành công trong mục tiêu của doanh nghiệp hay mục tiêu nghề nghiệp mặc dù làm việc trong sự ép buộc. Không có phương pháp nào làm người quản lý dư thừa trừ khi được hành xử bởi những con người hoàn hảo. Một cách thức được thiết lập các chỉ dẫn. Khi có ở đó một cách thức chệch hướng, khi có con người , ở đó có vấn đề. Để quản lý con người và các vấn đề, để kiểm soát sự chệch hướng và thay đổi, mỗi dự án phải được phụ trách bởi chuyên gia quản lý. Đồng thời người quản lý cũng là con người. Họ thuộc về thế giới không hoàn hảo. Các quyết định quản lý nhất định cũng có thể thất bại. Các cổ đông phải chấp nhận điều đó.Trong môi trường nhất định, người quản lý cần có quyền hạn để áp dụng các phương sách trong sự hứng thú cao nhất của dự án. Các phương thức có thể bị các thành viên đội chống cự và dẫn đến việc để áp dụng nó, thỉnh thoảng HLV/ người tạo thuận lợi phải làm việc tốt và trong một số phạm vi, người quản lý có quyền hạn sẽ làm việc tốt.

Nguồn tham khảo: Viblo, Toidicodedao

About the author:

Top