[Team] Team building notes

Joel Test là mang tên của Joel Spolsky - cựu PM ở Microsoft, CEO Stack Overflow, Founder của Trello. Joel đã đưa ra một bài test gồm 12 câu hỏi Yes/No. Bài test này có lẽ được ra đời từ những năm 2000 khi anh còn ở Micrsoft, nhưng bây giờ nó rất phổ biến trong các JD trên Stack Overflow.

Khi bạn trả lời những câu hỏi này, với mỗi câu trả lời Yes, team của bạn sẽ được 1 điểm. Nếu team nào có 12 điểm thì đây là một team hoàn hảo, 11 điểm ở mức chấp nhận được, còn từ 10 điểm trở xuống thì team của bạn đang gặp vấn đề.

Sự thật là ở các công ty phần mềm - không chỉ ở Việt Nam thì số điểm sẽ khoảng 2 hoặc 3, chúng ta cần nghiêm túc nhìn lại và cải thiện, bởi vì theo Joel thì ở những công ty như Microsoft họ luôn duy trì mức 12 điểm tuyệt đối.

1. Do you use source control?

Team của bạn có sử dụng phần mềm quản lý phiên bản mã nguồn như Git hay SVN?
Nếu team của bạn không sử dụng bất kỳ phần mềm quản lý phiên bản mã nguồn nào thì bạn sẽ gặp rắc rối nếu muốn các lập trình viên làm việc cùng nhau trong một dự án. Lập trình viên sẽ không có cách nào để biết thứ mà người khác đang làm. Và nếu chẳng may có lỗi xảy ra thì làm sao để họ quay trở lại vị trí không có lỗi?

Ở công ty mình mọi thứ liên quan đến mã nguồn được quản lý qua Git, khi code một thứ mới hoặc tạo 1 thử nghiệm, mọi người thường không có thói quen commit và khi lỗi xảy ra thì phản ứng thường thấy là Ctrl + Z, nhưng tổ hợp phím thần thánh này không giúp được gì nhiều bởi cái gì cũng sẽ có giới hạn của nó, Ctrl + Z cũng không phải ngoại lệ.

Ngoài ra, một trong những ưu điểm của những phần mềm quản lý mã nguồn là cách thức hoạt động của chúng tạo ra nhiều bản back ở trên nhiều máy khác nhau, và hiếm có team nào sử dụng phần mềm quản lý phiên bản mã nguồn rồi mà vẫn bị mất hết code cả. Nếu mà có thì team đấy nên giải tán.

2. Can you make a build in one step?

Câu này có nghĩa là team của bạn cần bao nhiêu bước để từ mã nguồn tạo thành 1 bản build mà người dùng có thể sử dụng được?

Ở các team xịn sò, họ tự tạo cho mình một script có thể kiểm tra mọi thứ lại từ đầu, từng dòng code, automation test, auto build, auto deploy và bất cứ thứ gì để biến mã code thành sản phẩm tới tay người dùng cuối.

Ở team mình, dù đang rất cố gắng những vẫn thể chưa đạt được level này. Việc biến mã nguồn thành sản phẩm trên tay người dùng cuối giống hệt những bước nhảy lò cò của trẻ con từ A đến Z. Có quá nhiều bước cần phải thực hiện khiến cho ông chịu trách nhiệm triển khai của team mình luôn trong tình trạng bực dọc cáu gắt, bởi vì đơn giản một sai lầm ngớ ngẩn của anh có thể khiến cả đội ngồi làm lại từ đầu.

3. Do you make daily builds?

Team của bạn có thực hiện các bản build từ mã nguồn hằng ngày?

Nghe có vẻ có gì đó sai sai, đúng không? Sai là bởi vì thời điểm Joel viết bài này là tháng 8 năm 2000, việc build từ mã nguồn hằng ngày(daily build) hay hằng đêm(nightly build) ở thời điểm ấy là rất phổ biến nhưng nó có vẻ lạc hậu so với hiện tại.
Ngày nay có quá nhiều công cụ xịn sò để anh em làm việc này, có thể kể ra như Hudson CI, TeamCity, Travis CI, Jenkin, Gitlab CI/CD, Circle CI... Với những công cụ này, các bản build được tạo ra một cách hoàn toàn tự động bất cứ khi nào code được merge vào repository chung, việc này diễn ra bất cứ lúc nào cũng được và chẳng cần đợi đến đêm.

Nhưng câu hỏi này lại không hề sai ở một khía cạnh khác. Chúng ta đang hiểu từ  "daily builds" chưa chuẩn. "Daily build" được hiểu là cả một quá trình bao gồm việc tạo ra một bản build và test để tìm ra lỗi trên bản build đó. Từ định nghĩa này chúng ta nhìn ra được một số lỗi mà chúng ta thường gặp phải: 1 là merge xong không tạo bản build, 2 là build xong không test hoặc để mấy ngày mới test một phát.

Việc build và test hằng ngày sẽ giúp cho chúng ta rất nhiều trong quá trình phát triển sản phẩm:

• Làm giảm vòng lặp edit - compile - test, thời gian này càng kéo dài sẽ khiến cho hiệu suất làm việc của chúng ta đi xuống. Nếu áp dụng daily build, bug được tìm thấy nhanh hơn, được sửa nhanh hơn, một phiên bản mới được ra lò và tester có thể confirm rằng lỗi này còn tồn tại hay không trước khi tiếp tục code mới.
• Lúc nào cũng có một phiên bản hoạt động tốt. Lập trình viên sẽ không phải lăn tăn rằng thay đổi ở thời điểm hiện tại của họ, sẽ gây lỗi cho phiên bản trước đó. Các nhóm khác như marketing, sale,  người dùng thử... bất cứ ai không cần một sản phẩm xịn nhất, họ luôn có cái để sử dụng.
• ....

4. Do you have a bug database?

Không quan tâm đến việc bạn lý giải vì sao team của bạn không có bug database. Nếu sản phẩm đang trong quá trình phát triển và không có phần mềm, database hay đơn giản 1 list trên excell để quản lý bug thì chắc chắn 100% sản phẩm ra lò sẽ có chất lượng kém.

Chúng ta thường chủ quan rằng chúng ta có thể nhớ hết mọi bug trong đầu, nhưng thực ra chẳng ai có thể nhớ qua nổi một đêm, ngày mai khi thức dậy chúng ta sẽ quên sạch. Và sẽ ra sao nếu những bug chưa được sửa này xuất hiện khi người dùng sử dụng sản phẩm?

Joel gợi ý rằng "bug database" không cần thiết phải quá phức tạp, bởi khi mọi thứ quá phức tạp thì chúng ta có xu hướng bỏ qua. Nên bạn chỉ cần giữ chúng ở mức đơn giản, gồm có:

• Các bước để tái hiện - reproduce lại bug này.
• Kết quả mong đợi
• Kết quả thực tế đang thấy
• Người đảm nhận sửa bug
• Nó đã được fix hay chưa?

Bên mình đã dùng Asana để quản lý bug luôn, nhưng tình hình vẫn chưa hiệu quả cho lắm. Hiện tại đang tìm cách triển khai nó trên Gitlab.

5. Do you fix bugs before writing new code?

Theo Joel, phiên bản đầu tiên của Microsoft Word bị coi là một project thảm họa. Nó mất quá nhiều thời gian và mọi thứ cứ trượt dài. Mặc dù cả team đã rất cố gắng nhưng càng làm thì dự án càng bị trì hoãn hết lần này đến lần khác và mãi không có sản phẩm nên hồn. Tinh thần xuống dốc và cả team căng như dây đàn. Cuối cùng họ quyết định dừng lại để suy nghĩ nghiêm túc về vấn đề mình đang gặp phải.

Một điều mà họ nhận ra là PMs đã quá khăng khăng theo schedule. Và để thỏa mãn schedule này lập trình viên phải làm mọi thứ trong tâm thế vội vã. Code cực kì xấu, lỗi xảy ra liên tục. Việc schedule đã thiết kế thiếu thời gian fix-bug là nguyên nhân khiến họ trượt dài.

