Tốc độ trong việc phát triển phần mềm: Sự phức tạp của hệ thống (Hết)

7 phút

Tiếp nối phần trước đó, mình tổng hợp lại một chút về Nợ kỹ thuật và kỹ thuật Refactor. Về cơ bản, kỹ thuật Refactor là một phương pháp (có vẻ) mang tính tự nhiên nhất để giảm thiểu sự phức tạp không đáng có của một hệ thống, đồng thời trả một món nợ đã vay: Nợ kỹ thuật. Tuy nhiên vấn đề mới lại phát sinh tuỳ mô hình của bạn: Bạn có cần Auto Test hay là không?

Nếu bạn thật sự cần Auto Test, bạn phải xem liệu mã nguồn của mình có sẵn sàng bước vào một số giai đoạn tự động hoá nào chưa? Có một điểm đặc biệt cần nhớ rõ từ đầu: Áp dụng refactor với vài biện pháp Auto Test không mang lại giá trị kinh tế nào cả. Hoặc có chăng là rất thấp. Bạn giảm sự phức tạp của hệ thống, trả vài món nợ kỹ thuật. Nhưng khách hàng thì chẳng được gì.

Về lý thuyết, giá trị kinh tế mới tương đương với những dòng ngôn ngữ mới. Thế nhưng bạn có thể một phát ăn ngay từ đầu với những dòng code chất lượng và tuyệt hảo 100%? Mình ước bạn có thể. Nhưng rất tiếc. Thêm vào đó là các yêu cầu về tính năng của hệ thống sẽ được cập nhật mới, dựa trên yêu cầu của khách hàng cũng như của chính bạn. Đó là lý do tại sao bạn nên cân nhắc kỹ những vấn đề mình nói ở trên.

Một điểm đau đầu khác vẫn thuộc về phạm vi của Auto Test: Đó là tính ổn định. Thoạt tiên bạn đọc lý thuyết về Auto Test, bạn nghĩ rằng “Ồ, thật tuyệt. Mình đã tìm ra cây đũa thần”. Nhưng trong thực tế, nó có thể khiến bạn đau đầu theo năm tháng, có khi bạn lại mắc Nợ nhiều hơn nữa đấy. Một số test case bổng dưng dở chứng và báo tín hiệu đỏ: Có nghĩa là những dòng ngôn ngữ này xuất hiện lỗi. Nghịch lý ở đây khi bạn biết chắc bạn những gì bạn viết không thể có lỗi được. Bạn có quyền nghi ngờ hệ thống Auto Test đó có gì đó không ổn. Lỗi ở đây có phải do chính bạn vô tình làm ra, hay do chính Auto Test đó không ổn định?

Thành thực mà nói, mình chưa thấy có một công ty nào áp dụng thành công Auto Test (ít nhất là với kinh nghiệm làm việc khiêm tốn của mình, mình rất vui nếu ai có thể có ví dụ khác phản bác lại). Những phương pháp test truyền thống có thể chậm hơn chút, nhưng bù vào đó chúng ta thay đổi phương thức làm việc: cùng thực hiện song song với những việc lập trình khác. Hoặc từ chính kinh nghiệm của người Tester.

Vấn đề về sự ổn định của phương pháp Auto Test vẫn còn bỏ ngỏ. Có chỗ thì áp dụng một tý, có chỗ thì bỏ hẳn, hoặc thậm chí chấp nhận tốn thêm nhân lực để bù khuyết. Bởi dù sao một Tester thực sự thì biết giao tiếp. Còn bọn Auto Test thì chỉ biết đưa tín hiệu đỏ. Câm như hến. Cho nên về đường dài thì chúng ta có thể không cần Auto Test đối với các hệ thống tương đối phức tạp (mức trung bình khá so với thời gian hoàn thiện sản phẩm). Sẽ rất thiếu thực tế khi chúng ta cố áp dụng Auto Test vào các dự án vừa và nhỏ.

Có bao nhiêu vấn đề siêu hóc búa trong phần mềm? Không nhiều, nếu không phải nói là hiếm. Có công ty nào áp dụng Auto Test ở cấp độ cao không? Có. Các công ty đó tuyển toàn trâu bò, tiến sĩ thạc sĩ trở lên. Bèo lắm cũng mấy ông siêu Senior Programmer về làm. Mấy vấn đề vĩ đại của thế giới đó để biệt đội Avengers đó xử lý. Chúng ta chỉ cần làm tốt việc của chính chúng ta là đủ cứu thế giới rồi.

