I. The Agile Manifesto key values
1. Individuals and interactions
- Agile khuyến khích sự communication giữa team members, development team và customer. Thay vì mô hình traditional sẽ tập trung vào process.
- Trong Agile thì trọng tâm sẽ là những team member và abilities (khả năng) của họ. Sự tin tưởng tuyệt đối vào team sẽ nâng cao khả năng tương tác giữa mọi người trong team. Tester trong team Agile là 1 phần không thể thiếu đối với development team và nhờ làm việc thống nhất với nhau mà các delivery target của sản phẩm được đáp ứng.
- Các too đắt tiền hay giàu tính năng thì không phải là chìa khóa thành công và thay vào đó chỉ cẩn những tấm bảng hay sticky notes có hiệu quả đáng kể. Mục đích chính là team communication với nhau và đưa ra sản phẩm tốt nhất
2. Working software
- Một trong điểm trọng tâm của mô hình traditional là tập trung vào detailed document. Ngược lại, đối với Agile thì document "just enought" vừa đủ là được, thay vào đó nên tạo ra sản phẩm hoạt động sớm và thường xuyên. Agile luôn tự hào về việc cung cấp thường xuyên các tính năng mong muốn cho khách hàng
- Thay vì nhóm Agile dành thời gian cho việc detailed document, design document, test plan... thì sẽ tạo ra giải pháp mà KH mong muốn. Trong team việc vào là ra tài liệu với 1 challenge lớn là tài liệu được cập nhập liên tục đặc biệt khi các yêu cầu của KH liên tục thay đổi hoặc có dự không chắc chắn sản phẩm cuối sẽ như thế nào. Thì team tập trung để tạo ra tài liệu "just enought".
- Bằng cách chuyển trọng tâm từ việc tạo ra detail document sang tạo ra sản phẩm thì đòi hỏi việc communication và tương tác giữa các thành viên trong team là 1 điều thực sự cần thiết. Đặc biệt k có report hoặc teamplate cho việc lưu trữ những thỏa thuận, kiến thức được chia sẽ bằng lời nói và mối quan hệ với KH.
3. Customer collaboration
- Trong quá trình phát triển phầm mêm, một tài liệu chẳng hạn như requirement specification, thường trở thành hợp đồng thực tế giữa development team cà KH. Được xem như 1 hợp đồng nên tất cả mọi người sẽ focused và loại bỏ những sự mơ hồ. Điều này thường được thực hiện trước khi dự án start.
- Trong nhiều trường hợp thì sự tham gia liên tục của KH là khi hệ thống được delivery cho KH và KH được yêu cầu tiến hành kiểm tra acceptance testing để xác nhận rằng những gì họ quy định trong hợp đồng là những gì đã được delivery. Khi có sự khác biệt giữa hợp đồng và mong đợi thì sẽ xem lại requirement specification và đưa ra biện luận cũng như giải pháp phù hợp. ==> Agile tránh quá trình này bằng cách coi sự hợp tác của KH như là 1 giá trị của nó. Thông qua việc hợp tác chặt chẽ với KH và cung cấp phần mềm liên tục thì team Agile sẽ nhận được phản hồi liên tục và bất ky yêu cầu thay đổi nào sẽ dễ dàng kết hợp trước khi có quá nhiều công việc bổ sung được thực hiện.
4. Responding to change
- Ai đã từng làm việc trong dự án mà yêu cầu của KH không thay đổi trong suốt dự án, sẽ khó tin nếu KH không thay đổi bất kì yêu cầu nào or kết hợp tính năng mới vào sản phẩm từ 3-6 tháng. Có thể đáp ứng sự thay đổi theo cách này là điều cần thiết đối với những KH hài lòng. Tuy nhiên, nếu có quá nhiều dự án dành thời gian chủ yếu cho việc lập kế hoạch chi tiết, khi dự án được progress thì điều gì ảnh hưởng đến dự án
- Thay đổi môi trường kinh doanh đối với KH.
- Một đối thủ cạnh tranh tung ra một sản phẩm tương tự
- Luật mới được ban hành sẽ ảnh hưởng đáng kể đối với sản phầm
- Bất kì những gì không lường trước có thể xảy ra ==> Có nghĩa dự án phải dễ dàng thích ứng với những sự thay đổi. ==> Trong Agile, thông qua việc devlopement được lặp đi lặp lại tập trung vào lập kế hoạch phát hành dài hạn chung và lập kế hoạch chi tiết ngắn hạn. Không thể nói trước điều gì có thể xảy ra trong vòng đời sản phẩm, do đó, có thể phản ứng với thay đổi nhanh chóng và hiệu quả có thể là sự khác biệt giữa thành công và thất bại của dự án.
II. 12 principles of the Agile Manifesto
1/ Ưu tiên cao nhất của Agile là làm hài lòng KH thông qua việc phân phối sản phẩm sớm và liên tục các phần mềm có giá trị
- Agile team luôn cố gắng cung cấp phần mềm 1 cách thường xuyên, mỗi version của phần mềm là các features bổ sung từ phiên bản trước
- Làm thế nào để thực hiện:
- Product teams sử dụng các sản phẩm khả thi tối thiểu và thử nghiệm nhanh để kiểm tra giả thuyết và xác nhận các ý tưởng.
- Việc phát hành thường xuyên giúp thúc đẩy chu kỳ phản hồi liên tục giữa khách hàng và sản phẩm.
- Shipped và done không giống nhau. Thay vì phát hành một sản phẩm “đã hoàn thiện”, các lần lặp lại tiếp tục tạo ra những cải tiến gia tăng cho sản phẩm dựa trên phản hồi của khách hàng và thị trường.
2/ Luôn welcome sự thay đổi yêu cầu ngay cả khi development muộn. Agile process luôn khai thác sự thay đổi vì lợi thế cạnh tranh của KH
- Trong agile project, thay đổi được coi là điều không thể tránh khỏi. Điều thay đổi được coi là điều tích cực ở chổ KH, thông qua việc nhìn thấy những features sớm và để hiểu rõ những điều KH mong muốn.
3/ Delivery phần mềm thường xuyên từ vài tuần đến vài tháng, với ưu tiền thời gian ngắn hơn.
- Việc cung cấp cho khách hàng ngay cả một giải pháp thô sơ trong giai đoạn đầu của dự án sẽ bắt đầu quá trình phản hồi. Sau đó, điều này được bổ sung với nguồn cung cấp liên tục các yêu cầu tính năng cập nhật, do đó làm sâu sắc hơn và phong phú hơn về feadback của khách hàng.
- Làm thế nào để thực hiện:
- Trong Agile development cycles, thường được gọi " sprint" hay "iterations", chia nhỏ những sáng kiến sản phẩm để hoàn thành trong khung thời gian đã định, thướng sẽ là 2-4 tuần.
4/ Business people và developers phải làm việc cùng nhau hàng ngày trong suốt dự án.
- Agile projects phụ thuộc vào sự tham gia liên tục của khách hàng. Có một đại diện khách hàng tại chỗ trong quá trình phát triển là mục tiêu cuối cùng.
- Làm thế nào để thực hiện:
- Nhóm phát triển sản phẩm nhanh nhẹn đa chức năng bao gồm những người làm sản phẩm. Điều này có nghĩa là sản phẩm được đại diện trong development team và thu hẹp khoảng cách giữa các khía cạnh kỹ thuật và kinh doanh của sản phẩm.
- Daily update meetings hoặc standups, là kĩ thuật mà agile thường được dùng để kết nối mọi người trong team với nhau
5/ Build project từ những cá nhân có động lực. Hãy cho họ môi trường và sự hỗ trợ mà họ cần, và tin tưởng để họ hoàn thành công việc tốt nhất.
- People là chìa khóa thành công của các dự án Agile, vì vậy hãy loại bỏ mọi trở ngại đối với productivity và đảm bảo team được trao quyền để đưa ra quyết định.
- Làm thế nào để thực hiện:
- Product phải đảm bảo engineering hiểu rõ chiến lược và yêu cầu trước khi bắt đầu phát triển. Điều này có nghĩa là không chỉ chia sẻ câu chuyện của người dùng với nhóm đa chức năng mà còn là bức tranh toàn cảnh hơn được vạch ra trong lộ trình sản phẩm.
- Product không chịu trách nhiệm giải thích "How" xây dựng thứ gì đó. Họ cần chia sẻ nội dung và lý do, nhưng nhiệm vụ của delivery team là xác định cách thức thực hiện. Hơn nữa, trong quá trình chạy sprintt, product không quản lý vi mô kết quả, thay vào đó chúng luôn sẵn sàng trả lời các câu hỏi và cung cấp hỗ trợ khi cần thiết.
6/ Phương pháp hiệu quả và hiệu quả nhất để truyền tải thông tin đến và trong developement team là trò chuyện trực tiếp (face to face).
- Phương pháp chính để trao đổi thông tin trong một nhóm Agile là thông qua giao tiếp face to face, không phải tài liệu. Giao tiếp mặt đối mặt làm rõ các yêu cầu và giúp loại bỏ sự mơ hồ. Trong trường hợp bản chất của dự án gây khó khăn cho giao tiếp mặt đối mặt, chẳng hạn như trong phát triển phân tán, thì các dự án Agile sẽ sử dụng những cuộc gọi như skypes.. để thay thế
- Làm thế nào để thực hiện:
- Daily standup meetings
- Sprint planning meetings
- Frequent demos
- Pair-programming
7/ Working software là thước đó chính quả quá trình progress.
- Thay vì sử dụng "giai đoạn hoàn thành" làm thước đo cho mức độ tiến triển của dự án, thì Agile đo lường tiến độ bằng các hoạt động của chức năng thông qua các acceptance testing của KH
8. Các quy trình Agile thúc đẩy sự phát triển bền vững. Các sponsors, developers và user sẽ có thể duy trì tốc độ liên tục vô thời hạn.
- OT quá nhiều và áp lực liên tục có thể dẫn đến sai lầm, thiếu sót và cuối cùng là sự kiệt sức và không hài lòng của teams. Agile Team hướng tới một tốc độ bền vững giúp giảm thiểu thời gian OT và làm quá nhiều giờ. Cách tiếp cận này đảm bảo các thành viên trong team có động lực và chất lượng công việc cao.
- Làm thế nào để thực hiện:
- Trước khi bắt đầu sprint, hãy cân nhắc kỹ lưỡng về khối lượng công việc có thể cam kết. Developement team không hứa quá nhiều về những gì họ có thể và không thể cung cấp. Estimate effort là một thực tế phổ biến trong việc đặt ra các kỳ vọng đầu ra cho các development team.
- Mọi người trong team đều đồng ý về những gì sẽ hoàn thành trong sprint. Khi sprint, không có task bổ sung nào được thêm vào ngoại trừ một số trường hợp hiếm hoi.
- PM sản phẩm nên đóng vai trò như những người bảo vệ team và giúp team tránh bị chèn ép thêm vào các task ngoài kế hoạch trong quá trình chạy sprint.
- Product nên làm phần việc của mình trong việc thúc đẩy cảm giác an toàn về tâm lý trong development team, khuyến khích giao tiếp cởi mở và feedback.
Nguồn tham khảo: