---

Xem thêm một số bài viết liên quan:

• Microsoft Access là gì? Cách sử dụng Microsoft Access đơn giản
• eSIM là gì? Những điều cần biết về eSIM trước khi quyết định sử dụng
• Hub là gì? Một số thông tin cơ bản cần biết khi sử dụng Hub

---

 

Mô hình Agile là gì?

 

Agile Software Development - gọi tắt là Agile đã trở nên rất phổ biến trong ngành phát triển phần mềm.

Với ý tưởng khắc phục nhược điểm của các phương pháp phát triển phần mềm truyền thống, với mục tiêu mang đến cho phần mềm khả năng biến đổi, phát triển linh hoạt theo từng giai đoạn, phương pháp Agile đã ra đời góp phần tạo ra một phần mềm thật đơn giản đáp ứng đúng yêu cầu của khách hàng hôm nay và sẵn sàng cho những thay đổi vào ngày mai. Hiểu một cách đơn giản Agile là cách thức làm phần mềm linh hoạt để làm sao đưa sản phẩm đến tay người dùng càng nhanh càng tốt càng sớm càng tốt.

 

 

4 tôn chỉ của mô hình Agile

 

Agile hoạt động dựa trên những tôn chỉ sau:

 

Cá nhân và sự tương hỗ quan trọng hơn quy trình và công cụ

 

Trong Agile, không phải lúc nào cũng có giải pháp cho mọi vấn đề và để tìm ra được giải pháp thì không chỉ dựa vào lý thuyết mà phải trải qua thực tiễn. Tất nhiên sẽ không thể có một phần mềm tốt nếu không có quy trình và công cụ tốt nhưng Agile luôn đề cao vai trò của từng cá nhân và mối quan hệ giữa các cá nhân trong đội ngũ phát triển phần mềm. Nếu dự án có những thành viên có năng lực, luôn sẵn sàng chia sẻ kiến thức, hỗ trợ lẫn nhau trong công việc thì sẽ mang đến thành công.

Nếu dự án của bạn có quy trình làm việc tốt, được hỗ trợ những công cụ tốt nhất nhưng những thành viên không “cùng nhìn về một hướng” thì khả năng dự án thất bại là rất lớn. Nói điều này không có nghĩa là phủ nhận tầm quan trọng của quy trình và công cụ nhưng trong Agile nó được đặt sau yếu tố con người.

 

Phần mềm sử dụng được quan trọng hơn tài liệu về sản phẩm

 

Trong một số quy trình phát triển phần mềm, việc tạo và cập nhật các tài liệu về sản phẩm là bắt buộc. Nhóm phát triển không thể hoặc không đồng ý tiến hành công việc nếu không có tài liệu đặc tả về yêu cầu, thiết kế hệ thống. Nhóm kiểm thử thì yêu cầu tài liệu về sản phẩm để có thể viết trường hợp kiểm thử và kiểm thử được. Nhóm kiểm soát quy trình thì đòi tất cả các tài liệu phải được viết trước khi sản phẩm được giao cho khách hàng nếu không thì không đủ điều kiện, tiêu chuẩn để giao sản phẩm cho khách hàng.

Thực ra đứng với góc độ khách hàng thì khách hàng chỉ quan tâm đến sản phẩm có hoạt động được và tốt hay không. Trong khi việc tạo và cập nhật tài liệu mất nhiều thời gian và được cho là buồn tẻ. Vậy tại sao mình phải tập trung quá nhiều cho việc không cần thiết mà không dành thời gian đó để trao đổi để hiểu thêm về công việc phải làm. Mọi người đừng hiểu lầm là làm Agile là không viết tài liệu. Ý tưởng là chỉ viết những gì mà mọi người cần đọc.

 

 

Cộng tác với khách hàng quan trọng hơn đàm phán hợp đồng

 

Vẫn dựa trên tiêu chí "Khách hàng là thượng đế" nhưng khách hàng có rất nhiều loại, có khách hàng am hiểu về công nghệ, có người không, có người suy nghĩ nhất quán có người thay đổi xoành xoạch, chính vì vậy mà Agile luôn luôn chú trọng việc cộng tác thường xuyên chặt chẽ với khách hàng để hiểu được khách hàng muốn gì và cần gì để có thể tư vấn và điều chỉnh thay vì chỉ dựa vào những điều đã quy định trong hợp đồng.

 

