Thao Trinh – Người thích tự do và lang thang như gió -
  • Trang chủ
  • Chuyện nghề
  • Đọc
  • Me
Thao Trinh – Người thích tự do và lang thang như gió -
Trang chủ
Chuyện nghề
Đọc
Me
  • Trang chủ
  • Chuyện nghề
  • Đọc
  • Me
Chuyện nghề, Đọc

Giá trị của Scrum Master trong case study của Leflair

thaotrinh.info__gia-tri-cua-scrum-master-trong-case-study-cua-leflair

Leflair là một case study hấp dẫn.
Nhân viên cao cấp của Leflair không đồng ý với cách CEO “đốt tiền” bằng việc thuê nhà thầu ở Úc làm app di động.
App di động đa chức năng, high-performance phát triển hoàn toàn tại Úc tầm giá 1 triệu đô đổ lên.
Giá các team gia công ở Việt Nam chào ở khoảng từ 10 nghìn – 100 nghìn đô.
Bài toán nghe tưởng dễ, làm ở Việt Nam đi cho nó rẻ. Để tiền đó để tăng trưởng người dùng, hoàn thiện khâu vận hành.

Nhưng thực tế không hiếm khi các sếp startup mặc dù có nguyên team phát triển ở Việt Nam, vẫn chấp nhận mang đi outsource với một giá cao hơn rất nhiều.

Tại sao nhỉ?

Mình xin mạn phép đưa ra một số giả thuyết cá nhân, và xin phép các cây đa, cây đề công nghệ trong danh sách bạn bè “sửa lưng” nếu có ý sai.
Qua kinh nghiệm làm thiết kế trải nghiệm cho các sản phẩm tech, và việc thường xuyên làm “người bắc cầu” giữa đội chỉ huy và đội phát triển. Mình thấy chuyện thị trường phần mềm, và web ở Việt Nam như sau:
Khúc 1: Làm gia công cho phần mềm doanh nghiệp lớn, khách hàng chủ yếu là Nhật Hàn. Sử dụng những hệ thống đã khá lâu năm, ổn định. Nhóm này có FPT, CMC
Khúc 2: Nghiên cứu và phát triển dựa trên những tiến bộ về kĩ thuật mới như AI và cryptocurrency. Khúc này có công ty cũ của mình: Kyber Network
Khúc 3: Làm sản phẩm cho khách hàng cá nhân hoặc doanh nghiệp nhỏ. Tập trung vào các nền tảng web mới, Java Script, RoR, nền tảng di động Android, iOS.

Khúc này chạm đến nhiều phần, là phần khúc to nhất và ra nhiều tiền nhất nếu làm đúng, xoay trái xoay phải làm tốt đi đâu cũng ra tiền. Vì giá chúng ta đang chào quá rẻ với thị trường thế giới, chưa kể có rất nhiều mô hình kinh doanh nội địa chúng ta có thể xây được từ khúc này.

Nhưng… chúng ta lại không có được những hợp đồng tốt nhất, và các sếp vẫn đòi đi gia công nước ngoài.

Và mình ấn vào app của Techcombank vẫn lag đều, Timo giao diện rất tốt nhưng phần logic phục hồi tài khoản cực kì “tụt mood”. Dù rất yêu Now nhưng vẫn phải dùng Grab Food cho đỡ lag.

Nguyên nhân của khúc 3 vẫn còn chưa ổn là do những lý do sau đây:

Cấp chỉ huy cao nhất không có nền tảng kỹ thuật, hoặc không tin tưởng vào cấp phó/cố vấn kĩ thuật của mình. Không phải ngẫu nhiên mà 5 năm trở lại đây mà các nhà đầu tư ra rả nói bọn tao muốn đầu tư vào các công ty công nghệ được chỉ huy bằng kĩ sư và người thiết kế sản phẩm – “engineer and design driven”.

Không phải ngẫu nhiên mà HSBC – một huyền thoại banking đang thua trong cuộc chơi digital, và mất đi túi tiền của tập khách hàng trẻ.

