2. Nội dung
Agile & ITO?
Lợi thế của Agile khi sử dụng trong ITO
Vấn đề của ITO & cách khắc phục
Tổng kết
3. Outsourcing
Tiết kiệm chi phí, thời gian, nhân lực
Phong phú về mặt kĩ thuật
Tăng năng suất lao động
Mở rộng việc kinh doanh
Agile Development
Làm rõ Requirement
Đem lại giá trị sớm
Tăng năng suất phát triển
Giảm rủi ro về mặt con người, tiến độ
Có nên áp dụng Agile trong dự án Outsourcing
⇒ Tại sao không?
15. - Chia sẻ rủi ro, mục tiêu kinh doanh chung với khách hàng, tạo nền tảng vững chắc cho hợp tác
- Đầu tư nhiều thời gian và công sức để đào tạo new member về giá trị của agile
- Xây dựng mối quan hệ vững chắc giữa 2 bên
- Minh bạch, cởi mở, tôn trọng lẫn nhau
- Giữ vững cam kết (thời gian..) dựa trên ưu tiên của người dùng
- Tuân thủ kỷ luật Agile
- Cải tiến liên tục dựa trên việc đo đạc thường xuyên để nhắm tới mục tiêu chung của dự án
- Loại bỏ các trở ngại về communication, thành viên nên được tương tác trực tiếp
- Nên có gặp mặt trực tiếp ở các cột mốc quan trọng (kickoff, release, end phase)
- Loại bỏ trung gian
- Build team ổn định, hạn chế luân chuyển member giữa các dự án
- Cả KH và team đều phải biết và đã có thói quen sử dụng Agile trước khi áp dụng mô hình vào dự án.
- Phía khách hàng nên có 1 nhóm bao gồm cả dev, SM điều phối các bên liên quan
Yếu tố cần để Agile outsoucing thành công
Vì sao lại cần outsourcing?
Các điểm mạnh của Agile hỗ trợ rất tốt cho các dự án phát triển phần mềm - đặc biệt trong Outsourcing.
Tất nhiên, một số vấn đề của Outsourcing làm cho Agile Development bị ảnh hưởng. Nếu khéo léo áp dụng ta có thể hạn chế, thậm chí loại bỏ hoàn toàn các vấn đề này
Vậy tại sao lại không nhỉ?
Outsourcing: KH ở xa, bất đồng ngôn ngữ => việc thông tin bị sai lệch là khá cao
Agile Development: tập trung rất nhiều vào Plan, tìm hiểu rõ một số tính năng trong 1 sprint. Ngoài ra, trong quá trình phát triển, mọi vấn đề phát sinh đều được đồng bộ lại.
=> rất phù hợp
Thực tế: Planning là sự kiện quan trọng nhất trong 1 sprint. Ở NAL, thường tiến hành planning dài hơn lý thuyết tầm 50~100%
“Shit in shit out” - đúng cho cả buổi planning lẫn Sprint ^^
Case: phần lớn team ở NAL đều tiến hành pre-planning (1 dev + Proxy). Sau khi plan xong thì tập trung QA để hỏi 1 lần
KH sớm nhìn thấy/trải nghiệm sản phẩm sẽ như thế nào, hoạt động ra sao…
=> sớm điều chỉnh kế hoạch (tính năng, lịch phát hành…)
=> tiết kiệm chi phí
Outsourcing: KH outsource với mục đích tìm kiếm cơ hội sản xuất với chi phí rẻ hơn
⇒ phù hợp ^^
Case NAL: Thay đổi tính năng
Dự án Bang-guru: nâng cấp web/app cũ - bổ sung tính năng mới, giao diện mới.
Trong quá trình phát triển, khách hàng thường xuyên chỉnh sửa lại thiết kế (cả giao diện lẫn tính năng).
Lý do: lúc thiết kế ko nghĩ tới, có hàng để dùng mới thấy ko thật sự hợp lý.
=> nâng cao UX
Trong Agile dev, mọi sự kiện đều time-box => tạo cảm giác gấp gáp cho team khởi động và kết thúc mọi việc sớm. Ngoài ra, các cơ chế cộng tác, chia sẻ kiến thức, tháo gỡ khó khăn… giúp team tăng năng suất công việc.
Outsourcing: thuê ngoài thì tất nhiên mong muốn có năng suất cao.
⇒ quá phù hợp
Case: Kenshin
Kenshin ko release dc item nào trong 1 tháng
Từ khi tinh chỉnh lại để làm đúng Scrum, loại bỏ khó khăn => tốc độ tăng dần và ổn định
Tốc độ trung bình: 50 point / sprint (2 tuần). Riêng 13 và 14 có 2 member cưới nên 12, 13 anh em dồn sức OT để bù đắp công số cho 2 bạn. Các sprint cuối giảm dần vì khách tích hợp ko kịp -> ko chuẩn bị kịp spec cho team ^^
Agile áp dụng các kỹ thuật chia sẻ thông tin (code ownership, pair programming, daily report…)
⇒ giảm rủi ro về mặt con người cho dự án
Case NAL: dịch bệnh
Team SIP là trung tâm ổ dịch - hoành hành suốt 2 tuần. Cao điểm có 3 member nghỉ cùng một lúc (2 dev + Proxy). Trong khi team có 7 member.
Các member team khác cũng ảnh hưởng: lây bệnh hoặc sợ lây xin nghỉ.
Sale nói chuyện với từng khách hàng để xin feedback - Kết quả: output của team/công ty suy giảm không đáng kể. KH ko thấy điều gì bất thường trong output.
Khách hàng luôn có những kế hoạch (dự kiến & mong muốn) “vào thời điểm nào phát hành những tính năng nào”
Thông qua các vòng lặp ngắn, tốc độ của team sẽ được làm rõ. Tương tự, độ lớn của dự án sẽ được ước lượng ngày càng chính xác
⇒ xác định được các mốc dự án có khả thi hay không
=> phù hợp với mọi loại dự án, ko chỉ riêng Outsourcing
Case: Kenshin
KH tự estimate
> lượng việc ký với NAL ban đầu: 18 MM
3 Dev dự kiến 5-6 tháng (31/12 kết thúc)
> lượng việc lúc est lại: 54 MM
6 Dev dự kiến (31/03/2017)
Nhờ xác định được tiến độ và khối lượng công việc - KH đã đưa thêm người để phối hợp cùng team, cắt giảm lượng việc cũng như thay đổi DoD => hoàn thành đúng tiến độ.
Khách hàng có thể yêu cầu team VN dùng Agile - mặc dù bản thân có thể chưa hiểu đúng.
Team VN nhận yêu cầu, cho cả team đọc “Scrum guide” / cử 1 chú đi học 2 ngày về làm SM.
Agile là 1 danh từ riêng
agile là tính từ “nhanh nhẹn” hoặc “linh hoạt”
Từ hiểu sai dẫn tới làm sai: ai muốn làm gì thì làm, rất linh hoạt và không có quy trình.
Giải quyết
NAL: thuê coaching fulltime (ĐớiPA) để bản thân hiểu đúng/áp dụng đúng Agile/Scrum. Từ đó tiến tới tư vấn cho khách hàng cuối.
Case: Kenshin Dự án NAL nhận, outsource sang cho vendor. Sau 2 Sprint (4 tuần) ko burn được dù chỉ 1 point. Giải quyết: hót về NAL để giải quyết. Và giải quyết được ^^
Dự án này còn được nói đến trong các slide sau.
Communication: khi đội dự án làm việc ở xa thì chỉ vấn đề nhỏ cũng trở thành lớn
Khác biệt văn hóa
Thời gian: lệch múi giờ
Ngôn ngữ
Rất khó để gặp mặt đối mặt
Case NAL : team G
Tình trạng từ “luôn luôn hài lòng” (2 năm liên tiếp) trở thành “thường xuyên bị trỉ trích” (trong tháng 2, 3, 4 năm 2017. Đến tháng 5 đã khôi phục lại trạng thái “bình thường”).
Lý do: 2 sự kiện chính. JP đổi người quản lý dự án, bàn giao ko đủ. VN sau đó cũng đổi người giao tiếp, follow người mới ko chặt => “phía JP ko biết phía VN đang làm gì” và “phía VN không hiểu phía JP muốn gì”
Case Framgia: Buổi họp giữa BrSE và KH kéo dài do Team không thể trao đổi trực tiếp tiếng nhật với KH, Brse phải tổng hợp câu hỏi và khi họp hỏi, nhưng lúc đặt câu hỏi KH mới suy nghĩ spec → việc này kéo dài lâu gây mất thời gian của cả 2 bên
Giải quyết:
Tăng thời lượng và số lượng kênh giao tiếp
Khuyến khích team VN học ngôn ngữ của khách
Mời khách sang định kỳ
Bố trí thời gian làm việc chung giữa 2 bên càng nhiều càng tốt
Chuẩn bị trước nội dung cần trao đổi, thống nhất ở dạng văn bản
Trung gian: Khách hàng chính => khách hàng kí hợp đồng => BrSE...
* Case Framgia : đã chốt Sprint Goal & các item. Tuy nhiên giữa tuần khách lại muốn đẩy thêm item mới. Mặc dù item rất khó để clear cần bao nhiêu công số để thực hiện, spec của item mới cũng chưa đầy đủ, vừa làm vừa phải confirm.
Lý do: - đẩy thêm việc: bản thân khách ký hợp đồng bị KH cuối ép - mất thời gian: bản thân khách hàng ký hợp đồng cũng ko clear về DB, phải tương tác với khách hàng cuối
Case NAL: Banking
KH ký hợp đồng đi “cướp” dự án của mrX => ko dc bàn giao các tài liệu liên quan Khi uỷ thác lại cho VN làm thì hai bên vừa làm vừa mò => bug nhiều vô số => ảnh hưởng xấu đến cả tiến độ release lẫn tinh thần team.
Đề xuất giải quyết
Tập trung làm việc với khách hàng ký hợp đồng
Giao tiếp cần lưu vết
Tích luỹ know-how trong nội bộ team, từ đó giảm dần các giao tiếp không cần thiết, thậm chí hỗ trợ khách hàng ký hợp đồng
Minh bạch giữa KH cuối (PO) và Team phát triển
> Member thực sự làm trong team? công việc thực sự làm trong dự án?
> Big picture & tầm nhìn của sản phẩm? Spec thay đổi?
Đàm phán với khách nhận output theo tuần (nếu có thể, 2 tuần một lần). Giải quyết ntn là phần của VN (dạng black-box)
Khách hàng sang chia sẻ thông tin dự án thường xuyên (3 tháng / lần)
KH update spec nhưng quên báo với team => Xây dựng protocol với khách hàng:
Spec lưu offline: mỗi lần update spec thì gửi lại riêng spec đó - ghi chú rõ thay đổi ở đâu
Spec lưu trên cloud: ca này khó => né
Đồng bộ Spec qua tool (SVN, Git…): khi commit phải kèm comment cụ thể về thay đổi. Thiết kế hook để email các bên liên quan mỗi khi repo được cập nhật
Case Framgia: khách hàng kí hợp đồng không hiểu rõ spec, đưa ra requirement ko hợp lý (nhưng vẫn đủ clear để thực hiện), team cố làm theo ko feedback để confirm → đến khi demo mới nhận thấy ko hợp lý và lại làm lại.
Khách hàng *thường* chỉ quan tâm đến lượng hàng nhận được, có kịp mốc release sắp tới ko...
Vì thế, dev team VN cũng thường bị cuốn vào luồng suy nghĩ này.
=> miss các thông số khác liên quan đến sức khoẻ của team, của dự án.
Ví dụ như Code smell, lượng bug, nợ kỹ thuật, thời gian OT, unit test...
Giải pháp
NAL: Cài “cảm biến” vào từng team, từng dự án. Đo hàng ngày - do từng team chủ động tiến hành.
(mặc dù hiện tại khách hàng cuối ko yêu cầu)
Framgia: dùng Jira hỗ trợ trong việc export/filter các báo cáo, số liệu
> Xây dựng mối quan hệ vững chắc giữa 2 bên
Như một số case đã trình bày - đặc biệt từ phía NAL, các ca khó đẻ đều dc tháo gỡ dựa trên sự hợp tác.
Ví dụ Kenshin, nếu khách khăng khăng “hợp đồng ký rồi, ông làm đi” thì chắc chắn vỡ dự án.
> Loại bỏ các trở ngại về communication, thành viên nên được tương tác trực tiếp
Các thành viên nên được tương tác trực tiếp để confirm với KH trong từng task, hạn chế việc trao đổi 1-1 và truyền đạt thông qua BrSE vì có thể bị miss thông tin hoặc hiểu sai về mặt kĩ thuật, việc truyền đạt qua 1 người quá nhiều thông tin cũng gây chậm chễ trong cv
> Nên có gặp mặt trực tiếp ở các cột mốc quan trọng (kickoff, release, end phase)
Để KH tương tác trực tiếp với team, đưa đến vision về sản phẩm - chạy thử bản alpha trên môi trường dev - tăng mối liên kết giữa các bên
> Build team ổn định, hạn chế luân chuyển member giữa các dự án
Team ổn định -> chia sẻ know how về dự án tốt -> hạn chế các rủi ro về con người cũng như tiến độ dự án.
=======================
> Cả KH và team đều phải biết và đã có thói quen sử dụng Agile trước khi áp dụng mô hình vào dự án.
Khách hàng yêu cầu mình dùng Agile nhưng bản thân họ làm ko đúng => mâu thuẫn
> Phía khách hàng nên có 1 nhóm bao gồm cả dev, SM điều phối các bên liên quan
Sử dụng Scrum of Scrum
