Running a Retrospective Meeting

Overview/Giới thiệu

Cuộc họp retrospective là cuộc họp quan trọng nhất trong. Nó quyết định sự thành công và độ ổn định lâu dài của nhóm Scrum. Việc khung làm việc của Scrum không định nghĩa rõ về cuộc họp này tạo sự sáng tạo và đặc thù riêng theo từng nhóm.

Tuy vậy, việc thể hiện những giá trị cốt lõi của Scrum trong cuộc họp này – minh bạch, thích nghi và cải tiến liên tục – không phải là điều dễ làm.

KPT

KPT là một cách làm retrospective theo kiểu Nhật.

“K” = Keep là những việc tốt nên keep (duy trì) trong thời gian tiếp theo.
“P” = Problem, là những tồn tại (việc xấu) trong thời gian vừa qua cần được giải quyết.
“T” = Try, là những việc cần thử nghiệm về sau này.
KPT tương ứng với giai đoạn “C” (check) trong mô hình PDCA (Plan-Do-Check-Action)

So sánh KPT với các phương pháp chạy một cuộc họp Retrospective, ta sẽ thấy các điểm chung.

Mô hình PDCA chính là sự cải tiến liên tục. Tương tự như thế, khi Retrospective – cuộc họp cuối của một sprint – kết thúc, cũng là lúc một sprint mới bắt đầu với kế hoạch mới, hành động mới.

Starfish Model/Mô hình Sao biển

Theo cách này, bảng trắng được chia thành các múi, giống như Sao biển với các ô tương ứng

  1. start doing: Bắt đầu làm cái này
  2. stop doing: Dừng không làm cái này nữa
  3. keep doing,
  4. more of,
  5. less of

 

Team Radar

Không dùng. Đây là cách cho điểm từ 1 đến 10 các tiêu chí cần đánh giá. Có lẽ cách làm này phức tạp nhưng “pick brain” được team member và cách thể hiện khá nghệ thuật một cách khoa học. Cách làm Team Radar có thể xem thêm trong cuốn “Agile Retrospectives: Making Good Teams Great”.

Conclusions/Kết luận

Có nhiều cách làm Retrospective. Một trong những mục đích cuối cùng của Retrospective là để nhóm nhìn lại những điểm tốt xấu đã làm trong nhịp trước, tạo tiền đề làm bàn đạp cho việc Kaizen của (những) sprint tiếp theo.

Chúng tôi lựa chọn một biến thể của KPT để thực hiện Retospective. Lý do của sự lựa chọn khá đơn giản: Nó được thực hiện từ nhiều năm nay như một thứ văn hóa ăn và máu của của Nhật.

References/Tham khảo

  1. https://proessler.wordpress.com/2011/08/31/agile-team-retrospective-activities-starfish-team-radar/
  2. http://agile-and-testing.chriss-baumann.de/2012/02/the-starfish-retrospective/
  3. https://www.thekua.com/rant/2006/03/the-retrospective-starfish/

Đăng lại từ http://labs.septeni-technology.jp/offshore/running-a-retrospective-meeting/

 

Advertisements

Agile/Scrum/Kanban/Lean Learning Resources (in Vietnamese)

Một số nguồn học Agile/Scrum/Kanban/Lean, quản lý dự án Công nghệ Thông tin:

Kanban cơ bản và nâng cao: http://www.slideshare.net/vuhung16plus/basic-kanban
Scrum guide (Vietnamese) http://www.scrumguides.org/download.html
(Scrum) Nexus Guide: https://www.scrum.org/Portals/0/NexusGuideTranslations/NexusGuide-v1.1%20-%20Vietnamese%20nfv3.pdf
Agile Y https://www.goodreads.com/book/show/33629389-agile-y
Cẩm nang Agile http://hocvienagile.com/cam-nang-scrum/
Getting Value out of Agile Retrospectives – Vietnamese: https://www.facebook.com/gettingvalueoutofagileretrospectivesVN/
Anti-patterns in IT project management: http://www.slideshare.net/vuhung16plus/anti-patterns-in-it-project-management
Workshop: Software Project Management with Jira: http://www.slideshare.net/vuhung16plus/nguyen-vu-hung-software-project-management-with-jira-agile
Beyond & Insights of Agile Adoption: Mindset & Practices: http://www.slideshare.net/vuhung16plus/nguyen-vu-hung-beyond-agile-practices-and-mindset-agile-tour-vietnam-hanoi-2014
A Casestudy at Septeni Technology: Being Agile in a Cross-Cultural Environment: http://www.slideshare.net/vuhung16plus/being-agile-in-a-cross-cultural-environment-xp-day-2015-vietnam-nguyen-vu-hung
Beyond Project Management: http://www.slideshare.net/vuhung16plus/beyond-project-management-nguyen-vu-hung-201405-duy-tan-geek

TiDD: No Ticket, No Commit

TiDD là gì?
Ticket-Driven Development (Phát triển hướng ticket).

Ai phát triển TiDD
Một bác Nhật xây dựng và đặt tên cách quản lý dựa trên ticket, lấy ticket làm trung tâm là TiDD.

Khởi nguồn của TiDD
Tác giả của TiDD dùng Redmine, là task management tool để phát triển dự án phần mềm.

"No Ticket, No Commit"

  1. Đây là nguyên tắc cơ bản của TiDD.
  2. Phải có ticket trước thì mới commit.
  3. Một commit phải tương ứng với một ticket nào đó.
  4. Ticket này là yêu cầu công việc, là lý do mà một developers commit mã nguồn của anh ta.

Vì sao cần "No Ticket, No Commit"

  1. Để biết vì sao, ta làm cái gì.
  2. Để biết DoD (Definition of Done) ra sao
  3. Để mọi người hiểu được công việc rõ ràng hơn (không chỉ developers)

