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

Tôi đã nhiều lần nghe được câu nói “hãy sống một cuộc đời đáng sống”.

Một cuộc đời đáng sống trong các câu chuyện có thể là đi du lịch khắp nơi trên thế giới. Được ăn những món ăn tuyệt vời từ những nền ẩm thực khác nhau. Được du lịch khám phá những vùng đất ít hoặc chưa có người đặt chân tới. Được sống ở một lâu đài trên vách núi gần biển, nơi chỉ cần đi bộ vài phút là được tận hưởng ánh mặt trời địa trung hải. 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

Các cuộc họp chồng chéo, sự cộng tác nhiều bên, có quá nhiều thông tin. Đôi khi một cuộc họp sinh ra chỉ để "họp" về một cuộc họp khác. Chúng ta có quá nhiều cuộc họp.

Vậy làm cách nào để họp bớt việc, chứ đừng họp thêm việc?

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

Một kẻ tầm sư học đạo nghe nói vị guru thông thái nhất toàn cõi Ấn Độ sống trên đỉnh ngọn núi cao nhất của Ấn Độ. Vì vậy anh ta vất vả lặn lội khắp núi non và thành Delhi cho đến khi tới được ngọn núi trứ danh nọ. Ngọn núi dốc đứng quá sức tưởng tượng, anh ta trầy trật leo lên ngã xuống không ít lần. Lên được tới đỉnh núi, anh ta trầy xước thâm tím khắp cả mình mẩy, nhưng rốt cuộc đã gặp được vị guru đang ngồi kiết già trước cửa hang.
– “Ôi, thưa tôn sư thông thái,” kẻ tầm sư học đạo lên tiếng.
– “Con đến để hỏi thầy bí mật của cuộc sống là gì ạ.”
– “À, bí mật của cuộc sống,” vị guru nói.
– “Bí mật của cuộc sống là một tách trà.”
– “Một tách trà? Con cực nhọc đi bao đường đất tới đây để tìm ý nghĩa cuộc sống, thế mà thầy lại bảo con rằng nó là một tách trà thôi ư!”
Vị guru nhún vai.
– “Vậy có thể nó không phải là một tách trà.” Xem thêm