by ·Comments Off on Hội chứng nghiện thảo luận

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í.

94 total views, 2 views today

by ·Comments Off on Choose a baseline for Story Point

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.

107 total views, 3 views today

by ·Comments Off on Scrum Master: việc nhàn lương cao
Ở 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? 

34 total views, 3 views today

by ·Comments Off on Yearly master plan

Trong Agile Y, tôi có đề cập tới yearly master plan – phương pháp được tôi sử dụng để tạo lập kế hoạch. Tôi không phải là người theo đuổi trường phái thiết lập và bám theo những kế hoạch dài hạn, song tôi khuyến khích mọi người cần có mục tiêu và một kế hoạch phác hoạ cho một năm; và vì thế, cần có yearly master plan.

Mỗi năm, tôi thường dành từ 1/2 đến 1 ngày để tạo master plan vào ngày đầu năm (dương lịch) với các bước sau:

  1. Liệt kê những công việc muốn làm trong năm, theo độ ưu tiên. Ví dụ:
    1. Đọc 18 cuốn sách
    2. Đi du lịch 3 thành phố
    3. Viết 1 cuốn sách
    4. Viết 20 bài blog
    5. Học bơi
    6. …
  2. Dự trù tài chính. Tính toán dòng tiền vào, ra hàng tháng, chi tiêu cố định, chi tiêu phát sinh, tiết kiệm… Ví dụ:
    1. Tháng 1: lương: 20 triệu, chi tiêu: 10 triệu, tiết kiệm: 10 triệu
    2. Tháng 2: lương: 20 triệu, chi tiêu: 20 triệu (hàng tháng: 10 triệu + Tết: 10 triệu), tiết kiệm: 10 triệu
    3. Tháng 3: lương: 20 triệu, chi tiêu: 15 triệu (hàng tháng: 10 triệu + mua điện thoại: 5 triệu), tiết kiệm: 15 triệu
    4. …
  3. Dự trù thời gian. Tính toán thời gian cố định cho công việc, giao lưu, nghỉ ngơi… Ví dụ:
    1. Tháng 1: Bận chuẩn bị Tết, dư 15 giờ
    2. Tháng 2: Nghỉ Tết, dư 40 giờ
    3. Tháng 3: Muốn du lịch châu Âu
    4. …
  4. Đánh giá 3 danh sách trên. Ba yếu tố trên chính là những yếu tố ràng buộc lẫn nhau, cho thấy được thời điểm và tính khả thi của từng mục tiêu. Ví dụ: Tháng 2 thích hợp cho việc đọc sách và viết blog, tháng 3 là không thích hợp cho mục tiêu du lịch châu Âu bởi tình hình tài chính chưa đảm bảo nhưng lại đủ cho mục tiêu học bơi hoặc du lịch trong nước;… Quay trở lại các bước 1-2-3, điều chỉnh lại mục tiêu, danh sách công việc và thời điểm cho phù hợp. Ví dụ: Điều chỉnh mục tiêu du lịch 3 thành phố xuống 1 hoặc điều chỉnh dự trù tài chính: cần tiết kiệm hơn, cần tìm kiếm nguồn thu khác…
  5. Liên tục lặp lại các bước này tới khi 3 yếu tố trên đạt sự cân bằng cần thiết và khả thi. Thông thường, một năm tôi sẽ chọn lấy 2 công việc cần thực hiện, trong đó có 1 công việc phải thực hiện: năm trước nữa là du lịch châu Âu, năm trước là Agile Y…

Tất nhiên, khi thực hiện, chúng ta khó có thể bám theo yearly master plan một cách hoàn hảo do hàng trăm sự kiện xảy đến trong năm khiến chúng ta phải điều chỉnh lại kế hoạch / mục tiêu theo từng tuần. Song yearly master plan rất quan trọng, nó cho thấy những gì chúng ta có thể làm và ưu tiên cao nhất trong một năm.

144 total views, no views today

by ·Comments Off on Going through Collection

Year ago, I had a post about iterating through collection. Today my colleague’s question gave me the idea about an example of using collection right. Let’s say we have a collection like NSArray that contains multiple NSString objects, we want to print them in lines includes the line number.

Easy problem, right? Let’s see we have some solutions:

What’s a best way? I can say #2 > #3 | #1.

About #3, you can refer to my post to know why we should use iterator instead of index while going through collection. Of course they perform same with NSArray but using iterator help us more easily use another collection type later. So #1 and #2 are usually better than #3. Why is #2 better than #1? The issue is:

#1 is O(n) while #2 is O(1). We can see #1 is more readable (a bit easier to understand than #2) but #2 has better performance.

You could see #1 is worser in some way. In case of duplicated strings in lines, you may also get wrong result (index is the first found): http://stackoverflow.com/questions/3167849/indexofobject-vs-indexofobjectidenticalto 

by ·Comments Off on Abstract. More abstract.

Hôm nay đồng nghiệp hỏi câu này: Tại sao nên viết như #a thay vì #b?

Tôi mở rộng câu hỏi thành: Sắp xếp các cách viết sau theo thứ tự “tốt dần”.

Khá khó để nói #3 và #4, cách nào tốt hơn; nhưng có thể dễ dàng khẳng định #1 và #2 không tốt bằng #3, #4. Tại sao?

Nguyên tắc chung của lập trình hướng đối tượng là trừu tượng hoá và cố gắng tối đa việc trừu tượng hoá. Trừu tượng (không phải là giải pháp toàn vẹn nhưng) là một phần trong cách tư duy về Open / Closed principle. #1 rất trực quan và dễ hiểu: tạo một danh sách lưu trữ sách dưới dạng ArrayList. Nhưng những thứ cụ thể rất khó để sửa đổi và thay thế. Ví dụ, sau khi implement, chúng ta phát hiện ra đoạn code phía sau sử dụng rất nhiều thao tác thêm phần tử vào list thay vì lấy phần tử ra; do đó lưu trữ dưới dạng Stack cho hiệu suất tốt hơn; chúng ta phải sửa đổi các đoạn code phía dưới với implement cụ thể của Stack (thay cho ArrayList). Một thời gian sau, nhu cầu lấy phần tử từ list đủ nhiều để sử dụng ArrayList cho hiệu suất tốt hơn, chúng ta phải sửa lại đoạn code phía dưới với implement cụ thể của ArrayList. (Tham khảo: hiệu suất các implement của List). Khổ chưa?

Một cách thông minh hơn là sử dụng #3, khi đó, đoạn code phía dưới chỉ sử dụng những method được định nghĩa cho interface List. Khi cần thay đổi implement cụ thể thành Stack, LinkedList…, chúng ta chỉ đơn giản thay new List<Book>() bởi new Stack<Book>() hay new LinkedList<Book>(). 

Và theo cách tư duy đó, #4 tốt hơn #3? Không hẳn, nếu chúng ta đã xác định list chỉ chứa Book, việc khai báo list chứa Object khiến chúng ta có thể mất công cast những object này trong trường hợp sử dụng những method cụ thể của Book (và thường là vậy). Nên dùng #4 thường là bất lợi hơn #3 (trừ trường hợp list chữa những object khác ngoài Book).

Do đó, sử dụng #3 (khai báo interface và khởi tạo bằng class (đương nhiên)) thường là cách viết nên được “quen tay”.

Thật ra #3 còn nên viết theo 1 cách khác tốt hơn như sau. Tại sao nhỉ?

490 total views, no views today

by ·Comments Off on eXtreme Programming is Dead

Following the topic in my short post eXtreme Programming is Dead, I had a talk at the monthly meetup of Agile Vietnam, Feb 2017, to explain more about my opinion.

Half of time, I focused on describing what exact eXtreme Programming (XP) is. Today most of development teams are applying some XP practices but they just do it with forgetting what are behind the scene: values and principles. It’s time to recall to how to do it right.

Then I explain more about my idea, why XP is dead. It’s dead in some ways: teams just follow the practices without knowledge of values and principles, the practices is more and more becoming standards of software development instead of extreme, original XP makes the confusion of applying it at enterprise.

You can find the slide here – it just is the outline, I will try to explain more in longer post later.

246 total views, no views today

by ·Comments Off on eXtreme Programming is dead

Tại sao ở Việt Nam, những tư tưởng và thực hành XP không được coi trọng? Theo tôi quan sát, có ba lý do chính.

