6 thói quen của agilist: (1) Coi trọng feedback
Software Engineering
36
agile
8
White

Ngoc Dao viết ngày 23/03/2016

Từ agilist trong tựa đề của loạt bài viết này chỉ những lập trình viên phát triển phần mềm bằng phương pháp Agile (phương pháp lập trình linh hoạt). Agilist vừa thích ứng với hoàn cảnh, vừa phát triển phần mềm một cách linh hoạt. Loạt bài viết này dựa trên kinh nghiệm của bản thân tôi, là một agilist, cộng với những phát hiện về những agilist xung quanh, xin được giới thiệu về phương pháp Agile thông qua những thói quen của agilist.

Tôi không là lập trình viên vĩ đại. Tôi chỉ là lập trình viên đã tập được cho mình những thói quen vĩ đại. (Kent Beck, quyển Refactoring: Improving The Desing Of Existing Code)

Người ghét công việc của mình thì cuộc sống thật ngắn ngủi.

Tôi là lập trình viên làm việc trong lĩnh vực thiết kế SI ở công ty qui mô cỡ 200 người. Công việc chủ yếu của tôi là phát triển phần mềm nghiệp vụ cho doanh nghiệp.

Tôi có một vài ước mơ. Đây là mơ ước của một lập trình viên phát triển phần mềm nghiệp vụ.

  • Dựa vào sức mạnh của team để thực hiện những công việc mà chỉ với sức của một người thì không thể gánh vác được.
  • Kết quả của team làm ra phải có ích cho ai đó.
  • Kết quả của team phải được trả công tương xứng.

“Người ghét công việc của mình thì cuộc sống thật ngắn ngủi”. Suy nghĩ đồng cảm với câu nói này của Joel Spolsky đã nhen nhóm trong tôi nhờ 2 cuốn sách. Một là The Pragmatic Programmer: From Journeyman to Master (Từ thợ đến thầy). Hai là Extreme Programming Explained: Embrace Change.

Sau khi đọc 2 quyển này vài năm, nhờ cơ duyên tôi đã nắm có cơ hội chuyển đến làm ở công ty hiện tại để tham gia vào cái gọi là cộng đồng agile của Nhật. Thế rồi tôi cảm thấy ước mơ như thế có vẻ không chỉ có mình tôi có.

Đôi điều về loạt bài viết này

Từ agilist trong tựa đề của loạt bài viết này chỉ những lập trình viên phát triển phần mềm bằng phương pháp agile (phương pháp lập trình linh hoạt). Agilist vừa thích ứng với hoàn cảnh, vừa phát triển phần mềm một cách linh hoạt. Loạt bài viết này dựa trên kinh nghiệm của bản thân tôi, là một agilist, cộng với những phát hiện về những agilist xung quanh, xin được giới thiệu về phương pháp Agile thông qua những thói quen của agilist.

Phần 1 là phần chuẩn bị. Trước hết tôi sẽ giải thích về phát triển phần mềm bằng phương pháp agile và agilist, theo cách của tôi. Tiếp đó, xin giới thiệu về thói quen đầu tiên, thói quen nền tảng cho những thói quen sẽ trình bày trong những phần sau, “Coi trọng feedback”.

Phát triển phần mềm bằng phương pháp Agile

Trước hết xin giải thích về từ khóa rất quan trọng của loạt bài viết này, từ “agile”.

Agile là tính từ

Agile là tính từ. Cho nên, Agile Software Development (Phương pháp phát triển phần mềm linh hoạt) nghĩa là tiến trình phát triển phần mềm được đặt trong trạng thái agile. Chet Hendrickson và  Ron Jeffries mô tả trạng thái này là Early and Often (Sớm và Thường xuyên).

Sớm và thường xuyên

Trạng thái “sớm và thường xuyên” đạt được chỉ khi mà nhóm phát triển phần mềm thỏa mãn điều kiện sau:

  • Cho ra đời phần mềm có test và hoạt động được,
  • release định kì,
  • trong suốt chu trình phát triển phần mềm.