Để khắc phục vấn đề này, Microsoft đã áp dụng một phương pháp có tên gọi "zero defects methodology" - dịch ra là phương pháp không khiếm khuyết. Nghe có vẻ buồn cười vì đơn giản không có phần mềm nào là không có khiếm khuyết. Nhưng chúng ta đang không hiểu đúng ý họ.

Trên thực tế "zero defects methodology" được hiểu là loại bỏ tất cả các lỗi trước khi code mới. Có thể lý giải như sau:
Thời gian từ khi code đến phát hiện bug và từ khi phát hiện bug đến lúc sửa nó càng dài thì team của bạn sẽ càng tốn chi phí. Nếu bạn phát hiện và sửa lỗi ngay khi bạn mới code xong thì bạn chẳng tốn một tý thời gian nào. Nhưng nếu bạn để đó 2 tuần, 1 tháng, bạn sẽ quên tất cả những dòng code mà bạn đã viết trước đó. Và giả sử tình huống xấu hơn, lỗi này lại liên quan đến nhiều module và chưa xác định được vị trí lỗi. Đến lúc này, việc lục lại để giải quyết nó là cả một vấn đề.

Rõ ràng, bạn sẽ tiệm kiệm thời gian hơn rất nhiều nếu chúng ta làm nó sớm hơn.
Một trong những lợi ích của việc giữ số bug luôn luôn ở mức 0 là giúp cho sản phẩm có thể ready-to-ship bất kể lúc nào. Bạn có thể phản ứng nhanh hơn với những thay đổi của đối thủ cạnh tranh khi họ tung ra một tính năng mới thay vì ngồi loay hoay với đống bug chưa xử lý.

6. Do you have an up-to-date schedule?

"Khi nào phần mềm hoàn thiện, khi nào mọi thứ sẽ xong?". Mỗi người có một cách trả lời khác nhau. Những ông lập trình viên hay trả lời rằng "Nó xong khi mọi thứ xong". Nghe rất hợp lý nhưng cực kỳ ngớ ngẩn, nhất là khi sản phẩm là một phần của câu chuyện kinh doanh.

Ngày xưa khi mình chỉ code thôi, mình cũng hay nghĩ trong đầu như thế. Thực tế khi làm lead rồi mới hiểu rằng để một sản phẩm thành công thì mọi thứ không chỉ đơn giản là code. Rất nhiều quyết định cần phải thực hiện để từ code có thể thành sản phẩm và đưa đến tay người dùng: pitching, demo, ads, sale... chưa kể là câu chuyện tài chính - khi không có sản phẩm thì không có doanh thu, không doanh thu thì lấy đâu ra tiền trả lương cho anh em.

Do đó không thể nói rằng nó xong khi mọi thứ xong một cách chung chung như thế được. Mọi thứ cần rõ ràng và chúng ta cần có một schedule cụ thể cho sản phẩm. Tất cả nội dung trong schedule sẽ được cập nhật hằng ngày, và những khoảng nghi ngại cần được các thành viên ngồi lại và trao đổi thẳng thắn, khi cần thì phải thay đổi.

Tham khảo: https://www.joelonsoftware.com/2000/03/29/painless-software-schedules/

7. Do you have a spec?

Viết mô tả sản phẩm giống hệt như yêu đơn phương và chờ tỏ tình. Ai cũng biết nó tốt nhưng không muốn làm. Lý do việc không muốn viết mô tả sản phẩm thì mình chưa rõ, nhưng có một điều chắc chắn là chẳng ông lập trình viên nào thích viết doc. Họ thích code để giải quyết vấn đề hơn là viết ra giải pháp.

