Bạn tiến hoá nhanh cỡ nào?
Software Engineering
38
agile
9
White

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

Từ khi Darwin xuất bản quyển Nguồn gốc các loài, tiến hóa đã trở thành khái niệm có cơ sở vững chắc. Darwin hiểu thấu rằng tiến hóa - thông qua quá trình chọn lọc tự nhiên - đã dẫn đến sự ra đời và phân hóa tất cả các loài. Giáo hội (thời điểm đó đã có cơ sở giáo lí vững chắc, thậm chí ngày nay vẫn còn giáo phái bác bỏ khái niệm tiến hóa) tất nhiên nóng mặt với điều này, phải đối mặt với chứng cứ khoa học quá rõ ràng.

Đầu thế kỉ 20 chứng kiến cuộc nổi dậy của chủ nghĩa Darwin mới. Nó đã làm được việc là cung cấp cơ chế của chọn lọc tự nhiên. Chọn lọc tự nhiên không phải đang xảy ra ở cấp độ loài, mà ở cấp độ gene. Chọn lọc tự nhiên chỉ đơn giản là thể hiện ra bên ngoài của cuộc chơi thống kê lâu dài dựa trên hoán đổi các gene, và điều khó chịu nữa là các loài (gồm cả loài người) là chỗ cư ngụ tuy tinh vi về hình thức nhưng chỉ tạm thời của các gene đó!

Tạo hóa không nương tay với thể xác. Tạo hóa không hề chú ý tới cái vật cụ thể mà người ta mệnh danh là cá nhân. Tạo hóa chỉ chú ý tới chủng loại, tới nòi giống.

Richard Dawkins, nhà khoa học đã được vinh danh và tác giả của quyển "The Selfish Gene", đã tiến một bước xa hơn. Ông cho rằng khả năng thích nghi và tiến hóa của một loài còn có thể thay đổi theo thời gian. Nói cách khác, khả năng tiến hóa là dấu tích có thể tiến hóa, giống như đuôi (giờ chỉ còn xương cụt) hoặc ruột thừa của con người.

Agile là từ đồng nghĩa với tiến hóa

Tóm lại điều này liên quan gì đến việc phát triển phần mềm? Tất cả những phương pháp phát triển phần mềm theo phong cách agile như XP, Crystal, Scrum, Lean và DSDM, đều đang cố gắng giải quyết cùng vấn đề: tìm ra cách có thể dùng đi dùng lại vào nhiều project để tiên đoán và thích ứng với thay đổi. Nói cách khác, chúng cố gắng làm cho việc phát triển phần mềm tiến hóa, sao cho cuối cùng có thể giao sản phẩm cho khách mà không bị trượt chân khi bước qua những thay đổi xảy đến trong quá trình làm project.

Là cố vấn về qui trình agile, nghề của tôi là tăng khả năng tiến hoá của team hoặc cả một tổ chức. Do bản chất con người là không thể thay đổi được ngay, không thể trông đợi điều này xảy ra trong một đêm. Nhiều bằng chứng cho thấy thay đổi ngay lập tức trên bình diện rộng chỉ mang lại bất lợi. Thay vì thế bạn cần mở đường trong tổ chức để nó tự tiến hoá, thông qua một loạt các bước nhỏ dễ thực hiện.

Hết chiến tranh, anh lính được giải ngũ về nhà. Đường về, xẩm tối từ xa thấp thoáng ngôi làng nọ, lòng anh khấp khởi vì đoán thể nào cũng được dân làng cho ăn uống no say. Nhưng đến nơi, chỉ thấy cả làng cửa đóng then cài - qua bao năm chiến tranh, dân làng đói kém ngại tiếp khách.

Không nao núng, anh lôi ra cái nồi chiến lợi phẩm, đổ nước, đặt vào... ba viên đá rồi bắt đầu luộc! Dân làng tò mò, lục tục kéo ra xem. "Đây là súp mầm đá" - anh giải thích. "Chỉ cần đá thôi à?" - dân làng thắc mắc. "Vờng, cơ mà có thêm cà rốt thì ngọt hơn...". Một người chạy đi, chốc lát đã mang đến rổ cà rốt. Phút sau, dân làng lại hỏi "Sắp chín chưa?" "Vờng", anh lính đáp "có thêm tí khoai tây thì có vị hơn". Lại người làng khác chạy đi. Trong vòng tiếng đồng hồ, anh lính liệt kê thêm nhiều thứ để tăng thêm hương vị cho món súp: thịt, tỏi, muối, rau mùi. Mỗi lần lại có người làng chạy đi lấy đồ từ chỗ dấu trong nhà.

