Kanban cho cá nhân

Bài được copy từ: http://tapchilaptrinh.vn/2013/04/22/kanban-cho-moi-nguoi/

(Tạp chí Lập trình) Hằng ngày chúng ta có rất nhiều việc phải lo: từ công việc cá nhân, học tập, tới công việc ở nơi công sở, các dự án lớn lao cho tới những việc mua quà sinh nhật cho cô bạn cấp Một.  Tất cả việc nào cũng muốn làm, việc gì cũng có vẻ gấp. Vậy mà mỗi ngày chỉ có 24 giờ.

Nhiều người ức chế vì không thể hoàn thành được công việc được giao, lúc nào cũng phải làm quá nhiều việc, đang làm việc này lại có yêu cầu việc khác. Stress dồn lên stress, càng khiến hiệu suất công việc giảm đi trông thấy. Làm sao đây?

Jim Benson đã học tập các nguyên lí cốt lõi của Tinh gọn (Lean) để sáng tạo phương pháp được gọi là Personal Kanban (Bảng công việc cá nhân), áp dụng cho mọi người với chỉ hai quy tắc đơn giản: giới hạn khối lượng công việc đang làm (Limit Work-In-Progress) về khả năng của cá nhân (capacity), và trực quan hóa đầu việc. Với Personal Kanban, ai cũng có thể giảm đáng kể stress và gia tăng năng suất lao động mà không phải thuê thêm Ô-sin nhắc việc.

Cách làm một Bảng công việc cá nhân rất đơn giản, chỉ bằng vài miếng giấy dán, hay những phần mềm ghi chú có sẵn trên PC, hoặc những công cụ số hóa chuyên nghiệp mạnh mẽ.

Một: Tạo Personal Kanban với giấy dán

Mời bạn xem hai cái Personal Kanban của hai người sau đây:

Kanban của một Giám đốc Đào tạo

Personal Kanban của một Lập Trình Viên – Sinh viên

Trông đơn giản nhỉ? Tôi có phải mô tả thêm điều gì để bạn thực hiện ngay không?

Trên một cái bảng (hay chỗ nào dándính giấy được) bạn tạo ra ba cột có tên “Cần làm” (ToDo), “Đang làm” (Doing) và “Xong” (Done).

Khi có việc cần làm (việc tự nghĩ ra, việc được giao…), bạn viết vào tờ giấy dán và đặt vào ToDo trước, phân tích kĩ lưỡng nên làm ngay hay để làm sau. Việc này có bản chất là “lập kế hoạch”, sẽ giúp bạn có được trình tự và cách làm công việc có bài bản hơn. Nhiều người bắt tay vào làm ngay việc được giao mà không suy nghĩ, tính toán. Đó không phải là chiến lược tốt. Nếu bạn có thể xếp độ ưu tiên theo giá trị (cái nào có giá trị thì làm trước), thì ta có thể mất ít công sức hơn mà làm được nhiều giá trị hơn (sử dụng quy tắc Pareto, 80-20).

Khi quyết định làm việc gì, ta sẽ chuyển công việc sang cột Doing. Có thể ghi ngày giờ bắt đầu làm lên giấy.  Giới hạn số lượng thẻ ở cột này (ví dụ 3). Đừng để nhiều, vì nó sẽ khiển bạn phải nhảy từ công việc nọ sang công việc kia (task-switching), là nguồn cơn của thiếu hiệu quả và stress. Con số 3 hay 5 tùy thuộc giới hạn khả năng (capacity) của từng người, chỉ bạn mới biết được. Khi bạn đặt con số 5 và thấy bắt đầu rối tung lên thì chắc là phải giới hạn con số đó xuống thấp hơn. Thực hiện trong một hai tuần rồi đánh giá lại con số đó. Qua một hai tuần ta sẽ có con số hợp lí. Nhưng khi khởi đầu, tôi gợi ý là nên để con số 3.

Khi làm xong việc gì thì đặt nó sang cột Done, có thể ghi ngày giờ kết thúc lên giấy để đánh giá về sau.

Việc đặt một công việc sang cột Done chứ không vứt đi (cuối tuần thì kẹp lại, lưu trữ cho bảng sạch sẽ)  sẽ giúp bạn nhìn thấy được tiến độ công việc, tạo giá trị thúc đẩy bản thân. Đó là một trong những lợi ích của trực quan hóa (visualization).

Về tờ giấy dán, bạn có thể chọn nhiều màu, dùng nó tùy theo chủ ý. Ví dụ: các việc học tập để giấy xanh, các việc giấy tờ để giấy vàng, các việc liên quan đến khách hàng dùng giấy đỏ v.v. Tùy bạn. Nhưng hãy dùng có chủ ý. Việc này sẽ giúp cho bảng trực quan hơn, có sức sống hơn.