Revolut, Transferwise – những kì lân ngân hàng trẻ đều có founder với background kĩ thuật. Điều kiện gọi vốn ban đầu đối với CEO của Canva, một người vốn có tố chất thiết kế sản phẩm là cần tìm một co-founder có nền tảng kĩ thuật.

Văn hoá đội tech tốt cần bình đẳng và tranh luận tích cực.

Với văn hoá Á Đông, chúng ta ít khi “có được những cuộc đối thoại khó khăn” với sếp.
Một người bạn Mỹ làm quản lý công nghệ cao cấp ở Nhật đã nói với mình rằng:
“Khi một kĩ sư trẻ trình bày một vấn đề, anh ta phát hiện lúc code hàng ngày: rằng quy trình team đang vận hành sẽ tạo ra nhiều bug và thứ khó sửa về sau”
Bạn mình thở dài và nói tiếp “Chúng nó, sẽ dùng tất cả các biện pháp có thể, dúi thằng bé xuống – như đóng 1 cái đinh lại vào mặt sàn ấy mày biết không, đóng cho tất cả những cái đinh bằng nhau thì thôi”
Và cái lỗi đấy được chôn sâu, cho đến khi hệ thống vỡ. Bạn kĩ sư trẻ đã học được bài học “phải im lặng”. Team đó đã mất một thời gian dài để hồi phục lại hệ thống, và vĩnh viễn mất đi sự tận tâm của hai kĩ sư tâm huyết.

Văn hoá “mày sai là mày chết”

Phần mới của phim “Những thiên thần của Charlie” có thêm 1 cô điệp viên hacker tốt nghiệp MIT cho hợp thời đại.
Có một đoạn, cô điệp viên hacker đề nghị thử một phương án để cứu nguy cả team trong tình huống nguy cấp. Cô bạn tác chiến cùng đội hỏi: cái này mày nghĩ là “Sự thật hay giả định”? (Fact or Hypothesis?).
Cô hacker hùng hồn trả lời “Dĩ nhiên là giả định – nguyên tắc số 1 của khoa học là bắt đầu bằng giả định”, nói rồi tí toáy hack vào cái thiết bị với khả năng 50/50 – hoặc là ra ngoài, hoặc chết.

Mình đang uống nước tí sặc vì buồn cười.

Vì làm sản phẩm startup công nghệ cũng có lúc cãi nhau chán chê xem cái này có đúng không? Và mọi người quên rằng nhiều thứ chỉ là dự đoán cho đến khi có đầy đủ dữ liệu.
Xây một hệ thống đầu tiên cho 10,000 người dùng thì ổn. Khi bung ra 10x thì một team trẻ chưa có kinh nghiệm bắt đầu từ đâu? Dĩ nhiên bắt đầu bằng giả định.

Làm thế nào để làm được việc chưa ai làm bao giờ, ở quy mô lớn chưa từng có bao giờ? Dĩ nhiên phải bắt đầu bằng giả định.

Với giả định thì rất có thể sẽ sai. Cái khó là làm sao chúng ta có thể vui vẻ chấp nhận “sự sai đấy” ở mọi cấp quản lý và yêu lại từ đầu.

Bạn không tin mình ư? Hãy nhìn vào killedbygoogle.com – tập hợp những giả định sai của Google.

Mình nhận ra rằng chúng ta vẫn còn rất nặng nề với chuyện thất bại, hay ai sai ai đúng ở VN, và đặt rất nhiều gánh nặng lên cấp quản lý.

Lâu dần những sự nặng nề thành văn hoá ngại thử nghiệm, ngại sai, ngại học, ngại góp ý.

Tại sao tao phải thử framework hoạt động mới khi cái cũ vẫn tạm dùng được. Bất chấp những yêu cầu mới của khách hàng, thị trường. Thói quen này là đòn chí mạng với các team hoạt động ở Khúc 3, khi thị trường trả lời cực nhanh cho những team không thích ứng được.

Cũng là nguyên nhân tại sao chúng ta vẫn chưa chạm tay được vào những hợp đồng outsource hấp dẫn nhất.

