ScrumBUT is an interesting term for a Scrum team. I have met a lot of Scrum team that has never been performance team because of this thought “Agile and especially Scrum normally welcome the changes, Scrum itself is just a framework so we always need to modify it to work for us”. This idea doesn’t seem wrong because Scrum provides the method that helps the team finds it best process itself; but modifying Scrum before the team totally own it seems a bad idea. Because Scrum is very simple and a minimise framework, the team should follow Scrum guide for being stable before thinking about adjustment. Remember, the adjustments just bring the best values while the team owns Scrum to deep understand which is suitable for it. And please adjust, don’t modify it.

ScrumBUT is practising Scrum without following Scrum guide:

“We use Scrum BUT we don’t have Daily Scrum”

“We use Scrum BUT we do Sprint Retrospective for 5 hours”

ScrumBUT of course isn’t recommended by the Scrum organisations. In my opinion, practising Scrum or ScrumBUT doesn’t matter, if it can bring the good values. But the important thing is: Is the team aware of practising Scrum or ScrumBUT? The team practises ScrumBUT because of ability of following Scrum guide or adjustment need? Is there any reason, evidence shows that practising ScrumBUT brings more values? If these questions are well answered, ScrumBUT brings more values and it should be recommended. But, practising ScrumBUT without deep understand about Scrum is normally a pitfall, be careful.

If there are many BUT, the team isn’t practising ScumBUT; it’s following another process that might unrelated to Scrum. Then why does the team need Scrum? It happens in 2 cases: or team has high knowledge and practice to give another method (there are few teams); or the team in “Scrum beginning” period.

Somebody talks to me “my team is practising Scrum because we have daily standup meeting”. “No, you don’t practise Scrum, you just practise only 1 Scrum event. It isn’t ScrumBUT as well”.

1,442 total views, no views today

Code refactoring là hoạt động chỉnh sửa khiến source code dễ đọc hơn, được tổ chức khoa học hơn, và (có thể) có kiến trúc / cấu trúc tốt hơn nhưng không làm thay đổi hành vi của hệ thống về mặt chức năng.

Việc này giống như chúng ta sắp đặt lại hệ thống điện trong nhà theo một cách khoa học hơn nhưng vẫn đảm giữ nguyên vị trí và chức năng của những công tắc, ổ cắm trên tường. Tôi muốn lấy ví dụ này để bạn hiểu rằng, những gì nhóm phát triển làm với code refactoring hoàn toàn “nằm trong bức tường”, nơi mà khách hàng hoàn toàn không nhìn hay cảm nhận được; nhưng lại rất quan trọng, đặc biệt trong dự án thực hành Agile. “Tôi muốn có một ổ cắm điện ở vị trí này”, sau 10 lần hoàn thành yêu cầu đó từ khách hàng, hệ thống dây điện chắc chắn sẽ chứa nhiều bất cập và không dễ bảo trì. Việc sắp đặt lại những dây điện này một cách hợp lý nhưng vẫn đảm bảo được chức năng hiện có giúp chúng ta sẵn sàng cho yêu cầu về một ổ cắm điện thứ 11. Và thật may là code refactoring thì thường không “tốn kém” và phức tạp như việc đục các bức tường để sắp đặt lại hệ thống dây điện. Vì vậy, chúng ta cũng có thể (và nên)  làm việc này thường xuyên.

Thực hiện code refactoring như thế nào? Vấn đề này thậm chí là quá nhiều cho cả một cuốn sách. Những cách thức đơn giản nhất bạn có thể tham khảo tại http://refactoring.com của huyền thoại Martin Fowler. Tại đây bạn có thể tham khảo những kỹ thuật đơn giản nhất và dấu hiệu nhận biết một đoạn code có thể được refactor; từ chuyện đơn giản nhất như chuyển 2 đoạn code giống nhau thành một hàm đến sự liên kết giữa các đối tượng nhằm đảm bảo tính hướng đối tượng của chương trình. Trang web này thực sự hữu ích với những hệ thống thiết kế theo tư tưởng hướng đối tượng (phù hợp với đa số những mã nguồn hiện giờ), nhưng cũng rất tốt với những tư tưởng lập trình khác. Một chú ý hay là, đôi khi bạn thấy hướng dẫn refactor một đoạn code từ A sang B và nơi khác lại hướng dẫn refactor đoạn code từ B sang A. Điều này không mâu thuẫn, bởi “A hay B tốt hơn?” thì chỉ chính bạn mới có câu trả lời xác đáng trong ngữ cảnh của source code hiện tại. Tuy vậy, vẫn sẽ có những chuẩn chung để một đoạn code được coi là “tốt” hay “dở”; ví dụ, đặt tên biến là a là điều không chấp nhận được trong phát triển phần mềm (nơi duy nhât tôi thấy cách đặt tên biến này phát huy tác dụng là trong những cuộc thi lập trình với source code ngắn và thời gian ganh đua tính bằng mili giây). Và hãy nhớ rằng, code refactoring không làm thay đổi hành vi của chức năng hay hệ thống; do đó, kết quả của việc kiểm thử phải không đổi.

Khi nào thực hiện code refactoring? Về lý thuyết, hãy thực hiện code refactoring bất cứ khi nào có thể. Trước khi commit, mỗi lập trình viên cần đọc lại những đoạn code mình đã viết và xem có thể cải tiến được không. Sau một thời gian, nhóm phát triển cần cùng nhau nhìn lại xem có thể cải tiến ở những điểm nào và cùng thực hiện code refactoring. Tuy nhiên, vấn đề không đơn giản như vậy.

Điều gì ngăn cản code refactoring? Đây là một câu hỏi rất thú vị. Tôi đã gặp rất nhiều nhóm thực hành Agile nhưng không bao giờ thực hiện code refactoring, với những lý do chính như sau:

  • Trình độ kém. Khi nhóm phát triển không có hiểu biết sâu sắc về OOP thì đương nhiên những đoạn code ban đầu viết ra sẽ rất “dở”, nhưng quan trọng là họ hoàn toàn không biết rằng nó “dở”. Việc này càng nguy hại nếu không thực hiện code refactoring bởi nhóm sẽ mãi duy trì năng lực hiện có.
  • Chấp nhận. Sau một thời gian dài, nhóm phát triển nhận ra có rất nhiều đoạn code “dở” nhưng nhóm vẫn chấp nhận bởi số lượng code “dở” là quá nhiều và có tư tưởng chấp nhận “sống chung với lũ”, hoặc nghĩ tới việc viết lại toàn bộ hệ thống.
  • Không có thời gian. Đây là lý do khá xác đáng; bởi như tôi nói ở trên, khách hàng hoàn toàn không nhận được lợi ích trực tiếp từ code refactoring, nên khó thuyết phục họ trả tiền cho nhóm phát triển thực hiện code refactoring. Tuy vậy, việc lắp ổ điện thứ 11 mất 10 giờ, thay vì 2 giờ cho ổ điện thứ 1, thì cũng là tiền của khách hàng mà thôi (và điều này có thể nảy sinh nghi ngờ từ khách hàng rằng năng lực hoặc thái độ làm việc của nhóm đã kém đi).

Tuy vậy, những lý do này sẽ đẩy cả nhóm phát triển vào một vòng luẩn quẩn không hồi kết: trình độ kémsức ép thời gian đưa ra những đoạn code “dở”, không thực hiện code refactoring khiến trình độ không được cải thiện, sau một thời gian đành chấp nhận, khiến sức ép thời gian càng lớn, không thể thực hiện code refactoring, và trình độ không được cải thiện… Và dự án, từ đam mê bỗng thành gánh nặng với nhóm phát triển, khiến động lực làm việc không còn đúng.

Vậy giải pháp là gì? Từ góc độ một lập trình viên, tôi cho rằng việc không thực hiện code refactoring là trách nhiệm của lập trình viên; do họ không đủ đam mê và trách nhiệm cần thiết với “đứa con tinh thần” của mình; không khác một nhà văn viết ra những tác phẩm rẻ tiền. Tuy vậy, người “lãnh đạo” trong dự án Agile cũng phải có trách nhiệm tạo ra những “khoảng lặng” về những chức năng cần bổ sung để nhóm phát triển thực hiện code refactoring. Việc này diễn ra càng đều đặn, trình độ và năng suất của lập trình viên càng cao bởi code refactoring chính là một cách nâng cao tay nghề và hiểu biết sâu sắc dựa trên những best practice cải tiến họ tốt hơn. 1 ngày dành cho code refactoring hôm nay có thể giảm bớt 10 ngày phát triển buồn tẻ sau này.

Giải pháp cho source code đã quá “cũ”? Khi chúng ta “động đâu cũng thấy vấn đề” trong source code, chấp nhận hoặc làm lại từ đầu thường là giải pháp; tuy vậy, cả 2 giải pháp này đều rất tốn kém. Code refactoring có thể là một giải pháp:

  • Sử dụng công cụ phân tích source code (tôi sẽ đề cập ở những bài viết sau) để tìm ra những đoạn code “dở”
  • Nhóm phát triển cùng quét nhanh qua mã nguồn để đánh giá và tìm thêm những vấn đề
  • Ước lượng tổng thời gian cần cho code refactoring
  • Định nghĩa và lên kế hoạch việc kiểm thử. Việc này rất quan trọng vì code refactoring phải đảm bảo không thay đổi hành vi của chức năng và hệ thống. Lúc này automation test được ưu tiên bởi khối lượng kiểm thử nhiều. Không nên (thậm chí là nghiêm cấm) thực hiện code refactoring nếu không có kế hoạch kiểm thử tốt.
  • Lên kế hoạch và thực hiện dần, từng phần. Thật tuyệt vời nếu chúng ta có toàn bộ thời gian để thực hiện; nếu không, hãy thực hiện từng phần song song với quá trình phát triển tiếp. Và hãy kiên nhẫn, chúng ta không thể thấy kết quả chỉ sau 1 vài ngày.

Thât ra, code refactoring là công việc rất đơn giản, đến mức người ta dễ dàng bỏ qua code refactoring để nghĩ tới architect refactoring hay structure refactoring. Nhưng theo tôi, khi thực hiện code refactoring tốt, những design pattern sẽ dần được hình thành và từ đó kiến trúc mới cũng sẽ được hình thành. Rất ít khi chúng ta cần tới architect refactoring; và tôi cũng không tham vọng giới thiệu những điều này sớm.

2,220 total views, no views today

Đặt mục tiêu đúng là một việc rất quan trọng bởi mục tiêu định hướng công việc chúng ta làm. Có lẽ tôi không cần phải nói nhiều hơn về điều này. Đặt mục tiêu một cách khoa học quan trọng hơn rất nhiều. Theo nghiên cứu của ĐH Scranton, chỉ 8% những người được khảo sát đạt được mục tiêu trong năm 2014 của mình, đa phần thất bại do không đặt được mục tiêu một cách khoa học.