Một là, ngành CNTT của Việt Nam chủ yếu vẫn đang tiếp cận theo hướng top-down; những vấn đề về công nghệ, phương pháp luận, thực hành vẫn chủ yếu được định hình bởi các quản lý cấp cao, cấp trung. Và XP thường không bao giờ nằm trong danh sách lựa chọn của những nhà quản lý dự án hay quản lý tổ chức thuần tuý, bởi XP không phải là phương pháp luận về “quản lý”.

Hai là, tên. eXtreme Programming chết bởi cái tên. Kent Beck có lẽ nên chọn một cái tên khác, có thể là vô nghĩa thì tốt hơn. XP cho thấy sự coi trọng hoá programming một cách cực đoan. Và thực sự, điều đó là đúng. Gốc rễ của mọi sản phẩm phần mềm là lập trình. Song nếu như vậy, ngành công nghiệp phần mềm sẽ là quá chật hẹp; và những nhà tư vấn cần phải làm phức tạp nó lên, để mở ra nhiều vị trí khác, nhiều công việc khác. Tư tưởng này được đẩy tới những nhà quản lý, và họ thành ra không coi trọng vấn đề lập trình; họ hiểu rằng để làm ra sản phẩm phần mềm phức tạp, thì tổ chức phải cần những phương pháp phức tạp; và nhiều công việc, nhiều quản lý chính là cách hiện thực hoá điều đó. Có lẽ eXtreme Managing sẽ được lòng hơn là eXtreme Programming.

Và thế là, ba, thị trường XP ngày càng yếu. Những nhà tư vấn, đào tạo không hào hứng với việc đào tạo XP. XP là những gì hand-on rất cụ thể, tốn kém hơn, nhưng nhu cầu ít hơn, là mảnh đất khô cằn của thị trường tư vấn, đào tạo; trong khi những phương pháp quản lý tiếp tục lên ngôi trên một mảnh đất màu mỡ hơn. Và do ít được đào tạo, XP ít được biết đến và ít được thực hành; nên dữ liệu cũng ít, nên càng khó chứng minh được sức mạnh một cách rõ ràng.

Vậy là XP chết.

Đó là tình hình ở Việt Nam. Trên thế giới? XP cũng đã chết. Ít nhất là cái tên.

Ở Việt Nam, các tổ chức không coi trọng XP, họ coi trọng những phương pháp luận về quản lý dự án và quản lý tổ chức mới. Họ mải miết với việc xây dựng môi trường làm việc thân thiện, vui vẻ. Nhưng vui vẻ sao được khi chất lượng sản phẩm không cao? Vui vẻ sao được khi các lập trình viên phải fix bug trên production? Phải căng thẳng khi merge code và lo lắng rằng việc deploy không thành công? Phải để tester chờ tới đêm mới có một bản build?

Trên thế giới, trừ một số người “học hành tử tế”, bây giờ cũng ít ai nhắc tới XP. Nhưng thực tế lại trái ngược hoàn toàn. TDD, pair programming, code refactoring… là những khái niệm và thực hành rất căn bản, ai cũng có thể làm. Continuous Integration (với Jenkins, TeamCity…) xuất hiện ở mọi dự án, đến nỗi người ta không nhớ rằng đó là practices của XP, trừ những người nghiên cứu chi tiết. Và XP chết vì nó đã trở thành bình thường, trở thành “chuẩn” kỹ năng của mọi lập trình viên, không còn là eXtreme nữa. XP là extreme của những năm 2000. Sau gần 20 năm ra đời, XP giờ đây là chuẩn theo nghĩa phổ thông. Hãy thử tìm xem có IDE nào tử tế không hỗ trợ unit test và TDD? Hãy thử tìm xem có framework nào tử tế không có test?

Trong khi thị trường thế giới cạnh tranh gay gắt về những công cụ hỗ trợ tư tưởng, thực hành XP, thì ở Việt Nam, chúng ta vẫn chưa dùng nhiều. XP chết, ở hai nơi, theo hai cách khác nhau.

Tiêu đề rất kêu này của Hiệp Lê. Nhưng nội dung thì cả Hiệp và Hiển đều có chung ý tưởng và hoàn toàn đồng tình.

635 total views, 1 views today