Ghi chú: Bài viết đã được hiệu chỉnh 1 chút về mặt hiển thị, và thêm 1 cái tiêu đề khá kêu để các bạn Scrum Master thử đặt mình vào case Study để giải quyết thử vấn đề ở mức đội nhóm, coach về Agile mindset và Scrum framework cho Team.
Bài viết đi lượm trên internet, lỡ quên nguồn. Xin lỗi tác giả!

March 5, 2021by thaotrinh
Chuyện nghề

Bàn về rủi ro trong dự án sử dụng Agile

thaotrinh.info__ban-ve-rui-ro-trong-du-an-su-dung-agile

Quản lý rủi ro dự án là phạm trù rộng lớn, theo đó trong dự án chúng ta cần quản lý rủi ro tới từ nhiều phía. Rủi ro từ phía khách hàng, rủi ro từ nguồn lực thực hiện dự án (nhóm phát triển), rủi ro tới từ quy trình phát triển sản phẩm, rủi ro từ hiểu biết về công nghệ, rủi ro tới từ thị trường, rủi ro tới từ các quyết định của các cấp quản lý…
Trong mô hình phát triển sản phẩm truyền thống, các rủi ro này được quản lý dự án định nghĩa và quản lý trong suốt quá trình thực hiện, và mặc dù nó là một công việc có khối lượng khổng lồ cần rất nhiều thông tin để đưa ra các đánh giá và quyết định, quản lý dự án thường rất bị động trong việc tiếp nhận thông tin tới từ các bộ phận trong dự án và các bên liên quan: đôi khi nó quá chậm, hoặc đôi khi, độ chính xác của nó cần được lên án!

Vậy Scrum thực hiện quản lý rủi ro dự án bằng cách nào? Hay như thế nào?
Scrum framework được tổ chức gồm 3 vai trò: product owner, scrum master, development team; cả 3 vai trò trên đều thực hiện việc quản lý rủi ro dự án theo các công việc mà mình đảm nhận, được thiết kế thông qua các sự kiện trong framework. Thông qua đó, việc đánh giá và xử lý các rủi ro được trao cho các vai trò cụ thể. Mỗi vai trò sẽ có trách nhiệm giải quyết những vấn đề ảnh hưởng tới sự thành công của dự án liên quan công việc mà mình đảm nhận.

Các sự kiện giúp xác định rủi ro và hạn chế rủi ro

Dailly Meeting tuân theo framework, với các sự kiện, scrum team sớm phát hiện các vấn đề cần xử lý để lập kế hoạch hành động nhằm thích ứng hoặc giải quyết.
Ví dụ với Daily Meeting nhóm đồng bộ thông tin sau mỗi 24h, tự lên kế hoạch để thích nghi và giải quyết các vấn đề ảnh hưởng tới mục tiêu của nhóm. Hoặc lúc này scrum master sẽ có trách nhiệm hỗ trợ giải quyết các vướng mắc từ bên ngoài tác động tới công việc của nhóm. Việc trao quyền cho nhóm tự giải quyết các khó khăn lúc đầu có thể là thách thức với các bên: nhóm quản lý, PO, SM và chính cả nhóm phát triển. Tuy nhiên về lâu dài, điều này khuyến khích nhóm tự quản lý, nâng cao trách nhiệm, tính chủ động và tăng khả năng dự đoán của nhóm. Một nhóm tự quản lý, có trách nhiệm và khả năng dự đoán có thể tin tưởng được chắc chắn sẽ hạn chế rủi ro cho bất kì dự án nào.

Sprint Planning cùng với Dailly meeting, sprint planning cho phép nhóm lập kế hoạch ở mức sản phẩm, trong khoảng thời gian ngắn dưới sự tối ưu giá trị công việc từ product owner.
Product owner sắp xếp các công việc, theo độ ưu tiên để nhóm phát triển thực hiện trong Sprint. Điều này giúp sản phẩm luôn mang tới giá trị lớn nhất cho khách hàng và các bên liên quan. Các thông tin được nhóm lập kế hoạch dựa trên kinh nghiệm đã trải qua trong quá khứ (các sprint trước) dẫn tới tính tin cậy cao hơn. Việc trao quyền lập kế hoạch phát triển cho nhóm phát triển cũng giúp các bên có trách nhiệm liên quan nhìn nhận thực tế, tránh đi vào việc kì vọng vượt quá khả năng thực tại và gây ra những quyết định sai lầm. Nhóm lập kế hoạch dựa trên những user story là đại diện cho những yêu cầu của người dùng, điều này giúp nhóm phát triển hiểu đúng mong muốn của khách hàng, giảm thiểu lãng phí nguồn lực trong quá trình phát triển. Sprint planning không phải là kế hoạch hoàn hảo 100% nhưng nó là kế hoạch đáng tin cậy để thực hiện những tác vụ quan trọng nhất.