Phản hồi với sự thay đổi quan trọng hơn bám theo kế hoạch

 

Có một điểm chung mà mình thấy trong hầu hết những dự án mình đã trải qua đó là không có dự án nào không có sự thay đổi điều chỉnh khi thực thi. Sự thay đổi đó có thể là thay đổi về yêu cầu, thay đổi công nghệ, thay đổi nhân sự, thay đổi deadline, thay đổi phương thức làm việc, v.v mặc dù kế hoạch đã được định ra rõ ràng từ đầu. Agile không khuyến khích cho sự thay đổi nhưng khuyến khích chúng ta tập thích nghi với thay đổi. Bạn hãy chuẩn bị tinh thần để thay đổi khi tham gia vào dự án Agile nhé.

Có một điều thú vị là đa số trong chúng ta đều cơ bản đồng ý với 4 tuyên ngôn của Agile. Nhiều người hiểu tầm quan trọng của “cá nhân” hay “cá nhân là tài sản quý giá nhất công ty” nhưng sẳn sàng thay đổi nhân lực để tương thích với quy trình/công cụ hiện có. Nhiều người hiểu “khách hàng là thượng đế” và “phải thích nghi với sự thay đổi” nhưng sẵn sàng tuyên bố “Dẹp, không làm nữa” vì khách hàng thay đổi yêu cầu liên tục. Hay như “sản phẩm xài được là quan trọng “ nhưng vẫn cố gắng viết thêm tài liệu với ý nghĩ rằng “biết đâu/lỡ sau này có ai cần thì có cái mà cung cấp”.

4 tuyên ngôn của Agile nói dễ hơn làm nhưng khi bạn theo Agile thì bạn hãy chuẩn bị tinh thần để “làm” chứ không phải để “nói”.

 

6 nguyên tắc của mô hình Agile

 

Nguyên tắc 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.

 

 

Nguyê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)

Mục đích của dự án phát triển phần mềm là phát triển phần mềm và làm khách hàng hài lòng và không có gì làm khách hàng hài lòng hơn việc cho khách hàng thấy được sản phẩm của mình thường xuyên và chạy được. Trong Agile, sản phẩm sẽ được demo cho khách hàng thường xuyên (thường là hàng tuần) để cho khách hàng thấy được sản phẩm của mình như thế nào. Nếu có chỗ nào không ổn hay cần cải tiến thì sẽ phản hồi với đội dự án ngay lập tức.

 

Nguyên tắc 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

Dù bạn thích hay không thì việc thay đổi yêu cầu từ khách hàng là dường như không thể tránh khỏi và nhiệm vụ của bạn là phải thích ứng với sự thay đổi đó. Thích ứng không có nghĩa là khách hàng yêu cầu gì mình làm cái đó. Khi khách hàng thay đổi yêu cầu, chắc chắn phải có lý do của họ và nhiệm vụ của đội dự án là phải hiểu được lí do đó để có thể điều chỉnh sự thay đổi, tư vấn hay đề nghị giải pháp cho khách hàng tương ứng.

 

 

Nguyên tắc 4

 

Khách hàng của dự án và đội phát triển phải làm việc cùng nhau hàng ngày trong suốt dự án

Đội phát triển phải làm việc thường xuyên và gần gũi với khách hàng để hiểu được nhu cầu của họ cũng như cho phép khách hàng hiểu về công việc của đội phát triển. Đó là một trong những lí do mà Agile dường như khó triển khai trong các dự án offshore trong đó rào cản về địa lý, thời gian, ngôn ngữ là một trở ngại lớn.

 

Nguyên tắc 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

Như đã chia sẻ ở trên, Agile đặt trọng tâm là con người. Con người ở đây chỉ những cá nhân có động lực làm việc với tinh thần cộng tác, chia sẻ và giúp đỡ lẫn nhau. Song song đó, đội dự án sẽ được hỗ trợ những công cụ, môi trường, sự tin tưởng và những đãi ngộ cần thiết để hoàn thành công việc.

 

Nguyên tắ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

• Phần mềm chạy được là thước đo chính của tiến độ
• Phát triển bền vững và duy trì được nhịp độ phát triển liên tục
• Liên tục quan tâm đến kĩ thuật và thiết kế để cải tiến sự linh hoạt
• 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
• Nhóm tự tổ chức
• Thích ứng thường xuyên với sự thay đổi

 

