Sau giai đoạn nhà nhà nói về “tinh thần Agile” như một thuật ngữ cửa miệng, giờ người ta bắt đầu nói về “tinh thần MVP”.

Nhưng giống như bao nhiêu thứ “tinh thần” khác được hô hào, cổ vũ mà thiếu nền tảng và thực hành rõ ràng – rất nguy hiểm. Chạy theo “tinh thần Agile” mà thiếu thực hành tạo ra một nhóm hỗn độn. Chạy theo “tinh thần MVP” mà thiếu thực hành tạo ra một sản phẩm tạp nham.

Tôi bắt đầu gặp nhiều nhóm làm sản phẩm với một công cụ MVP duy nhất là “tinh thần”:

  1. MVP không đồng nghĩa với kém chất lượng. “Có bug chút cũng được, chắc gì đã có ai dùng”. Nếu bạn đã không tin sẽ có người dùng (chức năng đó), tại sao lại làm? Rồi bạn sẽ biết người dùng không sử dụng do chức năng đó thực sự không nằm trong nhu cầu của họ hay nó tệ đến mức không thể sử dụng? Chúng ta có thể đặt nhỏ scope nhưng không được thoả hiệp với chất lượng.
  2. MVP không đồng nghĩa với “cứ làm đi”. MVP phải dựa trên giả định, phải tìm kiếm, nghiên cứu trước để củng cố phần nào cho giả định… MVP là công cụ để kiểm chứng lại giả định trong thực tế. MVP không phải là cứ có ý tưởng là lao vào làm, rồi để thực tế trả lời mà không định nghĩa rõ những giả định nào cần kiểm chứng.
  3. MVP rồi cũng phải dừng hoặc đi tiếp. Cần phân biệt rõ ràng, test là test. Khi đã đủ dữ liệu để kiểm chứng giả định, học từ đó và quyết định: đi tiếp hay dừng lại. Đã quyết định dừng lại thì phải thẳng tay loại bỏ chức năng không hữu ích. Đừng biến sản phẩm thành bãi rác.

Một sản phẩm làm sao phát triển bền vững nếu nó cứ loanh quanh trong việc “test” để tìm ra phần hồn của mình? “Tinh thần MVP” không có thực hành sẽ tạo ra một mớ hổ lốn không còn đúng với nguyên lý 80/20 mà chính MVP theo đuổi nữa.

79 total views, no views today

Lập trình không dùng if-else, có được không?

If-else thật xấu xí

Đối diện với một bài toán, lập trình viên (LTV) thường phải trả lời câu hỏi: Đây là bài toán đặc thù hay phổ quát? Bài toán “số ít” hay “số nhiều”?  Và thông thường, câu trả lời sẽ quyết định thành quả tiếp theo. Ví dụ, con chó kêu gâu gâu?” là bài toán số ít. Ta có thể viết thế này:

Thật đơn giản. “Con chó kêu gâu gâu, con mèo kêu meo meo” thì sao? Vẫn là bài toán số ít thôi.

Thật đơn giản. “Con chó kêu gâu gâu, con mèo kêu meo meo, con vịt kêu quạc quạc” thì sao? Vẫn là bài toán số ít thôi.

Thật đơn giản. À từ từ, chuyển sang switch cho đẹp mắt.

Đẹp đẽ quá rồi. Tuyệt vời.

Bạn có thấy câu chuyện trên quen thuộc trong cuộc sống hàng ngày của LTV? Khi if-else bắt đầu phát huy sức mạnh, làm ơn đừng chuyển sang switch – chẳng hay ho gì đâu. Khi if-else bắt đầu phát huy sức mạnh, chính là khi nó bắt đầu trở nên xấu xí, chính là khi chúng ta cần phải xem lại cách đánh giá bài toán của mình. Đây không phải là bài toán số ít ngay từ đoạn code #2. Các LTV cần hiểu đúng đắn rằng đây là bài toán số nhiều ngay từ khi nó có dấu hiệu là bài toán số nhiều, thay vì cứ else-if và hy vọng giữ nó là bài toán số ít.

LTV có thể sống mà không cần if-else?

Có, dùng switch thôi. Không không, tiêu đề trên để cho vui thôi. Câu hỏi thực sự là “chúng ta có thể lập trình mà không sử dụng câu lệnh rẽ nhánh (conditional statement)?”.  Vâng, không dùng if-else, switch,…?

Từ thưở đầu học lập trình, ai trong chúng ta cũng biết những thứ căn bản nhất của một ngôn ngữ lập trình (NNLT): variable, array, conditional, loop statement. Lâu dần chúng ta coi đó là điều nghiễm nhiên của một NNLT. Nhưng bạn cần biết rằng, âu lệnh if-else còn nhiều điểm xấu xí khác, từ logic cho tới runtime speed, memory… nên một số NNLT hoàn toàn không có if-else.