Sprint refinerment là một sự kiện dễ bị bỏ qua nhưng lại rất quan trọng.
Có thể hiểu đây là một buổi lập kế hoạch cho buổi lập kế hoạch. Tuân theo scrum framework, mọi thứ đều được chuẩn bị và trù liệu nhằm tăng khả năng thành công của dự án. Để đổi lại điều này, chúng ta cần dành ra thêm thời gian để meeting, tuy nhiên nó đáng giá để đánh đổi.

Sprint review nơi mà scrum team cộng tác với khách hàng nhằm thích nghi với sản phẩm và lên kế hoạch cho những gì thực hiện tiếp theo.
Không giống cách làm truyền thống, sau quá trình phát triển, kiểm thử khách hàng mới được tiếp cận sản phẩm, đôi khi lúc này phản hồi của khách hàng là quá trễ cho sự thay đổi của thị trường hoặc nhu cầu. Chu trình lặp đi lặp lại, phát triển, kiểm thử, phản hồi (quá muộn). Việc này đặt khách hàng và nhóm phát triển vào các tình thế khó khăn khác nhau. Scrum framework xử lý vấn đề này bằng sự kiện sprint review, nơi khách hàng có thể “dùng” sản phẩm sau mỗi 2-4 tuần. Đánh giá tính khả thi và đưa ra quyết định. Ngoài ra điều này cũng kéo khách hàng gần hơn với nhóm phát triển để thông qua đó, hiểu nhóm đang nỗ lực; và có thể cung cấp thông tin phản hồi sớm hơn. Điều này giúp giảm thiểu các rủi ro từ phía khách hàng, từ việc hiểu sai yêu cầu, thay đổi và phản hồi; hoặc đôi khi là nhận xét nhóm phát triển đang không nỗ lực.

Sprint restropective scrum team cải tiến chất lượng.
Tại buổi hợp restropective, scrum team tìm giải pháp để cải tiến các vấn đề về con người và quy trình, lấy ra ít nhất một cải tiến được đánh độ ưu tiên để thực hiện trong sprint tiếp theo. Việc không ngừng cải tiến và thực thi cách tương tác, và quy trình làm việc giúp giảm thiểu rủi ro cho những việc được phát hiện, nhưng bị “bỏ quên”.

Các Role quản lý rủi ro

Scrum team định nghĩa 3 vai trò: Product Owner, Scrum Master và Development Team. 3 vai trò thực hiện những công việc khác nhau, theo quy trình Scrum giúp giảm thiểu rủi ro.

Product owner giảm thiểu rủi ro cho dự án bằng cách lập kế hoạch phát hành sản phẩm, tối ưu hoá ROI, và năng suất làm việc của nhóm.
Product Owner quản lý product backlog hay những “yêu cầu” từ phía khách hàng, thị trường hoặc bên liên quan. Việc quản lý product backlog bao gồm các nhiệm vụ: Thêm mới yêu cầu, phân tách chức năng thành những yêu cầu nhỏ hơn, đặt tiêu chí hoàn thành, tiêu chí chấp nhận cho user story; và quan trong là việc sắp xếp lại độ ưu tiên cho các user story. Việc này giúp scrum team ưu tiên tập trung vào các công việc có giá trị cao trước, thêm nữa, các công việc này khá rõ ràng để hiểu và thực hiện. Product owner cũng là người làm việc nhiều với các bên liên quan, tìm kiếm những yêu cầu để đưa vào product backlog, hạn chế việc một developer với ngôn ngữ kĩ thuật làm việc với một khách hàng có ngôn ngữ end user, điều này có thể gây conflix không cần thiết trong nhóm phát triển.

