Positive Thinkings for IT engineers

Tư duy tích cực cho dân IT:

  1. Đừng bàn lùi
  2. Thay vì trình bày vấn đề, hãy đưa ra giải pháp
  3. Tạo cảm giác dễ chịu cho người nghe/xung quanh
  4. Ba xoa một đập
  5. Chê nhẹ nhàng; khen đúng. Xem cuốn "Đắc nhân tâm"
  6. Hài hước: Cuộc sống tươi đẹp hơn với những nụ cười, hãy đem nó tới cho đồng nghiệp và những người xung quanh ta
  7. Đúng mực: Đừng tỏ ra bề trên, đừng coi thường (ý kiến) người khác
  8. "Em không làm được đâu": Chưa làm sao biết. Thử đi, thất bại cũng được.
  9. "Em chưa làm cái đấy bao giờ": Cũng chưa làm qua cả. Thử đi. Những phát minh, phát kiến đều bắt đầu bằng ý tưởng điên rồ, sự tò mò cái mới…
  10. "Em không có thời gian làm đâu": Bạn có thời gian lướt Facebook thì cũng có thời gian thử. Thời gian làm có. Thử đi, trong một khoảng thời gian nào đó, ví dụ 2 ~ 3h, hay 2 ~ 3 ngày, nếu không ra kết quả tốt thì tổng kết và dừng sự thử nghiệp.
  11. "Không có cách khác đâu": Chắc chắn có cách khác. Cách khác có thể tốt hay không tốt hơn nhưng ít nhất là bạn dám thử, dám thất bại, có sự so sánh giữa cách này và cách kia.
  12. "Em làm mãi thế rồi, đừng thay đổi cách làm": Em làm thế đã đủ tốt chưa? Đã thử cách làm mới chưa, và kết quả ra sao? Cứ thử đi, thất bại cũng được (không bị trách đâu)
  13. "Thế này là tốt lắm rồi". Có cách nào làm tốt hơn không?
  14. "Khó quá": Đừng nói câu này. Nếu khó thì phải làm gì?

Tham khảo:
http://www.mayoclinic.org/healthy-lifestyle/stress-management/in-depth/positive-thinking/art-20043950?pg=2

​​

Blockchain technology

Blockchain technology:

1. Được dự đoán là một xu hướng (công nghệ: "disruptive potential of blockchain technology") của năm 2016+
2. Nhiều tổ chức (tài chính) đang nghiên cứu. Ví dụ: Deloitte, PWC
3. Nhiều dịch vụ về Blockchain đã được cung cấp

Một vài từ khoá liên quan:

– Blockchain
– Finance
– Banking
– Anti-Money Laundreing (AML)
– Know Your Customer (KYC)
– Bitcoin
– FinTech
– Finance Services
– P2P (peer-to-peer)

Q: Ứng dụng của blockchain là gì (ngoài lĩnh vực finance)
(payment,insurance, asset management, retail banking, capital markets, real estate)

Mình đã từng được à ơi một dự án về Blockchain.
Có vẻ như các đối tác nước ngoài chưa tin tưởng Việt Nam lắm nên chưa lấy dự án về được.

Tổng kết/Wrap-up: Agile Singapore 2016

Tóm tắt
Đây là bài tổng kết, ghi nhận về những gì tôi/Nguyễn Vũ Hưng ((board) member của Agile Vietnam), được Agile Singapore mời (free entrance ticket, tự túc đi lại lại, khách sạn) tới sự kiện Agile Singapore 2016

Đối tượng đọc
– Những người có quan tâm đến Agile
– Những người (muốn) tổ chức sự kiện (liên quan đến Agile), tầm cỡ quốc tế

Cảm nhận chung
Đây là sự kiện lớn, nhiều diễn giả tầm cỡ thế giới, tổ chức chuyên nghiệp, chất lượng (rất cao)

Chi phí
Cá nhân: Vé máy bay 2 chiều Hà Nội – Changi + 3 đêm khách sạn (hạng thường) (100 SGD x3). Vé vào cửa (800 SGD: được Agile tặng với lý do: Ông Hưng đóng góp cho Agile Vietnam nhiều :D)