Quy trình thực hiện của mô hình Agile

 

Agile phát triển dựa trên quy trình phát triển lặp. Mỗi dự án được chia thành nhiều giai đoạn nhỏ dễ dàng đáp ứng khi có yêu cầu thay đổi từ khách hàng.

Sản phẩm được bàn giao cho khách hàng theo từng giai đoạn, cứ mỗi khi một mảng nhỏ được bàn giao, khách hàng có thể đưa ra các thay đổi hoặc yêu cầu mới cho dự án và nhóm phát triển sẽ cập nhật sản phẩm theo đúng yêu cầu của khách hàng mà không cần làm lại từ đầu.

 

 

Quy trình của từng giai đoạn sẽ như sau:

 

Lập kế hoạch

 

Kế hoạch tổng thể của dự án được vạch ra trong những tuần đầu tiên. Khách hàng và đội dự án sẽ cùng nhau bàn bạc để chia dự án thành các giai đoạn phát triển nhỏ, ước lượng thời gian, công sức và lịch phát triển cho từng giai đoạn phát triển nhỏ đó.

Mỗi một giai đoạn phát triển nhỏ có một kế hoạch cụ thể được vạch ra vào đầu mỗi giai đoạn.

Đội dự án sẽ họp mặt hàng ngày để cập nhật tình hình công việc.

 

Phân tích

 

Việc phân tích yêu cầu không cố định vào một khoảng thời gian nào mà nó diễn ra trong suốt thời gian phát triển dự án. Đại diện phía khách hàng và đội dự án sẽ làm việc chung với nhau, cùng nhau trao đổi để đưa ra cách làm tốt nhất trước khi bàn giao cho đội phát triển

 

Thiết kế và lập trình

 

Thiết kế của sản phẩm được cải tiến liên tục. Mã nguồn được coi là sở hữu tập thể. Mọi thành viên được yêu cầu sửa lỗi bất kể lỗi đó là do ai gây ra.

 

Kiểm thử

 

Tất cả các thành viên trong dự án đều có trách nhiệm đảm bảo chất lượng của sản phẩm. Khi có lỗi, cả đội cùng nhau phân tích nguyên nhân và cùng nhau xử lý.

 

Bàn giao sản phẩm

 

Phần mềm sẽ được demo hàng tuần và đưa cho khách hàng xem xét, góp ý kiến.

 

Ban biên tập 1BOSS

 

 

1BOSS cung cấp gói các giải pháp toàn diện kết hợp bởi sự hiểu biết tinh thông trong quản lý và điều hành. Kết hợp cùng kinh nghiệm triển khai và ứng dụng từ những best practice từ các doanh nghiệp đầu ngành. Với công nghệ hiện đại, giao diện thân thiện, kích hoạt và dùng ngay với chi phí vô cùng hợp lý. Được nghiên cứu và thiết kế và tham vấn chuyên sâu, ứng dụng các khoa học, nghệ thuật hiện đại. 

Giải pháp quản lý doanh nghiệp 4.0 của 1BOSS gồm có:  

• 1BOSS SUPERAPPS Siêu ứng dụng quản lý doanh nghiệp​ 
  • Văn phòng điện tử 
  • ​Quản lý quan hệ khách hàng
  • Quản lý đơn hàng 
  • Quản lý kho 
  • Quản trị nhân sự 
• 1BOSS OFFICE+ Văn phòng điện tử
  • ​Mạng xã hội nội bộ doanh nghiệp
  • Văn phòng thông minh 
  • Tài nguyên chia sẻ
  • Quản lý công việc
  • Quản lý dự án
  • Siêu ứng dụng văn phòng điện tử
• 1BOSS CRM+ Quan hệ khách hàng
  • ​Marketing tự động
  • Quan hệ khách hàng
  • Chăm sóc khách hàng
  • Siêu ứng dụng quản lý quan hệ khách hàng
• 1BOSS OP+ Quản lý đơn hàng 
  • Quản lý đơn hàng bán
  • Quản lý đơn hàng mua
  • Siêu ứng dụng quản lý đơn hàng
• 1BOSS WH+ Quản lý kho 
  • Quản lý kho thông minh
  • Siêu ứng dụng quản lý kho