Development team giảm thiểu rủi ro thông qua việc thích nghi với quy trình, phát lộ các vấn đề trong các sự kiện Scrum và giải quyết chúng. Tập trung vào sprint backlog và sprint goal.
Giống product owner chỉ tập trung vào product backlog, development team chỉ tập trung vào sprint backlog. Nơi mọi công việc đã được lập kế hoạch trong sprint planning. Mọi thay đổi không nằm trong kế hoạch sẽ được đánh giá và thảo luận với sự đồng thuận của nhóm phát triển. Việc này duy trì khả năng cam kết của nhóm, khả năng tự tổ chức. Điều này giúp các kế hoạch ban đầu luôn có khả năng hoàn thành cao hơn. Và các dự đoán của nhóm phát triển ngày càng trở nên tin cậy hơn.

Scrum Master đảm bảo quy trình được vận hành đúng, hỗ trợ tháo gỡ các khó khăn trong quá trình làm việc cho PO và Development Team. Ngoài ra Scrum Master cũng là người chịu trách nhiệm để 3 trụ cột của Scrum được tuân thủ: minh bạch, thanh tra và thích nghi. Việc thực hiện thanh tra và thích nghi giúp tạo ra sự minh bạch. Minh bạch cuối cùng sẽ giảm thiểu rủi ro khi thực hiện dự án.

Thông qua Agile và Scrum framework, việc quản lý rủi ro được “điều phối” cho 3 vai trò và các sự kiện thay vì tập trung việc quản lý rủi ro cho vị trí Project Manager như cách làm truyền thống.

September 4, 2020by thaotrinh
Agile (APM)

Bàn về rủi ro trong dự án Agile

thaotrinh.info__ban-ve-rui-ro-trong-du-an-agile

Với sự hiểu biết về Agile và Scrum, bạn dễ dàng nhận thấy việc quản lý rủi ro trong dự án áp dụng Agile/Scrum được thể hiện ở các đặc điểm của Agile hay trong các sự kiện của Scrum Framework.

– Lặp và tăng trưởng: Scrum chia “dự án” thành các giai đoạn – sprint kéo dài từ 1-4 tuần. Kết quả của mỗi sprint là một phần tăng trưởng có thể sử dụng được (tuỳ thuộc định nghĩa hoàn thành, phần tăng trưởng này có thể deploy hoặc không). Việc theo dõi thường xuyên và liên tục được phần tăng trưởng này giúp khách hàng tiếp cận được kết quả sản phẩm sớm hơn và đưa ra các phản hồi. Việc này giúp tránh lãng phí nguồn lực, thời gian và chi phí. Việc theo dõi kết quả của nhóm phát triển thường xuyên cũng giúp PO (SM) nhận định được năng suất thực tế của nhóm. Từ đó đưa ra các chiến lược để tối ưu hoá được năng suất lao động.

– Giao tiếp thường xuyên và hiệu quả: Scrum định nghĩa các sự kiện, tuân theo nó, nhóm phát triển thực hiện công việc theo nhịp độ đều đặn. Từ nội dung và kết quả các sự kiện, SM giúp nhóm phát lộ các vấn đề – bằng các kĩ thuật đặt câu hỏi, từ đó xử lý hoặc đưa ra các giải pháp thích ứng. Ví dụ thông qua buổi họp daily stand up, nhóm phát triển phát hiện một vài issues có thể ảnh hưởng tới tiến độ chung của cả đội, việc tìm ra giải pháp và người chịu trách nhiệm (follow up để hỗ trợ) là cần thiết, lúc này thay vì cá nhân đang gặp issue tự giải quyết vấn đề, buổi họp daily stand up có thể giúp đội nhóm hiểu vấn đề đang có, và cùng đưa giải pháp hoặc cùng tìm kiếm giải pháp trợ giúp thành viên của nhóm. Nhóm phát triển cũng luôn giao tiếp với PO nhờ hỗ trợ giải đáp các vấn đề liên quan tới User Story – nơi được hiểu là bao gồm các yêu cầu của các bên liên quan, và khách hàng cuối. Điều này khiến nhóm phát triển luôn hiểu đúng các yêu cầu và thực hiện đúng những mong muốn của PO (hay khách hàng)

