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

Advertisements

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.