Phong cách cao bồi Viễn Tây

Nhiều bạn lập trình viên không thích các quy trình làm việc. Mình tin điều này là đúng. Mình cũng đã chứng kiến nhiều. Họ chỉ đơn giản là chàng cao bồi miền Viễn Tây. Nhiều người trong số họ thích phong cách tự do và không thích các luật lệ, quy tắc. Các nhà phát triển có kinh nghiệm hơn thì hiểu rằng sẽ thật sự cần thiết khi có những quy tắc tối thiểu.

Mấy anh cao bồi thường có chủ ý bỏ qua các quá trình phát triển phần mềm, và chỉ muốn đi nhanh tới bước lập trình – sở trường của họ. Thực tế điều này không phải bao giờ cũng tiêu cực. Sẽ thật hoàn hảo nếu bạn – một cao bồi – làm việc dạng freelancer, làm việc độc lập theo hợp đồng từ xa, hoặc thậm chí trong một team nhỏ 3-4 người.

Cao boi

Nhưng trong các team làm phần mềm nghiêm túc, và ở đẳng cấp cao, chính bạn sẽ gây ra sự hỗn loạn và đem tới nhiều món Nợ kỹ thuật nhất cho team. Và không ai khác công ty cũng sẽ là người cuối cùng đi trả nợ cho phong cách Viễn Tây này.

Cái gì nhanh thì cần nhanh. Cái gì chậm thì nên cần chậm, nếu bản chất nó phải thế. Đối với một mô hình phát triển phần mềm trên 20 người, bạn buộc phải xây dựng các quy trình phát triển. Quy trình XP là một ví dụ điển hình (ở VN thì hầu như không có ai áp dụng cách này, thường sẽ có các kiểu biến tấu từ Scrum đi lên).

Việc xây dựng các quy trình phát triển chỉ là một phần. Chính bạn – những nhà phát triển chuyên nghiệp trong tương lai – buộc phải học cách thích nghi với những quy trình đó. Nói cách khác, bạn học cách làm việc với hơn 20 người.

Như vậy, nếu bạn tự nhận thấy mình là một người mang phong cách thập niên 90, bạn nên nhìn ra thế giới xung quanh mình. Tìm cho mình một hướng đi phù hợp để thoải mái code hoặc muốn phát triển thành một nhà phát triển thực thụ, cái đó do bạn tự chọn lấy. Con đường luôn rộng mở.

Đẩy nhanh tiến độ ngắn hạn

Khoan hiểu lầm. Bài này viết về các yếu tố ảnh hưởng đến Tốc độ của phát triển phần mềm nhé. Xém tí nữa mình cũng lầm theo bạn rồi đấy.

Từ quan điểm kinh tế, khi một số lượng khách hàng có những nhu cầu đặc biệt và hợp với thị trường, bạn buộc phải cân nhắc việc đẩy nhanh tiến độ. Lúc này bạn nhận thức rõ ràng rằng mình phải hy sinh Chất lượng của sản phẩm. Quan điểm này vẫn thường xảy ra, và chúng ta cũng học cách chấp nhận nó qua thời gian, qua nhiều dự án.

Người phương Tây hay có câu “Không có bữa ăn trưa nào miễn phí cả”. Ngụ ý ở đây là việc tăng tốc như vậy nó chỉ là một đầu của đòn bẩy: Đầu kia sẽ gây ra các hậu quả về lâu dài, Nợ kỹ thuật, Tốc độ làm việc chậm lại, Cơ hội đầu tư công việc mới không xuất hiện.

OK, tới bài này cũng đã khá nhiều thông tin. Mình tóm tắt lại như sau cho dễ hiểu:

Phần 1, bạn có Nợ kỹ thuật. Phần 2, bạn có Sự phức tạp của hệ thống. Hai cái món này cùng chĩa mũi dùi về một chỗ, nhất là khi bạn quyết định đẩy nhanh tiến độ trong ngắn hạn. Lúc này bạn quên đi sự hiện diện của 2 cái món đó. Như vậy là 3 món cùng tổng hợp lại gây nên sự ức chế về lâu dài.

Nợ kỹ thuật ➙ Đẩy nhanh tiến độ ➙ Ảnh hưởng tốc độ của việc phát triển.
Sự phức tạp của hệ thống ➙ Đẩy nhanh tiến độ ➙ Ảnh hưởng tốc độ của việc phát triển.

Dễ hiểu phải không?

Thời hạn làm việc (Deadline)

Xài từ deadline cho nó hầm hố chút. Cái này nhìn đơn giản chứ nhiều người phạm mấy lỗi rất cơ bản. Để ra được deadline đúng phải như ví dụ sau:

Chưa chuẩn
Chưa chuẩn
Chuẩn hơn chút

Giao deadline đồng nghĩa với việc gieo rắc áp lực vô hình. Thường áp lực này mang tính tiêu cực và có tính ăn mòn. Nó giống axit vậy. Chỉ tốt ở vài trường hợp đặc biệt. Chúng ta làm nhanh, bỏ qua các giai đoạn rườm rà, tiến tới mục tiêu cuối cùng càng nhanh càng tốt. Nợ nần kỹ thuật sinh ra thêm, Tính năng có khi lại thêm phức tạp. Rất rõ ràng.

Ngoài ra, mình hay thấy vụ giao deadline còn rơi vào tình huống kiểu Get Shit Done. Chúng ta là biệt đội anh hùng, hãy đi giải cứu thế giới, không thì chúng ta ngỏm giờ! Get Shit Done nó còn lấy thêm Nợ kỹ thuật về các bạn à. Bạn cứu thế giới nhưng đừng bây bưa ra đó, vì không ai rảnh đi hốt giúp bạn đâu.

Vậy nên hãy cẩn thận sử dụng phương pháp này. Giao deadline nhưng phải có phương pháp để theo kỹ mới được. Không nên giao deadline rồi rung đùi chờ ngày cuối hỏi thăm đồng bọn.

Giao deadline và Tìm cách phát triển lặp đi lặp lại

OK nãy giờ mình luyên thuyên vậy chắc cũng đủ. Bây giờ mình chia sẻ một quan điểm còn gây nhiều tranh cãi: Việc phát triển lặp đi lặp lại trong các quãng ngắn là một tập hợp bao gồm nhiều deadline nhỏ.

Thật vậy, một cục bự chà bá được giao vào ngày nào đó. Bạn buộc phải có cách để sinh tồn. Quan điểm trên chỉ ra rằng bạn chia nhỏ công việc ra, mỗi việc nhỏ có 1 deadline nhỏ tương ứng. Liệu các hệ quả sinh ra (nếu có) có giống y chang với việc làm 1 lần rồi giao? Không hẳn là chính xác nhưng ở góc độ nào đó có thể hai việc này có sự tương đương nhau. Vì cuối cùng rồi cũng phải giao deadline, thay vì tự chịu áp lực ăn mòn lớn lao, ta nên chia nó ra để cảm giác áp lực đó dễ chịu hơn bội phần.

kc

Nếu team đặt mục tiêu làm 19 story ở Sprint thứ 4, team sẽ cố gắng hoàn thành hết tất cả số story này. Cách khả dĩ nhất là giảm đi 1 lượng yêu cầu và bỏ qua story nào không đảm bảo được chất lượng và tiến độ. Nhưng bạn có biết không? Không, chỉ có lập trình viên và tester biết mà thôi.

Ví dụ với Scrum, mình thực nghiệm được rằng các bạn vẫn tiếp tục xu hướng cắt-xén ở đâu đó. Thỉnh thoảng nó tốt, bởi vì mình chủ động cho phép điều đó xảy ra để phục vụ mục đích cuối cùng của doanh nghiệp: vấn đề kinh tế. Nhưng rõ ràng là bạn nên thấu hiểu được bản chất của nó sớm, hiểu được việc phản tác dụng của nó khi để cho việc này xảy ra nhiều lần. Khi đó bạn có thể tự do điều khiển luồng làm việc của team, và điều hướng nó đi đến đúng mục đích ban đầu đặt ra.

Đam mê

Mình có lý do khi xếp nó gần cuối thế này. Đam mê rõ ràng là tốt nhưng tại sao nó được xem là 1 trong các nhân tố ảnh hưởng đến tốc độ phát triển?

Rõ ràng chúng ta đều luôn muốn tuyển dụng những người đam mê thật sự. Họ có thể làm tất cả để viết mã tốt, phát minh ra nhiều sáng kiến và thậm chí có thể ở lại công ty làm việc thêm giờ một cách tự nguyện.