Vào mỗi cuối tuần (hay cuối tháng – tùy bạn, tôi thì thích cuối tuần), bạn có thể ngồi lại một chút tự đánh giá lại mình đã làm được bao nhiêu việc, trong đó có bao nhiêu việc ưu tiên, bao nhiêu việc trễ hẹn, bao nhiêu việc đạt kết quả mĩ mãn. Rồi so sánh với tuần trước đó. Qua đó, bạn có thể đánh giá được cách thức làm việc của chính mình. Rồi đưa ra một vài ý tưởng để cải thiện cách làm việc của chính mình. Điều này sẽ giúp bạn liên tục cải tiến. Ngày một tốt hơn.

Hai: biến desktop thành kanban

Bạn có thể vận dụng quy tắc trên để biến desktop thành kanban như hình dưới:

Kanban trên Desktop

Chỉ cần một phần mềm giả lập giấy dán (sticky notes), dọn sạch desktop và làm vài cái cột là xong. Cách làm hoàn toàn tương tự như mô tả ở phần trên.

Ba: Lựa chọn công cụ “chuyên nghiệp”

Nếu bạn hay di chuyển, làm việc nhiều trên máy tính chứ không thích giấy dán thì có thể lựa chọn một công cụ số hóa ưa thích để làm Personal Kanban.  Có rất nhiều công cụ chạy trên nhiều nền tảng khác nhau, từ Android, iOS đến Windows hay Ubuntu. Công cụ loại này có thể kể đến: Trello, KanbanFlow, Pomodoro Daisuki, LeanKit, Kanbanery, JIRA, KanbanTool, PearlTrees, … Với những công cụ hỗ trợ đa nền tảng, (như Trello chảng hạn) bạn có thể tạo lập một bảng công việc lưu trữ “trên mây”, truy xuất ở mọi nơi, mọi lúc. Như hình dưới đây:

Kanban trên mây và di động

Việc tạo lập Personal Kanban trên các dịch vụ này khá dễ dàng. Hãy vào trang web của nhà cung cấp và đăng kí với vài thao tác đơn giản , bạn sẽ có ngay một kanban tiện dụng và đẹp mắt.

Kanban trên Trello web

Ảnh chụp màn hình Galaxy Tab 7 Plus

Personal Kanban là công cụ hết sức đơn giản nhưng hữu hiệu. Rất nhiều người thấy ngạc nhiên vì độ hiệu của công cụ đơn giản này. Bạn hãy thử và sẽ thấy ngay điều đó sau một tuần. Tuy thế Personal kanban chỉ là công cụ, nó không quyết định được hết chất lượng từng công việc hằng ngày của bạn. Điều đó phụ thuộc vào khả năng xử lí từng việc cụ thể đó. Mặc dù Personal Kanban cũng gián tiếp tác động đến chất lượng công việc do giúp bạn tập trung hơn vào số ít việc đang làm. Nhưng  tác dụng trực tiếp nhất của Personal Kanban là  giúp bạn trực quan hóa mọi thứ lên để dễ bề trù liệu và lập kế hoạch, giới hạn công việc để không bị phân tán và mất tập trung. Nếu biết dùng công cụ một cách hữu hiệu, nó sẽ giúp ích rất nhiều; bằng không, nó chỉ làm phiền bạn thêm thôi. Có người bảo công cụ nối dài cánh tay của con người; nhưng có người lại bảo càng nhiều công cụ con người càng dễ bị lệ thuộc. Cũng có ý đúng cả. Tôi tin là bạn có thể dễ dàng làm chủ personal kanban. Chắc chắn thế.

Dương Trọng Tấn.

Scrum - Những vấn đề trong các cuộc hợp

Scrum là khung làm việc chứa những cuộc hợp. Nếu chúng ta làm không đúng vô tình làm cho khung làm việc này nặng nề và lãng phí thời gian. Nhân viên của bạn cũng dần mất lòng tin và qui trình làm việc này.

Như các bạn đã biết. Hầu hết các cuộc hợp điều dưới sự dám sát của scrum master. Người chịu trách nhiệm đào tạo scrum cho các thành viên trong team. Nếu có vấn đề ở đây là do scrum master chưa tốt.

Sau đây là những vấn đề mà team tôi thường mắc lỗi khi triển khai.

1. Cuộc hợp làm mịn product backlog.

