Gặp gỡ team Magestore tại series 'Chân chất kể tất - Webinar #9: "Thu hút nhân tài thời 4.0 nhờ chiến lược Inbound Recruiting"
Đăng ký tham gia!

Agile Manifesto và Agile Principles

Agile là gì? Tuyên ngôn agile là gì? 12 Principle của agile hiểu như thế nào?
Nội dung chính

Trong môi trường kinh doanh mà mức độ cạnh tranh thì liên tục tăng và thời gian phát triển sản phẩm thì liên tục rút ngắn, nhiều doanh nghiệp đang áp dụng phương pháp Agile để nhanh chóng thích ứng với hoàn cảnh liên tục biến đổi. Nếu bạn quan tâm tới lĩnh vực công nghệ thông tin, có thể bạn đã nghe về Agile, Lean, Scrum, Kanban… 

Agile hứa hẹn là một mô hình đem lại nhiều lợi ích cho cả công ty phát triển phần mềm và người dùng. Tuy vậy, nhiều công ty đã gặp không ít vấn đề khi áp dụng mô hình này vào thực tiễn công ty họ. Vậy Agile là gì, có cần thiết không, và làm thế nào để trở nên Agile?

Agile là gì? 

Định nghĩa Agile

Agile là một triết lý thiết kế công việc linh hoạt nhằm thích ứng nhanh chóng với các thay đổi. Agile thể hiện qua:

  • Lập kế hoạch thích ứng (adaptive planning);
  • Phát triển lặp (iterative), gia tăng (incremental), và tiến hóa (evolutionary);
  • Chuyển giao sớm (early delivery); và
  • Không ngừng cải tiến (continual improvement). 

Agile nhấn mạnh việc xây dựng các nhóm làm việc tự quản (self-organization) và liên chức năng (cross-function). Agile chú trọng con người, sự hợp tác, và tạo dựng một môi trường làm việc tốt. Triết lý này cho rằng chính sự cộng tác giữa công ty và khách hàng/người dùng sẽ đưa ra được yêu cầu và giải pháp đúng đắn. 

Agile ảnh hưởng đến mọi hoạt động trong doanh nghiệp của bạn, từ cách các đồng nghiệp làm việc đến cách các lãnh đạo quản lý và xây dựng chiến lược. Ngày nay, Agile đã trở thành một triết lý phổ biến và có ảnh hưởng sâu rộng, được áp dụng trong nhiều lĩnh vực từ phát triển phần mềm đến marketing, sales, HR… nhằm nâng cao sức cạnh tranh và phát triển bền vững.

Lịch sử của Agile

Khi nói đến lịch sử Agile, nhiều người sẽ nghĩ rằng tư tưởng này bắt đầu từ cuộc gặp mặt của 17 chuyên gia phát triển phần mềm tại một khu trượt tuyết ở Utah vào 2001. 

Đúng là trong cuộc họp này họ đã quyết định chọn từ “agile” (linh hoạt) làm cái tên cho tư tưởng này. Tuy nhiên, cốt lõi của Agile - việc thích ứng với thay đổi - cùng với các công cụ làm tiền đề cho Agile đã được nghiên cứu từ thế kỉ trước đó. 

1950: 

W. Edwards Deming giới thiệu mô hình cải thiện chất lượng PDSA (Plan-Do-Study-Act) cho các công ty lớn tại Nhật Bản. Theo ông, cải thiện chất lượng là cải tiến liên tục và không ngừng nghỉ. Toyota đã thuê Deming đào tạo các nhà quản lý và phát triển hệ thống sản xuất nổi tiếng của họ, cũng chính là nền tảng cho Tư duy tinh gọn (Lean thinking). Từ những thập niên 80s, mô hình của Toyota đã được nhiều công ty khác nghiên cứu và áp dụng. 

1953

 Kanban: Toyota bắt đầu sử dụng các thẻ giấy để trực quan hóa quy trình sản xuất và cải tiến hiệu suất công việc.

1970: 

Winston W. Royce viết “Quản lý phát triển các hệ thống phần mềm lớn” (Managing the Development of Large Software Systems: Concepts and Techniques). Trong bài ông đã khái quát trình tự phát triển một phần mềm máy tính lớn đến tay người dùng. Đây chính là nền tảng của mô hình Waterfall (Thác nước). Ông cũng nói rằng mô hình này có thể được thay thế bởi mô hình lặp.

1986: 

Hirotaka Takeuchi và Ikujiro Nonaka viết “Trò chơi phát triển sản phẩm mới” (The New New Product Development Game) trên tạp chí Harvard Business Review. Thay vì để một nhóm hoàn thành công việc của mình và chuyển sang cho nhóm khác, bài báo đề cập đến việc tất cả các nhóm cùng tham gia vào công việc, ở các giai đoạn khác nhau của phát triển sản phẩm. Họ so sánh phần mềm với quả bóng bầu dục, được chuyền qua lại giữa các thành viên cho đến vạch cuối sân. Trong bài viết sử dụng từ Scrum, một thuật ngữ trong bóng bầu dục. 

