Project ManagementChia sẻ/Trao đổi cùng AltPlus

Nguyễn Vũ Hưng2016/04/21 @ AltPlus

Tự giới thiệu1. Thạc sĩ CNTT Nhật Bản

2. 18 năm sống và làm việc với người Nhật

3. Kỹ sư cầu nối/Kỹ sư (CNTT)

4. ScrumMaster/Project Manager/CxO

5. Agile/Scrum/Kanban

6. IT Leader Club Hanoi, Agile Vietnam

facebook.com/nguyenvuhung

vuhung16plus@gmail.com

+84-904-28-7878

Mục lục

1. Cứu dự án chậm2. Dự án thường gặp với dự án outsource/offshore3. Quản lý nhân sự (Việt Nam/Japan)4. Agile Development 5. Mapping Agile với Software Engineering

Cứu dự án chậmDự án Issue (chậm) Giải pháp

PX01 Dự án đã chạy 10 tháng,Chưa test tích hợp,Các nhóm đề nghĩ phần việc của mình là “DONE”,Nhưng tổng thể dự án chưa xong

Dự án đang ở đâu?Vấn đề của dự án là gì? (risk & issue log)Internal/External integrationTiếp theo phải là gì?Tiếp theo phải là gì?

SE01 Sản phẩm chạy trên production serverMọi người đều bức xúc, khó chịuMỗi tháng xảy ra 20 tickets trên production serverSố lượng ticket/công việc nhiềuTime-to-fix, time-to-release rất lâuCác thành viên nói xấu nhau, chia rẽ theo nhóm

Đo đạc1. EVM (theo feature)2. Time3. Những gì đã done, lượng hóa bằng

time + $$$Đặt độ ưu tiênLàm rõ yêu cầuLàm rõ DoD (thế nào là “xong”) -> gửi lại alt+Hỗ trợ communicationGiải quyết mâu thuẫn, tách thành viên dần ra khỏi dự án, thay đổi vai trò trách nhiệmMô tả lại quy trình

Ref. http://phalanx-vietnam.blogspot.com/2016/04/closing-project-what-you-need-to-do-as.html

Lý do vì sao dự án của chúng ta chậm?

1. Spec thay liên tục

2. Communication/dịch nhiều, sai

3. Estimate sai

4. Năng lực dev kém

a. Giải pháp: Đào tạo (có phí, trong ngoài, tự học), thay người, chấp nhận

b. Năng lực kỹ thuật của kỹ sư/lập trình viên nam không đến nỗi tồi

5. Chia task không tốt

6. Thay đổi nhân sự giữa đường

7. Nghĩ là xong nhưng thực sự là chưa xong

8. Phát sinh công nghệ mới

9. Req không rõ

10. Có issue nhưng không ai nói

Issue thường gặp với dự án outsource/offshoreVấn đề Cách giải quyết

Communication1. Biên dịch2. Phiên dịch

Leader học tiếng NhậtChọn ông biết tiếng Nhật là leaderCho người Nhật là leaderThay communication ở Nhật. Sales: not, tìm người biết tech, vị trí bridge ở Jp (madoguchi)Phiên dịch giỏiCó review

Quản lý yêu cầu (đầu vào)1. Không rõ ràng2. Hay thay đổi3. Yêu cầu quá cao vs. budget4. Leader ở Vn không quyết đoán, bị đì, gì cũng nhận

từ Jp5. Không đề cao việc quản lý yêu cầu

Làm cho nó rõ. Q: Thế nào là đủ rõ? Dev hiểu là OK. Review/confirm. Đặt Q để biết dev hiểu hay không.Confirm trước khi làmDoD (req) rõ ràngTư vấn ngược lại khách hàngCó vision/mission, long term planTừ chối, nói thẳngViệc của BA, fit and gapThuyết phục khách hàng, kỹ năng thuyết phục

Chốt/Close dự án (đầu ra)1. User Acceptance (Test)2. Definition of Done3. Change Request