• Bỏ qua: Thường bị coi thường và bỏ qua. Đây là cuộc hợp tốn nhiều thời gian và có nhiều tranh cãi phần lớn rất ngại tham gia cuộc hợp này. Cuộc hợp này giúp làm rõ requirement hơn cho product owner.
• Phản bác chứ không phải góp ý: Team thường phản bác requirement thay vì góp ý cho requirement nó tốt hơn. Cần phát huy tin thần góp phần giúp đỡ người ra quyết định.

2. Cuộc hợp sprint planing.

• Nội dung story card không rõ ràng: đây là một nguyên nhân chính làm cho qui trình scrum thất bại. Tên của story card cần được đặc tên một cách rõ ràng để người dùng đọc và tiêu đề là dễ dàng hiểu mà không phải đọc vào nội dung bên trong của story card. Thêm phần vào đó là các thành viện không đi đến mức cuối cùng để làm rõ và đảm bảo những thành viên điều hiểu chung về nó. Nên cố gắn áp dụng một số kỹ thuật như lá bài (poker) khi tiến hành sprint planing.
• Estimate time: Các thành viên không dám đặt thách thức cho mình về thời gian hoàn thành công việc. Thông thường bạn sẽ bị ép phải trả lời những câu hỏi về thời gian hoàn thành. Tôi chưa có ý giải pháp nào tốt hơn ngoài việc khuyên các thành viện của mình tự thách thức mình về thời gian.
• Mọi người không hiểu chung về story card: Thật là khó để biết người nào có hiểu giống mình hong? Kỹ thuật poker có thể cho bạn biết người đó có chùng suy nghỉ với bạn hong. Tuy nhiên nó cũng có giới hạn khá lớn với những người không có cùng kiến thức kỹ thuật.

3. Cuộc hợp Daily Scrum.

• Thời gian của daily scrum: Phần lớn các cuộc hợp daily scrum điều chưa được đảm bảo đúng thời gian kết thúc. Phần lớn chúng ta không tôn trọng được 3 câu hỏi:
  • Hôm qua bạn làm gì?
  • Hôm nay bạn sẽ làm gì?
  • Bạn có gặp khó khăn gì hong?

(Scrum master sẽ giải quyết nó sau cuộc hợp daily scrum).

• Bàn luận theo cảm hứng: Phần lớn chúng ta bị thối quen nói ngay những gì chúng ta đang nghĩ. Chúng ta thường bị đan xen những cuộc bình luận không liên quan đến những thành viên khác trong nhóm. Tốn thời gian không cần thiết.
• Không chuẩn bị mình nói gì trong scrum: Cần ghi vào những tời note những gì mà chúng ta muốn nói để khi nói chuyện chúng ta dễ dàng nói chuyện một cách nhanh chóng.

4. Cuộc hợp Sprint Retrospective.

• Đi trễ: Vì cuộc hợp này phần lớn được tổ chức tại các quán cafe nên phần lớn chúng ta hay không tôn trọng thời gian. Thường đi trễ không tôn trọng các thành viên khác.
• Nêu quá nhiều vấn đề: Chúng ta chỉ nên nêu những vấn đề lớn mà chúng ta ấn tượng không nên nêu quá nhiều rồi sau đó quên hết không improve thì cũng không có tác dụng gì.
• Improve không được quản lý: Chúng ta thường nói sẽ improve nhưng chúng ta lại không quản lý nó. Dẫn đến nói mà không làm. Retrospective không phát qui tác dụng

NHỮNG VẤN ĐỀ KHI ÁP DỤNG SCRUM Ở VIỆT NAM

1 Hãy để water fall trong theo dòng thác.

Khi chuyển từ watter fall sang scrum là một vấn đề lớn vì hầu như những điều chúng ta biết trong watter fall được chúng ta chấp nhận như chuyện hiển nhiên. Scrum thoáng nghe qua có những thứ gần như trái ngược với những gì chúng ta từng biết. Chẳng hạn như:

Water fall	Scrum
Tài liệu thiết kế rõ ràng càng rõ càng tốt	Tài liệu cần thiết đủ để implement
Làm từng khâu (Phân tích, thiết kế, Implement … ) cần theo tuần tự rõ ràng. Mõi giai đoạn được cần có những tài liệu rõ ràng để lưu lại.	Chỉ lấy một chức năng (story card) một nhóm team cần làm. Sau đó cùng nhau chơi tất cả các giai đoạn này (Phân tích, thiết kế...)

Bạn đã thấy ví dụ trên. Nó đã thể hiện sự khác nhau rõ ràng. Những kiến thức về watter fall và quá hoàn hảo thế bây giờ chuyển đổi qua Scrum với quan điểm mới là chuyện hoàn toàn khó làm và khó triển khai.