1993: 

Dựa trên bài viết của Hirotaka và Ikujiro, Jeff Sutherland và Ken Schwaber bắt đầu phát triển khái niệm Scrum. Tuy nhiên, phải đến 1995 Scrum mới được Sutherland hệ thống hóa và giới thiệu tại một hội thảo tại Austin, Texas, Hoa Kỳ. 

1996: 

Kent Beck khởi xướng Lập trình cực độ (Extreme Programming - XP). Ông được mời tư vấn, và sau đó bổ nhiệm làm người đứng đầu một dự án thử nghiệm tại Chrysler (Chrysler Payroll Project). Mục tiêu của Beck là nâng cao chất lượng phần mềm bằng cách đưa các hoạt động lập trình lên mức cao nhất có thể. Kent Beck xuất bản sách Extreme Programming Explained vào năm 1999.

2001: 

Tuyên ngôn Agile (Manifesto for Agile Software Development - The Agile Manifesto). Vào tháng 2 năm 2001, 17 chuyên gia từ các phương pháp Extreme Programming, Scrum, DSDM, Adaptive Software Development… đã họp mặt tại khu nghỉ dưỡng trượt tuyết Snowbird, Utah, để chia sẻ các ý tưởng về phát triển phần mềm “gọn nhẹ” (Light). Tuy nhiên, cuối cùng họ chọn cái tên Agile để nói về cách thích nghi mới trong tình hình thị trường luôn biến đổi. Họ đã đưa ra Bản Tuyên ngôn Phát triển Phần Mềm Agile - thường gọi là Bản tuyên ngôn Agile. Bản Tuyên ngôn nhanh chóng lan rộng, và đến 2016 đã có hơn 20,000 người ký vào bản Tuyên ngôn. 

Cũng trong năm 2001, Kent Beck và Mike Beedle đã xuất bản cuốn “Phát triển phần mềm Agile với Scrum”, chỉ ra vai trò của triết lý Agile, phương pháp Scrum, và cách áp dụng chúng trong các doanh nghiệp. 

Hai tổ chức về Agile (Agile Alliance) và Scrum (Scrum Alliance) cũng được thành lập trong năm này. 

2003:

Tom và Mary Poppendieck xuất bản cuốn “Phát triển Phần mềm Tinh gọn: Công cụ Agile” (Lean Software Development: An Agile Toolkit). Dựa trên quá trình Sản xuất Tinh gọn (Lean Manufacturing), Poppendieck đã đưa ra bảy nguyên lý của sự Tinh gọn (Lean thinking) và cách áp dụng nguyên lý vào phát triển phần mềm tinh gọn (Lean Software Development). Trong những cuốn sách sau đó, họ cũng giới thiệu về cách áp dụng Kanban trong Agile.

Từ đó đến nay, Agile đã trở thành sự tổng hợp của nhiều tư tưởng và mô hình áp dụng và vẫn không ngừng phát triển.  

agile manifesto la gi

Tuyên ngôn Agile - Agile manifesto

Như bạn có thể thấy, Agile là một tập hợp nhiều tư tưởng và cách ứng dụng khác nhau. Tuy 17 nhà lập trình đến từ những trường phái khác nhau, họ chia sẻ nhiều giá trị liên quan đến sự tất yếu của thay đổi, sự cần thích ứng với môi trường, và vai trò của cá nhân cũng như môi trường làm việc. Bốn giá trị của triết lý Agile đã được đúc kết trong Bản Tuyên ngôn Agile, và sau đó các giá trị này được làm rõ thông qua 12 nguyên tắc hoạt động. 

Những người đi theo tuyên ngôn Agile đánh giá:

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

Agile đặt trọng tâm vào con người và sự cộng tác. Dự án của bạn, cho dù có quy trình và công cụ đúng và hiện đại nhất, cũng sẽ không thể thành công nếu thiếu đi những cá nhân chủ động và sẵn sàng hợp tác để đạt được mục tiêu.

Phần mềm chạy tốt hơn là tài liệu đầy đủ:

Đối với khách hàng thì điều quan trọng và có giá trị nhất là sản phẩm phần mềm giải quyết được vấn đề của họ. Tài liệu giúp cho họ có thể sử dụng phần mềm một cách dễ dàng và hiệu quả nhưng nếu chúng ta tạo ra một phần mềm không hữu ích thì tài liệu cũng không có ý nghĩa gì.

Đối với người làm sản phẩm, không phải mọi thứ chúng ta tạo ra đều có giá trị. Có những chức năng chúng ta tạo ra xuất phát từ việc không nghiên cứu yêu cầu khách hàng, không xuất phát từ vấn đề thực tế cần giải quyết thì chức năng đó dù có chạy tốt cũng vẫn là thứ không có giá trị.

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