Vậy thì sống làm sao? Làm sao để giải bài toán trên mà không dùng if-else? OOP – polymorphism là một giải pháp. Thử xem:

Không có gì huyền bí cả, bạn có thể tham khảo tại blog của Martin Fowler về pattern này.

Nếu bạn muốn thực hành nhiều hơn, có thể tìm đến Anti-IF pattern tại đây.

No if-else

Về lý thuyết, chúng ta hoàn toàn có thể lập trình mà không sử dụng if-else. Tại các buổi Code Retreat thường có 1 session mà LTV nhất định không sử dụng if-else khi lập trình ngay cả khi NNLT đó hỗ trợ. Mục tiêu là luyện tập khả năng ít phụ thuộc vào conditional statement để hình thành tư duy abstract. Như ví dụ trên, câu lệnh if-else thực sự quá mạnh mẽ, đến nỗi các LTV không thể tránh được cám dỗ, giải bài toán theo “số ít” và tạo ra những thiết kế sai lầm, vi phạm nguyên tắc open-closed cơ bản.

Nếu bạn chưa biết thực hành thế nào, hãy tới một buổi Code Retreat cho biết.

370 total views, no views today

Trong quá trình đào tạo, tư vấn về Agile, tôi nhận được nhiều câu hỏi về “nhóm không chủ động đưa ra suy nghĩ, ý tưởng, thảo luận”, đây là vấn đề lo ngại rất cơ bản. Nhưng rất ít người nhận ra một vấn đề trái ngược hoàn toàn – nhóm có quá nhiều ý tưởng và thảo luận – điều mà tôi thấy xuất hiện nhiều hơn trong thực tế, ở một số nơi tôi huấn luyện.

Khi triển khai Agile, tư tưởng đề cao nhóm (phát triển) được cổ vũ, nhóm hiểu rằng mình là nòng cốt, trung tâm, quyết định thành bại của việc phát triển (được ScrumMaster và Product Owner hỗ trợ hết mức trong Scrum). Những thành viên trong nhóm (phát triển) yêu cầu thảo luận và tham gia thảo luận vào mọi vấn đề, và dường như không có một điểm dừng cụ thể. Tôi gọi đó là hội chứng nghiện thảo luận. Bài viết đề cập tới hội chứng này trong nhóm phát triển Agile/Scrum.

Dấu hiệu

Hội chứng nghiện thảo luận có thể được nhận biết qua những dấu hiệu:

Quá nhiều ý tưởng không được quản lý. Các thành viên nảy ra ý tưởng và thảo luận mọi lúc mọi nơi: trong các cuộc họp, trong ngày làm việc… , được đưa ra song không được ghi chép, lưu trữ lại.

Liên tục thảo luận không theo kế hoạch. Mỗi khi một ý tưởng được đưa ra là bắt đầu ngay một cuộc thảo luận không có dự định trước. Hai thành viên thảo luận bên ly cafe. Nhóm thảo luận trong buổi họp hàng ngày…

Liên tục đặt câu hỏi hoặc thảo luận trên những miền kiến thức khác với chủ đích không rõ ràng. Khi công việc đã được gán cho một thành viên cụ thể, các thành viên khác vẫn luôn mốn thảo luận thêm về cách làm. Lập trình viên quan tâm quá mức tới từng bước nhân viên marketing giới thiệu về sản phẩm và đóng góp ý kiến.

Liên tục mở rộng ý tưởng. Khi một ý tưởng được đưa ra, cuộc thảo luận bắt đầu, ý tưởng khác lại phát sinh, lại tiếp tục thảo luận không có hồi kết.

Tất cả chỉ là ý tưởng, không có nhiều hành động cụ thể. Hiệu suất sản sinh ý tưởng của nhóm vượt xa hiệu suất thực thi, nhóm dành 1/2 thời gian để sinh ra 8 ý tưởng khác nhau mỗi tuần và dành 1/2 thời gian còn lại để thực hiện 1 ý tưởng không rõ ràng.

Thực thi trên những thứ không rõ ràng. Khi thực thi một ý tưởng, những yêu cầu dừng ở mức chung chung, không rõ ràng, khiến việc thảo luận tiếp tục không dừng.

Hệ quả

Tốn thời gian. Tốn tiền.

Nguyên nhân