Một phương pháp đặt mục tiêu khoa học được giới thiệu từ những năm 1980 là SMART, nhưng hiện nay cũng không hẳn nhiều người biết hoặc áp dụng thành công. Tôi chỉ giới thiệu sơ qua về phương pháp này, bởi bạn có thể tìm thấy rất nhiều bài học về SMART thông qua Internet.

Phương pháp đặt mục tiêu SMART dựa trên 5 yếu tố tạo nên từ này: S.M.A.R.T = Specific, Measurable, Achievable, Relevant, Time-Bound.

  • Specific (Cụ thể): Nếu mục tiêu mông lung, làm sao chúng ta biết phải làm gì? WHAT.
  • Measurable (Đo được): Nếu mục tiêu không đo được, làm sao chúng ta biết khi nào mình đã đạt được? WHERE.
  • Achievable (Khả thi): Nếu mục tiêu không khả thi, làm sao chúng ta thực hiện? HOW.
  • Relevant (Liên quan): Nếu mục tiêu không có sự liên quan (tới cuộc sống, những mục tiêu khác), chúng ta đạt mục tiêu có ý nghĩa gì? WHY.
  • Time-Bound (Có thời hạn): Nếu mục tiêu không giới hạn thời gian, khi nào nó được đánh giá? WHEN.

Ví dụ, mục tiêu “năm nay kiếm được nhiều tiền” không khoa học. Thế nào là nhiều (measurable)? 1 tỷ USD là nhiều (achievable)? Tiền để làm gì (relevant)?

Một mục tiêu tốt hơn là “để phục vụ cho công việc (relevant), năm nay (time-bound) kiếm được thêm 50 triệu (measurable) để mua laptop mới (specific) nhờ việc bán hàng online (achievable)”. Yếu tố achievable là khó nhất, nếu chúng ta đã có kỹ năng bán hàng online tốt, đã có vốn thì mục tiêu này khả thi. Ngược lại, mục tiêu không khả thi.

Gần đây, một phát triển mới từ phương pháp S.M.A.R.T là S.M.A.R.T.E.R, được thêm vào 2 yếu tố nữa E.R. Có nhiều biến thể của phương pháp này, nhưng phiên bản tôi thấy thích nhất là E.R = Evaluate, Re-Adjust.

  • Evaluate (Đánh giá): Một mục tiêu khoa học cần có trong đó khả năng đánh giá được qua từng giai đoạn hoặc tiến trình đạt được mục tiêu.
  • Re-Adjust (Điều chỉnh): Trong quá trình thực hiện, nếu mục tiêu đã lỗi thời hoặc cách tiếp cận của chúng ta không còn đúng, mục tiêu ngay lập tức được điều chỉnh lại cho phù hợp với tình hình hiện tại.

Ví dụ, với mục tiêu chúng ta đã có theo S.M.A.R.T ở trên, có thể bổ xung như sau “để phục vụ cho công việc (relevant), năm nay (time-bound) kiếm được thêm 50 triệu (measurable) theo từng tháng (evaluate) để mua laptop mới (specific) nhờ việc bán hàng online (achievable)”. Như vậy, cứ sau mỗi tháng, chúng ta lại đánh giá lại quá trình đạt được mục tiêu. Nếu đến tháng 5, chúng ta chỉ kiếm được 10 triệu thì cần phải điều chỉnh lại mục tiêu hoặc cách làm. Cũng có thể, đến tháng 5 chúng ta vẫn chưa phải điều chỉnh gì với mục tiêu là “để phục vụ cho công việc (relevant), năm nay (time-bound) kiếm được thêm 50 triệu (measurable), tập trung vào tháng 6,7 (Euro 2016) để mua laptop mới (specific) nhờ việc bán hàng online (achievable)”. Cũng có thể, tháng 4, chúng ta trúng xổ số 100 triệu, thì mục tiêu cũng đã lỗi thời, có thể nên loại bỏ (mục tiêu “kiếm thêm 50 triệu mua laptop” đã hoàn thành, nhưng nếu chúng ta đặt mục tiêu “kiếm thêm 50 triệu mua laptop và thử sức trong lĩnh vực kinh doanh” thì việc trúng xổ số có rất ít liên quan để mục tiêu này bị loại bỏ).

Tóm lại S.M.A.R.T.E.R = Specific, Measurable, Achievable, Relevant, Time-Bound, Evaluate, Re-Adjust

Xin nói thêm lý do khiến tôi thích phiên bản S.M.A.R.T.E.R này vì nó rất “agile”: chúng ta luôn phải đánh giá và điều chỉnh liên tục để có cách làm phù hợp nhất, nhằm hoàn thành phần công việc có giá trị nhất giúp đạt được mục tiêu có ý nghĩa nhất. Dù vậy, có thể bạn cho rằng yếu tố Evaluate và Re-Adjust gắn với quá trình thực hiện mục tiêu, không gắn với việc xây dựng mục tiêu ban đầu. Nhưng mục tiêu đặt ra là để đạt được và có ý nghĩa, đâu phải chỉ để “đặt ra”, phải không? Hơn nữa, qua ví dụ trên bạn cũng thấy yếu tố Evaluate hoàn toàn có thể được đặt ra ngay trong lúc xây dựng mục tiêu.

Tuy vậy, vẫn còn nhiều phương pháp S.M.A.R.T.E.R khác có thể phù hợp hơn với bạn. Bạn có thể tham khảo thêm tại:

https://www.wanderlustworker.com/setting-s-m-a-r-t-e-r-goals-7-steps-to-achieving-any-goal/

5,244 total views, 3 views today

My talk about the life although I learn the knowledge and technique from my daily works.

It’s actually too short for my 1.5 hour talk but this slide can cover my ideas for having a happy life. Here are:

Firstly, we need to understand what the life is. I recommend the great book Our Ultimate Reality, Life, the Universe and Destiny of Mankind by Adrian P. Cooper who is the mind leader of mankind. I learnt too many things in this book, from the the ‘basic things’ such as human, life, money…etc to the life laws.

Secondly, we need to understand ourself. It’s the key to know exactly what make us happy in the daily life. In fact, a person feels happy in his good point that the 4 parts of a human balanced: body, emotion, mind and spirit. This point, of course, is very different for each person.

When we know the point where we feel happy while standing on, we know exactly who we will be. Then we try to be? No, trying makes us unhappy. We need to think we are being and staying this point – it makes us happy (just because we know that it makes us happy) :). If we want to be the rich men, we need to think that we are the rich men and we act like the rich men. If we want to be the nice men, we need to think that we are the nice men and we act like the gentlemen, treat everybody by the nice actions. It’s the attraction law; if we act like the rich men, we attract the Source to give us money; if we act like the gentlemen, we attract the Source to give us the good mood, good spirit and open mind. The law that you can find in any self-help book.

BUT how we act like a rich men if we don’t have money? How we act like the gentlemen if we are feeling stress? That’s no self-help book gives us 🙂

Then I find the root cause is how we deal with our works to let us more productive to make money, to reduce stress,… and achieve the success to make us happy.

Manage works is for productivity

Manage productivity is for improvement

Manage improvement is for success

Manage success is for happiness

Manage happiness is for life

While we have a good way to manage our works, we are more productive and increate both quantity and quality of works. It makes us having good enough time, energy and attention for the things that make us happy.

While we look back to find the way to increase our productivity, we are improved. It makes us reaching to the next level, and we are always looking for the new things that make us happy.

While we have a lot of improvement, we are ready for the success. No matter our starting point is, if we improve ourself day by day, we will be of course successful. No matter small or big success, it makes us motivated and happy.

Then think big but do small. Small achievements make us happy day by day to build the big success. That’s called manage success.

But my talk just stop at the “manage productivity for improvement”, if you think it helps, I will go forward with the rest points 🙂

1,617 total views, no views today

Hôm rồi lướt Facebook, vô tình đọc được comment trên status của anh bạn, đại thể là thế này: Ở Việt Nam, mấy ông đào tạo về quy trình toàn hội đọc với dịch sách, chẳng có kinh nghiệm dự án thực tế gì, không áp dụng được. Không dài dòng, khẳng định luôn: Tình hình đó không chỉ ở Việt Nam, ở đâu ở trên quả đất này đều thế hết; có khác là nhiều ông đào tạo về quy trình ở “nước ngoài” thì có viết sách, không chỉ có dịch sách (nói “nước ngoài” là khoảng 200 nước khác Việt Nam, cũng có khoảng trăm nước chỉ có sách dịch thôi, nên không phải cứ “nước ngoài” là to đâu ạ).

Ví dụ về thế giới bóng đá cho dễ hiểu đi: cầu thủ là người có kinh nghiệm thực chiến, huấn luyện viên (HLV) là người đào tạo và huấn luyện; thì có mấy kiểu phổ biến, xin kể ra mấy điển hình: Đá bình thường (có khi chẳng biết đá), huấn luyện tốt: Alex Furguson – rất bình thường với sự nghiệp cầu thủ nhưng là một HLV đại tài; Jose Mourinho thậm chí không biết đá bóng. Đá giỏi, huấn luyện dở: Maradona – cả thế giới phải ngả mũ về tài năng bóng đá nhưng dẫn dắt đội tuyển Argentina cực “bết bát”. Đá giỏi, huấn luyện giỏi: Pep Guardiola – thôi khỏi bàn, ai cũng biết. Đá dở, huấn luyện cũng dở luôn: Toshi Miura – ai phản đối không?

Nói vậy để thấy rằng, không có mối liên hệ nào đảm bảo việc một người thành công trên cương vị cầu thủ sẽ đảm bảo thành công trên cương vị HLV. Rồi, bây giờ một CLB cần HLV, chọn ai giờ?

Pep Guardiola thì quá tuyệt vời, nhưng hãy nhớ, số này không nhiều nên luôn là hàng “hot”, vậy nên quyền lựa chọn đôi khi không thuộc về CLB dù có rất nhiều tiền. Toshi Miura thì chẳng bao giờ “đắt hàng”, nhưng cũng hữu dụng với mấy CLB hạng 2, 3 của Nhật. Phần nhiều HLV “được chào đón” thuộc dạng “đá thường, huấn luyện tốt” hoặc “đá hay, huấn luyện dở”.

Tại sao? Bởi chung quy mỗi người cũng chỉ có 24 giờ trong một ngày mà thôi, tập trung vào “học thuật, chiến thuật bóng đá” thì phải bớt thời gian tập luyện thực địa trên sân; và ngược lại. Đấy là quy luật chung, một số ít dành hết thời gian khác của cuộc sống mới hoàn thành tốt cả 2 vai trò. Người ta tin dùng Maradona, Didier Deschamps… vì cho rằng những kinh nghiệm thực tế sẽ giúp họ thành công trên cương vị HLV. Ngược lại, người ta tin dùng Jose Mourinho, Villas Boas… vì cho rằng họ đã kinh qua rất nhiều “lý thuyết” bóng đá và sẽ thành công trên thực địa. Ai cũng có lý cả. Bởi một số thành công, một số thất bại.