Mỗi khách hàng có một nhu cầu khác nhau và có thể thay đổi theo thời gian. Nếu chúng ta chỉ quan tâm tới việc hợp đồng viết gì và miễn cưỡng làm theo, chúng ta chưa chắc đã tạo ra được sản phẩm khách hàng thật sự cần. Hãy cộng tác và tham vấn khách hàng, để họ được tham gia trong quá trình làm sản phẩm cho phù hợp với họ. 

Nói về giá trị của việc cộng tác mật thiết với khách hàng, anh Steve, CEO của Magestore cũng chia sẻ: “Sự cộng tác chặt chẽ với khách hàng có ý nghĩa vô cùng quan trọng trong quá trình làm phần mềm và là tác nhân quan trọng giúp cho dự án hoặc phần mềm thành công.

Cộng tác với khách hàng giúp chúng ta hiểu rõ mong muốn của họ hơn từ đó giúp tạo ra phần mềm có giá trị.

Cộng tác với khách hàng và bàn giao những gì ta làm được cho khách hàng sử dụng sớm sẽ giúp họ đưa ra những feedback để tránh được những hiểu lầm về yêu cầu sớm.”

Phản hồi dựa trên thay đổi hơn là bám theo kế hoạch: 

Dự án phần mềm là một loại dự án vô cùng phức tạp và khó thể lập một plan chi tiết ngay từ đầu, nhất là đối với các sản phẩm mới hoặc các công ty startup. Sự linh hoạt là đặc điểm quan trọng nhất tư duy Agile. Những người tham gia vào dự án luôn luôn phải hiệu chỉnh kế hoạch của mình để thích nghi với những thay đổi và điều kiện mới.

12 Agile principles và ví dụ thực tiễn áp dụng

Bốn giá trị này được làm rõ hơn thông qua 12 nguyên tắc hoạt động:

Agile principle 1. “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

Ưu tiên hàng đầu của chúng ta là sự hài lòng của khách hàng, thông qua việc chuyển giao sản phẩm có giá trị, nhanh chóng, và liên tục.

Nguyên tắc đầu tiên nhấn mạnh vào các cụm từ:

  •  Our - chúng ta ở đây hiểu là team, đội nhóm làm việc phục vụ khách hàng, là những người phát triển và chuyển giao sản phẩm tới khách hàng.
  • Early delivery - chuyển giao sớm: Hiểu rằng chúng ta cần chia sản phẩm lớn thành từng phần nhỏ, có thể bàn giao sớm cho khách hàng . Khi rút ngắn lại feedback loop - vòng lặp phản hồi, chúng ta có thể hiểu hơn khách hàng muốn gì và điều chỉnh theo yêu cầu của họ. Nguyên tắc này đặc biệt nhấn mạnh vào giá trị chúng ta chuyển giao cho khách hàng. Làm ngưng trệ hoạt động chuyển giao hoặc phát triển sản phẩm không mang lại giá trị gì cho khách hàng sẽ dẫn tới làm chậm việc tiếp nhận góp ý từ khách hàng, từ đó có thể dẫn đến chậm trễ cả sản phẩm tổng thể. 
  • Continuous delivery - chuyển giao liên tục. Hiểu là việc bàn giao thứ chúng ta làm được cần được diễn ra sớm, và thường xuyên, liên tục. Như vậy thì quá trình phản hồi qua lại giữa khách hàng với team cũng sẽ diễn ra liên tục vào mỗi lần bàn giao, chứ không bị gián đoạn.

Agile Principle 2: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

Chấp nhận thay đổi yêu cầu, cho dù là ở các giai đoạn cuối của quy trình. Quá trình Agile tận dụng thay đổi để đem lợi thế cạnh tranh tới cho khách hàng.

Ở đây ta cần chú ý đến các từ khóa để hiểu hơn về nguyên tắc này

  • Changing - thay đổi: Nguyên tắc này nhấn mạnh vào bản chất của agile là linh hoạt, thích ứng, đón nhận sự thay đổi yêu cầu từ khách hàng. Nó nhấn mạnh rằng yêu cầu chính là yếu tố động, luôn tiến hóa & phát triển để hình thành nên 1 sản phẩm dùng được trong thực tế cuộc sống. 
  • Late - muộn ở cuối quy trình: Hiểu rằng không thể tránh khỏi việc khách hàng đưa ra  thay đổi sai khác so với yêu cầu ban đầu. Để tránh được những thay đổi diễn ra ở cuối giai đoạn, cách tốt nhất là nên tương tác với khách hàng để thấu hiểu nhu cầu của họ, rồi phát hành các phần tăng trưởng sản phẩm nhỏ và sớm, liên tục. Sau đó đón nhận feedback, và yêu cầu tiếp tục cải tiến sản phẩm. 
  • Competitive advantage- lợi thế cạnh tranh: Bằng cách bàn giao sản phẩm phần mềm sớm, với tính năng đúng yêu cầu, giúp họ làm giảm chi phí,...đội phát triển có thể gia tăng sự cạnh tranh cho khách hàng của mình. 