Chi phí cho diễn giả
Bao đi lại + khách sạn. Đây là chi phí rất lớn với các diễn giả lớn, đa số từ Mỹ sang

Diễn giả
– Martin Fowler là diễn giả lớn, tầm cỡ số 1 thế giới (ở một số mảng)
– Mary & Tom Poppendieck: Số một thế giới về Lean
– Các diễn giả khác: Đều là những tác giả sách nổi tiếng, hoặc là/làm Agile coaches. Một số diễn giả khác, ít tên tuổi hơn, là người local (ở Sing)

Khách sạn (Fort Canning Hotel)
– Sạch sẽ, một phòng lớn + 3 phòng làm session (cũng rất lớn)
– Thiết bị hiện đại, nhân viên khách sạn care hết
– Vị trí thuận tiện
– Khách sạn nằm trong một công viên lớn (Fort Canning Park)

Logistics
Không nhiều (vì đã dùng hết dịch vụ của khách sạn)
Stanly Lau việc chính là đi pha cà phê

Ăn uống
Buffet, đặt từ khách hạn.
Tea breaks (ăn nhẹ, cà phê…)
Với 800 SGD thu từ người tham gia thì các bữa ăn + tea break cũng khá tốn

Sponsored keynote
Là keynote speech của sponsor, được nói trong lúc mọi người ăn trưa.
Suy nghĩ: Sponsor bỏ tiền ra, và họ có quyền yêu cầu lợi ích gì đó

Đối tượng tham gia
Speaker (khủng): đa số từ Mỹ
Một số local speakers ở Sing, chất lượng cao
Người tham gia đến từ nhiều nước: Mỹ, Việt Nam, Nhật, Thái, Malaysia, Ấn Độ, Singapore
Người tham gia từ Singapore có lẽ là nhiều nhất (hiển nhiên)

Về các bài nói chuyện
Về bài của Martin Fowler
Nói hay, rất cuốn hút, xứng đánh số 1 thế giới🙂

Design Stamina Hypothesis
Long-term factoring
The ecconomics of refactoring
Comprehension refactoring
Agile vs plan-driven

Về bài của Mary Poppendieck (#1)
Khá hay. Ảnh trong slide của Mary *đều* là do Tom chụp.
Ảnh: https://www.flickr.com/photos/vuhung/30146880065/in/album-72157675046803715/

Về bài của Mary Poppendieck (#2)

Khá hay. Ảnh trong slide của Mary *đều* là do Tom chụp.
Ảnh: https://www.flickr.com/photos/vuhung/30131050046/in/album-72157675046803715/

Về đội tình nguyện viên
10+ người
Việc không nhiều
Tổ chức tốt, chuyên nghiệp,
Tự giác, tự lập

Quay phim/chụp ảnh
Quay phim full mọi session. Có lẽ là thuê ngoài. Khá nhẹ nhàng. Thiết bị tốt
Mọi speakers đều có lazer points, có máy ghi âm gắn ở áo
Các phòng sự kiện đều có loa ấm, đủ nghe cả phòng (đẳng cấp)

Tiếng Anh
Singlish: Đủ nghe, hơi khó nghe
Tiếng Anh của speakers: 1) Từ Mỹ: Khá dễ nghe 2) Từ các nước khác như Đức: Cũng khá dễ nghe

Việt Nam cần gì để tổ chức một sự kiện như thế không?
Vì sao không nhỉ? Chúng ta hoàn toàn làm được
Stanly nói Agile 2016 là Agile Conference cuối cùng (mấy lần "cuối cùng" rồi)
Việt Nam có thể host tiếp nhỉ?

Xu hướng năm 2016
– Con người
– Infra outsourcing

Các điểm khác:
– Nhiều sponsor
– Nhiều booths
– Hoạt động kiểu "Agile"
– Thẩm mĩ
– Tặng sách
– Wefie contest
– Tag chung #agilesg16
– Nhiều mẫu áo, nhiều mầu, nhiều size
– Mũ phớt: Đẹp
– Sách của Jutta Eckstein (Retrospectives for Organizational Change) https://www.flickr.com/photos/vuhung/30131530726/in/album-72157675046803715/

Thông tin về Agile Singapore 2016
Website: http://2016.agilesingapore.org/

Agenda: https://confengine.com/agile-singapore-2016/schedule
Ảnh: https://www.flickr.com/photos/vuhung/albums/72157675046803715
Movies: https://www.youtube.com/playlist?list=PL7WMPB8PxGft-MQqYgTZD2Ll4OWBW0X5B

Nim game

Nim game:

Counting to S (=30)

– Số người chơi: 2
– Mục đích: Người nào nói số S thắng
– Người đầu tiên bắt đầu từ số 1
– Mỗi người được nói tối thiểu một, tối đa N (=2) số trong lần nói của họ (không được skip).
– Người nói tiếp theo phải bắt đầu từ số kế tiếp của người nói trước.
– Ví dụ, người đầu tiên nói "1", người thứ hai có thể nói "2" hay "2, 3"
– Ngừoi nào nói số S (=30) là người chiến thắng

Bài tập:
1. Hãy chơi game với S = 10, 20 (nhỏ)
2. Hãy chơi game với N = 2 hay 3
3. Hãy tìm chiến lược cho người đi trước (hoặc sau), luôn thắng
4. Tìm điều kiện (giữa S và N) để đảm bảo người đi trước luôn tìm được chiến lược thắng

Câu hỏi:
Những lý thuyết số học gì đằng sau bài toán này?

Cu lớp 1 nhà mình tìm được chiến lược với S = 30, N = 2

Tham khảo:
https://riverbendmath.org/modules/Nim_Games/
https://en.wikipedia.org/wiki/Nim

http://www.java-online.ch/gamegrid/gamegridEnglish/index.php?inhalt_mitte=gittergames/nimspiel.inc.php

Problems and solutions with slack

Hiện trạng sử dụng slack:
– 6 team
– Tổng số 5 – 20 channels trong mỗi sites
– Khoảng 5 – 10 thành viên trong mỗi sites/channels

Chưa hài lòng/chưa làm tốt:

– Quá nhiều team
– Quá nhiều channel
– Check vẫn bị sót thông tin

Slack làm tốt:
– PC hay mobile đều xem được
– Tốc độ xử lý nhanh
– Ai cũng xem được (nếu muốn, online), luôn và ngay

Phải chăng là mình (biết cách) chưa dùng slack hiệu quả?

Giải pháp (để cải thiện):

– Dùng shortcuts (Ctrl-1, 2, 3, 4),

– Dùng alt+shift+(lên/xuống arrow) để move giữa các channel mà có unread message

– Giảm lượng việc, dự án, thông tin cần phải xử lý

Nguyên nhân cốt lõi:

– Nhiều việc, nhiều dự án, nhiều thông tin quá

ref. https://www.facebook.com/nguyenvuhung/posts/10209172825909853

Raw estimation for unclear requirement

Yêu cầu từ khách hàng:
Hãy estimte các task (khoảng N = 50) trong một sprint, theo giờ.

Bối cảnh:
Khách hàng yêu cầu thêm/sửa khoảng N issues.
Team chưa rõ những yêu cầu này.
Có thể dùng planning poker để estimate.
Tuy nhiên, công cụ quản lý issue của dự án là backlogtool, không hỗ trợ point estimte, nên nhóm quyết định estimate theo giờ, ghi số giờ vào backlog trong cột "số giờ dự định" cũng như "thời điểm" bắt đầu.

Quy ước về cách sử dụng số giờ:
– 1h, 2h, 4h: Task nhỏ, yêu cầu khá rõ ràng
– 8h: Task lớn, có thể làm trong tầm 1 ngày, có thể nhiều hơn hoặc ít hơn
– 16h, 24h, 32h: Task rất lớn, team chưa hiểu yêu cầu, chưa estimate được (chính xác), cần làm rõ yêu cầu với PO, cần phân tích mức độ ảnh hưởng của issue với hệ thống/module hiện tại.