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.

What Google recommend IT/CS students about learning?

Google gợi ý một số nội dung, khoá học cho sinh viên.

Vài điểm nhấn:

– Google cần computer science, không phải software engineering
– Các ngôn ngữ lập trình được gợi ý chủ yếu là scripting và focus và Web technologies
– Kỹ năng tự test là quan trọng
– Có khả năng sư phạm (để hướng dẫn người khác)
– Nhiều kiến thức cao cấp được đòi hỏi: Cryptography, AI, Parallel programming,
– Tham gia các dự án nguồn mở
– Hiểu rõ về OS (môn học khó)
– Hiểu rõ về logic (không chặc chẽ về logic, thậm chí không thông tam đoạn luận thì không thể trở nên (kỹ sư) giỏi)

Xem:
https://www.google.com/about/careers/students/guide-to-technical-development.html

What PHP full stack developers need

Thu nhập của một full stack developers
– Khoảng 1000$+ theo giá thị trường ở thời điểm hiện tại, tháng 6 năm 2016

PHP full stack developer là gì
– Là một senior web developers
– Làm được tất cả mọi việc, từ việc nhận yêu cầu từ khách hàng, phân tích, đề xuất, estimate, thiết kế, lập trình, sửa lỗi, test, triển khai, bảo trì

PHP full stack developers làm gì (cụ thể hơn)?
– Thiết kế đồ hoạ, sử dụng, ví dụ Photoshop, Illustrator,
– Frontend technologies: HTML, CSS, JavaScript, PHP
– Backend technologies: PHP và các công nghệ liên quan
– Quản trị server
– Network
– Và những gì liên quan khác, cần cho công việc
– Tư thế sẵn sàng làm những việc gì cần, khó hay dễ, thú vị hay nhàm chán… để hoàn thành công việc