Đây chính là giải phápThống nhất với khách hàng: Change request (CR), xử lý ra sao

1. CR, nghĩa là extend time2. CR, thì để phase/sprint sau làm3. Tôn trọng4. PMO (kiểu kiểu): những người có quyền quyết khi xảy ra mâu thuẫn, không đồng thuận

Technical issues/ HR skills Thuê expertTin tưởng là HR làm đượcVn: làm , lỗi, sửa, lõi, sửa tiếp. Kaizen, retrospective (chuẩn)

Brainstorm

1. Communication nhiều

2. Req không rõ (hiểu hơi sai. Lý do req không rõ

a. Khác biệt văn hóa, cách làm Jp/Vn

b. Mức độ nhận thức vấn đề khác nhau

c. Năng lực (làm ref. Definition (của khách hàng) thấp

3. Phải dịch

4. Văn hóa khác (Jp, vn)

5. Timezone lệch (Vn, Jp: không ảnh hương nhiều, time zone diff = 2h)

6. Quan điểm về chất lượng khác nhau

Đặc thù của dự án outsource/offshore là gì? (5’)

Khi nào thay thế nhân sự? (5’)Brainstorm

1. Bất khả kháng thì thay

2. Thay dần, đừng đột ngột

3. Thay càng sớm càng tốt

4. Khi được yêu cầu thay

5. Thiếu, cần bổ sung khả năng

6. Thay gối đầu, handover

7. Thay khi có mâu thuẫn không thể khắc phục

8. Khách hàng ép đuổi

9. Teamwork quá kém?

Quy trình phát triểnHiện trạng

1. Chưa có mấy

2. Tự build từ đầu

3. Dễ: với người mới

4. Khó: ở lâu, khó

Brainstorm

5. Bottleneck hay xảy ra ở đâu?

a. Tester không available

b. Req./spec không rõ

c. Communication không clear

6. Quy trình thế nào là tốt?

a. Rõ ràng RACI

b. Estimate chính xác

c. Tạo ra đột phá so với quy trình cũ

d. Có hoạt động kaizen, retro

e. Giao tiếp giữa các mem là smooth

f. CMMI, Agile/Scrum, Lean, Kanban

g. TiDD (Redmine)

7. Quy trình nặng/nhẹ

Quản lý nhân sự (IT: E, PG) (Việt Nam/Japan)Vấn đề Cách giải quyết

Nói xấu Team building, Nói xấu chỗ công khaiMinh bạch (thông tin)

Nhóm, vùng/miền Không có !?

Hứa mà không làm Thưởng, phạt, động viên

“Vâng ạ” nhưng không hiểu Confirm, hỏi khéo, hỏi bẫy, hỏi ngu

(có vẻ) thiếu trách nhiệm Điều chỉnh, giải thích, Define DoD

Viết, nói, trình bày kém Training (nội bộ, youtube, ra ngoài),Tổ chức seminarViết blog

Bụt chùa nhà không thiêng Thay đổi quan điểm

Không tin tưởng nhau Hãy tin nhau điCho phép thất bại

Quản lý nhân sự (IT: SE, PG) (Việt Nam/Japan)Vấn đề Cách giải quyết

Soi mói, bới lông tìm vết(không thấy lỗi của mình)

Dằn mặt, soi lại, khéo

Lười Thưởng/phạt -> ruleVì sao lười? Động cơ? -> mmotivate?

Cứ cho là mình đúng Khó, Phong thánh

Thiếu đoàn kết HR, Team buildingTeam lead

Kém kỷ luật Thưởng/phạt -> ruleLợn, rule

Học OK/nhanh, không đào sâu Cùng nhau học, học nhóm, học + hành,

Chạy nhanh giỏi, chạy bền kém Đổi gió,

Tính xấu người Việt (5’)

Brainstorm

1. http://vuongtrinhan.blogspot.com/2012/03/thoi-hu-tat-xau-nguoi-viet-trong-lam.html

2. Tính xấu người Việt.

Agile Development

1. Adoption/Transformation

a. Internal development team

b. Upward influence

i. (Top) Management

ii. Customers

2. Learning cycle

a. Shu-ha-ri

b. Tự quản

c. Tự chủ

d. Tự lập

Phát triển con người

Phương thức

1. Training

2. Coaching/Mentoring

3. Sensei-seito

4. Pair (programming)

5. Book reading club (読書会)

6. Internal/external seminars

7. Self study

Thuyết phục khách hàng dùng Agile/Scrum

Một số điểm quan trọng

1. Phía Nhật cần: Product Owner tốt

2. Phía Việt Nam: Cần ScrumMaster tốt

3. Educate, thay đổi quan điểm khách hàng

4. Làm thử thành thật

5. Tạo quan hệ tốt

6. Top down approaches (nhờ CEO/sếp nói xuống)

Khó khăn

7. Bảo thủ

8. Không chịu thay đổi

9. Cứ nghĩ mình là đúng

Mapping Agile với Software Engineering

1. Software Requirement

2. Software Design

3. Software Implementation

4. Software Testing

5. Software Maintenance

6. Software Configuration Management (CMM)

http://www.slideshare.net/vuhung16plus/run-hybrid-agile-waterfall-nguyen-vu-hung-scrumday2013

Tổng kết ITLC HN HR meetups

Xem các file đính kèm cùng folder này

(Agile) estimate: Có thể làm tốt hơn

1. Estimate: Chuẩn hơn, sai

2. Rõ ràng

3. Chia để trị

4. Chấp nhận thất bại

5. Lead estimate -> push mem làm

a. Ai estimate? Team lead? Member?

6. Loại công việc

a. Coding 1 chức năng (not 1 hàm/class) đã được break down

b. Rủi ro kỹ thuật, kỹ thuật mới

c. Có task phân tích

7. 1 tuần

8. Mức độ task nhỏ

9. Ẩn spec, spec chưa clear

10. Degrade

11. BA: tốt

12. Technical expert

13. Review chéo, toàn team

Một số KPI/Metrics cho dự án phát triển phần mềm

1. Schedule on time or not

2. Customer satisfaction (point, max 100)

3. Leakage bugs on User acceptance test

4. Code coverage (must not be lower than rates X = 20%, 40%, 60%, 80%...)

5. Unit test rate

6. Following coding convention

7. Cyclomatic Complexity/function (Jenkins)

8. Duplicated Code (Jenkins)

9. Number of defects on production server after deployment

10. Performance test gateway

11. Security test gateway

1. Number of Q&A

2. Team members understand requirements correctly (Rating: 1 ~ 5)

3. Productivity (user story/time/lines of code)

4. Time-to-fix for major tickets

5. Time-to-release for major tickets

6. Project process following defined process (Scrum, Kanban…) (Rating: 1 ~ 5)

7. Design document is clear enough (Rating: 1 ~ 5)

DoD mẫu cho dự án phát triển phần mềmHạng mục DoD (định nghĩa hoàn thành)

Đầu vào Chức năng yêu cầu/User story

Khi developers không còn câu hỏi (Q&A) nào (nghĩa là họ đã hiểu)

Coding Hoàn thành hết, viết unit test và pass 100%Code: 1) commit lên SCM 2) chạy được trên (staging) (test) server (dùng chung) (chứ không phải chỉ chạy trên local PC của developers)Mã nguồn được review và “OK” bởi mọi team members (cross review)

Đầu ra chức năng/story Demo với khách hàng Khách hàng test và chấp nhận là “done”

Hướng dẫn sử dụng Nếu cần thì viếtKhách hàng “OK” (approved)

Tài liệu thiết kế Developers nó “vừa đủ để code” (không cần viết quá chi tiết, không cần khách hàng review/approve)

Q&ATrao đổi

Project ManagementChia sẻ/Trao đổi cùng AltPlus

Nguyễn Vũ Hưng2016/04/21 @ AltPlus