Nội dung trao đổi cùng AltPlus: Cứu dự án chậm Dự án thường gặp với dự án outsource/offshore Quản lý nhân sự (Việt Nam/Japan) Agile Development Mapping Agile với Software Engineering

1. Project ManagementChia sẻ/Trao đổi cùng AltPlus
Nguyễn Vũ Hưng
2016/04/21 @ AltPlus

2. Tự giới thiệu
1. 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

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

4. Cứu dự án chậm
Dự á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 integration
Tiếp theo phải là gì?
Tiếp theo phải là gì?
SE01 Sản phẩm chạy trên production server
Mọi người đều bức xúc, khó chịu
Mỗi tháng xảy ra 20 tickets trên production
server
Số lượng ticket/công việc nhiều
Time-to-fix, time-to-release rất lâu
Các thành viên nói xấu nhau, chia rẽ theo
nhóm
Đo đạc
1. EVM (theo feature)
2. Time
3. Những gì đã done, lượng hóa bằng
time + $$$
Đặt độ ưu tiên
Làm rõ yêu cầu
Làm rõ DoD (thế nào là “xong”) -> gửi lại alt+
Hỗ trợ communication
Giả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ệm
Mô tả lại quy trình
Re

5. 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

6. Issue thường gặp với dự án outsource/offshore
Vấn đề Cách giải quyết
Communication
1. Biên dịch
2. Phiên dịch
Leader học tiếng Nhật
Chọn ông biết tiếng Nhật là leader
Cho người Nhật là leader
Thay communication ở Nhật. Sales: not, tìm người biết tech, vị trí bridge ở Jp (madoguchi)
Phiên dịch giỏi
Có review
Quản lý yêu cầu (đầu vào)
1. Không rõ ràng
2. Hay thay đổi
3. Yêu cầu quá cao vs. budget
4. Leader ở Vn không quyết đoán, bị đì, gì cũng nhận
từ Jp
5. 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àm
DoD (req) rõ ràng
Tư vấn ngược lại khách hàng
Có vision/mission, long term plan
Từ chối, nói thẳng
Việc của BA, fit and gap
Thuyế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 Done
3. Change Request
Đây chính là giải pháp
Thống nhất với khách hàng: Change request (CR), xử lý ra sao
1. CR, nghĩa là extend time
2. CR, thì để phase/sprint sau làm
3. Tôn trọng
4. 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ê expert
Tin tưởng là HR làm được
Vn: làm , lỗi, sửa, lõi, sửa tiếp. Kaizen, retrospective (chuẩn)

7. 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’)

8. 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

9. Quy trình phát triển
Hiệ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
1. Bottleneck hay xảy ra ở đâu?
a. Tester không available
b. Req./spec không rõ
c. Communication không clear
2. Quy trình thế nào là tốt?
a. Rõ ràng RACI

10. 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 khai
Minh 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 seminar
Viế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 đi
Cho phép thất bại

11. 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 -> rule
Vì sao lười?
Động cơ? -> mmotivate?
Cứ cho là mình đúng Khó, Phong thánh
Thiếu đoàn kết HR,
Team building
Team lead
Kém kỷ luật Thưởng/phạt -> rule
Lợ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ó,

12. 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.

13. 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ủ

14. 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

15. 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

16. 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)

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

18. Tổng kết ITLC HN HR meetups
Xem các file đính kèm cùng folder này

19. (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

20. 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
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)

21. DoD mẫu cho dự án phát triển phần mềm
Hạ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ết
Khá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)

22. Q&A
Trao đổi

23. Project ManagementChia sẻ/Trao đổi cùng AltPlus
Nguyễn Vũ Hưng
2016/04/21 @ AltPlus