Agile Principle 3. “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

Chuyển giao sản phẩm thường xuyên, trong vài tuần hoặc vài tháng, với mục tiêu trong thời gian càng ngắn càng tốt.

Để hiểu được nguyên tắc số 3, bạn cần chú trọng vào các cụm từ:

  • Working software - phần mềm có giá trị, chạy được.

Nguyên tắc này nhấn mạnh vào sự chuyển giao sản phẩm có giá trị và dùng được tới khách hàng. Để sản phẩm dùng được nghĩa là phải tuân theo các định nghĩa hoàn thành, điều kiện chấp nhận mà 2 bên đã thỏa thuận trong thời gian cộng tác. 

  • Shorter timescale - khung thời gian ngắn. Hiểu là chuyển giao sớm, rút ngắn khoảng cách giữa các lần chuyển giao. Điều này giúp giảm thiểu các tính năng thừa, tính năng rác, và giúp giữ vững lịch trình tiến tới phần mềm bàn giao. 

Ví dụ về việc chuyển giao sản phẩm tại Magestore, hiện tất cả các team không chỉ là các team tech, mà cả các team Sales, Marketing cũng thực hiện các Sprint 1 tuần, chuyển giao giá trị, sản phẩm tới khách hàng theo từng tuần. 

Thậm chí cả các em sinh viên thực tập ngành công nghệ thông tin, ngay khi mới vào Magestore, đã được rèn luyện thói quen chuyển giao sản phẩm thường xuyên, liên tục. 

Các em làm thực tập đồ án dưới sự hướng dẫn của các anh chị senior tại Magestore. Sản phẩm cuối cùng là 1 bài luận văn, đồ án. Nhưng hàng tuần, các em sẽ có những phần tăng trưởng sản phẩm (increment), chuyển giao tới team làm việc, tới các anh chị làm cùng hoặc toàn công ty. Đó có thể là 

  • Dàn ý đại cương cho nội dung
  • Dàn ý chi tiết
  • Nội dung phần lý thuyết các em đang tìm hiểu
  • Chi tiết áp dụng lý thuyết đó vào công việc của các em tại team
  • Các bài học các em rút ra trong quá trình vận dụng lý thuyết vào thực tế
mindset weekly delivery agile

Các nội dung, sản phẩm từng phần nhỏ như vậy sẽ giúp các em nhìn thấy được tiến bộ của bản thân. Đó cũng là các sản phẩm đóng góp vào 1 sản phẩm to cuối cùng, đó là luận văn/đồ án của các em. 

Như vậy tư duy Agile, cụ thể là chuyển giao sản phẩm liên tục sẽ giúp các em liên tục có sự học tập, phát triển, thậm chí nhiều ý tưởng cải tiến (từ chính các góp ý của các anh chị tại Magestore) để ra được sản phẩm cuối cùng mang lại giá trị cho chính các em và người hưởng lợi (doanh nghiệp, team làm việc).

mindset continuous delivery

Agile Principle 4: “Business people and developers must work together daily throughout the project.”

Người kinh doanh và các nhà kỹ sư phần mềm cần làm việc với nhau hàng ngày.

Hiểu về nguyên tắc thứ 4 của agile như thế nào?

- Business people - Hiểu là Product Owner hoặc bất cứ ai là người cầu nối giữa khách hàng và đội phát triển. 

- Must work together - Nhấn mạnh vào trách nhiệm chung được chia sẻ bởi cả business people và development team. 

Ở Magestore chúng mình đều ở trong các development team cross-functional. Các team này đều có người đứng ở view nhìn khách hàng là Product Owner, Business Analyst, Project Manager. Các thành viên này sẽ cộng tác sâu sát với các Developer để cùng nhau triển khai giải pháp cho khách hàng được thành công. Việc cộng tác mật thiết này thể hiện ở qua các cuộc họp hàng ngày Daily stand up meeting, các cuộc họp lên giải pháp, các tương tác 1-1 trực tiếp (gặp mặt hoặc call video) để làm rõ vấn đề. Việc nói chuyện và bày tỏ những khúc mắc với nhau hàng ngày giúp cho đội phát triển nhanh chóng bàn bạc, dùng trí tuệ tập thể để tìm ra phương án xử lý được các nút thắt cổ chai trong các dự án. 

Agile Principle 5. "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

Xây dựng dự án với những cá nhân có động lực. Tạo môi trường và hỗ trợ họ nếu cần, và đặt niềm tin vào họ để hoàn thành công việc được giao.