Có ticket nào không tương ứng với commit?

  1. Có, những task không liên quan đến mã nguồn như hỗ trợ khách hàng, tìm hiểu.
  2. Không. Nếu hiểu "commit" rộng hơn nghĩa "commit mã nguồn" và đối tượng của việc commit là "thay đổi một cái gì đó của hệ thống".
  3. Hiểu rộng hơn, "cái gì đó" ở đây là "configuration" (như trong CM: Configuration Management".

"Cấu hình" là gì?

  1. Cấu hình (Configuration) bao gồm mã nguồn, tài liệu, cấu hình hệ thống, máy chủ, server…
  2. Việc chỉnh sửa cấu hình là việc của những người liên quan đến dự án.
  3. Việc chỉnh sửa mã nguồn (một loại cấu hình) là việc chính của developers.
  4. Việc chỉnh sửa các cấu hình khác thuộc về thành viên dự án, ví dụ: Chỉnh sửa file ảnh, chỉnh sửa tài liệu hướng dẫn sử dụng, sử dụng tài liệu thiết kế hệ thống.

Quản lý cấu hình thế nào?

  1. Một cách lý tưởng, mọi thứ (cấu hình) được quản lý trong một hệ thống có hỗ trợ version (Version Control System: VCS).
  2. SCCS (Source code Control System) là công cụ quản lý mã nguồn.

Một số biểu hiện (người/cách làm) không tuân theo TiDD

  1. Developers tự nhiên commit, không rõ lý do,
  2. Comment trong git trống không,
  3. Developers hotfix mà không hiểu vì sao ,
  4. Thay đổi của hệ thống không được theo dõi (tracking),
  5. Thông tin về quản lý hệ thống/phần mềm không thông suốt,
  6. Release Note không đủ, rõ ràng, phải làm bằng tay.

Quan điểm về TiDD

  1. Việc quản lý dự án lấy ticket làm trung tâm.
  2. Việc phân chia công việc và quản lý tiến độ dựa trên ticket.
  3. Không có ticket thì cấm commit.

Quy định trong TiDD

  1. *No Ticket, No Commit

Một số loại tickets

  1. Bugs
  2. Yêu cầu thay đổi
  3. Phát triển chức năng mới
  4. Phân tích tính khả thi của công nghệ mới
  5. Tạo tài liệu thiết kế
  6. Hãy release vào ngày 2017/01/01 với 30 yêu cầu có ticket ID như sau

TiDD đem lại điều tốt lành gì?

  1. Ai, bao giờ, làm gì: đều track được từ ticket. Qua đó communication thông suốt hơn,
  2. Việc quản lý thay đổi của nội dung/yêu cầu công việc dễ dàng hơn (chỉ cần thay đổi ticket tương ứng),
  3. Release dễ hơn,
  4. Test dễ hơn (dựa trên ticket),
  5. Workflow của dự án tuân theo workflow của ticket, dễ nhìn hơn.

Cần gì để thực hiện TiDD

  1. (Bắt buộc) Source code management system như git, subversion,
  2. (Bắt buộc) Ticket managment system như redmine, backlog, Jira…
  3. Wiki hay một hệ thống quản lý văn bản hỗ trợ versioning,
  4. Hệ thống versioning khác để quản lý CM (tài liệu…)

​Tham khảo:

https://www.flickr.com/photos/vuhung/7508088100
https://ja.wikipedia.org/wiki/%E3%83%81%E3%82%B1%E3%83%83%E3%83%88%E9%A7%86%E5%8B%95%E9%96%8B%E7%99%BA
http://forza.cocolog-nifty.com/blog/2011/09/no-ticket-no-co.html

Học chủ động: Quá sức với người Việt không?

Học chủ động: Quá sức với người Việt không?

Phát biểu: Người học cần chủ động
Người học: Chúng tôi chưa/không biết cách tự học!
Người dạy: Chúng tôi sẽ dạy cách tự học trước khi học

Funix: Đừng dạy nữa, mà chỉ hướng dẫn thôi
Người học: Nếu tôi biết cách tự học thì tôi cần phải bỏ tiền, đến trường không?

Cá nhân mình nghĩ: Tự học phương pháp tự học là quan trọng nhất :slight_smile: Mâu thuẫn chưa.

Quan sát người Việt với việc tự học, mình quan sát và thấy học chủ động (active learning) chỉ thích hợp với một số rất ít người Việt.

Điều đáng buồn là những người chủ động học được thì họ không cần nhiều hướng dẫn, bản thân họ "giỏi" (trong việc (tự) học) sẵn rồi.

Triết lý giáo dục này liệu có áp dụng cho 80% lượng sinh viên, người học còn lại không?

Với 80% đó liệu cách giáo dục hiệu quả lại là dạy thụ động à.

Nghe có vẻ không đúng lắm.

SSL and TLS: a brief comparison

SSL và TLS khác nhau thế nào?
http://stackoverflow.com/questions/3690734/difference-between-ssl-tls
https://luxsci.com/blog/ssl-versus-tls-whats-the-difference.html

SSL có an toàn không?
– Đủ an toàn ở mức thuật toán
– Nói "SSL bị hack" là oan cho thuật toán SSL. Implementation cho SSL bị crack bằng lỗ hổng nào đó thì đúng.
http://security.stackexchange.com/questions/53596/how-safe-is-ssl

TLS/SSL và HTTPS
http://security.stackexchange.com/questions/5126/whats-the-difference-between-ssl-tls-and-https

History of TLS
– 1.0, 1.1, 1.2

History of SSL
– 1.x, 2.x, 3.x

TLS vs SSL
TLS 1.0 = SSL 3.1
TLS 1.1 = SSL 3.2
TLS 1.2 = SSL 3.3

RFC về TLS và SSL
Nên đọc (rất khó hiểu, dài)

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

​​