– Vòng phản hồi ngắn và thích ứng thường xuyên, minh bạch thông tin: Các sự kiện trong Scrum giúp nhóm phát triển tương tác thường xuyên, minh bạch thông tin từ đó phát hiện sớm các vấn đề để giải quyết (hoặc thích ứng).

– Công cụ hỗ trợ, bao gồm: Tích hợp liên tục CI/CD, lập trình cặp – pair programing, refactoring code, lập trình hướng kiểm thử TDD…

Scrum không nhắc đến cụ thể việc quản lý rủi ro cho dự án phần mềm, tuy nhiên cùng với triết lý Agile, Scrum Framework thiết kế các sự kiện, các vai trò, sprint và các artifact từ đó giúp nhóm phát triển vận hành và làm việc theo một khung làm việc chung, đều đặn, từ đó dần cải thiện năng suất, sớm phát hiện các vấn đề để tìm cách xử lý thích nghi.

Là 1 PM truyền thống, và giờ đóng vai trò PO trong dự án phần mềm, bạn cần làm gì để quản lý rủi ro hiệu quả?

– Giao tiếp, giao tiếp và giao tiếp: Vai trò PM hay PO khá giống nhau ở yêu cầu công việc cần giao tiếp rất nhiều. Tương tự PM, PO cần giao tiếp với các stack holder, khách hàng để chuyển hoá những yêu cầu thành các User Story trong Product backlog.PO cần dành đủ thời gian cho nhóm phát triển để giải thích về các User Story trong Sprint backlog – trong trường hợp buổi planning chưa thể làm rõ được, hoặc tiêu chí hoàn thành cần phải cập nhật cho phù hợp với điều kiện thực tế. Bởi vậy, lời khuyên đầu tiên là Hãy dành đủ thời gian – cho nhóm phát triển và product backlog.

– Product backlog là quan trọng: Hãy luôn làm rõ các hạng mục công việc trong product backlog theo độ ưu tiên, càng ở trên cao thì các yêu cầu công việc càng phải rõ ràng, có tiêu chí hoàn thành – làm thế nào nhóm phát triển có thể hoàn thành công việc nếu họ không biết thế nào là hoàn thành? Bạn sẽ tốn bao nhiêu tài nguyên và nhân lực để làm một chức năng không đúng với yêu cầu của người dùng (khách hàng)?. Làm sao PO tối ưu hoá được ROI nếu không có thứ tự ưu tiên cho các công việc? Làm thế nào các manager có thể hỗ trợ team nếu không phát hiện ra các vấn đề. Hãy chú ý lời khuyên thứ 2: Product backlog là quan trọng, làm rõ nó, minh bạch với các bên liên quan.

– Tập trung vào một sản phẩm: Tuỳ tình huống, PO có thể phải đảm nhiệm hơn 1 sản phẩm. Việc này không bị cấm, nhưng không hề được khuyến khích. Đừng tham lam, lúc này bạn và tổ chức phải đánh đổi, 1 người chuyên hay 1 người đa nhiệm?

– Dù PO sẽ bị áp lực bởi nhiều bên để đưa vào các yêu cầu mới, cập nhật các yêu cầu cũ, nhưng bạn hãy cân nhắc việc này. Đưa nó vào product backlog, đánh độ ưu tiên, tạo tiêu chí hoàn thành, tiêu chí chấp nhận được thì tốt hơn là đưa vào sprint backlog – nơi các công việc của nhóm phát triển đã được định hình. Hãy chỉ nên dừng 1 sprint khi mục tiêu của nó đã lỗi thời – không nên vì một lý do nào khác. Lời khuyên thứ 3: Chuyển các yêu cầu vào product backlog. Đánh giá các cập nhật, nếu nó không làm ảnh hưởng tới sprint goal thì có thể thương lượng với nhóm phát triển để xử lý nó đồng thời trong sprint.