Hết bóng đá, quay trở lại chuyện đào tạo: thì cũng vậy cả thôi. Số “sang chảnh” có Pep Guardiola hay số “cực chẳng đã” chọn Toshi Miura thì khỏi bàn; vì cả cung và cầu đều ít. Số đông còn lại nên chọn ai, Maradona hay Mourinho? Lợi hại ra sao?

Chọn Maradona là chấp nhận ưu tiên kinh nghiệm. Kinh nghiệm là con dao sắc hai lưỡi: nó ngay lập tức phát huy hiệu quả tốt nếu ngữ cảnh hiện tại giống (hoặc gần giống) với quá khứ; ngược lại là đứt tay ngay. Đặc biệt trong chuyện đào tạo. Không ai lấy thuần kinh nghiệm ra để đào tạo cả. Những thành công anh gặp trong quá khứ tạo lối mòn cho thất bại sắp tới. Những thất bại anh gặp trong quá khứ ám ảnh chuyện “quản lý rủi ro”, làm chậm quá trình thành công. Điều quan trọng là, anh sẽ thiếu lý thuyết để có góc nhìn rộng, hiểu biết cho những phương án dự phòng trong trường hợp kinh nghiệm không phát huy tác dụng. Với Maradona, đội bóng chỉ tấn công; nhưng xin lỗi, đấy là thời của ông, giờ đây đội bóng cần biết cả tấn công và chống phản công.

Chọn Jose Mourinho là chấp nhận ưu tiên lý thuyết. Lý thuyết là con dao cùn một lưỡi: nó không ngay lập tức phát huy hiệu quả trong bất cứ điều kiện hiện tại nào, nhưng an toàn. Người được đào tạo phải đổ nhiều thời gian hơn để nghiên cứu sự phù hợp giữa lý thuyết và thực tế để có những điều chỉnh phù hợp. Việc này đương nhiên là khó hơn, tốn nguồn lực hơn, cũng có thể thất bại, nhưng thành công sẽ bền. Lý thuyết Mourinho có chỉ rất rõ: đá ở Premier League, Seria thì phải ưu tiên hạn chế bàn thua, đá ở La Liga thì cứ ghi nhiều bàn thắng là xong.

Nói như vậy để hiểu rằng, người làm đào tạo nghiêm túc là người có xu hướng lý thuyết nhiều hơn. Tất nhiên là có cả kinh nghiệm thực chiến nữa thì tốt (nhưng mỗi người chỉ có 24 giờ trong một ngày thôi đấy, thêm cái này đương nhiên sẽ bớt cái kia). Ngay cả khi họ có nhiều kinh nghiệm thực chiến, đó cũng chỉ coi như phần bonus hoặc minh hoạ cho lý thuyết mà thôi. Bởi vậy mới nói, kinh nghiệm là “chia sẻ” chứ đâu phải “đào tạo”, không ai dám mài kinh nghiệm ra để đào tạo cả. Đã lập trình viên nào thành công sau khi nghe Nguyễn Hà Đông “chia sẻ kinh nghiệm” thành công với Flappy Bird đâu? Người làm đào tạo nói về cách làm ý tưởng, lập trình, ASO, marketing… đúng nghĩa – điều đảm bảo thành công đến chậm nhưng bền.

Ví dụ vậy, để mọi người hiểu rằng người làm đào tạo dù có bao nhiêu lý thuyết hay kinh nghiệm thực chiến cũng đều ưu tiên lý thuyết; thậm chí cố tình che giấu phần kinh nghiệm để tránh người được đào tạo đi theo con đường đó trước khi có hiểu biết nền tảng lý thuyết đầy đủ. Khi móng đã chắc, hãy phân tích đến kinh nghiệm. Trong các sự kiện, talk, tôi cũng thường quan tâm đến nền tảng kiến thức của diễn giả là gì, lý thuyết và sự kiện gì thúc đẩy họ đưa ra những quyết định hơn là đơn thuần kinh nghiệm được họ chia sẻ.

Tôi là người hâm mộ Carlo Ancelotti – một quý ông lịch lãm, người thành công trên cương vị cầu thủ nhưng lại không quá mang kinh nghiệm đó vào sự nghiệp HLV, rất uyển chuyển trong việc huấn luyện, đào tạo ở nhiều môi trường khác nhau, với những con người, ngữ cảnh khác nhau, và đều thành công rực rỡ. Đó là sự kết hợp hoàn hảo giữa kinh nghiệm thực chiến và triết lý, nền tảng lý thuyết tốt. Nhưng HLV như Ancelotti trên thế giới có được bao nhiêu? Nên tôi chờ đợi một thần tượng khác của mình, Zizou 🙂

1,588 total views, no views today

ScrumBUT là một khái niệm rất đáng lưu tâm với những nhóm thực hành Scrum. Tôi đã tiếp xúc với rất nhiều nhóm Scrum không đạt được hiệu quả cao bởi tư tưởng “Scrum và Agile nói chung chào đón những thay đổi, bản thân Scrum cũng là một framework nên việc thay đổi Scrum cho phù hợp là đương nhiên”. Ý kiến đó không sai, bởi Scrum cung cấp cách thức giúp nhóm tìm ra quy trình hợp lý cho chính mình; song việc chỉnh sửa Scrum khi nhóm chưa thực sự làm chủ Scrum thường là một quyết định thiếu sáng suốt. Bởi Scrum đã rất tối giản, các tổ chức khi triển khai Scrum cần làm theo hướng dẫn Scrum để có sự ổn định trước khi đưa ra những điều chỉnh, bởi những điều chỉnh chỉ đạt hiệu quả tốt khi chúng ta thực sự làm chủ bằng cách thực hành đúng để hiểu Scrum có phù hợp hay không.

Khái niệm ScrumBUT để chỉ việc thực hành Scrum không theo chỉ dẫn:

“We use Scrum BUT we don’t have Daily Scrum” – “chúng tôi thực hành Scrum nhưng không thực hiện Daily Scrum”

“We use Scrum BUT we do Sprint Retrospective for 5 hours” – “chúng tôi thực hành Scrum nhưng sử dụng 5 giờ cho sự kiện Sprint Retrospective”

ScrumBUT đương nhiên là không được khuyến nghị từ các tổ chức đào tạo Scrum. Nhưng theo tôi, việc thực hành Scrum hay ScrumBUT không quan trọng, nếu việc làm đó mang lại hiệu quả cao. Điều quan trọng là: Nhóm có nhận ra mình đang thực hành Scrum hay ScrumBUT không? Nhóm thực hành ScrumBUT vì không thể thực hành đúng Scrum hay cần sự điều chỉnh? Có lý do, bằng chứng nào cho thấy việc thực hành ScrumBUT cho hiệu quả cao hơn không? Nếu 3 câu hỏi đó được trả lời thoả đáng, việc thực hành ScrumBUT sẽ cho hiệu quả cao và nên được khuyến khích. Tuy vậy, việc thực hành ScrumBUT nếu thiếu những lý thuyết thường là cạm bẫy, hãy cẩn thận.

Nhưng nếu có quá nhiều BUT, nhóm cần biết rằng mình đã không còn thực hành ScrumBUT nữa, mà đang đi theo 1 quy trình hầu như không còn liên quan tới Scrum. Lúc đó nhóm cần một tên gọi khác cho quy trình của mình, đừng sử dụng Scrum. Nhưng nếu vậy, nhóm cần Scrum để làm gì? Chỉ có 2 trường hợp dẫn tới kết quả này: hoặc nhóm đã có hiểu biết và thực hành rất cao để đưa ra một phương pháp khác (rất ít); hoặc nhóm đang trong giai đoạn “chưa hiểu gì về Scrum”.

Thậm chí nhiều người gặp tôi và khẳng định “nhóm của tôi đã thực hành Scrum vì chúng tôi có standup meeting hàng ngày”. “Không, bạn thậm chí còn không thực hành ScrumBUT, bạn chỉ thực hành 1 trong nhiều sự kiện của Scrum mà thôi.”

1,238 total views, no views today

Khi cá nhân muốn cải thiện sự thành công, chúng ta thường có xu hướng mở rộng tập kỹ năng cũng như làm thêm việc. Doanh nghiệp cũng vậy, để cải thiện sự thành công, họ thường có xu hướng mở rộng lĩnh vực kinh doanh. “Sự thành công” ở đây đươc đo bằng thu nhập của cá nhân và doanh thu của tổ chức. Điều này khá dễ hiểu bởi chúng ta kỳ vọng “trứng sẽ không nằm trong một giỏ”, doanh thu sẽ được tăng lên khi thị trường tăng lên bởi việc kinh doanh nhiều lĩnh vực. Thời điểm chiến lược này được đưa ra thường là khi chúng ta nhận thấy việc tăng thêm thu nhập, doanh thu từ lĩnh vực hiện tại trở nên khó khăn hơn bởi chúng ta không còn duy trì được lợi thế cạnh tranh hoặc thị trường trở nên bão hoà hoặc chúng ta có “những đồng tiền rảnh rỗi”. Một ví dụ dễ hiểu là, khi một lập trình viên nhận mức lương $2000 / tháng, anh ta sẽ nghĩ tới việc dành số tiền tiết kiệm được cho việc mở 1 cửa hàng thời trang hay 1 hàng cafe; một doanh nghiệp kinh doanh gỗ sau khi một vài năm không tăng trưởng về mặt doanh thu, họ nghĩ mình nên mở rộng việc kinh doanh bất động sản.

Dù một cá nhân làm thêm một công việc nằm ngoài tập kỹ năng chính của anh ta hay một doanh nghiệp mở rộng lĩnh vực kinh doanh, họ (anh chàng lập trình viên và CEO công ty kinh doanh gỗ) đều có một điểm chung, là họ đều có thêm 1 việc nữa cần hoàn thành. Và liệu họ có thực sự cần công việc này cho mục đích (cải thiện thành công) của mình? Không chắc chắn.

Bởi thật tiếc việc “thị trường đã bão hoà” thường là một nhận định không chính xác. Đúng hơn là “thị phần đã tới giới hạn với khả năng cạnh tranh hiện có” hoặc “thị trường đã bão hoà với khả năng sáng tạo hiện có”. Vì vậy, thay vì quyết định rằng “cần thêm một công việc nữa”, chúng ta hoàn toàn có thể dành nguồn lực đó (hoặc thậm chí, “cần bỏ thêm 1 công việc nữa” để có thêm nguồn lực) để cải thiện khả năng cạnh tranh hiện có. Bởi việc mở rộng sang một lĩnh vực khác ít liên quan sẽ làm chúng ta đánh mất năng lực cốt lõi và lợi thế cạnh tranh hiện có và rồi cũng sẽ lại loanh quanh với những vấn đề về mở rộng thị trường. Và vòng luẩn quẩn sẽ không có hồi kết: không mở rộng được thị phần / thị trường, mở rộng lĩnh vực kinh doanh…