Nguyên tắc này nhấn mạnh vào motivated individuals - các cá nhân có động lực. Để có được các thành viên giàu động lực và tinh thần làm việc hăng hái thì cần tạo ra môi trường an toàn để họ chủ động cam kết và hành động, triển khai phương án họ nghĩ ra. Loại bỏ các rào cản ngáng chân họ đồng thời tin tưởng rằng họ sẽ hoàn thành công việc họ đã cam kết. 

Agile Principle 6. "The most efficient and effective method of conveying information to and within a development team is the face-to-face conversation."

Cách tối ưu và hiệu quả nhất để truyền đạt thông tin trong một nhóm phát triển là trực tiếp nói chuyện. 

Nguyên tắc này nhấn mạnh vào sự hiệu quả của các phương thức giao tiếp truyền đat. Nói chuyện trực tiếp là tốt hơn cả. Nếu không gặp mặt được trực tiếp thì dùng video call. Tham gia vào các cuộc họp daily meeting hàng ngày, Sprint Planning, Review, Retrospective. 

Ưu tiên các cách trực diện sẽ giúp team bạn không bị mất thời gian trong việc giao tiếp và trao đổi thông tin. 

tuong tac trong agile

Agile Principle 7. "Working software is the primary measure of progress."

Sản phẩm cuối cùng chạy tốt chính là thước đo tiến độ.

Các sản phẩm dùng được, mang lại giá trị cho khách hàng chính là thước đo cho sự tiến bộ của đội phát triển trong doanh nghiệp. Kết quả theo sau một sản phẩm tốt là sự hài lòng của khách hàng và nguồn doanh thu từ sản phẩm làm ra. 

Agile Principle 8. "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely."

Các quá trình Agile thúc đẩy sự phát triển bền vững. Người tài trợ, phát triển, và người dùng có thể duy trì nhịp độ ổn định và không ngừng. 

Để hiểu về nguyên tắc thứ 8, cần chú ý đến cụm từ sustainable development - sự phát triển bền vững và constant pace - nhịp độ ổn định. Các đội phát triển cần giữ vững nhịp độ chuyển giao sản phẩm theo các phân đoạn (iteration - Sprint), giữ vững các nhịp độ làm việc, các sự kiện trong team như daily meeting, Sprint Planning, Review, và Retrospective. 

Suy ngẫm về nguyên tắc thứ 8 của Agile, đã có lần anh Steve, CEO của Magestore chia sẻ về chủ đề thế nào là chuyển giao giá trị một cách đều đặn và bền vững?

Mỗi một team chọn một khoảng thời gian nhất định: 1 tuần, 2 tuần, 3 tuần hoặc 4 tuần để coi là độ dài của Sprint. Cứ sau mỗi khoảng thời gian đó, team sẽ bàn giao kết quả công việc của mình cho khách hàng. Kết quả này cần phải có đạt được các nguyên tắc sau:

  • Có giá trị với khách hàng
  • Khách hàng có thể sử dụng được để giải quyết một vấn đề nào đó của họ.
  • Tương đối độc lập so với các phần khác (nhất là những thứ chưa làm), để không bị phụ thuộc và chờ đợi vào những thứ chưa được hoàn thành.

Cần làm gì để có thể chuyển giao một cách đều đặn?

Chuyển giao sản phẩm/giá trị công việc một cách đều đặn đòi hỏi người thực hiện cần có các kỹ năng sau:

  • Cần có mindset và niềm tin rằng có thể làm được điều đó (mặc dù luôn có một khả năng hoặc một lý do nào đó để nói rằng nó là không thể)
  • Kỹ năng phân chia công việc thành những phần hợp lý.
    Đây là khâu khó nhất và đòi hỏi người thực hiện cần phải rất hiểu công việc để có thể chia tách các khối công việc lớn thành những phần nhỏ hơn, tương đối độc lập với nhau và có thể deliver được trong một Sprint.
  • Sắp xếp các công việc đã bẻ nhỏ theo thứ tự từ quan trọng nhất đến ít quan trọng hơn.
    Cần biết được điều gì là quan trọng với khách hàng và công ty để sắp xếp thứ tự ưu tiên.
  • Lựa chọn những công việc quan trọng nhất để team thực hiện trong Sprint tiếp theo.
    Cần lựa chọn những công việc để đưa vào Sprint tiếp theo một cách hợp lý theo nguyên tắc:
    -> Lựa chọn những việc nhất định phải hoàn thành Must Have trước tiên. Khối lượng những công việc Must Have này không được chiếm toàn bộ thời gian của sprint. Thường chỉ nên để tối đa 60% những việc loại này. Nếu không hoàn thành hết được toàn bộ việc trong phần này thì coi như Sprint fail.
    -> Lựa chọn thêm những việc tiếp theo mình mong muốn có thể làm được: Should Have.
    Những việc này chiếm 40% thời lượng của Sprint.
    –>Lựa chọn những việc dự phòng để nếu may mắn mà chúng ta hoàn thành được hết các công việc ở trên thì team sẽ lấy để làm: Could Have.
    Loại này cũng nên chiếm từ 30% đến 40% tổng thời gian của Sprint.

