【Phần I - Nhập môn Agile】Chương 1- Cái nhìn khái quát về Agile (2)

Trước khi đọc bài viết này, mời các bạn tham khảo: 【Phần I - Nhập môn Agile】Chương 1- Cái nhìn khái quát về Agile (1)

1.2 Xây dựng Agile schedule

Trong mô hình Agile, Master story list có thể được gọi là ToDo list. Trong đó, sẽ liệt kê - mô tả tổng quát những việc cần làm, những feature khách hàng mong muốn thực hiện...Và trong list công việc đó, khách hàng sẽ thiết lập độ ưu tiên cho mỗi task, qua đó team phát triển sẽ biết được task nào cần ưu tiên thực hiện trước.
Đối với dự án phát triển theo mô hình Agile, chúng ta có thuật ngữ Iteration - đây là khoảng thời gian để hoàn thành 1 hay 1 vài công việc cụ thể nào đó.
1 Iteration thường kéo dài trong khoảng 1 tuần hoặc 2 tuần. Trong thời gian 1 iteration, chúng ta lần lượt thực hiện các task trong list task căn cứ trên độ ưu tiên cho mỗi task đã thiết lập. Mục đích là đảm bảo các task được hoàn thành đúng thời hạn và với chất lượng - độ hoạt động ổn định tốt nhất. Sau khi team thực hiện xong iteration đầu tiên. Chúng ta sẽ thực hiện đo năng suất công việc của team. Từ kết quả - chúng ta có thể hiểu được lượng công việc mà team có thể hoàn thành được trong 1 iteration là bao nhiêu.
Nếu việc đo năng suất này được thực hiện thường xuyên, nó sẽ trở thành tài liệu tham khảo đáng tin cậy trong tương lại, giúp ta có thể estimate 1cách chính xác hơn.
Và nó cũng giúp chúng ta hiểu được giới hạn - năng lực của mỗi member trong Development team, qua đó tránh được việc hứa với khách hàng trong 1 thời gian quá ngắn, mà các member trong nhóm không thể hoàn thành.
Vậy nếu rơi vào tình trạng có quá nhiều task cần hoàn thành trong 1 khoảng thời gian thì chúng ta phải làm sao?
Đối với những bạn hăng hái làm việc, chắc sẽ nghĩ rằng thôi thì làm hết sức có thể, làm được nhiều bao nhiêu tốt bấy nhiêu. Tuy nhiên, theo tôi cách tốt nhất là giảm số lượng task xuống!
Chúng ta cần làm cho scope mềm dẻo hơn - số lượng task không quá nhiều giúp những task chúng ta đã quyết định làm thì có thể hoàn thành 1 cách trọn vẹn. Tóm lại là, nếu schedule không phù hợp với thực tế đang diễn ra, thì chúng ta nên thay đổi nó. Vì về cơ bản, để mang lại thành quả tốt đẹp như mong muốn, chúng ta cần tạo ra schedule thích ứng - phù hợp với thực tế.

Trong khi làm schedule của dự án, ắt hẳn các bạn đã gặp trường hợp là quá chủ quan vào scope của task, hay chỉ là muốn làm vui lòng khách hàng mà chúng ta đã estimate thời gian quá ngắn - không tương xứng với scope của task.
Để đến khi bắt tay vào làm, chúng ta mới ngỡ ra là có quá nhiều vấn đề phát sinh, nó không dễ như chúng ta tưởng tượng, chả nhẽ lúc đấy lại nói với khách hàng là chúng ta không thể hoàn thành task đó, hoặc có cố hoàn thành task đó cũng phải kéo dài thêm hàng tháng, và chỉ có phép màu mới giúp chúng ta hoàn thành task đúng deadline.
Nếu điều đó xảy ra, ắt hẳn chúng ta sẽ đánh mất đi rất nhiều sự tín nhiệm từ khách hàng.
Để tránh điều tồi tệ đó xảy ra. Chú ý vấn đề sau:

• Không che dấu về tình trạng của team với khách hàng - nghĩa là bạn cần đánh giá, truyền đạt đúng năng lực của các thành viên trong team.
• Không vì muốn làm khách hàng vui lòng, mà estimate thời gian cho mỗi task quá ngắn.
  

Từ việc cung cấp thông tin xác thực, Phía khách hàng và team của bạn sẽ có đánh giá đầy đủ, chính xác về scope, budget, và kỳ hạn phù hợp cho mỗi task.
Tóm lại là, chúng ta cần cùng với khách hàng, tạo ra 1 schedule - 1 plan đang tin cậy, qua đó giúp công việc trở nên trôi trảy hơn, mang lại nhiều giá trị tốt đẹp hơn.
Khi mỗi task được hoàn thành, chúng ta thường thay đổi status của task thành "Done" đúng không nào!. Vậy để biết chúng ta đã thực sự hiểu đúng ý nghĩa của status "Done" chưa, các bạn tiếp tục tham khảo tiếp mục tiếp theo nhé.

1.3 Hiểu đúng về trạng thái "Done" trong Agile.

Bạn thử tưởng tượng tình huống sau đây, giả sử Ông Bà bạn muốn nhờ đứa trẻ con hàng xóm lấy chổi quét hết lá rụng ở sân. Quét xong thì cho 5k mua bim bim chẳng hạn.
Vậy thì, ông bà sẽ dựa vào điều kiện - thời điểm nào, để kết luận rằng đứa trẻ kia đã hoàn thành công việc.

• Khi đứa trẻ nộp kế hoạch quét sân.
• Khi đứa trẻ nhớ ra cách sử dụng cái chổi xịn xò
• Khi đứa trẻ tạo ra một checklist để check sau khi sân được quét xong.
  

Thực ra là không có cái nào đúng trong 3 cái trên cả. Điều đúng là đứa trẻ chỉ nhận được tiền khi nó quét hết đống lá rụng ở sân và đổ vào thùng rác ở góc sân.
Định nghĩa status "Done" trong Agile project cũng tương tự như tình huống "Quét sân kiếm 5k" vậy. Trong đó, chúng ta chỉ nói là hoàn thành task đó khi tất cả công việc liên quan đến task đó được hoàn thành, nghĩa là chức năng được tạo ra phải chạy một cách ổn định, sẵn sàng cho việc release.

Ở trên t đã nói là hoàn thành tất cả các công việc liên quan, cụ thể đó là: phân tích yêu cầu, thiết kế, coding, test... thậm chỉ UX design. Tuy nhiên, Bạn cũng đừng hiểu lầm rằng, chúng ta phải làm tất cả các công việc trên từ ban đầu, và phải public chức năng đó trong khoảng 1 hoặc 2 iteration.
Ý tôi muốn nói ở đây là, sau khi chúng ta làm xong 1 chức năng, mà không chắc chắn chức năng đó có sẵn sàng cho việc release hay không, thì chức năng đó - task đó không thể được thiết lập status là "Done".
Nếu bạn xác đình sẽ trở thành một Agile Developer thì bạn cần hiểu được quy tắc sau đây:

Quy tắc đó là: "Một phần mềm tốt là thước đo quan trọng nhất khi đánh giá tiến độ công việc.!"
Tiếp theo, bạn nên hiểu về 3 sự thật thường gặp trong quá trình thực hiện project.

1.4 "3 sự thật" nên biết.

1. Sự thật đầu tiên, "Tại thời điểm bắt đầu dự án, bạn không thể nắm rõ hết tất cả các requirement của dự án."
   Dù bạn không có đầy đủ tất cả các thông tin cần thiết, bạn vẫn có thể thực hiện chuyến đi hàng hải xung quanh thế giới. Thật đấy, requirement đôi khi là thứ để chúng ta khám phá ra, vậy nên, trường hợp không có đủ các thông tin cần thiết, không có nghĩa rằng bạn không thể bắt đầu công việc.
2. Sự thật thứ hai, "Requirement của dự án thường xuyên bị thay đổi"
   Nếu bạn không phải là người sợ sự thay đổi, thì tôi tin bạn có thể đối diện trực tiếp với điều này, và không cần phải trốn tránh nó. Bạn cần nhận thức được rằng, sự thay đổi - biển đổi là điều đương nhiên sẽ xảy ra => Do đó, chúng ta cần chấp sự nhưng sự thay đổi cần thiết, và vừa xây dựng kế hoạch thích ứng phù hợp, vừa tiến lên phía trước.
3. Sự thật thứ ba, "Nhưng việc cần làm lúc nào cũng nhiều hơn thời gian, và nguồn lực bạn có"
   Thực ra, từ trước đó có thể bạn đã tạo 1 ToDo list vượt quá nguồn lực và thời gian mà bạn khó, tuy nhiên bạn đã không thể cảm nhận được áp lực mà sau này nó sẽ gây ra cho bạn.
   Thực ra điều này cũng thường xảy ra trong khi làm project. Thôi thì chúng ta cố gắng hết sức có thể, nhưng quy tắc quan trọng là chúng ta cần thiết lập độ ưu tiên cho mỗi task. Task nào ưu tiên cao làm trước, ưu tiên thấp làm sau.
   
   Nếu bạn có thể chấp nhận, và đối diện được với 3 sự thật hiển nhiên này, tôi nghĩ bạn sẽ thoát khỏi được sự lo lắng và cả những stress mà đã gặp phải. Và nếu làm được vậy, bạn có thể vượt qua được những thách thức đặc trưng trong nghề này, từ đó bạn sẽ suy nghĩ lạc quan hơn và dám đương đầu với những thử thách hoàn toàn mới.
   Và thêm một điều bạn cần biết nữa đó là, luôn tồn tại nhiều phương pháp để hoàn thành mục tiêu.
   
   Ví dụ:
   

• Scrum: là khung làm việc đã được sử dụng để quản lý quá trình phát triển các sản phẩm phức tạp từ đầu những năm 1990. Scrum không phải là một quy trình hay một kĩ thuật cụ thể để xây dựng sản phẩm hơn thế, nó là một khung làm việc cho phép bạn sử dụng nhiều quy trình và kĩ thuật khác nhau. Scrum làm sáng rõ mức độ hiệu quả tương đối của công tác quản lý và phát triển sản phẩm, từ đó cho phép bạn cải tiến nó.
• XP (Extreme Programming): là một phương pháp phát triển phần mềm hướng đến việc nâng cao chất lượng phần mềm và khả năng đáp ứng với thay đổi yêu cầu người dùng. XP là một trong các phương pháp thuộc họ Agile, nó chủ trương đưa ra các bản phát hành thường xuyên thông qua các chu trình phát triển ngắn. Việc này là để nâng cao năng suất và tạo ra những thời điểm để tiếp nhận những yêu cầu người dùng mới.
• Lean: là một trong những phương pháp quản trị hiện đại nhằm tinh gọn hóa sản xuất, nâng cao năng suất, giảm thiểu lãng phí trong doanh nghiệp, gia tăng hiệu quả kinh doanh.
  Một số thuật ngữ thường được sử dụng:
  
• Iteration: Tương tự với Sprint.
• Master Story List: Product Backlog.
• Customer: Product owner.

Thông qua bài viết trước và bài viết lần này, tôi nghĩ các bạn cũng đã có thể hiểu cơ bản về phương pháp phát triển kiểu Agile là như thế nào. Trong chương 2, cụ thể chúng ta tìm hiểu việc áp dụng Agile trong 1 team sẽ như thế nào nhé.

Hết. Mời các bạn tham khảo tiếp các bài viết lần tới.

Nguồn:  アジャイルサムライ