Nhưng trên thực tế - ở giai đoạn thiết kế, bạn tìm ra được vấn đề, bạn có thể xử lý nó bằng cách sửa vài dòng code trong vài giây. Một khi code được viết ra, chi phí để giải quyết vấn đề bây giờ đã khủng khiếp hơn nhiều lần. Để xử lý 1 bug có khi sẽ mất cả ngày trời, trường hợp xấu nhất có thể vứt đi đống code mà mình đã tạo ra trước đó.

Một phần mềm không được thiết kế spec rõ ràng đến khi hoàn thành thường có một thiết kế tồi, và cũng có thể không bao giờ hoàn thành. Một ngày đẹp trời bạn đem phần mềm này cho sếp và bảo xong rồi và ngay sau đó sếp bắt bạn làm lại vì không vừa ý ông ấy. Nếu đến lúc này vẫn chưa có spec thì nhiều khả năng vòng lặp này lại tiếp tục.

Đội ngũ phát triển của Netscape đã gặp phải vấn đề này, khi 4 phiên bản đầu tiên như một mớ hỗn độn, nó tệ đến nỗi đội quản lý của họ phải quyết định vứt đi và bắt đầu lại. Nhưng một lần nữa họ lại gặp vấn đề với Mozilla - một dự án khác cũng mất mấy năm để có phiên bản alpha.

Joel đưa ra 2 giải pháp để giải quyết việc này. Một là yêu cầu lập trình viên viết tài liệu đầy đủ. Hai là tuyển về một ông PM, BA gì đó có thể làm được việc này. Điều quan trọng để giải quyết tận gốc vấn đề này là "no code without spec"

Tham khảo: https://www.joelonsoftware.com/2000/10/02/painless-functional-specifications-part-1-why-bother/

8. Do programmers have quiet working conditions?

Một trong lỗi ngớ ngẩn của mình khi bắt đầu ở vị trí PM là thi thoảng lại hỏi thông tin từ các thành viên trong dự án. Điều này khiến các teamate phát bực. Và mình chỉ phát hiện ra lỗi này khi đọc những dòng đầy thấm thía của Joel.

Trên thực tế, người ta đã nghiên cứu ra rằng năng suất làm việc sẽ tăng lên nhiều lần nếu cung cấp cho người thực thi khoảng không gian yên tĩnh và riêng tư, không vướng bận bất cứ điều gì. Khi những người thực hiện công việc đang không gian đạt năng xuất cao nhất, người ta gọi là "getting into flow" hoặc "in the zone".

Nhưng vấn đề nằm ở chỗ, để "getting into flow" thì không phải dễ dàng. Thời gian trung bình để một người đạt được luồng làm việc của họ mất 15' nhưng chỉ cần một tác động từ bên ngoài như chuông điện thoại, tin nhắn thông báo trên màn hình, interupt từ đồng nghiệp... thì mọi thứ lại bắt đầu lại từ đầu.

Trong trường hợp của mình, một ngày mình sẽ thi thoảng hỏi thông tin từ đồng nghiệp, việc interupt người khác khiến họ phải rời khỏi luồng làm việc, họ sẽ mất cả giờ để đạt được phong độ trở lại, hoặc cũng có thể cả buổi không thể làm được gì. Và kết quả tất yếu là họ trở nên bực mình và cáu gắt.

Thử làm một phép so sánh đơn giản để thấy việc interupt có thể gây hậu quả thế nào:
Trong ví dụ này, chúng ta có hai lập trình viên, Bách và Tuấn cùng làm trong 1 team và ngồi cạnh nhau. Tuấn có thể nhớ tên phiên bản Elasticsearch đang cài đặt. Anh ta có thể tìm thấy nó trong 30s, hoặc anh ta có thể hỏi Tuấn, mất 15 giây. Vì anh ấy ngồi ngay cạnh Tuấn nên anh ấy hỏi Tuấn. Tuấn bị phân tâm và mất 15 phút năng suất (để tiết kiệm cho Bách 15 giây).

9. Do you use the best tools money can buy?

Một trong những việc tù túng nhất mà lập trình viên từng làm là đi tìm License cho JetBrain, Intellij, Pycharm, Webstorm....vv. Đã có lúc nó ngốn đến cả buổi sáng của mình, cả buổi sáng đó không làm được gì mà lại thêm bực vào thân.

"Các team phát triển hàng đầu không tra tấn lập trình viên của họ". Bản thân là lập trình viên, mình cũng thấy việc không được dùng những phần mềm tốt nhất kéo mọi người chậm lại.

Team mình đang dùng Asana để quản lý công việc nhưng vì dùng bản miễn phí nên bị giới hạn rất tính năng: không có workload, không priority, không nhìn thấy progress... muốn sử dụng nó mọi người lại phải nghĩ cách lách luật. Và việc này quá tốn thời gian, trong khi ưu tiên lớn nhất là focus vào phát triển sản phẩm. Nhưng mà hiện tại anh em còn nghèo, mà license thì đắt, biết làm sao?

10. Do you have testers?

Một trong những sai lầm mà Joel chỉ ra ở các team đang cố gắng phát triển sản phẩm là họ không hề có tester. Cái này mình rất hiểu, nếu không có tester, team sẽ có 2 sự lựa chọn.

• Một là bỏ qua việc test - ông nào code, ông ấy tự test nhưng sản phẩm khi tung ra sẽ có rất nhiều bug - buggy product.
• Hai là cho một ông lập trình viên ra làm vai của test.

Cách thứ 2 thì hơi lãng phí, bởi đơn giản tình trung bình bạn trả 600K cho 1 ông lập trình để ông ấy làm việc của một tester có giá 250K trong cả một ngày, trong khi đó bạn hoàn toàn có thể thuê 1 ông tester với giá rẻ hơn và để cho ông lập trình viên kia phát huy hết khả năng của ông ấy.

11. Do new candidates write code during their interview?

Hầu hết các công ty phần mềm đang tuyển dụng lập trình dựa trên CV đẹp hoặc người phỏng vấn thích cách nói chuyện của họ. Những câu hỏi thường xoay quanh kinh nghiệm, nhưng rõ ràng trong nhiều tình huống cũng chẳng cần dùng đến kinh nghiệm.
Một số công ty lại tuyển người bằng cách làm bài test, nhưng ứng viên cũng có thể học thuộc và chép lại y sì.
Lời khuyên của Joel cho trường hợp này là nếu bạn tuyển lập trình viên, hãy để cho họ viết code. Cách họ code sẽ thể hiện con người họ và cách họ xử lý vấn đề.

Tham khảo: https://www.joelonsoftware.com/2000/03/23/the-guerrilla-guide-to-interviewing/

12. Do you do hallway usability testing?

"Hallway usability test" - kiểm tra tính khả dụng hành lang, dịch sang tiếng Việt thấy hơi thông minh cho lắm. Từ này được hiểu là một phương pháp test để kiểm tra tính khả dụng của phần mềm dựa trên việc chọn ngẫu nhiên người dùng thử sản phẩm.
Trong bài viết của mình, Jacob Nielsen đã chỉ ra rằng bạn chỉ cần chọn 5 người dùng là đủ để tìm ra đến 95% vấn đề của sản phẩm. Điều này khiến mình nghĩ đến một sai làm thường thấy khi mình làm thiết kế. Đó là thiết kế giao diện sản phẩm nhưng lại chẳng hỏi ý kiến người dùng, chứ đừng nói là test.

Mọi người thường nghĩ thứ mình làm là rất hoàn hảo. Nhưng thực tế khi sản phẩm được tung ra, người sử dụng sản phẩm "vả sấp mặt" mới biết là thứ mình làm ra cũng chẳng ra gì. Những sai lầm kiểu này không chỉ mất công sửa chữa mà còn bị tổn thương sâu sắc - có ai muốn đập đi làm lại đâu.

Lời khuyên cho phần này đơn giản là hãy thực hiện "hallway usability test" càng sớm càng tốt với chỉ 5 người dùng thử nghiệm để tìm ra và giải quyết những vấn đề trước khi đưa vào code hoặc trước khi launch sản phẩm.