1.1 Tài liệu phát triển như thế nào.

Để cần biết chúng ta nên viết tài liệu trong scrum được ghi đến mức nào chúng ta nên cần biết chúng ta viết tài liệu để làm gì?

Water Fall	Scrum
Dùng để report cho khách hàng	Dùng để report cho khách hàng
Dùng để đảm bảo các giai đoạn cần khóp để có thể gắn với nhau được	Dùng để note lại gợi nhớ sau này về chức năng.

Như vậy chúng ta đã thấy rằng Tài liệu dùng để trao đổi thông thông tin qua các giai đoạn Design → Implement …

Vì Water Fall, các giai đoạn tách rời nhau nên tài liệu cần rõ ràng để các giai đoạn đảm bảo khóp nhau.

Còn Scrum các giai đoạn cùng làm một lúc, thành viên trong team thường xuyên trao đổi nhau và đi đến hoàn thành task. Vậy tài liệu chỉ cần đủ ghi chú lại để gợi nhớ sau này. Không có giá trị trong giai đoạn làm ra sản phẩm nhiều.

1.2 Quan niệm từng giai đoạn và chờ đợi.

Như bạn biết đấy trong watter fall khâu này xong rồi đến khâu kia. Nếu đến khâu của mình, phát hiện vấn đề phải chuyển về khâu trước để thiết kế lại dẫn đến tốn thời gian và gặp nhiều phiền phức.

Scrum được cái là mọi người ngồi gần nhau có gì hỏi nhau liền. 2 yếu tố quan trọng cùng làm trong scrum là: Cùng làm chung một task và trao đổi nhau liên tục. Nhưng thực tế có bao nhiêu công ty làm được điều này? Vấn đề ở đâu?

Vấn đề là:

• Trong qui trình làm phần mềm phần lớn được chuyên môn hóa rất nhiều ví dụ: Graphic, Developer... Để một người có thể làm được tất cả là vấn đề lớn và độ chuyên sâu không có. Nên các công ty thường làm theo dạng cuốn chiếu (cho một sprint làm Graphic và một sprint Implement chức năng này – Cách này vô tình đã chuyển chúng ta qua watter fall – Chúng ta đã nghĩ nó nhanh nhưng thưc tế nó không nhanh như chúng ta tưởng).
• Có vài khâu bị chậm trể so với khâu khác vì task này cần nhiều hơn task kia. Ví dụ tôi đang làm game. Vẽ art và graphic cực kỳ lâu. Hơn so với implement. Vậy nếu làm chung thì developer phải ngồi chơi chờ art ah? Oh không.Chúng ta cần tăng resource art để tương xứng để đảm bảo đi chung luồng với developer.

2 Không tìm cách cải tiến estimate.

Tất cả các dự án nếu bạn làm đúng kết hoạch bạn đã thành công lớn rồi. Nhưng với Scrum lúc đầu nó không cần bạn phải đúng. Chính vì thế vô tình chúng ta thiết lập cho bản thân chúng ta một cơ hội không cần đảm bảo về thời gian như chúng ta nói.

Đây phần nhiều là vấn đề tâm lý. Tôi ví dụ: Trong water fall thời gian của bạn được PM set rồi hỏi bạn và ép bạn làm đúng hạn. Nhưng trong Scrum là bạn quyết định thời gian và chịu trách nhiệm với Product Owner.

- Khi bạn được hỏi “Em vẽ màn hình này chừng nào em xong?”. Bạn rất là đắng đo vài áp lực trách nhiệm được đổ dồn lên bạn đúng hong?

- Thông thường bạn trả lời “Em chưa biết nữa để em trong đó có gì rồi nói anh sau”. Để estimate Scrum Master nói “Em cứ cho anh thời gian đại đi, không cần phải chính xác 100% đâu”.

- Thế là bạn cho anh trả một estimate mà bạn không hề có trách nhiệm gì với nó cả

Đó là phần lớn những nguyên nhân dẫn đến estimate sai. Làm như thế bạn đã vô tình làm cho bạn nhiều lý do để fail hơn (Ngoại trừ task không rõ ràng hoặc gặp khó khăn về kỹ thuật).

3 Chưa xác định kết quả công việc

Khi bạn nhận một task bạn nên biết được bạn phải trả về cái gì cho người ta. Bạn với PO phải thỏa thuận và làm rõ kết quả đó. (Thông thường bạn phải chủ động cho PO thấy kết quả mà họ muốn vì phần lớn là các PO không được không minh và họ thường nói những thứ mà họ không biết họ muốn nói gì).
Bạn cần tìm đủ mọi cách để lấy requirement rõ ràng để bạn không bại reject sau này.