Development stack gồm những công nghệ gì
– LAMP (OS: Linux (và OS khác như Windows nếu cần), Web/application server: Apache/nginx, Database: MariaDB/MySQL/PostgreSQL, PHP (với ngôn ngữ script khác: Ruby, Python…)
– Quản trị, theo dõi, vận hành hệ thống
– UI/UX, design

Cụ thể hơn về các công nghệ

Quản trị hệ thống:

  1. Linux, shell scripting (cơ bản)
  2. Cloud computing: Amazon, Rackspace…
  3. Background processing: Gearman, Redis
  4. Search: Elasticsearch, Sphinx, Solr
  5. Caching: Varnish, Memcached, APC / OpCache
  6. Monitoring: Nagios

Công cụ phát triển Web:

  1. Version control: Git, Mercurial, SVN
  2. Virtualization: VirtualBox, Vagrant, Docker

Back-end tech:

  1. Web servers: Apache, Nginx
  2. Programming language: PHP, NodeJS, Ruby
  3. Database: MySQL, MongoDB, Cassandra, Redis, SQL / JSON

Design:

  1. Converting website design into front-end code
  2. UI
  3. UX
  4. Mockup tools như balsamiq
  5. Thiết kế màn hình/giao diện

Biết thêm về mobile technologies

  1. iOS
  2. Android
  3. Hybrid: PhoneGap, Appcelerator

Các kỹ năng khác:

  1. Thiết kế, lập trình web service
  2. Phân tích, thiết kế database
  3. Phân tích nghiệp vụ, viết tài liệu đặc tả nghiệp vụ
  4. Phân tích, viết tài liệu thiết kế cơ bản, chi tiết
  5. Test tự động
  6. Developer testing
  7. Tự động hoá (dùng shell script)

Members Left Because of Technical Debt

Tình hình:
Thành viên dự án xin nghỉ và lý do là "em thấy mã nguồn bẩn quá" và "làm mãi ở dự án, gần một năm mà không học được gì"

Phân tích lý do:
Khi nhận được thông tin member xin nghỉ, quản lý/SM giả định nhiều lý do: Lương, thưởng thấp, mâu thuẫn với đồng nghiệp, lý do cá nhân, bạn bè lôi kéo.
Member xin nghỉ vì họ có lý do nào đó, mỗi tình huống xin nghỉ đều có lý do khác nhau, và trong trường hợp này "mã bẩn", "không học được gì" là hai lý do chính

Mã nguồn bẩn:
Đây là một dạng technical debt. Dự án đã phát triển trong trạng thái không kiểm soát về mã nguồn, kiến trúc. Một số biểu hiển về sự bẩn của mã nguồn:

  • Nghiệp vụ lung tung
  • Đọc code spaghetti không hiểu được, học khó hiểu
  • Với yêu cầu từ khách hàng, developer phải đi "mò" những yêu cầu ẩn
  • Dự án có nghiệp vụ phức tạp nhưng không có tài liệu về nghiệp vụ, quy trình, thiết kế
  • Dự án sử dụng CodeIgnitor như mô hình MVC và kiến trúc không được tuân thủ tốt
  • Coding convention không được tuân thủ
  • Không có tài liệu thiết kế database. DB không có annotation
  • Luôn xảy ra nhu cầu cần sửa đổi cấu trúc DB, tên trường trong DB do thay đổi nghiệp vụ
  • git pull request không được review (dù có cơ chế approve) tốt
  • (HMLT) Data table đơn giản, ít chức năng, cần phải code nhiều khi có yêu cầu thay đổi từ khách hàng (như: sorting, hide/unhide trường, dữ liệu, điều chỉnh độ rộng cột, hàng, inline edit cell (giống Excel)

Không học được gì:

  • Dự án không thực sự có một người mạnh về kỹ thuật ở mức "technical lead", dẫn dắt team về định hướng kỹ thuật
  • Kỹ thuật sử dụng trong dự án không có gì nổi trội
  • Không được hướng dẫn
  • Không được hỗ trợ gì nhiều từ những người có kinh nghiệm hơn (họ bận việc khác)
  • Phản biện: Liệu member này thiếu sự tự giác, tự chủ, cầu tiến hay không?
  • Các framework kỹ thuật dùng trong dự án cũ kỹ
  • Dự án/sản phẩm thiếu một vision dài hạn và mục tiêu ngắn hạn (member lo lắng cho tương lai của dự án/của bản thân mình)

​Giải pháp:

  1. Trả nợ technical debt càng sớm càng tốt
  2. Viết tài liệu cho hệ thống
  3. Viết thiết kế cho hệ thống
  4. Tổng hợp know-how, kiến thức cho hệ thống, từ developers, members trong team
  5. Tổ chức test festival để thu thập kiến thức, tìm ra một cái nhìn chung về cách hệ thống chạy, requirement, tìm lỗi hệ thống
  6. Tổ chức code review festival để chia sẻ hiểu biết về code, tìm ra bất cập về mã nguồn
  7. Tổ chức retrospective thường xuyên để tìm ra những điểm bất cập, những điểm cần/có thể improve

Backlog Management for Product Owner

Tình huống

Một dự án phát triển P bao gồm 5 developers và một scrummaster (hoặc project lead/project manager… tuỳ theo cách bạn gọi) chung sống và phát triển một phần mềm vui vẻ.

Họ sử dụng một dạng kanban để quản lý công việc của họ.
Các lane trong kanban khá đơn giản và cơ bản, bao gồm TODO, DOING, VERIFIED (đã test) và DONE (hoàn thành).

Họ sử dụng cycle, theo cách gọi khác là sprint/iteration là 2 tuần.
Cứ mỗi cuối 2 tuần, họ archive những công việc đã DONE, tiếp tục chuyển các công việc từ TODO sang DOING và tiếp tục công việc.
Cách sử dụng của họ có vẻ lẫn, hay áp dụng phối hợp những thói quen của các khung làm việc Scrum, Scrumban và Kanban.

Cho đến một ngày, Product Owner từ phương trời xa đến join vào dự án.
PO chưa có thói quen sử dụng phần mềm để quản lý yêu cầu.
Tuy nhiên, khi nhìn thấy công cụ kanban mà nhóm phát triển sử dụng, PO thích ngay mà muốn dùng kanban để quản lý chính công việc của anh ta, cùng đội phát triển.

Các cách tiếp cận

Một developer có kinh nghiệm khuyên rằng, khi chưa quen với backlog, kanban và các công cụ, PO có thể đưa rất cả các yêu cầu, nguyện vọng, phản hồi của anh vào TODO và nhóm sẽ xử lý dần.

PO gật đầu và làm theo cách đó một thời gian

PO nhận ra rằng nhu cầu quản lý công việc cần làm (backlog) của PO nhiều hơn là TODO.

Sau một thời gian sử dụng cột TODO, trao đổi với nhóm phát triển hàng ngày, kéo thả task từ TODO sang DOING, VERIFY những gì mình yêu cầu, PO phát triện ra rằng workflow của anh nhiều hơn thế. Anh không chỉ cần biết những gì cần phải làm.

PO cần một backlog như thế nào?

Việc quản lý yêu cầu (backlog) thuộc về PO.
Những ý tưởng bất chợt đếu với PO cũng cần được ghi lại.
Những công việc, feedback từ stakeholders mọi nguồn cũng cần được PO lưu lại.

Hơn thế nữa, anh cần đánh giá độ ưu tiêu của các công việc này. Cái gì cần làm trước, cái gì làm sau, cái gì quan trọng hơn… đối với từng stakeholder, với chính bản thân anh ta và chính dự án.

Đội phát triển cũng involve, ở thời điểm thích hợp.
Sau khi có một danh sách backlog có độ ưu tiên đứng từ góc nhìn của PO, những yêu cầu này được trao đổi đội phát triển để quyết định một số điểm như: 1) tính khả thi, 2) bao giờ nhóm có thể bắt đầu 3) mất khoảng bao nhiêu giời gian và dự định hoàn thành.

Những nội dung trên cần sự trao đổi và đồng thuận giữa PO và nhóm phát triển.

Một số trường hợp dễ thấy:

  1. PO muốn, nhưng dev team không thể đáp ứng về mặt kỹ thuật, năng lực hay thời gian,
  2. PO muốn, nhưng dev team quá bận vì những tác vụ khác, do đó không làm được.

Những yêu cầu từ phía PO được cho là “OK” khi nhóm phát triển tự tin rằng họ có thể thoả mãn yêu cầu của PO mà không cần hỏi thêm gì nhiều.

Tới thời điểm này, việc định nghĩa yêu cầu công việc được coi là xong.
Tiếp đó, nhóm phát triển làm việc được giao và khi họ xong, sản phẩm đầu ra được VERIFY bởi PO (là tốt nhất)

Sau khi yêu cầu được đưa vào DOING, nhóm phát triển phát triển theo quy trình mà họ đã quen thuộc.

JIRA/Atlassian đã làm tốt việc trên, mô trình trên được JIRA mô tả và sử dụng như sau.

Chia “TODO” thành các lane,
(từ trái qua phải)
Not ready yet: Feedback thô đối với nhóm dev. Những task dạng này cần PO, stakeholder trao đổi rõ ràng hơn, trả lời câu hỏi: 1) Họ muốn gì? 2) Thay đổi (high level…) thế nào
– “Not ready yet” được (tiền xử lý) sao cho thông tin đơn giản, dễ hiểu và được đưa vào “Unprioritized”. Unprioritized nghĩa là, những công việc trong lane này là các việc phải làm, nhưng chưa được đô tiên và đã khá rõ ràng hơn là ý tưởng thô.
Ready for dev team: Nhóm dev hài lòng về độ chi tiết của yêu cầu và sẵn sàng kéo sang cột DOING

Lưu ý

Backlog quản lý bằng kanban ở đây có chức năng: Thể hiện độ ưu tiên cuả công việc theo một cách nào đấy, tốt nhất là đánh số được theo chuỗi 1, 2, 3… trong đó: việc số càng nhỏ thì độ ưu tiên càng lớn.

Nếu không thể sử dụng chuỗi số, PO có thể đánh độ ưu tiên theo thứ tự: High, Medium, Low…

Tham khảo

The JIRA roadmap backlog has four major states:

  1. Not ready yet: Raw feedback
  2. Unprioritized: Committed to the back log, but not ready for handoff to development
  3. Ready for feature teams: The feature teams should work on the highest priority items first
  4. In design (PM and Dev): The feature story is actively being worked on

http://blogs.atlassian.com/2013/04/how-to-manage-a-product-backlog-with-ease/