Mục đích của loạt bài viết này là nghĩ cách làm sao để nhóm phát triển đạt được trạng thái này. Phần giải thích về các mục xin sẽ đăng tải bổ xung ở những loạt bài tiếp theo.

Giá trị về mặt thời gian của phần mềm

Tại sao cần phải thực hiện “sớm và thường xuyên” – nói cách khác là agile? Nền tảng của suy nghĩ này là ý tưởng về giá trị của phần mềm. Giá trị phần mềm ở đây là giá trị của phần mềm đối với khách hàng. Đối với khách hàng, phần mềm chỉ có giá trị từ thời điiểm được đưa vào sử dụng. Theo phương pháp agile, giá trị của phần mềm được tính như sau:

Giá trị của phần mềm = độ lớn của giá trị  × thời gian giá trị tồn tại

Chuẩn bị từ bước sơ khai nhất (sớm) của qui trình phát triển phần mềm, tiếp tục phát triển đến những mốc release được (thường xuyên), cho đến khi sản phẩm ra đời, phương pháp agile dùng cách này để gia tăng tối đa tổng giá trị của phần mềm.

Tác giả của Từ thợ đến thầy, Dave Thomas gọi cách suy nghĩ này là “Giá trị về mặt thời gian của phần mềm” (xem From Java to Ruby: Things Every Manager Should Know). Ý tưởng của ông xuất phát từ ý tưởng “giá trị về mặt thời gian của tiền bạc”, “$1 ngày hôm nay có giá trị hơn $1 của ngày mai”.

Chính con người mới tạo ra phần mềm

Để gia tăng tối đa giá trị về mặt thời gian của phần mềm, nhóm phát triển cần tiếp diễn quá trình tạo ra release một cách “sớm và thường xuyên”. Những hoạt động để đạt đến mục đích này chính là sự phát triển linh hoạt (agile development). Vì thế mới có suy nghĩ phải hướng tới Agile development. Đây là suy nghĩ “chính con người mới tạo ra phần mềm”.

Vì phát triển một cách linh hoạt nên ta đang thực hiện Agile development

Đơn vị cấu thành nhỏ nhất của Agile developement là từng cá nhân. Nhóm phát triển chính là nơi để các thành viên cộng tác với nhau.

Trong Agile development, qui trình phát triển xét cho cùng chỉ là công cụ để phát huy sức mạnh của nhóm mà thôi. Khi cần (chắc chắn là sẽ cần) ta phải thay đổi, cải thiện qui trình ấy. Nói cách khác, Agile development nghĩa là, vì những con người phát triển (phần mềm) một cách agile, nên nó là một qui trình phát triển có tính agile.

Agilist (lập trình viên linh hoạt)

Trong agile development, mỗi thành viên của nhóm là một lập trình viên linh hoạt – là người có (hoặc sẽ có) kỹ năng và sự sẵn sàng để phát triển linh hoạt.

Nếu thay đổi cách nhìn một chút, ta có thể nói qui trình phát triển linh hoạt phụ thuộc vào từng thành viên của nhóm phát triển. Nhưng ngày nay, phát triển phần mềm đâu có đơn giản là cứ dập khuôn theo một qui trình sẵn có là chắc chắn sẽ cho ra sản phẩm đâu.

Tinh thần và kỹ năng

Tinh thần của agilist ở đây là thái độ phấn đấu đạt được và duy trì “Sớm và Thường xuyên”.

Nếu không có tinh thần này thì Agile development sẽ chẳng đi đến đâu. Tuy nhiên, chỉ có tinh thần thôi cũng không làm được gì. Nếu chỉ có tinh thần mà thành công được thì hẳn là death march đã tuyệt chủng. (death march là thuật ngữ để chỉ việc mặc dù ai cũng biết chắc chắn dự án sẽ thất bại, nhưng nó vẫn được tiến hành không thể dừng lại được)

