Apache Voting Processes

Quy trình vote của Apache

0. Lazy vote

 Không cần mất thời gian, chỉ vote "đồng ý", "phản đối" hay "phiếu trắng"

 Lấy ý kiến, sự đồng thuận từ rất nhiều người (cả team) trong thời gian ngắn

 

1. Các tuỳ chọn vote cơ bản

 +1: Đồng ý

 -1: Phản đối

 0: Không có ý kiến (phiếu trắng)

0.x: Không/ít dùng (hơi hơi phản đối, hơi hơi đồng ý...)

 

2. Các tuỳ chọn khác 

+0: 'I don't feel strongly about it, but I'm okay with this.'

-0: 'I won't get in the way, but I'd rather we didn't do this.'

-0.5: 'I don't like this idea, but I can't find any rational justification for my feelings.'

++1: 'Wow! I like this! Let's do it!'

-0.9: 'I really don't like this, but I'm not going to stand in the way if everyone else wants to go ahead with it.'

+0.9: 'This is a cool idea and i like it, but I don't have time/the skills necessary to help out.'

3. Lợi ích

 - Tốn ít thời gian

 - Thích hợp với remote team 

 - Phù hợp với các nhóm kỹ thuật 

 

4. Quy trình vote của Apache thích hợp ở đâu?

 - Dùng lúc nào cũng được

 - Vote nhanh

 - Hay vote chậm 

5. Tham khảo 

http://apache.org/foundation/voting.html

--

Best Regards,
Nguyen Hung Vu [aka: NVH] (in Vietnamese: Nguyễn Vũ Hưng, グェン　ヒュン　ウー, 阮武興)
vuhung16plus{remove}@gmail.dot.com , YIM: vuhung16 , Skype: vuhung16plus, twitter: vuhung, MSN: vuhung16.
vuhung's facebook  Nguyễn Vũ Hưng's blog on Free and Open Source, Blog tiếng Nhật, Vietnamese LibreOffice, Mozilla & Firefox tiếng Việt

Disclaimer: When posted to social networking groups include, but not limited to Linux Users' Groups, Free and Open Sources forums, mailing lists, the above is my personal opinion and is *not* the opinion of my employer(s), associations and/or groups I join.

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/

--

Best Regards,
Nguyen Hung Vu [aka: NVH] (in Vietnamese: Nguyễn Vũ Hưng, グェン　ヒュン　ウー, 阮武興)
vuhung16plus{remove}@gmail.dot.com , YIM: vuhung16 , Skype: vuhung16plus, twitter: vuhung, MSN: vuhung16.
vuhung's facebook  Nguyễn Vũ Hưng's blog on Free and Open Source, Blog tiếng Nhật, Vietnamese LibreOffice, Mozilla & Firefox tiếng Việt

Disclaimer: When posted to social networking groups include, but not limited to Linux Users' Groups, Free and Open Sources forums, mailing lists, the above is my personal opinion and is *not* the opinion of my employer(s), associations and/or groups I join.

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

--

Best Regards,
Nguyen Hung Vu [aka: NVH] (in Vietnamese: Nguyễn Vũ Hưng, グェン　ヒュン　ウー, 阮武興)
vuhung16plus{remove}@gmail.dot.com , YIM: vuhung16 , Skype: vuhung16plus, twitter: vuhung, MSN: vuhung16.
vuhung's facebook  Nguyễn Vũ Hưng's blog on Free and Open Source, Blog tiếng Nhật, Vietnamese LibreOffice, Mozilla & Firefox tiếng Việt

Disclaimer: When posted to social networking groups include, but not limited to Linux Users' Groups, Free and Open Sources forums, mailing lists, the above is my personal opinion and is *not* the opinion of my employer(s), associations and/or groups I join.

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​

--

Best Regards,
Nguyen Hung Vu [aka: NVH] (in Vietnamese: Nguyễn Vũ Hưng, グェン　ヒュン　ウー, 阮武興)
vuhung16plus{remove}@gmail.dot.com , YIM: vuhung16 , Skype: vuhung16plus, twitter: vuhung, MSN: vuhung16.
vuhung's facebook  Nguyễn Vũ Hưng's blog on Free and Open Source, Blog tiếng Nhật, Vietnamese LibreOffice, Mozilla & Firefox tiếng Việt

Disclaimer: When posted to social networking groups include, but not limited to Linux Users' Groups, Free and Open Sources forums, mailing lists, the above is my personal opinion and is *not* the opinion of my employer(s), associations and/or groups I join.