Hội chứng nghiện thảo luận tới từ việc thiếu cách làm việc khoa học, trong khi nhóm được cổ vũ quá mức. Sức mạnh của nhóm là không thể nghi ngờ, trí tuệ đám đông thì tốt. Nhưng khi tổ chức cổ vũ nhóm thì cũng cần song song với đó trang bị cho nhóm cách làm việc khoa học, nhận biết những vấn đề nào nhóm cần thảo luận và vấn đề nào thì không. Những thành viên trong nhóm phát triển có tần suất ra ý tưởng nhiều hơn cả Product Owner (nhóm Scrum) thường là không tốt.

Loại bỏ

Đừng nhầm lẫn giữa loại bỏ hội chứng nghiện thảo luận và loại bỏ thảo luận, giữa loại bỏ hội chứng nghiện ý tưởng và ý tưởng. Ý tưởng và thảo luận luôn luôn là điều tuyệt vời, song nhóm cần thực hiện khoa học hơn

Hãy đảm bảo có các buổi họp / workshop để brain storming. Hãy tạo không gian để những ý tưởng được “xả” ra, tập trung và đều đặn.

Hãy đảm bảo mọi sự kiện kết thúc trong khung thời gian cho phép. Buổi họp hàng ngày cần kết thúc đúng trong 15 phút, không nêu ý tưởng và thảo luận vượt quá thời gian.

Hãy đảm bảo mọi cuộc họp đều đi đúng mục tiêu ban đầu. Các buổi họp Planning là để lập kế hoạch, buổi họp Retrospective là để đánh giá lại quy trình… không thảo luận những ý tưởng bất chợt, không liên quan.

Hãy đảm bảo mọi thảo luận đều phải có kết luận cụ thể. Làm, không làm, để sau tính. Không kết thúc cuộc thảo luận, họp mà không có kết luận cụ thể. Không chuyển sang thảo luận trên chủ đề khác khi chủ đề trước đó bị bỏ lửng.

Hãy luôn nhớ tới Product Backlog. Bất cứ khi nào thành viên có ý tưởng, viết ra, đặt vào một nơi tập trung, Ideas Bag, Brown Bag… PO sẽ cùng nhóm xem xét để đưa vào Product Backlog và làm rõ sau.

Hãy thực thi. Thảo luận không có giá trị cho tới khi việc thực thi mang lại kết quả. Hãy đảm bảo những thảo luận phải được chuyển hoá thành hành động với sản phẩm cụ thể.

Cụ thể hoá và đo lường. Nhóm phải cụ thể hoá ý tưởng trước khi thực thi. Và hãy nhớ đo lường. Nếu không, ý tưởng nào cũng tốt hoặc tệ như nhau.

Kết

Trong đào tạo Agile/Scrum, những trainer luôn đề cao vai trò của nhóm, cho rằng tri thức của nhóm là tốt – điều này không sai. Song nếu nhóm không tỉnh táo nhận biết những gì nên thảo luận trong toàn nhóm, những gì nên giải quyết bởi cá nhân, việc hình thành tri thức nhóm sẽ dẫn đến chi phí khủng khiếp. Những thành viên với kỹ năng chính là testing tham gia thảo luận về kiến trúc với lý do “đóng góp một góc nhìn khác”, nhóm phát triển tham gia bàn quá sâu về kế hoạch marketing sản phẩm (không liên quan tới công nghệ)… không hề hợp lý. “Góc nhìn khác” đôi khi mang lại giá trị, song hãy nhớ, “đôi khi” – đánh đổi quá nhiều công sức chỉ để chờ đợi một “đôi khi” là lãng phí.

292 total views, no views today

Estimating by Story Point (SP) is important for a project that is following Scrum. It helps Product Owner (PO) and Development Team (DT) quickly imagine the workload of the upcoming Sprints and vision the release roadmap. Good estimation helps so much; the better accuracy is, the better Sprint goes. Then choosing the “unit” User Story (US) or the baseline of SP is important step.

Some of the Scrum guideline chose the baseline of SP by following:

  • Choose the “smallest” US and set it is 1 SP, call it a baseline.
  • Estimate other USs by comparing them with the baseline.

But this method isn’t good enough by 2 reasons at least:

  • What does it come between 1 or 2 if DT think a US is larger than 1 but less than 2 SP? We don’t have 1 and 1/2 in single card.
  • How does DT maintain the consistent compare of each US estimation? How they can make sure all 5-SP US are the same?

As my observer, following guideline above leads the new DT to less accurate estimation. One signal of not-good estimation is that SPs are distributed around a number like 1, 2, 1, 2, 1, 1… as it shows that the DT doesn’t know how to compare the difference between USs so that they choose the same number just because of the feeling.