Cần phải có cả tinh thần và kỹ năng để thực hiện tinh thần ấy. Có kỹ năng thực hiện nhưng lại không có tinh thần thì cũng chẳng ích gì.

Tôi cho là tinh thần của agilist thể hiện và thấm dần trong quá trình dùi mài những kỹ năng của agilist. Vì vậy, loạt bài này xin chỉ tập trung vào phần kỹ năng.

Từ kỹ năng vốn được sử dụng với nhiều ý nghĩa. Ở đây, kỹ năng mà tôi đề cập là kỹ thuật mà lập trình viên thực hiện hằng ngày để trở thành một thành viên của nhóm phát triển.

4 kỹ năng

Theo như tài liệu “Early and often” nói ở trên, agilist cần cố 4 kỹ năng sau.

  1. Tạo story (Creating Stories)
  2. Lên kế hoạch (Planning)
  3. Dùng test để dẫn đường chỉ lối (Test-Driven Development)
  4. Refactoring

4 kĩ năng này sẽ được giới thiệu chi tiết qua loạt bài này, nên ở đây chi giải thích sơ qua.

Tạo story

Story là những câu chữ bình thường để mô tả hoạt động của hệ thống được viết trên quan điểm giá trị đối với khách hàng, và khách hàng có thể hiểu được. Giá trị của phần mềm là cái nhìn từ khách hàng, nên khả năng tạo story là kĩ năng rất quan trọng.

Lên kế hoạch

Agile development không lập kế hoạch mà viết code ngay - là hiểu nhầm thường gặp. Rõ là agile development không tuyệt đối hoá kế hoạch. Thay vào đó, tuỳ tình trạng mà lên kế hoạch. Ở agile development tần suất lập kế hoạch cao, nên ở mỗi lần lập kế hoạch việc thực hiện sao cho hiệu quả là kiẽ năng rất quan trọng.

Dùng test để dẫn đường và refactor

TDD và refactor là 2 kĩ năng liên quan mật thiết, được công nhận là rất quan trọng đối với agile development.

Trở thành agilist

Chỉ học 4 kĩ năng thôi thì chưa hoàn toàn là agilist. Khi nào 4 kĩ năng này trở thành thói quen dùng thường xuyên đến láng bóng thì mới là agilist.

Tập thói quen

Tôi cho rằng thói quen tạo bởi 3 yếu tố sau:

  • Tinh thần (mindset)
  • Thực hành
  • Dùng thường xuyên

Đến khi nào bạn coi những yếu tố là "thì hiển nhiên rồi", thì mới bắt đầu được coi là có thói quen.

Theo kinh nghiệm bản thân và quan sát của tôi, agilist đều có vài thói quen. Thông qua loạt bài này, tôi sẽ giới thiệu những mindset và thực hành cần có để tạo thói quen. Còn việc dùng chúng thường xuyên là tuỳ mỗi người.

Trước hết là bản thân mình, sau đó là team

Chú ý đừng áp dụng ngay những điều tôi giới thiệu ngay lên toàn bộ team. Mỗi người cần tự mình thử nghiệm và tự xác nhận hiệu quả. Tự thử, rồi sau đó mới cùng nhau áp dụng là rất quan trọng. Theo kinh nghiệm của tôi, mình chưa làm thử mà lại ép người khác làm thì sẽ không thành công.

Thói quen #0: Coi trọng feedback

Người có mục đích trở thành agilist cần tập thói quen để tạo 4 thói quen đánh bóng 4 skill, nghĩa là meta thói quen (thói quen để tạo thói quen, như metadata là dữ liệu về dữ liệu). Đó là thói quen "coi trọng feedback". Kì này tôi sẽ giới thiệu meta thói quen này. Vì là "thói quen để tạo thói quen", nên đặt nó là thói quen số 0.

Xác định tinh thần "học từ thực tế"

Từ thực hành, thu được kinh nghiệm là feedback. Học từ kinh nghiệm, nên có thể lập chiến lược hiệu quả để tiến bộ. Tuy nhiên, vì coi trọng feedback nên không phải cứ thực hành là được. Khi thực hành và học từ feedback cần luôn nhận thức "khi nào/làm như thế nào".