Ban đầu mình tính đưa việc làm thêm giờ (OT – Overtime) vào bài viết. Nhưng nghĩ kỹ thật sự việc làm thêm giờ nó mang tính lợi ích về mặt phúc lợi nhiều hơn là cách làm việc chính thống.

Tuy nhiên, đam mê không phải là tất cả. Nếu bạn mới ra đi làm, bạn cần học hỏi, lẽ dĩ nhiên bạn sẽ cần đam mê. Nhưng đừng để sự đam mê đó dẫn dắt chúng ta đi lầm đường. Nếu bạn đam mê thật sự, bạn sẽ tự động làm việc nhiều hơn. Hơn nữa bạn sẽ khó cân bằng cuộc sống trở lại nếu ngoài công việc bạn gặp nhiều vấn đề cá nhân như tình cảm, tiền bạc, các mối quan hệ.

Thật sự những người có đam mê đều có khả năng giúp thúc đẩy dự án chạy nhanh. Nếu bạn là một người có đam mê, bạn nên hiểu chính bản thân mình một cách tốt nhất. Không gì khác hơn là phải học cách cân bằng giữa công việc và bên ngoài.

Sự không ổn định của Team

Giữ một nhóm còn nguyên vẹn (ổn định) trong một thời gian dài có thể dẫn tới khả năng tăng năng suất làm việc khoảng 60%. Lúc này các công việc của nhóm dễ dự đoán hơn, đưa ra quyết định chính xác hơn, và có tính tương thích với tình huống cao hơn.

Tại sao lại như vậy? Bất kỳ một nhóm làm việc nào cũng có một vòng đời cơ bản. Nó cũng giống như vòng đời của sản phẩm vậy. Thường khi lập nhóm đều phải trải qua một số giai đoạn ngắn để nhóm hình thành nên các thói quen làm việc, và hiểu được những quy tắc chung nhất của sản phẩm cũng như tiến độ. Hiệu quả cao nhất chỉ được thể hiện ở giai đoạn cuối cùng của nhóm. Đó là giai đoạn thể hiện năng lực.

Nếu bạn xoay thành viên trong nhóm, bạn sẽ phá vỡ cấu trúc vòng đời hiện tại, và sẽ lặp lại các giai đoạn cũ cho đến khi đạt được giai đoạn thể hiện năng lực này. Trong tình huống xấu nhất thì các thành viên sẽ vô thức bỏ qua các giai đoạn khởi động ban đầu, lao vào làm việc và muốn thể hiện năng lực liền. Nhìn thì đúng là có vẻ tốt, nhưng thực tế nhóm của bạn chỉ có giá trị kinh tế một lần.

Lời kết

Việc phát triển phần mềm/hiệu suất làm việc/tốc độ phát triển luôn là một khái niệm phức tạp. Các yếu tố này có sự phụ thuộc và ràng buộc lẫn nhau, và quan trọng hơn là tính đa dạng của chúng. Thật không dễ để có các giải pháp ngay lập tức. Bạn không thể hét trong buổi họp, bạn không thể đưa ra các chỉ thị bắt buộc team làm nhanh hơn. Bạn cũng không thể nhắm mắt lại và đưa ra các yêu cầu trọng tâm để thu về các giá trị kinh tế. Giải pháp duy nhất là suy nghĩ sâu sắc về công ty, về nhóm, về các quy trình làm việc, về con người, về công cụ. Bạn cần xây dựng mô hình, thử nghiệm, đánh giá, và bạn nên dành thời gian suy ngẫm về nó nhiều như khi bạn cần tính toán các giá trị kinh tế khác.

Cá nhân mình rất hứng khởi với các khái niệm phát triển khác trong nội bộ nhóm. Có thể đó là khái niệm về việc làm sao cân bằng được tốc độ làm việc và độ bền, sức dẻo dai của nhóm. Như mình nói ở trên, các khái niệm này bản chất đã đa dạng. Nói theo xác suất thống kê thì tổ hợp các sự đa dạng này sẽ sinh ra các kết quả ngạc nhiên khác.

Hết.

Tp.HCM, ngày 05 tháng 06 năm 2016.

Quoc Huy Tran Written by:

I do digital product management. I grew up in Danang and moved to Ho Chi Minh City in 2003 where I've enjoyed the tech/startup scene since. I'm a minimalist in lifestyle. I'm passionate about technology, startups, design, football and basketball. For now I focus on building Web App/App products. I have 6+ years of tech startup experience and believe in the MVP approach of shipping early and often.