Một lập trình viên, thay vì nghĩ rằng “cần thêm một việc nữa” và mở một cửa hàng thời trang – lĩnh vực mà anh ta hoàn toàn không có nhiều kiến thức và kỹ năng về kinh doanh – có thể lựa chọn việc dành thời gian, tiền bạc đó cho những khoá đào tạo nhằm nâng cao khả năng hiện có để có mức thu nhập lớn hơn. Tất nhiên nếu anh ta mở cửa hàng thời trang chỉ vì mục đích tăng thêm thu nhập, hoàn toàn không phải bởi anh ta đam mê kinh doanh. Hoặc anh ta nên kiếm thêm tiền từ việc mở một vài lớp học lập trình hay tiếng Anh, nơi anh ta có lợi thế cạnh tranh thực sự bởi những gì mình đang có.

Một doanh nghiệp kinh doanh gỗ, thay vì nghĩ rằng “cần thêm một việc nữa” và mở thêm lĩnh vực kinh doanh bất động sản, có thể cắt giảm bộ phận giao vận hiện có để dành nguồn lực phát triển những sản phẩm gỗ tốt hơn. Hoặc họ nên mở rộng sang việc sản xuất giấy, nơi họ có lợi thế cạnh tranh bởi nguồn cung ứng sẵn có.

Facebook, sau khi đạt ngưỡng 1 tỷ người sử dụng, họ nghĩ rằng thị trường đã bão hoà (1 tỷ người sử dụng là một con số quá lớn để tin điều đó là đúng), họ mở rộng bởi hàng loạt sản phẩm mới, phần nhiều trong số đó được khai tử chỉ sau 1 tháng ra mắt. Hiện tại Facebook có 1,6 tỷ người sử dụng. Giờ đây, tôi tin rằng thị trường sẽ chỉ thực sự bão hoà khi Facebook có 7 tỷ người sử dụng.

Sự thành công của Apple ngày nay có công lớn của Steve Jobs, vì ông đã thẳng tay loại bỏ hàng trăm dự án và sản phẩm mà Apple đang có khi tiếp quản Apple vào năm 2005. Nếu nhình lại, chúng ta sẽ thấy trong danh sách đó có nhiều những dự án rất tiềm năng, thậm chí có lợi nhuận không đến nỗi nào tại thời điểm đó. Nhưng nếu chúng không được đóng lại, Apple sẽ có hàng trăm sản phẩm “làng nhàng” và không có một iPod hay iPhone cực kỳ thành công. Bởi Steve Jobs dù có tài giỏi cũng chỉ có 24 giờ một ngày và chỉ ông hiểu được giới hạn của chính mình; nếu ông góp mặt vào 5 sản phẩm, đó sẽ là 5 sản phẩm xuất sắc; nếu ông dành thời gian cho 50 sản phẩm, đó sẽ là 50 sản phẩm trung bình. Apple giờ đây có quá nhiều tiền mặt, và việc mở rộng lĩnh vực kinh doanh của họ đơn giản hơn bao giờ hết. Nhưng Tim Cook chắc hiểu rằng thêm 1 chiếc ô tô đồng nghĩa với việc iPhone sẽ không còn được chăm chút ở mức cần thiết. Tim Cook đã từng thử nghiệm “iPhone cho người có thu nhập thấp hơn” bằng phiên bản iPhone 5C và dù doanh số không đến nỗi tệ thì dự án đó cũng nên được đóng lại, thay thế bằng việc bán những chiếc iPhone phiên bản cũ với giá “mềm” hơn – cách mà Apple không cần bỏ thêm quá nhiều nguồn lực vẫn thu được hệ quả tương tự.

Satya Nadella, dù chịu mất hàng tỷ đô la Microsoft đã chi ra khi mua lại mảng điện thoại thông minh của Nokia, cũng biết rằng để khiến lĩnh vực đó sinh lời hàng triệu đô la mỗi năm là không khó, nhưng những nguồn lực đó có thể khiến ông mất nhiều tỷ đô la trong lĩnh vực điện toán đám mây. Người ta dễ dàng chỉ trích Steve Ballmer vì để Microsoft thất thế trong mảng di động dù đã đi trước Apple cả chục năm, nhưng lại rất khó để trả lời câu hỏi “nếu Steve Ballmer dồn nguồn lực vào mảng di động, liệu Microsoft có duy trì sự ổn định trong tăng trưởng và thu về hàng chục tỷ đô la từ mảng điện toán đám mây như bây giờ?”. Và nếu nghĩ khác, câu hỏi “nếu Steve Ballmer dũng cảm khai tử mảng di động, tập trung toàn bộ nguồn lực cho mảng điện toán đám mây, giờ đây Microsoft có thể thu về hàng trăm tỷ đô la từ mảng này?” còn khó trả lời hơn nhiều. Ít nhất đấy là cách Satya Nadella đang điều hành, thay vì cạnh tranh với iOS, Microsoft sống trên đó với hàng tá ứng dụng của mình như Outlook, Sunrise,…

Bởi vậy, bớt đi một công việc cũng quan trọng như làm thêm một công việc. Lợi ích không chỉ sinh ra khi làm thêm một công việc, lợi ích sinh có thể ra khi chúng ta quyết định bỏ đi một công việc. Việc xoá đi một dòng code hay loại bỏ một chức năng cũng có thể mang lại lợi ích như việc viết thêm một dòng code hay thêm vào một chức năng mới; bởi mã nguồn sẽ dễ đọc hơn, và người sử dụng sẽ thấy dễ dàng hơn. Sparrow, phần mềm ưa thích của tôi, từng một thời khuynh đảo thị trường (và được Google mua lại) vì đã làm rất tốt chức năng của một email client và chỉ như vậy, không tích hợp contacts hay calendar như những email client khác, là điển hình cho việc “làm xuất sắc một chức năng đúng”. Việc thêm một dự án có thể khiến doanh nghiệp có giá trị hơn về mặt hoành tráng khi có rất nhiều dự án, nhưng cũng khiến doanh nghiệp mất giá trị hơn trong việc kết nối những thành viên trong tổ chức và khiến các đội dự án chịu sự “lạnh nhạt” hơn từ những người quản lý. Dù rằng một số dự án có thể mang lại nhiều giá trị cho tương lai, nhưng nếu không tập trung vào những thứ hiện có, liệu tương lai có đến? Bởi hàng ngày chúng ta có quá nhiều lựa chọn, rất nhiều trong số chúng đều có tiềm năng lớn nên quyết định “thêm việc”, “giữ nguyên” hay “bớt việc” là khó khăn hơn rất nhiều. Đó thực sự là những cám dỗ và cạm bẫy. Tất nhiên, việc chuẩn bị cho tương lai là luôn cần thiết với mỗi cá nhân hay tổ chức, nhưng chúng ta cần nhận định chính xác việc gì “phải làm”, “nên làm” bởi nếu tất cả các ý tưởng đều trở thành “phải làm” đồng nghĩa với không một công việc nào trong số chúng “được hoàn thành tốt”. Do đó, mỗi cá nhân hay tổ chức cụ thể có những quyết định rất khác nhau dựa trên tình hình hiện tại của chính mình, mà chỉ họ mới thực sự hiểu capacity của mình. Bởi nghĩ tới “do the thing right” chỉ tới sau khi chúng ta quyết định được đó có phải là “right thing” hay không. Một việc không phù hợp nên được loại bỏ (hoặc trì hoãn) ngay cả khi nó đang được hoàn thành rất tốt. Chẳng phải “limit works in progress” là một trong những nguyên lý quan trọng của Lean mindset đó sao?

Có thêm một việc đã vốn không dễ dàng. Quyết định thực hiện còn khó khăn hơn. Bỏ đi một việc, ngay cả khi việc đó đang hữu ích, là khó nhất.

Hãy bớt đi nhiều nhất những lựa chọn, khi chỉ còn số công việc tối thiểu, chúng ta sẽ biết cách hoàn thành chúng ở mức độ cao nhất ngay cả trong thời gian rảnh rỗi.

1,647 total views, no views today

Here is my presentation in the monthly meetup of Agile Vietnam in August, 2015. In this session, I shared our approach and implementation for current Agile project in both mindset, team structure and technical aspects. It’s really good that I got a lot of questions during my presentation time and feedbacks afterward – lot of them conflict with my share in some points or wholeness. If you have something like that, please comment or contact me for the open discussion as you are a testing domain master who may have different approach to me, an Agile / Lean fan and have another view point of whole project and don’t just focus on testing area.

But please note:

  • My share is just in Agile project. It maybe incorrect for another project that doesn’t follow Agile method. For example, “the total cost usually doesn’t change” seems incorrect in a traditional project.
  • Our specific doings are not new or magical things – they are just a normal things that you are doing in any project. For example, unit testing is as the same as it in any project. BUT my idea is the wholeness where we can combine the separated things together and make it automated and run it everyday. It recalls to Agile testing manifesto “testing throughout over testing at the end” to “defect prevention over defect detection”. I’m sorry for lacking of recall to my share before about our continuous integration, you could find it here – it’s not the project I showed today but the idea is the same.
  • It may conflict to you because it seems to decrease the importance of tester (QC, QA) role or work. No, it helps tester (QC, QA) reduce her works by quality built-in but cannot replace her importance.

And here is my view points (again, in Agile project):

Automation testing is not a tool that let us work from Monday to Thursday and let the machine do your repeatable works in Friday. It’s a method to let us work from Monday to Friday safety by knowing our issues and preventing bugs everyday.

Yes, it recalls to“testing throughout over testing at the end” to “defect prevention over defect detection”.

We have to do the manual works for automated test, includes the testing for it. So more automated testing could be done, more manual work may need to be done.

Remember we usually refactor code / structure in Agile project instead of having a fixed design in traditional method, so we need to continuously maintain the test afterward manually.

The total cost usually doesn’t change. But whenever we want to execute large set of test cases in a short time, we can – that we normally cannot do by using people.

That means if you need to spend cost (people, effort, money, time…) for testing, its total usually doesn’t change, no matter that the automation or manual testing is implemented. So please define your objectives of applying automation testing. If you care about time reduction, please spend more money or people. Or if you care about people (team improvement), please spend more time. In my opinion, you could benefit more from automation testing in waterfall project than Agile project in maintenance cost (as it usually doesn’t change) BUT it doesn’t help in quality built-in and continuous integration run.

More unit test, fewer UI test.

Could you remember the automation testing pyramid?

Thousands thanks to you for spending time hearing me. Millions thanks to you with your feedbacks, especially your disagreements – just comment or contact me for open discussion. I may call for a coffee for the discussion in very next day, would you like to join?

2,018 total views, no views today