Tạo nhịp điệu

Xin giới thiệu 2 chiêu thức để học từ thực hành: timebox hoá và hồi tưởng. Tổng hợp 2 cái này, sẽ tạo ra nhịp điệu thực hành và học từ thực hành. Trong chữ thói quen có chữ thói, nên cảm giác nhịp điệu rất quan trọng.

Chiêu thức "timebox hoá"

Timebox hoá là thủ pháp quản lí thời gian và công việc. Ở timebox hoá, thời gian của project hay công việc được cấu thành từ làm nhiều "hộp thời gian" có kích thước cố định để quản lí.

Ví dụ, nếu chia project có thời gian 3 tháng thành timebox có đơn vị tuần, thì tổng cộng có 12 hộp.

Ý thức về thời gian

Thời gian của mỗi timebox là cố định. Không có chuyện đá bù giờ. Thay cho "tuần", dùng thuật ngữ "timebox" khi trao đổi giúp xác định rõ tư tưởng "thời hạn là tuyệt đối, không có chuyện đá bù giờ".

Chi tiết hơn

Timebox hoá có liên quan đến lập kế hoạch, sẽ được giới thiệu chi tiết hơn trong loạt bài này. Trước hết hãy nhớ rằng ở timebox hoá, kích thước của "hộp" là cố định, "thời hạn là tuyệt đối, không có chuyện đá bù giờ".

Chiêu thức: hồi tưởng

Sau khi xong một timebox, hồi tưởng lại công việc đã làm để cải tiến hiệu quả hơn cho timebox sau.

Thời điểm thực hiện

Việc hồi tưởng thực hiện tại thời điểm sau mỗi timebox. Điểm này khác với buổi tổng kết chỉ một lần sau khi kết thúc công việc. Mỗi lần hồi tưởng chỉ nên kéo dài 30 phút đến 1 tiếng. Kéo dài quá sẽ quên mất công việc thực sự.

Hồi tưởng bằng phương pháp KPT

Xin giới thiệu qua phương pháp KPT tôi thường viết lên bảng. Phương pháp này chia tấm bảng thành 3 phần có ghi tiêu đề Keep Problem Try. Ý nghĩa tương ứng từng phần: "Những việc thực hiện tốt, timebox kế tiếp cũng muốn tiếp tục", "Những việc chưa tốt", "Những việc muốn thử ở timebox kế tiếp".

Các bước tiến hành phương pháp KPT

Các bước tiến hành hồi tưởng bằng phương pháp KPT dựa trên phương pháp của nhóm phát trển sản phẩm TRICHORD của công ty Change Vision (tiếng hàng đầu Nhật với công cụ JUDE để vẽ UML).

  1. Kiểm tra mục Try của lần trước
  2. Nhớ lại những việc xảy ra ở timebox trước
  3. Tóm gọn theo hình thức Keep, Problem, Try
  4. Tổng kết (tuyên bố kết thúc buổi hồi tưởng và chụp lại ảnh tấm bảng)

Hiệu quả của hồi tưởng nằm ở bước 1 và 2. Khi chưa quen, cần chia nhiều thời gian cho 2 bước này thì mới đạt hiệu quả. Lúc này bước 3 sẽ đến tự nhiên.

Chi tiết hơn

Bản thân việc thực hành hồi tưởng rất đơn giản. Tuy nhiên, để hiệu quả cần có mẹo. Xin xem phụ lục ở dưới.

Ngoài ra, nhóm phát triển TRICHORD hầu như tuần nào cũng công bố kết quả hồi tưởng trên blog của họ. Nhiều thử nghiệm đa dạng để tăng hiệu quả hồi tưởng cũng được giới thiệu, rất nên tham khảo.

acts_as_agile