Agile Principle 9. "Continuous attention to technical excellence and good design enhances agility."

Sự để ý đến chất lượng kỹ thuật và thiết kế tốt sẽ tăng tính linh hoạt.

Cần chú ý vào cụm từ technical excellence - chất lượng kỹ thuật và good design- thiết kế tốt. Nhiều doanh nghiệp thường ưu tiên tốc độ đưa ra thị trường hơn là một thiết kế tốt.

Có thể người dùng cuối của bạn không quan tâm đến vấn đề kỹ thuật ngay từ đầu nhưng nếu team của bạn lờ đi việc thiết kế cấu trúc kỹ thuật quá lâu thì tốc độ ra thị trường của bạn cũng sẽ chậm lại. Khả năng thay đổi sản phẩm so với tốc độ thay đổi của thị trường sẽ giảm dần. Bạn sẽ mất đi tính linh hoạt. 

Trên thực tế, nhiều quản lý và developers không chú trọng nguyên tắc này. Trong các dự án nhỏ thì không cần phải quan tâm nhiều đến thiết kế, vì bạn muốn đi nhanh. Nhưng nếu các dự án to thì cần chú trọng đến chất lượng kỹ thuật. 

Agile Principle 10. "Simplicity — the art of maximizing the amount of work not done — is essential."

Sự đơn giản - nghệ thuật sắp xếp tối đa hóa lượng công việc chưa hoàn thành - là cần thiết. 

Sự đơn giản, bắt đầu không phải là phát hiện lượng việc quan trọng để làm mà lại là ở chỗ phát hiện các công việc không quan trọng, nhằm loại bỏ chúng đi. 

Tiếp tục là chia sẻ từ anh Steve về nguyên tắc thứ 10 về nghệ thuật của sự đơn giản hóa:

“Tại tối đa khối lượng những việc chưa hoàn thành lại là điều cần thiết?

Có phải là nguyên tắc này khuyên bạn làm ít đi hay không?

Nếu đúng thì tại sao làm ít đi lại là một điều quan trọng?

Để trả lời được những câu hỏi này thì bạn cần nhớ lại một triết lý rất cốt lõi của tư tưởng Agile là mọi việc mà bạn làm thì cần phải deliver giá trị cho khách hàng. Nếu một việc mà không deliver được giá trị cho khách hàng thì đó là một việc cần xem xét có nên làm hay không.

Ngoài ra Agile cũng nhấn mạnh đến tầm quan trọng của sự đơn giản hóa từ việc lập kế hoạch, các quy trình tổ chức thực hiện đến bản thân sản phẩm. Tất cả đều phải thực sự đơn giản, dễ hiểu và có giá trị đối với người sử dụng.

Quay trở lại nguyên tắc số 10 này, nếu bạn biết cách lựa chọn những điều quan trọng để làm, biết cách từ chối làm nhưng điều không đem lại giá trị. Thì quá trình đó chẳng phải là quá trình làm cho khối lượng những việc chưa hoàn thành hoặc chưa làm tăng lên hay sao?

Cụ thể hơn, để thực hành nguyên tắc này, bạn có thể:

  • Chia nhỏ các buổi họp thành các buổi họp ngắn hơn và tập trung hơn. Tạo ra nhiều buổi họp nhỏ và thường xuyên trong các sprint.
  • Tăng sự phối hợp giữa các thành viên trong team để giữ cho sản phẩm được đơn giản được coi là mối quan tâm chính của chúng ta.
  • Làm mịn backlog liên tục để có thể loại bỏ đi những việc không quan trọng một cách kịp thời.
  • Review các User Story với mong muốn làm cho chức năng mà nó thực hiện sẽ đơn giản hết sức có thể mà vẫn giải quyết được vấn đề của khách hàng.
  • Tạo ra danh sách “Work not done” để có thể review trong các buổi retrospective.
  • Giảm thiểu việc multi-tasking và chuyển đổi giữa các task một cách thường xuyên để giảm thiểu sự gián đoạn và mất tập trung.
  • Hãy hỏi thường xuyên một câu hỏi khi mà chúng ta quyết định làm một việc gì đó: chúng ta có đem lại giá trị khi làm việc này không?

Agile Principle 11. "The best architectures, requirements, and designs emerge from self-organizing teams."

Các cấu trúc, yêu cầu, và thiết kế tốt nhất đều xuất phát từ những nhóm có khả năng tự tổ chức.