– Năng suất của nhóm cần được tôn trọng: Agile hay Scrum không giải quyết tất cả các vấn đề, nó chỉ giúp sớm phát hiện các vấn đề. Đừng đưa cho nhóm phát triển khối lượng công việc quá sức của họ và bắt họ làm theo. Hãy để nhóm tự ước lượng khối lượng công việc của mình, thực hiện nó đều đặn và tăng dần năng suất. Việc PO (hay bất kì ai) can thiệp vào khối lượng công việc của nhóm sẽ làm mất tính tự tổ chức của nhóm. Và vì vậy mô hình quản lý truyền thống lại được nhắc tên. Bạn không muốn điều này đúng không? Lời khuyên thứ 4: Mặc dù vài sprint đầu, nhóm có thể có tiến độ không tốt hoặc bộc lộ nhiều vấn đề, hãy để Scrum Master xử lý các vấn đề, và nhóm tự điều chỉnh năng suất lao động. Tôn trọng nhóm và nhóm sẽ trả lại bạn giá trị tương xứng.

– Học cách xem burndown chart, burnup chart, xem bảng kanban vật lý (nếu có) của nhóm: Quan sát các biểu đồ để trích xuất thông tin, từ đó nắm được tình trạng của nhóm

Nếu bạn mới tiếp cận với Agile và Scrum, từ vai trò truyền thống Project Manager bạn phải đóng vai trò mới là Product Owner, mình thực sự khuyên các bạn nên chú ý mội vài chỉ dẫn trên. Tất nhiên, nó là không đủ trong môi trường phát triển phần mềm phức tạp, nhưng ít nhất, bạn cũng có những khái quát để tiếp cận vấn đề. Chúc bạn thành công.

July 10, 2020by thaotrinh
Agile (APM), Chuyện nghề

Làm sản phẩm có nên áp dụng Scrum không?

thaotrinh.info__lam-san-pham-co-nen-ap-dung-scrum-khong

Câu hỏi:
Làm sản phẩm nó nên áp dụng Scrum không?

Vấn đề gặp phải:

Tình hình là công ty mình đang chuyển đổi sang mô hình scrum cho việc phát triển sản phẩm. Nó khá là khó khăn khi mà các tính năng phải chia nhỏ hết mức để có thể hoàn thành Sprint Goal. Nhưng chính vì chia nhỏ ra như vậy mà End User không được có trải nghiệm tốt nhất khi tính năng không hoàn thiện 100% (vì chia nhỏ cho từng sprint). 2 tuần để làm 1 số tính năng mà còn phải fix production bug cũ + thêm không đánh giá được hết ảnh hưởng nền chuyện không hoàn thành Sprint Goal là chuyện thường xảy ra. Có cách nào khắc phục được không.

2 nữa là bản thân mình thấy nếu không tính năng không hoàn thiện mà đã đưa tới khách hàng thì tỷ lệ khách không lựa chọn sử dụng là cao với trải nghiệm lần đầu mà team không để tý tới điều đó thì mà chỉ nghĩ tới có sản phẩm để sale với KH thôi thì cũng không ổn mà 1 designer không đủ tiếng nói. Vậy có cách nào để có lý do thuyết phục hơn không hay mình suy nghĩ vậy là chưa đúng.

Trả lời:

Dù bạn làm gì, Agile (hay Scrum) sẽ giúp được bạn.

Agile giúp tổ chức hay đội nhóm của bạn linh hoạt và chủ động hơn trong việc tiếp cận và giải quyết vấn đề. Mọi đội nhóm với tinh thần và cách làm việc như trên, bạn sẽ đồng ý với tôi nó sẽ “tốt” hơn phiên bản hiện tại của đội nhóm bạn đang có đúng không?

Vậy tại sao lại không Agile (hay Scrum)?

Trở lại vấn đề của bạn.

  1. Tính năng chia nhỏ và End user không có sản phẩm hoàn thiện để sử dụng sau mỗi sprint.
  2. Sprint Goal thường không đạt được, và thường xuyên xảy ra.
  3. Đưa sản phẩm chưa hoàn thiện tới khách hàng.