Cuối cùng, nồi súp nóng sốt đã xong. Anh lính vứt mấy hòn đá ra ngoài, và cả làng cùng liên hoan món cả bao năm họ mới được ăn.

-------------------------

Có vài bài học từ câu chuyện này. Dân làng vì bản chất tò mò đã mắc mưu anh lính. Nhưng quan trọng hơn, anh lính là chất xúc tác gắn kết dân làng lại với nhau, giúp họ cùng nhau tạo được thứ riêng từng người không làm được.

Sẽ có lúc bạn muốn bắt chước anh lính.

Bạn biết WHAT và HOW để đạt mục đích - mọi thứ đều bày sẵn trước mắt. Nhưng mọi việc đều trì trệ: Everybody was sure Somebody would do it, Anybody could have done it, but Nobody did it, Somebody got angry about that because it was Everybody's job, Everybody thought Anybody could do it, but Nobody realized that Everybody wouldn't do it. Điều này gọi là "sức ỳ lúc khởi động" - một khi đã khởi động được thì mọi thứ sẽ chạy.

Đây là lúc mang hòn đá ra. Cần xác định bước đầu tiên sao cho bước này có thể thực hiện được dễ dàng và phải thực hiện thành công. Xong, cho mọi người xem thành quả. Rồi bảo "thì hiển nhiên, sẽ tốt hơn nếu chúng ta thêm vào..." Cứ giả vờ cái thêm vào chẳng quan trọng gì. Cứ thế, chỉ cần ngồi chờ mọi người hỏi xem cần thêm những gì. Mọi người sẽ thấy dễ dàng hơn khi thấy thành quả dần dần hiện ra. Đừng sốt ruột, hãy từ từ bật mí cho họ thấy tương lai, rồi chỉ dẫn để tự họ đạt được nó.

Bạn không thể chỉ bước vào phòng rồi tuyên bố "từ giờ chúng ta sẽ làm việc theo kiểu này này". Bạn cần bỏ thời gian để hiểu và tôn trọng hệ thống hiện có, và đưa ra qui trình thay đổi sao cho thật đơn giản và tự nhiên để đạt hiệu quả truyền tải cao nhất. Ở cấp độ làm-cho-nó-xong-việc: mã có test ít lỗi hơn mã không có test, mã tạo bởi lập trình đôi (pair programming, đôi bạn cùng tiến) tốt hơn mã tạo bởi một người. Những thay đổi dần dần trong cách làm project này rất dễ hiểu và dễ thực hiện.

Ở cấp độ quản lí cao hơn thông điệp cần tế nhị hơn. Không phải cứ truyền tải nhanh và chính xác là được - không phải cứ tập hợp một đống người lại rồi bảo làm thế này thế này thì hay lắm là project sẽ tự động hoàn thành. Thay vì thế vấn đề nằm ở chỗ cần mềm dẻo mưa dầm thấm lâu.

Agile có nhiều mẹo nhỏ giúp làm điều này. Lập trình đôi giúp giảm thiệt hại khi có người nghỉ việc. BDD, TDD giúp giảm bug v.v.

Càng mở đường để tổ chức tiến hoá, bạn càng dễ thay đổi nó, giúp nó dễ thích nghi với đổi thay, của cả trong nội bộ công ty lẫn nhu cầu của khách hàng. Kent Beck có câu nổi tiếng: hãy tác động để thay đổi. Thay đổi là điều tất yếu, và cơ hội sống sót của bạn liên hệ trực tiếp với khả năng tiến hoá.

Nguồn: How quickly can you evolve

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.
300 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
66 8
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 hơn 2 năm trước
66 8
White
42 1
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 hơn 2 năm trước
42 1
White
38 2
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 hơn 2 năm trước
38 2
Bài viết liên quan
White
6 0
Tiếp theo của phần 1, hôm nay mình sẽ tiếp tục viết về phần 2 quy trình Agile. Lần trước ta nói tới khái niệm của Scrum rồi, bây giờ tìm hiểu làm s...
Bùi Viết Hướng viết 2 năm trước
6 0
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 hơn 2 năm trước
1 1
{{like_count}}

kipalog

{{ comment_count }}

bình luận

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


White
{{userFollowed ? 'Following' : 'Follow'}}
102 bài viết.
300 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á!