Để hiểu được nguyên tắc này cần chú trọng đến cụm self-organizing team - team tự chủ, tự tổ chức. 

Các team này sẽ hoạt động theo hình thức tự sắp xếp, lên kế hoạch triển khai công việc, được tự lựa chọn cách để giải quyết các bài toán được đưa ra bởi khách hàng. Chính các cá nhân giàu động lực trong một team làm việc tự chủ chính là những người có thể định nghĩa và chuyển giao được cấu trúc, yêu cầu và thiết kế tốt nhất tới khách hàng. 

Agile Principle 12. "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

Đều đặn nhìn lại, phản tư, reflect để có thể tăng hiệu quả, và thay đổi hành vi cho phù hợp.

Ứng dụng các hoạt động như Retrospective, các hoạt động self-reflection vào trong công việc của cá nhân và đội nhóm, sẽ giúp team nhanh chóng tìm ra các điểm có thể sửa chữa, cải tiến. 

Từ đó thay đổi hành động của mình trong các Sprint tiếp theo. 

scrum la gi
Scrum - 1 framework trong agile

7 đặc điểm của phương pháp Agile

1. Tính module và lặp lại (modularity & iterative)

 Trong Agile, quy trình phát triển sản phẩm được chia thành nhiều phân đoạn. Các phân đoạn trên tập trung vào giải quyết một yêu cầu duy nhất và lặp đi lặp lại. Các nhóm sẽ lên kế hoạch, phân tích yêu cầu, thiết kế, triển khai, và kiểm thử để cho ra các phần nhỏ của sản phẩm cuối cùng.

2. Gia tăng và tiến hóa (incremental and revolutionary): 

Mỗi phần nhỏ của sản phẩm được phát triển song song, tại những thời điểm cũng như tiến độ khác nhau. Mỗi phần nhỏ được kiểm thử độc lập và được tích hợp vào sản phẩm khi chúng chạy tốt. Các phần nhỏ sẽ được tích lũy dần dần cho đến khi đáp ứng được nhu cầu của khách hàng. Điều này giúp bạn dễ dàng theo dõi tiến độ phát triển sản phẩm, và giúp sản phẩm không ngừng tiến hóa cho phù hợp với điều khách hàng cần. 

3. Thích ứng (adaptive): 

Trong quá trình thực hiện chúng ta có thể gặp thay đổi trong yêu cầu, công nghệ, nhân sự… Quy trình Agile có thể thay đổi để đáp ứng các điều kiện mới. Chúng ta có thể thêm các bước trong một phân đoạn, hoặc thêm các yêu cầu của khách hàng vào phân đoạn sau để xử lý. 

4. Nhóm tự tổ chức và liên chức năng (self-organizing & cross-function team): 

Agile đặt con người lên trên công cụ và quy trình. Khác với cơ chế mệnh lệnh và kiểm soát thường gặp, các nhóm làm việc trong một tổ chức Agile chủ động đưa ra quyết định và giải quyết vấn đề mà không cần chờ lệnh từ cấp quản lý. Họ chủ động nhận các đầu việc theo phân công công việc, chứ không chỉ dựa trên chức vụ hay phân cấp trong tổ chức. Các nhóm này được trao quyền để tự ra quyết định và tổ chức công việc để đạt được hiệu quả cao nhất.

5. Quy trình thực nghiệm (empirical process): 

Trong một tổ chức Agile, bạn đưa ra quyết định dựa trên các số liệu thực tiễn thay vì lý thuyết và các giả định. Quản lý đánh giá các phân đoạn dựa trên bằng chứng sẽ giúp bạn có được phản hồi kịp thời, xác định các yếu tố đang hoạt động hiệu quả, và đưa ra phương hướng tiếp theo một cách nhanh chóng.

6. Giao tiếp trực diện (face-to-face communication): 

Agile nhấn mạnh tầm quan trọng của làm việc nhóm và cộng tác. Giữa công ty và khách hàng, thay vì sử dụng giấy tờ, Agile khuyến khích công ty nói chuyện trực diện với khách hàng để hiểu đúng yêu cầu của họ. Trong nội bộ công ty, Agile khuyến khích các thành viên trong nhóm trực tiếp trao đổi với nhau để đưa ra kế hoạch triển khai. Để thực hiện được điều này, các tổ chức Agile thường xây dựng các nhóm nhỏ (không quá 12 người) và có các cuộc họp tập trung hàng ngày. 

7. Phát triển dựa trên giá trị (value-based development): 

Kết quả cuối cùng của phát triển phần mềm là một chương trình chạy tốt và mang lại giá trị cho khách hàng. Cách tốt nhất để tạo ra giá trị là thường xuyên trao đổi với khách hàng. Điều này sẽ giúp bạn xác định được các yêu cầu, cũng như tầm quan trọng của các yêu cầu này với khách hàng. Thông qua việc đánh giá độ ưu tiên, bạn có thể loại bỏ các phần thừa không đem lại giá trị cho sản phẩm và chuyển giao sản phẩm nhanh chóng, thường xuyên hơn. 