Another way to choose the baseline is:

  • Choose the “smallest” US and set it 2 SP.
  • Find a US that is good to set 5 SP.
  • Call 2 and 5 baseline, estimate others.

The idea of the above method is:

  • DT can reserve 1 SP for the future US that maybe less than today smallest – 2.
  • DT understand how to compare US because they did it when finding 5-SP US.
  • When estimating a US, DT can choose to compare it with 2 or 5 instead of single unit for better accuracy.

The idea of choosing 2 SP as baseline is getting DT understood about US comparison and setup more anchor for the next estimation. Then choosing 2 & 5, 3 & 8, 1 & 2… doesn’t matter but my recommend is 2 & 5 because they are small enough in both absolute value and their difference.

214 total views, no views today

Ở Việt Nam, nhiều tổ chức bắt đầu chuyển mình sang thực hành Agile/Scrum. Và như một lẽ tự nhiên, nhu cầu tìm kiếm / tuyển dụng Scrum Master (SM) tăng cao. Lương thì vô kể, từ vài trăm tới vài ngàn USD. Khoảng cách rộng ghê gớm, song cũng hợp lý tuỳ thuộc vào chất lượng của SM.

  • Mức thấp nhất, SM phải biết Scrum guide, tổ chức được các sự kiện của Scrum.
  • Mức tốt hơn, SM phải có khả năng thu thập thông tin, giải quyết những trở ngại trong nhóm.
  • Mức tốt nữa, SM phải đưa ra gợi ý cho nhóm, điều hướng tới những cải tiến.
  • Mức tốt nữa, SM phải có khả năng huấn luyện, tư vấn ở quy mô ngoài nhóm và trong tổ chức

Nói chung là nhiều level, cũng giống như developer vậy – từ đọc 1 vài cuốn sách “for dummies” hoặc stackoverflow là lập trình được đến hiểu rõ về ngôn ngữ, đến hiểu rõ về công nghệ, đến hiểu rõ về nguyên lý…

Nhưng điều khác biệt là test level một developer thì dễ hơn test level một SM. Để biết developer ở level nào, tổ chức dùng những developer hiện có để đánh giá. Để biết SM ở level nào thì lại không thể làm như vậy bởi trong đa số trường hợp, SM này là người duy nhất trong tổ chức có hiểu biết về Agile/Scrum. Tôi đang nói đến việc đánh giá khi tuyển dụng, khi SM đã làm việc trong tổ chức thì việc “đo đạc” cũng dễ hơn.

Không đánh giá được làm sao mà tuyển dụng? Làm sao mà đặt được mức lương? Chịu thôi. Thị trường còn mới thì các tổ chức phải chấp nhận giả định rằng chế độ mong muốn phản ánh năng lực và nhu cầu làm việc. Nếu tổ chức thiết lập vị trí SM mà tư duy rằng “SM làm gì mà hết được 8 giờ / ngày?” là đã sai ngay từ cách đặt bài toán; thì bất kỳ lời giải nào cũng sẽ không đúng.

Một cách đánh giá khác, là thông qua chứng chỉ. Chứng chỉ không phải tất cả nhưng phần nào phản ánh kiến thức và năng lực của SM. Chứng chỉ không quá quan trọng với developer vì trình độ của họ có thể test được khi phỏng vấn; song chứng chỉ khá quan trọng với SM vào thời điểm này (như đã nói ở trên). Và vì các chứng chỉ về Agile thì thường không rẻ, nên khi các SM đã đầu tư vào chứng chỉ thì họ cũng có mong muốn nhận về mức lương tương xứng cho ROI.

Thế là, các tổ chức thì nghĩ “SM có mang lại giá trị sản xuất trực tiếp đâu mà đòi lương cao?”, SM thì nghĩ “đầu tư nhiều vậy mà ROI như này thì sao làm được?” – nên họ có ít cơ hội gặp được nhau ở một tiếng nói chung.

Lại mới chi tiền và submit SEUs để gia hạn CSP. Lý do duy nhất là trót viết CSP vào Agile Y rồi, không gia hạn thì biến mất khỏi membership directory, anh em lại bảo “nhận bừa” thì cũng kỳ. Hay anh em tẩy dùm cái dòng đó ở #agiley đi, hoặc coi như em viết sai chính tả thôi để năm sau em khỏi mất tiền nữa, được không? 

150 total views, no views today

This is how I setup a free Facebook chatbot without coding. There are many services that allow you to create a Facebook chatbot without any line of code, I like Chatfuel in the way of its UX works and other service integrations.

Setup Facebook chat & Chatfuel

