Chúng ta quá quen với việc làm việc theo quy trình, chúng ta được hướng dẫn phải thứ tự thực hiện các bước để thu được kết quả tốt nhất. Những hướng dẫn này được kiểm chứng, được phân tích và thử nghiệm nhiều lần trước khi được ban hành. Thế rồi một ngày, bỗng sự cố xảy ra, các hướng dẫn thì chưa để cập tới cách xử lý sự cố này ra làm sao cả. Vậy là cả nhóm loay hoay ngồi tranh luận với nhau làm thế nào. Đôi khi từ tranh luận biến thành cãi vã lúc nào không hay, rồi thì vấn đề lúc đầu biến thành cái gì không biết nữa. Đang giải quyết khủng hoảng truyền thông khi uy tín doanh nghiệp bị tổn hại, cuối cùng sau một hồi tranh luận, lại thấy nguyên nhân đâu đó xuất phát từ chị lao công! Xem thêm

Thật kỳ lạ trong thế giới công việc ngày nay, nhiều người còn nhầm lẫn khái niệm “hiện tượng” và vấn đề.

Hiện tượng không phải là vấn đề.

Hiện tượng là thứ đã xảy ra, là quá khứ, chúng ta không thể thay đổi được nó.

Vấn đề, là cách chúng ta giải quyết hiện tượng, để đạt được mục đích của mình.

Nó đơn giản đúng không?

Việc nhầm lẫn hiện tượng là vấn đề khiến ta mải mê tìm cách giải quyết một “vấn đề” – không-phải-là-vấn-đề. Điều này không chỉ khiến chúng ta mất thời gian và công sức, lâu dần còn khiến chúng ta nghi ngờ cả về khả năng của mình, của đội nhóm mình. Và tất nhiên, khi loay hoay đi tìm lời giải cho một thứ không phải vấn đề, những thứ cản trở công việc của ta vẫn quay trở lại mãi. Vòng lặp này sẽ đến vô tận cho tới khi nào ta gỡ bỏ được vấn đề thực sự. Xem thêm

Bạn có bao giờ bắt tay vào giải quyết ngay khi vấn đề xảy ra nhưng rồi vấn đề dường như vẫn cứ lằng nhằng, không dứt điểm được? Nếu chuyện này xảy ra cho bạn, có lẽ vấn đề mà bạn đang giải quyết không phải là vấn đề, hoặc vấn đề chưa được giải quyết tận gốc rễ. Thường thì khi vấn đề xảy ra, phản ứng ngay lập tức của con người là suy đoán ngay nguyên nhân, rồi tập trung ngay vào giải pháp. Có khi, giải quyết nhanh cũng giống như lấy băng keo bịt vào ống nước, trước sau gì cũng bị lực nước đẩy bung ra. Xem thêm

Thế giới của những người làm phần mềm tồn tại một quy trình sản xuất từ lâu đời. Ở đó, quy trình gồm các bước xác định vấn đề, lập kế hoạch, thực thi, kiểm tra, và cuối cùng đưa ra sản phẩm cho người dùng sử dụng. Đó là quá trình liên tục, có hệ thống, có trật tự từng bước. Người dùng chỉ nhận được giá trị ở cuối của chu trình sản xuất.

Song song với đó, một cách làm khác, được dân phần mềm gọi là Agile (tức là linh hoạt) giúp phát triển phần mềm theo các vòng lặp, các bước ở quy trình sản xuất phần mềm cũ được lặp đi lặp lại trong một khoảng thời gian ngắn, cố định. Điều này giúp liên tục đưa ra các giá trị (nhỏ, có thể sử dụng ngay) cho khách hàng. Sự khác biệt trong cách tiếp cận này là giá trị được tạo ra liên tục và trong thời gian ngắn, đón nhận các phản hồi. Điều này giúp tất cả các bên tham gia vào quá trình dự án thích nghi với các thay đổi, đồng ý với nhau về các hiệu chỉnh nhanh và dễ dàng hơn, đón nhận thông tin sớm và kịp thời hơn để ra quyết định. Xem thêm

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

Mình thấy rất nhiều bạn, đi làm, ngập trong 1 núi công việc. Hết list việc này tới list việc kia, checklist để hoàn thành một việc cũng dài ngoằng. Để làm gì ta?

Cuối cùng, bạn có vì làm được số lượng lớn đầu việc mà trở nên thành công hơn và hạnh phúc hơn? Có nhà quản lý nào quan tâm tới số lượng công việc mà bạn làm được, 100 task/tháng hay hơn thế? Xem thêm

“Văn hoá làm việc Agile đáp ứng sự thay đổi nhanh trong dự án và team làm việc rất cởi mở, đó là môi trường làm việc thúc đẩy tốt teamwork, đó là một bức tranh đẹp mà các nhà quản lý luôn muốn doanh nghiệp/đội nhóm của mình đạt được”.

Điều đó dẫn tới mong muốn triển khai agile trong các tổ chức, nhưng phía sau đó, thách thức của chúng ta sẽ là gì?

Văn hóa

Văn hóa phân cấp trong công việc: Chúng ta làm việc trong môi trường công sở, nơi mỗi người có những kỹ năng chuyên biệt để thực hiện những nhiệm vụ khác nhau. Thông qua đó, để điều phối công việc trở nên đúng trật tự, chúng ta cần những vai trò khác nhau để vận hành tổ chức. Văn hóa sếp-nhân viên có thể là rào cản đầu tiên gây cản trở văn hóa agile trong tổ chức. Xem thêm

Trong tất cả các sự kiện của Scrum, đây có lẽ là sự kiện hay bị “bỏ-qua” nhất của các team, trong khi đó, Srpint Retrospective lại lại một sự kiện rất quan trọng.

Cuộc họp Sprint retrospective được tổ chức ngay sau sự kiện sprint review, nhưng trước khi bắt đầu sự kiện sprint planning cho một sprint mới. Khi kết thúc cuộc họp sprint retrospective, đội phát triển nên chỉ ra những cải tiến mà sẽ được thực hiện ở sprint tiếp theo. Xem thêm

Definition of Done (DoD) là một danh sách các yêu cầu mà các user story phải tuân theo để nhóm được xác nhận là hoàn thành một công việc. Trong khi đó Acceptance Criteria (tiêu chí chấp nhận) của một User Story bao gồm một danh sách các kịch bản kiểm thử cần được đáp ứng để xác nhận rằng “phần mềm” hoạt động giống như “kỳ vọng – hay yêu cầu” của khách hàng.

Sự khác biệt giữa DoD và AC ở chỗ: DoD là những yêu cầu chung nhất cho tất cả các User Story, trong khi đó AC sẽ được áp dụng cho những User Story cụ thể. Acceptance Criteria của mỗi User Story sẽ khác nhau, dựa trên yêu cầu của mỗi User Story. Xem thêm

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. Xem thêm

Chúng tôi biết Scrum Master là người đóng vai trò quan trọng trong các nhóm Scrum mới, nhưng chính xác thì anh ấy hoặc cô ấy đã bận rộn những gì trong suốt ngày làm việc của mình?

Đối với những người mới bắt đầu, chúng tôi biết Scrum Master không lập kế hoạch phát hành, vì điều đó được thực hiện bởi chủ sở hữu sản phẩm và nhóm. Chúng tôi biết anh ấy không quản lý các nhà phát triển vì nhóm Scrum tự tổ chức; và chúng tôi biết anh ấy thậm chí không phải là người phải chịu trách nhiệm nếu kết quả cuối cùng tệ hại (đó cũng là trách nhiệm của chủ sở hữu sản phẩm).