Hãy luôn nhớ rằng, releaseable (hay phần tăng trưởng được) không nhất thiết phải release ngay lập tức. Nó có thể đợi tới sprint sau, khi tích hợp đủ mới thực hiện release. Việc release không giới hạn (bắt buộc) khi bạn kết thúc sprint (tất nhiên team bạn có thể làm điều này nếu tính năng đó thực sự hay ho và “đủ” hoàn thiện để release).

Vấn đề thứ 2 là câu hỏi sẽ nhiều nhóm mới tiếp cận Scrum sẽ quan tâm. Sprint Goal không hoàn thành sẽ do nhiều nguyên nhân, dựa trên follow của Scrum, mình xin note một vài ý kiến:

  • Sprint Goal chưa thực tế. Nó quá nhiều US, có lẽ vậy.
  • Nhóm đang chưa thực sự tập trung vào Goal.
  • Có nhiều issue chen ngang trong sprint (PO có một chút điều chỉnh – SM chưa follow được, team chỉ quan tâm tới task mà bỏ quên sprint goal).
  • Plan chưa thực sự hợp lý: dựa trên các sprint trước, việc lập kế hoạch cho sprint sau là quan trọng, nếu team bạn liên tục fail sprint goal, hãy hỏi SM sao lại thế. Nếu bạn là SM hãy tự hỏi bản thân và xem lại các số liệu để nhìn nhận vấn đề.

Vấn đề tiếp theo, hãy follow PO để cùng thảo luận. Dù đề cao việc tổ chức đội nhóm, nhưng Scrum đề xuất 3 vai trò, trong đó PO là “chủ” thực sự của sản phẩm. Chỉ anh ấy mới biết tính năng release phục vụ việc gì. Và tại sao cần release một tính năng chưa thực sự hoàn hảo. Mọi thành viên trong development team nên quan tâm tới sprint goal nhiều hơn việc release khi nào và release cái gì. Tất nhiên bạn có trách nhiệm quan tâm tới đứa con tinh thần của mình, nhưng bằng cách hãy trao đổi nếu thấy điều đó có vấn đề. PO sẽ vui vẻ lắng nghe góp ý của bạn, vì dù sao, bạn cũng là người tạo ra sản phẩm – và biết đâu đấy là một khách hàng khó tính muốn góp ý cho sự phát triển của doanh nghiệp?

June 10, 2020by thaotrinh
Page 1 of 3123»

About me

Đề xuất cho bạn

Định nghĩa công việc theo phương pháp S.M.A.R.T

Định nghĩa công việc theo phương pháp S.M.A.R.T

Revision database

Revision database

Tạo đối tượng trong C# từ url API hoặc Json String

Git hướng dẫn cơ bản cho người mới

Git hướng dẫn cơ bản cho người mới

Không phải làm bao nhiêu mà là tạo ra bao nhiêu

Không phải làm bao nhiêu mà là tạo ra bao nhiêu

Bài mới

  • Định nghĩa công việc theo phương pháp S.M.A.R.T
  • Họp xong việc và họp thêm việc
  • Giá trị của Scrum Master trong case study của Leflair
  • Sự khác biệt giữa làm việc chăm chỉ và làm việc chăm chỉ một cách thông minh.
  • Một tách trà

Mọi người quan tâm

No comments to show.

Chuyên mục

  • Agile (APM)
  • Chuyện nghề
  • Đọc
  • Học nghề
  • Làm thợ
  • Uncategorized

Tags

Agile Dev Kanban Marketing Nhóm Scrum Sách Sản phẩm Think Tôi tự học

Người học thức, tức là người thà biết ít mà thật biết những gì mình biết, còn những gì mình không biết, thì cũng biết rõ là mình không biết. “Không có sự dốt nát nhục nhã bằng tin tưởng rằng mình đã biết trong khi mình chưa biết”. Văn hóa là một vấn đề thuộc phẩm chứ không phải thuộc lượng

© 2015 copyright thaotrinhminh@gmail.com // All rights reserved // Privacy Policy