A Faceboot chatbot needs a page, you need create a Facebook page: https://www.facebook.com/pages/create/
Create a Chatfuel account and a chatbot from built-in template, I use free conversation for the general purpose. https://dashboard.chatfuel.com/#/bots. Connect it with your Facebook page.

Set the chatbot scope

Users don’t find the chatbot for ‘everything’, so do Alexa, Siri, Cortana,…etc – they only support some common things like weather checking, music playing…etc. It’s fine with your chatbot can only answer things relate to your business and say no to others. People don’t ask for a bike if you are selling beer.
It’s important to set your chatbot goal then scope. It helps you know what sentences chatbot need to process. My Facebook page focus on 1) post on my blog GURUnH, 2) Agile Y information and 3) order Agile Y. Then I know there are 3 sentence groups .

Build the blocks

Chatfuel uses 2 terms Block and Group. A block is a single content chatbot gives to user. User raises a question and chatbot answers by a block. Group is a logical block container. I build the blocks by some types like text, image, menu and list…
There are 2 built-in blocks. Welcome Message is the first message user see when open the chat. Default Answer is for in-understood user input.

Build the conversations

Now you can build the simple AI based conversations with chatbot in Set Up AI area. You can add the rule-based responses like the image below. The response can be a block or text; you could use random response to make the conversation more human-able. The more sentences you add to rule, the better AI does. It means user doesn’t need to enter the exact text in the rule, he can message the similar sentences. You can choose one of various built-in languages but I recommend English, it’s much better than the rest. I use both English and Vietnamese but the AI seems not good enough.

More..

Now you can test the chatbot. But wait, you can do more like I show the latest post without coding. I just choose WordPress integration (works through Zappier). There are many integrations in Chatfuel for common use like Google search, Location…etc. You can also forward the user input, packed to JSON, to your own server for other process.
Here is simple setup a chatbot with Chatfuel, you can find a better service like FlowXO. The cons of Chatfuel is it doesn’t support context based conversation; it means chatbot doesn’t ‘remember’ the previous messages. For more intelligent chatbot, we need another service like Wit.ai or API.ai. I will integrate the current chatbot with API.ai and update in another post.

325 total views, 1 views today

This is very simple version of building your own Jarvis basing on what we have today. The Jarvis here can recognize and do some commands like showing the lunch menu, display menu of a specific day… etc. It’s less than a prototype but it can be the demo of what we can do by combining:
  • Speech recognize: It’s much easier today with Apple, Google and some others open the SDK. Many languages are supported but English is the best, of course.
  • Natural language understanding (NLU): Most of big tech companies are working on the promising system like LOUS.ai (Microsoft), Watson (IBM)… I use Wit.ai just because of its simple of use. These systems created the base model, our task is just inserting more data to train the machine with a specific topic.
  • Natural language processing (NLP): It’s actually the lower level of NLU but it could help. Google is in the best with cloud base service https://cloud.google.com/natural-language/, that can analyze the syntax and sentiment. It’s really helpful while we combine the NLU and NLP. We know the intent of the sentence as well as sentiment, it’s a guide to have more human react (with emotion). 
  • Text to speech: It’s a easy job, there are a lot of services help our Jarvis speak naturally like Amazon echo.

We can do somethings base on this code. Objectively, we can connect it with other things like laptop, IoT server… to do more jobs such as sending the message, turning on the light… etc. Technically, we can have better design to open for the possible command / intent, and think about the serverless jobs.

I hope I can do further in the next demo.

The presentation and source code are here: https://github.com/hiennvn/simple-jarvis 

 

564 total views, no views today

Here is my presentation for the workshop at CodeGym today about Design patterns. One of the biggest issue in training design patterns is the trainees don’t know how to apply them together in a single real world problem. I tried to create a real world problem and introduced a simple way to get it solved by combining some design patterns.

KFC. Order system

KFC is very famous fastfood brand, they have many franchises in various places that share the same hotline, menu.

When users open the menu on KFC website, they see the single menu, choose and order food by calling to the single hotline. A order center (OC) receives the order and notifies to the appropriate store by a specific criteria (now is location and can be changed in the future). A store can answer their possibility to take this order (they need to cook and deliver it on time). If a store takes this order, the process ends; otherwise, the OC will find another one.

To process a order, a store has a recipient who receives the order from OC, forwards it to the kitchen, finds the right delivery man and updates the order basing on the information from delivery man such as payment, status (accepted or declined), customer feedback… to OC. So OC has real time data of every orders but doesn’t have order’s internal note that works within the store.

When OC gets the order information from customer, they may get the extra information in some categories like food change, delivery time, special notes… If customer calls to OC to cancel the order, OC can directly cancel it by updating the order status in taken store.

Design the system by design patterns.

524 total views, no views today