Tại sao cần Agile? 

Cuộc sống ngày nay thật bấp bênh và tương lai thì vô cùng mờ mịt. Hãy hình dung vụ thiên thạch va chạm trái đất cách đây 65 triệu năm đã chấm dứt sự thống trị của những con khủng long to xác nặng nề, chỉ những loài nhỏ bé như kiến mới có khả năng thích ứng cao và linh hoạt để có thể tồn tại và tiếp tục phát triển với số lượng lớn đến tận ngày nay.Mặc dù nhìn chung thế giới đang hòa bình và ổn định chính trị, nhưng sự phát triển nhanh chóng về công nghệ khiến cho môi trường kinh doanh sớm bị thay đổi. Điều này làm một doanh nghiệp dễ dàng lâm vào khủng hoảng hơn bao giờ hếMặc dù nhìn chung thế giới đang hòa bình và ổn định chính trị, nhưng sự phát triển nhanh chóng về công nghệ khiến cho môi trường kinh doanh sớm bị thay đổi. Điều này làm một doanh nghiệp dễ dàng lâm vào khủng hoảng hơn bao giờ hếtNgành phát triển phần mềm vốn không có rào cản cạnh tranh, mỗi năm có hàng triệu công ty ra đời trên thế giới và cũng chừng đó công ty phá sản. Các thị trường béo bở cũng nhanh chóng bị xâu xé hoặc bị biến đổi, giống như cơn bão Smartphone tràn qua đã nhấn chìm hãng Nokia chỉ trong vòng ba năm.

vi sao can agile


Mặc dù nhìn chung thế giới đang hòa bình và ổn định chính trị, nhưng sự phát triển nhanh chóng về công nghệ khiến cho môi trường kinh doanh sớm bị thay đổi. Điều này làm một doanh nghiệp dễ dàng lâm vào khủng hoảng hơn bao giờ hết.

Ngành phát triển phần mềm vốn không có rào cản cạnh tranh, mỗi năm có hàng triệu công ty ra đời trên thế giới và cũng chừng đó công ty phá sản. Các thị trường béo bở cũng nhanh chóng bị xâu xé hoặc bị biến đổi, giống như cơn bão Smartphone tràn qua đã nhấn chìm hãng Nokia chỉ trong vòng ba năm.

Trong hoàn cảnh đó, các khách hàng sử dụng phần mềm, đặc biệt là phần mềm dành cho doanh nghiệp; bản thân họ cũng là một doanh nghiệp, họ cũng đòi hỏi sự linh hoạt và tinh gọn để có thể tồn tại và phát triển trong thế giới kinh doanh khắc nghiệt. Càng ngày, họ đòi hỏi thời gian triển khai sử dụng một phần mềm phải càng ngắn. Không chỉ như vậy, sản phẩm phải phù hợp với mong muốn mục đích của họ, cũng như đáp ứng với sự thay đổi kinh doanh thường xuyên của họ. Đây là thách thức lớn đối với các cách tiếp cận truyền thống khi một phần mềm phải triển khai tính theo năm và chỉ đáp ứng nửa vời yêu cầu của khách hàng. Cộng thêm vào đó là tư tưởng coi khách hàng là một chiến tuyến đối nghịch khi xử lý các thay đổi yêu cầu liên tục diễn ra trong quá trình làm phần mềm.

Với mục đích nhắm đến sự linh hoạt và tinh gọn, Agile tỏ ra là một cách tiếp cận phù hợp để giải quyết vấn đề nan giải trên bằng cách khuyến khích việc cộng tác chặt chẽ với khách hàng, bàn giao sớm và thường xuyên các gói phần mềm dùng được luôn đến khách hàng. Bên cạnh đó, Agile cũng khuyến khích thấu hiểu rằng việc thay đổi yêu cầu của khách hàng là cần thiết và phải được tôn trọng và đáp ứng.

Ngoài ra về mặt quản trị nội bộ, Agile yêu cầu sự tự chủ của nhân viên trong hành động và xử lý tình huống vốn biến động không ngừng hàng ngày. Bằng cách đó Agile tháo gỡ lãnh đạo khỏi sự quan tâm và ràng buộc quá chi tiết vào công việc của nhân viên, để họ tập trung vào công việc làm chiến lược và đường lối, mục tiêu.

Và hơn tất cả, Agile khuyến khích niềm tin giữa các đồng đội trong công ty, đề cao sự tin tưởng qua lại giữa lãnh đạo và nhân viên, từ đó tạo ra sự gắn kết toàn công ty hướng tới một mục tiêu chung.

Về chung một nhà với Magestore

More Articles