acts_as_agile là từ thể hiện rõ meta thói quen "coi trọng feedback". Phải ứng xử theo kiểu agile thì mới trở thành agilist. Thực hành. Feedback. Rút kinh nghiệm. Thực hành. Feedback. Dựa và việc lặp đi lặp lại, chậm mà chắc ta sẽ tập được thói quen agile để trở thành agilist.

Thư viện ActiveRecord của framework Ruby on Rails có nhiều plugin có tiền tố acts_as_, như acts_as_taggable, acts_as_cached. acts_as_agile là cách chơi chữ.

Tổng kết kì này

Tổng kết như hình vẽ.

Các kì sau sẽ giới thiệu thêm các meta thói quen khác để hỗ trợ việc tạo thói quen sử dụng thường xuyên 4 kĩ năng của agilist.

Phụ lục 1: Các phương pháp luận về phát triển phần mềm chỉ là phái sinh từ cách thực hiện

Võ học có cùng nguồn gốc, nhưng tách làm nhiều môn phái. Các phương pháp như XP (eXtreme Programming), Scrum, FDD (Feature Driven Development) đều chỉ là phái sinh của phương pháp phát triển có tính agile (tính từ!).

Phục lục 2: Tài liệu tham khảo về hồi tưởng

Giới thiệu tác giả

Shintaro Kakutani là lập trình viên thuộc bộ phận cung cấp dịch vụ của công ty Eiwa System Management.

Là lập trình viên theo phong cách TDD, tin rằng niềm vui trong lập trình mang lại hiệu suất làm việc nên ông thường dùng lập trình bằng Ruby theo qui trình agile. Mục tiêu của ông là trở thành lập trình sư. Ngôn ngữ yêu thích là Ruby, phương thức yêu thích là extend. Ông là thành viên chủ chốt trong ban tổ chức RubyKaigi 2008.

Ông là dịch giả (tiếng Nhật) các quyển: From Java to Ruby: Things Every Manager Should Know, Practices of an Agile Developer : Working in the Real World, Interface-Oriented Design.

Nguồn: 第1回 フィードバックを重視する

Bình luận


White
{{ comment.user.name }}
Bỏ hay Hay
{{comment.like_count}}
Male avatar
{{ comment_error }}
Hủy
   

Hiển thị thử

Chỉnh sửa

White

Ngoc Dao

102 bài viết.
252 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
56 6
Làm thế nào để nâng cấp trang web mà không làm gián đoạn dịch vụ? Đây là câu hỏi phỏng vấn các công ty lớn thường hỏi khi bạn xin vào vị trí làm lậ...
Ngoc Dao viết 2 năm trước
56 6
White
32 0
Bài viết này giải thích sự khác khác nhau giữa hai ngành khoa học máy tính (computer science) và kĩ thuật phần mềm (software engineering), hi vọng ...
Ngoc Dao viết gần 2 năm trước
32 0
White
28 1
Nếu là team leader, giám đốc công ty hay tướng chỉ huy quân đội, vấn đề cơ bản bạn gặp phải là “hướng mọi người đi theo con đường bạn chỉ ra”. Thử...
Ngoc Dao viết gần 2 năm trước
28 1
Bài viết liên quan
White
1 1
Lập trình đôi (pair programming) là hình thức lập trình trong đó 2 người cùng hợp tác làm việc trên cùng màn hình (có thể khác bàn phím v.v.). Bài ...
Ngoc Dao viết gần 2 năm trước
1 1
White
5 1
Trong quyển sách Beyond Java, xuất bản vài năm trước có đoạn:Java has characteristics that many of us take for granted. You can find good Java deve...
Ngoc Dao viết gần 2 năm trước
5 1
{{like_count}}

kipalog

{{ comment_count }}

bình luận

{{liked ? "Đã kipalog" : "Kipalog"}}


White
{{userFollowed ? 'Following' : 'Follow'}}
102 bài viết.
252 người follow

 Đầu mục bài viết

Vẫn còn nữa! x

Kipalog vẫn còn rất nhiều bài viết hay và chủ đề thú vị chờ bạn khám phá!