4 Không đủ kiến thức về Scrum

4.1 Chưa rõ tác dụng của các cuộc hợp

Scrum là một khung làm việc chứa các cuộc hợp. Nếu thành viên trong nhóm của bạn không hiểu rõ về những cuộc hợp này thì nó là vô ích. Những lý do là:

• Scrum master chưa truyền được tầm quan trọng các cuộc hợp. Nếu có thì tổ chức các cuộc hợp chưa được hiệu quả như lý thuyết → thành viên trong nhóm ngày càng nãn.
  
• Tư tưởng của team về Water fall vẫn còn ăn quá sâu.
  

4.2 Kỹ năng giao tiếp chưa tốt

Communication là một kỹ năng quan trọng trong Scrum. Nhưng phần lớn chúng ta không được tốt về skill này dẫn đến nó không được tốt. (vì thế chúng ta thích water fall hơn).

4.3 Giới hạn về kỹ thuật

Như chúng ta có những giới hạn về kỹ thuật mỗi người chỉ cần biết một lĩnh vực của mình thôi → Chúng ta phải làm cuốn chiếu như đã đề cập ở trên.

Waterfall vs Agile

5 mức độ của qui trình CMMI

Scrum in Game

Copy from http://vietgamedev.net/blog/50/scrum-framework/

1. Mở đầu:

Mình được nghe khá là nhiều người nhắc đến Scrum và khả năng tuyệt vời đối với việc quản lý cho những dự án phức tạp, hoặc là có độ thay đổi cao.

Thoạt nghe cũng rất lôi cuốn, nhưng vấn đề cần lưu ý, có rất nhiều doanh nghiệp cố gắng áp dụng mô hình này, nhưng lại không hoàn toàn kiểm soát hay hiểu được những yếu tố cơ bản để theo đúng định nghĩa của Scrum, nên có rất nhiều người tự hỏi, tại sao tôi không áp dụng được mô hình này vào công ty tôi . Và theo như mình được biết: có rất nhiều doanh nghiệp cố gắng áp dụng mô hình này, nhưng có rất ít đơn vị ; thành công, mà phần lớn theo mình là không tuân theo những quy định của Scrum.

Qua bài viết này, mình hi vọng sẽ chuyển đến các bạn một số hiểu biết của mình về Scrum và thảo luận thêm để mở rộng ý tưởng.

Mô hình Scrum tổng quát (theo tuyendungit.wordpress.com)

Làm chủ Agile

Hợp Daily Stand Up thế nào là đúng và phát huy hiệu quả?

Bài được copy từ http://tapchilaptrinh.vn/2014/02/24/hop-stand-up-hay-lam-cho-dung/

Triển khai stand-up meeting (Cuộc họp Đứng hay còn được biết đến với tên gọi là Họp Scrum Hằng ngày) cần sự đơn giản, vậy tại sao khá nhiều nhóm thực hiện sai hoạt động này?

Tôi tin rằng Họp Scrum Hằng ngày là một phương pháp tốt – và cần được thực hiện bởi tất cả các nhóm phát triển – bất kể họ có hay không sử dụng Scrum hay bất cứ một phương pháp luận Agile nào đó. Và Vì vậy tôi đưa ra suy nghĩa của mình về cách thực hiện stand up meeting để các bạn cùng xem xét:

Nguồn: http://www.flickr.com/photos/tahitipix/4257979529/

Scrum hắn là ai?

Cái tay ScrumMaster ấy làm việc gì?

ScrumMaster không quản lí nhân sự, không quản lí tiến độ, cũng chẳng quản lí công việc được gán cho ai, càng không quản lí tiền bạc, hay yêu cầu. Vậy thế cái tay này làm cái gì?

Trong những lớp học tôi dạy về Scrum, phần nhiều học viên cứ nghĩ là ScrumMaster chẳng có việc gì để làm. Nên trong các ý kiến thảo luận, họ thường để một ai đó – như Product Owner, hay Developer, Tester .. – kiêm nhiệm. Cực chẳng đã mới để một người làm ScrumMaster độc lập, vì sợ tốn rì-suộc (resource). Hi hi.

Kì thực thì có vài ScrumMaster mới nhận cái công việc này sẽ thấy ngập lụt, “ôi sao nhiều việc thế”, “thế này thì làm sao nổi”. Hihi.

Vậy thì hằng ngày cái vị ScrumMaster này làm những gì? Xin liệt kê ra đây vài cái thử xem có nhiều không nhé: