Khi bạn quản lý một nhóm người, không phải lúc nào bạn cũng có thể đảm bảo rằng họ sẽ hòa hợp với nhau. Sở thích, nhu cầu và các chương trình làm việc cạnh tranh được đưa ra, bạn thậm chí có thể có 2 người phản đối nhau kịch liệt. Vai trò của bạn là quản lý trong tình huống như thế này là gì? Bạn nên tham gia hay để họ tự giải quyết vấn đề của họ?

Lý tưởng nhất là bạn có thể huấn luyện đồng nghiệp trò chuyện với nhau và giải quyết xung đột của họ mà không cần bạn tham gia, đồng thời làm rõ rằng sự bất đồng của họ có hại cho họ và tổ chức. Nhưng điều đó không phải lúc nào cũng khả thi. Trong những tình huống này, chúng tôi tin rằng điều quan trọng là phải can thiệp, không phải với tư cách là quản lý mà là người hòa giải. Để chắc chắn, bạn sẽ không phải là một người hòa giải độc lập, trung lập vì bạn có một số lợi ích trong kết quả, nhưng bạn có khả năng hiệu quả hơn trong cuộc họp có liên quan tới lợi ích mọi người – của bạn, của họ và của tổ chức – nếu bạn sử dụng các kỹ năng hòa giải của mình hơn là quyền hạn của bạn. Xem thêm

Trong các nhóm truyền thống, các xung đột có thể được cấp trên đứng ra giải quyết. Ví dụ khi bạn không thể thống nhất về cách sắp xếp thứ tự ưu tiên cho các dự án, hay các deadline cần thay đổi. Lúc này tean có thể đưa lên và trưởng nhóm sẽ ra quyết định. Một ví dụ khác có bao giờ bạn nghĩ rằng đồng nghiệp đang cư xử cộc cằn hay công việc của họ quá cẩu thả? Lúc này nhóm sẽ cung cấp thông tin cho quản lý và chờ người đó đứng ra giải quyết. Nhưng với một nhóm lớn hoặc nhóm tự tổ chức, đây không phải là một lựa chọn. Nhóm tự tổ chức phải xác định các cách khác nhau để tìm kiếm và giải quyết các xung đột hàng ngày. Xem thêm

Michael Jordan liệu có trở thành huyền thoại bóng rổ nếu không có tư duy phát triển? Cùng xem lại cách người đàn ông này nói về thành công: " Tôi đã ném hụt hơn 9000 cú ném trong sự nghiệp của mình. Tôi đã thua 500 trận đấu. 26 lần tôi đã được tin tưởng giao cho cú ném quyết định chiến thắng và đã ném hụt...Tôi thất bai hết lần này tới lần khác trong cuộc đời tôi!

VÀ ĐÓ LÀ LÝ DO TÔI ĐÃ THÀNH CÔNG.

Quản lý rủi ro trong dự án Agile (Scrum) là câu hỏi nhiều người gặp phải trong quá trình tìm hiểu về Agile và Scrum. Ở bài viết này mình sẽ chia sẻ về nội dung này để mọi người có thêm góc nhìn.

1. Đặc điểm quản lý rủi ro trong dự án Agile/Scrum.
2. Thực hành quản lý rủi ro trong Agile.
3. Có thể sử dụng 2 phương pháp quản lý rủi ro cùng nhau không.
4. Tổng kết.

Phần 1: Đặc điểm của quản lý rủi ro trong dự án áp dụng Agile và Scrum

Đầu tiên, xin quay lại với tuyên ngôn Agile:

Cá nhân và tương tác hơn là quy trình và công cụ.
Phần mềm chạy tốt hơn là tài liệu đầy đủ.
Cộng tác với khách hàng hơn là đàm phán hợp đồng.
Phản hồi với thay đổi hơn là tuân theo kế hoạch.
Mặc dù những điều ở bên phải vẫn còn giá trị, nhưng chúng tôi đề cao những điều ở bên trái. Xem thêm

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

Hồi mới tập tễnh đi dạy, mình có một số anh chị đồng nghiệp thỉnh thoảng lại chê sinh viên dốt khiến cho kết quả học tập của lớp kém. Và bởi vì sinh viên dốt, cho nên Giảng viên có làm gì thì cũng không thể khá lên được, thành ra cuối cùng Giảng viên không làm gì cả.

Mình cũng hay tiếp xúc với sinh viên, của nhiều trường khác nhau, cũng nghe nhiều bạn chê học trong trường chán, chê thầy dạy khó hiểu. Và bởi vì nhà trường kém cho nên không học được, chứ đâu phải lỗi của mỗi sinh viên, thành ra học không tốt cũng là chuyện hợp lí. Xem thêm

Bìa sách có gạch nối từ A tới Y có lẽ cũng là cách chơi chữ của tác giả cùng với tên sách – Agile từ A tới Y (chưa tới Z). Nội dung sách gồm 3 phần rõ ràng: Agile, tổ chức, cá nhân. Các nội dung trong sách thì mình cũng đọc, góp nhặt từ nhiều nơi, tuy vậy cũng học hỏi được rất nhiều thứ từ cách nhìn nhận của tác giả và … 1 số thứ chưa biết 😀

Về Agile – phần 1, tác giả có 2 chương đầu nói về thực trạng của việc phát triển phần mềm và đưa ra câu hỏi tu từ: “Liệu Agile có phải là giải pháp?”. Phần này mĩnh sẽ note lại trong 1 bài viết khác bới nó khá dài và có nhiều câu chuyện để cùng bàn luận mổ xẻ. Lướt tiếp phần 1 điều mình thích là ở chương 5 phần kĩ thuật và công cụ, phần này có đề cập tới database versioning và branch strategy làm mình khá tâm đắc. Thực sự với mỗi team làm phần mềm, đây là 2 thứ cực kì quan trọng và đáng giá để nghiên cứu và đưa nó vào quy trình, nhất là khi team bạn làm Agile (Scrum). Tư tưởng ở đây cho việc database versioning là coi database như một version của code, commit kèm theo source. Luôn có script update database và restore database đi cùng nhau cho 1 version, điều này khiến CSDL của bạn được đảm bảo, có truy vết và luôn ở trạng thái có thể backup được lại phiên bản ổn định. Branch strategy với tư tưởng forward-intergration (tích hợp trước) giúp việc đảm bảo luôn có sự ổn định ở branch develop là 1 ý tưởng hay có thể áp dụng ngay lập tức cho nhóm của bạn. Xem thêm

Nếu phải chọn một hành động quan trọng nhất trước khi bắt tay làm bất cứ một công việc nào, bạn sẽ chọn hành động gì? Tôi đã hỏi rất nhiều người và câu trả lời tôi thường nhận được là lập kế hoạch. Thật đáng tiếc, đó không phải là câu trả lời tốt. Lập kế hoạch chỉ nên là hành động đứng thứ hai bởi nó phải nhường chỗ cho hành động định nghĩa công việc. An bắt đầu việc học tiếng Anh bằng cách lên một lịch trình chi tiết về việc đăng ký một khoá học, dành mỗi thời gian cuối tuần để luyện tập thêm; sau 6 tháng thực hiện kế hoạch hoàn hảo, An có thể đọc và viết các tài liệu bằng tiếng Anh, song An vẫn thấy thất vọng vì khả năng giao tiếp của mình. Một kế hoạch hoàn hảo cùng những nỗ lực tuyệt vời đã được An thực hiện nhưng không mang lại hiệu quả như An mong đợi; chỉ vì An đã bỏ đi hành động đầu tiên, và cũng là hành động quan trọng nhất, định nghĩa hoàn thành cho việc học tiếng Anh. Xem thêm

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

1. Khi nào thì branch off
2. Khi nào thì merge 1 branch vào 1 branch khác?

Gitflow

– master: branch chính, luôn ở trạng thái deploy-ready (có thể deploy), tức là đạt sự ổn định cao. Branch master chỉ được merge vào từ branch develop.
– develop: branch phục vụ việc phát triển. Chừng nào một commit còn tồn tại trên branch develop mà không được merge vào branch master, chức năng đó đang trong quá trình phát triển và chưa đạt sự ổn định để deploy. Xem thêm