Master table (マスタテーブル)
– Ít thay đổi
– Lưu dữ liệu "master" (マスタデータ)
– Ví dụ: dữ liệu kho, người dùng
– Dùng để lưu dữ liệu của hệ thống
– Không index
Transaction table (data)
– Thay đổi thường xuyên hơn
– Lưu giữ liệu transaction của hệ thống như giao dịch, sales
– Cần index
– (được tổ hợp từ các (bảng) dữ liệu (master) khác
Câu hỏi: Tôi muốn so sánh member của một Scrum team này với member của một Scrum team khác để biết ông nào hơn không nào, qua đó quyết định tới mức lương của hai ông.
Bối cảnh: Một công ty nhà nước thực hành với việc lập một vài nhóm chạy theo hướng Agile/Scrum.
Ý kiến của mình:
– Đánh giá cả team, thay vì cá nhân.
– Sau đó chia thưởng cho cả team đó
So sánh member của một team này với team khác: Không làm (làm được không?)
Xem hai điểm sau:
1. Promotions and demotions
Instead of subjectively selecting somebody for a promotion, consider creating a company job marketplace where interested candidates apply for open jobs.
Clarify and publicize the skills, abilities and knowledge required for a certain job title.
Allow the teams to exclude team members that don’t fit in.
2. Salaries and bonuses
Adjust salaries based on current market averages and yearly inflation.
Allocate bonuses to the team, let them decide the shares.
Include a feedback loop from the product’s success, using e.g. profit sharing.
Give bonuses as an exception, not as the norm. Don’t use large amounts.
Tham khảo: https://mozaicworks.com/blog/do-agile-teams-have-performance-reviews/
Minh bạch (transparency) là gì?
Ví dụ về sự không minh bạch
Ví dụ 1
Giám đốc và PM đặt 2 deadlines khác cho dự án. Một deadline công bố với team, một deadline còn lại, sau khi đã buffer được thông báo với khách hàng. Team members không biết tới deadline ẩn thứ hai này.
Ví dụ 2
Khách hàng, product owner nói "được" hay "không được với output của nhóm phát triển. Tuy nhiên, định nghĩa thế nào là được hay không được không được khách hàng/product owner phát biểu rõ ràng, không được viết/nói rõ trong các tài liệu dự án, chuẩn dự án, quy định dự án.
Ví dụ 3
Việc không có ground rule tốt, được sự đồng ý/đồng thuận của cả nhóm phát triển với khách hàng, product owner cũng thể hiện sự không minh bạch. Khi "rule" không rõ ràng, ai muốn làm gì cũng được, cho dù lợi cho cá nhân anh ta nhưng không lợi cho tổng thể. Lúc này, bản thân các cá nhân không hoàn toàn có lỗi.
Ví dụ 4
Chuẩn về chất lượng, giao diện giữa nhóm phát triển và khách hàng khác nhau, luôn cần điều chỉnh, thoả thuận khi demo, giao nộp sản phẩm.
Làm thế nào là/cho minh bạch?
1. Đừng giấu thông tin gì
2. Hạn chế trao đổi riêng
3. Luôn đi đến sự đồng thuận, thống nhất giữa số lớn thành viên liên quan
4. Nói cho đơn giản, dễ hiểu
5. Viết ra, tài liệu hoá
6. Khi conflict, cãi nhau: Xem lại hoặc update rules chung
Cụ thể hơn, mẹo và thực hành thế nào?
1. Chia sẻ thông tin
Chia sẻ thẳng thắn, cởi mở những thông tin liên quan đến dự án.
Mọi người trong dự án đều có nguồn thông tin ngang nhau, giống nhau để đảm bảo không hiểu khác nhau (có thể hiểu sai giống nhau)
2. Chủ nghĩa genba
"genba" nghĩa là "nơi làm việc". Chủ nghĩa genba được hiểu đơn giản là việc lấy nơi/người làm việc làm trung tâm tối ưu, tạo điều kiện tốt nhất cho người làm viêc tốt nhất. Việc minh bạch hoá là điều kiện tiên quyết để người thật việc thật ở genba cả thấy yên tâm, thoải mái làm việc hiệu quả.
3. Không có under table
Không giấu diếm gì. Những điều nhạy cảm và tế nhị như lương/thưởng, chế độ, conflict giữa các cá nhân nghiêm trọng, đánh giá nhân sự, tính xấu, hối lộ… có thể không được bàn công khai.
Những thông tin "cứng" về dự án như issue, tiến độ, yêu cầu công việc, thiết kế, điều kiện hoàn thành, điều khoản hoàn thành trong hợp đồng cần được chia sẻ rõ.
4. Không "đi đêm"
Việc có thoả thuận ngầm giữa một vài hay nhiều đối tượng liên quan không được chấp nhận.
Ví dụ,
a. Tester và developer thoả thuận ngầm không đưa ra lỗi của nhau
b. Các developers hardcode và không share việc đó cho members khác
5. Công khai báo cáo/chia sẻ
Báo cáo về dự án: Share bằng wiki, Google Drive để tất cả những người liên quan có thể nhìn thấy, và nhìn thấy thông tin giống nhau.
Việc nhìn thấy thông tin giống nhau quan trọng hơn việc (mọi người) đều thấy thông tin sai.
Tránh những chia sẻ/report bao gồm nội dung đánh giá con người, nhận xét xấu tới ai đó.
Công việc tồi: OK, nên report
Con người tồi: Không nên viết trong report
Việc tốt, người tốt: Nên khen công khai
6. Mọi người liên quan đều chia sẻ, báo cáo
Xem phần 5.
Những người liên quan có thể không phát ngôn, nhưng họ cần được truy cập vào thông tin báo cáo.
7. Hou-ren-sou
Những nội dung nói trong bài viết này là một phần của nguyên tắc cơ bản với người Nhật: hou-ren-sou (báo cáo, liên lạc, thảo luận)
Việc thực hiện hou-ren-sou tốt đảm bảo tính minh bạch được tăng cường.
8. Cộng tác với team, trên tinh thần hợp tác
Tâm lý nói dối vì sợ, giấu thông tin, chia sẻ một phần sự thật là phổ biến.
Để tránh điều này, hợp tác trên tinh thần giúp đỡ.
Sếp, người liên quan, người có quyền ảnh hưởng thay vì ra lệnh, hỏi vặn, trì triết… nên hợp tác, hỏi thông tin thật và tìm cách hợp tác cùng giải quyết.
Bằng cách này, nhóm phát triển (người thật, việc thật) cảm thấy yên tâm, nói thật hơn.
9. Nói thẳng, nói thật
Sự thật mất lòng. Nhưng vẫn cần tránh động tới cá nhân.
Giải quyết vấn đề trước. Nếu không được thì giải quyết con người.
Tập trung vào issue chứ không tập trung vào con người gây ra issue đó.
10. Công khai rủi ro, issues
Tài liệu hoá risk, issue register, để nó ở nơi mọi người nhìn thấy (báo cáo, wiki…)
Tham khảo: https://www.scrumalliance.org/community/articles/2013/june/transparency-in-agile-product-development
Thán thưởng:
– từ cũ
– từ này không có trong Vietlex 2013
Status/Lifecycle of a bug/issue/task như sau:
*New*
Task mới được tạo, chưa assign cho ai
*In Progress (Assigned)*
Task đã assign, đang làm
*Resolved*
Task đã được làm xong bởi người được assigned, tự review xong. Chờ review chéo hoặc review từ cấp trên hay confirm từ khách hàng.
*Feedback*
Vì một lý do nào đó, task bị "trả lại" cho người tạo ra nó.
Ví dụ: Tester X tìm ra lỗi #6868 assign cho developer Y. Y kiểm tra lại và
thấy đó không phải là lỗi do mình gây ra. Khi đó Y sẽ "feedback" lại task
#6868 cho X để X assign cho người thích hợp.
*Incomplete*
Task thiếu thông tin, cần được làm rõ.
Ví dụ: Tester X tìm ra lỗi #6767 assign cho developer Y. Y không thể tái
hiện được lỗi đó. Khi đó Y sẽ mask task #6767 là "Incomplete" và assign cho X để X phân tích thêm.
*Closed*
Done. đóng task.
*Rejected*
Task sai. đóng lại.
*Pending*
Treo task, tạm thời chưa làm.
Có thể đẩy lùi task sang sprint sau nhưng không đóng task.
*Reopen*
Mở lại 1 task/issue đã đóng.
Ví dụ: Developer Y fixed xong lỗi #7070 và Tester X đã closed lỗi đó. Tuy nhiên sau đó Tester X phát hiện lỗi này chưa được fix hẳn. Khi đó Tester X reopen lại lỗi #7070.
*Verified*
Issue/lỗi đã được verified bởi tester X sau khi tiếp nhận báo cáo lỗi từ
phía khách hàng.
*Invalid*
Issue/lỗi sai. Failed alert. Close.
*Wontfix*
Không phải làm. Lý do "wontfix" có thể là: báo cáo sai, chưa cần thiết
phải làm/fix trong sprint hiện tại, tuy là lỗi nhưng có workaround nên chấp
nhận được, hoặc độ ưu tiên/cần thiết của task là thấp
*Duplicated*
Task bị trùng lặp với một task khác. Close.
*Closed*
Done, đóng task.
Chú ý:
Đây là những status cơ bản của một issue/ticket/bug.
Có thể đơn giản hoá vòng đời của task với các bộ status như sau:
1. New, In Progress, Resolved, Closed (Backlog.jp default status)
2. TODO, DOING, DONE (Basic Kanban)
3. TODO, DOING, VERIFYING, DONE (thêm Verifying: Kiểm tra)
Tham khảo:
1. A life cycle of a bug:
http://www.bugzilla.org/docs/3.0/html/lifecycle.html
2. Design a workflow with Redmine:
<a href="http://www.redmine.org/projects/redmine/wiki/RedmineIssueTrackingSetup" rel="nofollow">www.redmine.org/projects/redmine/wiki/RedmineIssueTrackin...</a>
Tuckman’s stages of group development
Các giai đoạn phát triển team:
1. Forming: Thành lập (mới, hay thay đổi)
2. Storming: Trao đổi, tranh luận
3. Norming: Ổn định
4. Performing: Làm ra kết quả
Tình huống:
1. Team mới thành lập
2. Team có thành viên mới join
How to write daily report
(dành cho IT staffs, developers)
Chú ý chung
Viết report hàng ngày, vào buổi chiều tối trước đi khi về
Viết thật ngắn
Nếu đề cập tới issue: ghi issue ID (Jira, backlog.jp…)
Nội dung daily report:
Ngày hôm nay đã làm gì?
Ngày mai sẽ làm gì
Có vấn đề gì, khó khăn gì cản trở công việc không?
Các chú ý khác
– Tập hợp report ở một nơi
– Dễ tìm
– Dễ đọc theo từng người
– Dễ đọc cho cả nhóm
– Vừa nhìn được tổng thể
– Dễ so sánh (tiến độ, issue) của lần viết trước và sau
Ai đọc report?
– Thành viên dự án
– Những người liên quan đến dự án
– Sếp, sếp của sếp
– Khách hàng
Viết report cho ai?
– Cho mình
– Cho tất cả những người liên quan
Tham khảo
Cách thực hiện Daily Scrum: https://www.mountaingoatsoftware.com/agile/scrum/daily-scrum
Management by objectives (MBO): Quản lý theo mục tiêu
– Tập trung vào mục tiêu
– Dựa trên lượng tài nguyên có sẵn
– Để nhân viên hiểu rõ mục tiêu mà tổ chức, cá nhân họ cần đạt được
– Đánh giá nhân viên, tổ chức
– Các bước thực hiện
– Đặt mục tiêu
– Lập kế hoạch hành động
– Theo dõi
– Đánh giá hiệu quả
MBO cho ai?
– Nhân viên
– Sếp
– Nhóm
– Công ty
Viết MBO thế nào?
– SMART (Specific, Measurable, Agreed/Achievable/Attainable, Realistic/Responsible/Receivablem, Time-bound)
– Rõ ràng
– Càng số hoá càng tốt
Thời gian đánh giá MBO
– 3, 6, 12 tháng 1 lần,
– Có thể lấy các mốc review nhân viên, nhóm, phòng, công ty theo kỳ, quý, năm
MBO và KPI
– Liên quan mật thiết
MBO và BSC (Balanced Scorecard)
– Liên quan mật thiết
Cách lên MBO
– Bottom up: Từ cá nhân, tới team, phòng, ban, công ty
– Top-down: Từ chiến lược, mục tiêu công ty tới phòng, ban, team, và cuối cùng là từng cá nhân
Giải thích
Management by objectives (MBO) is a process of defining objectives within an organization /so that management and employees agree to the objectives and understand what they need to do in the organization in order to achieve them.
The term "management by objectives" was/first popularized by Peter Drucker in his 1954/ book ‘The Practice of Management’.[1]
The essence of MBO is participative goal setting, choosing course of actions and decision making. An important part of the MBO is the measurement and the comparison of the employee’s actual performance with the standards set. Ideally, when employees themselves have been involved with the goal setting and choosing the course of action to be followed by them, they are more likely to fulfill their responsibilities.
According to George S. Odiorne, the system of management by objectives can be described as a process whereby the/superior and subordinate jointly identify its common goals/, define each individual’s major areas of responsibility in terms of the results expected of him, and use these measures as guides for operating the unit and assessing the contribution of each of its members.[2]
Các bước thực hiện
Setting Objectives Goal-setting or objective setting is a multistage process. It starts with the examining of the current state of affaires, level of efficiency, threats, and opportunities. Then the key result areas are identified, such as product markets, improved services, lowered costs, work simplification, employee motivation, profitability innovation and social responsibility. The performance of these areas is critical for organization in the sense that failure in these areas may result in failure of the organization. And this is why they are known as “key” result areas. Peter says, objectives are important in every area where performance and results directly affect the survival and prosperity of business.
Developing Action Plans
Set objectives must be translated into action plans. It requires assignment of specific responsibilities to different departments, division, and individuals. It also requires allocation of necessary resources needed to perform the assigned responsibilities. Time dimensions are also to be decided in order that targets are reached without any unwarranted delays.
Periodic Review or Monitoring The Progress
After setting objectives and developing action plans, it is necessary to establish a proper a view to regularly keeping the activities. He progress is monitored without day path leading to the ultimate objective. It is ensured that the deviations found, if any, are thoroughly discussed and immediate corrective actions are taken to set them right on the course. Such a regular monitoring and periodic review not only provide feedback which is essential for completion of work in time. But also motivates the managers accountable for performance. Periodic review and monitoring are done at departmental level generally.
Performance appraisal
This is the last phase of MBO program that evaluates performance annually. The annual review or appraisal is comprehensive and is done at the organization level. The actual annual results are evaluated against the set objectives. Such assessment is also used for determining targets for next year, for modification in standards (goals0 if needed, and for taking corrective actions in order to avoid deviations form predetermined objectives.
cf. https://www.flickr.com/photos/vuhung/7744821596
Quy trình vote của Apache
0. Lazy vote
Không cần mất thời gian, chỉ vote "đồng ý", "phản đối" hay "phiếu trắng"
Lấy ý kiến, sự đồng thuận từ rất nhiều người (cả team) trong thời gian ngắn
1. Các tuỳ chọn vote cơ bản
+1: Đồng ý
-1: Phản đối
0: Không có ý kiến (phiếu trắng)
0.x: Không/ít dùng (hơi hơi phản đối, hơi hơi đồng ý…)
2. Các tuỳ chọn khác
+0: ‘I don’t feel strongly about it, but I’m okay with this.’
-0: ‘I won’t get in the way, but I’d rather we didn’t do this.’
-0.5: ‘I don’t like this idea, but I can’t find any rational justification for my feelings.’
++1: ‘Wow! I like this! Let’s do it!’
-0.9: ‘I really don’t like this, but I’m not going to stand in the way if everyone else wants to go ahead with it.’
+0.9: ‘This is a cool idea and i like it, but I don’t have time/the skills necessary to help out.’
3. Lợi ích
– Tốn ít thời gian
– Thích hợp với remote team
– Phù hợp với các nhóm kỹ thuật
4. Quy trình vote của Apache thích hợp ở đâu?
– Dùng lúc nào cũng được
– Vote nhanh
– Hay vote chậm
5. Tham khảo
http://apache.org/foundation/voting.html
Cuộc họp retrospective là cuộc họp quan trọng nhất trong. Nó quyết định sự thành công và độ ổn định lâu dài của nhóm Scrum. Việc khung làm việc của Scrum không định nghĩa rõ về cuộc họp này tạo sự sáng tạo và đặc thù riêng theo từng nhóm.
Tuy vậy, việc thể hiện những giá trị cốt lõi của Scrum trong cuộc họp này – minh bạch, thích nghi và cải tiến liên tục – không phải là điều dễ làm.
KPT là một cách làm retrospective theo kiểu Nhật.
“K” = Keep là những việc tốt nên keep (duy trì) trong thời gian tiếp theo.
“P” = Problem, là những tồn tại (việc xấu) trong thời gian vừa qua cần được giải quyết.
“T” = Try, là những việc cần thử nghiệm về sau này.
KPT tương ứng với giai đoạn “C” (check) trong mô hình PDCA (Plan-Do-Check-Action)
So sánh KPT với các phương pháp chạy một cuộc họp Retrospective, ta sẽ thấy các điểm chung.
Mô hình PDCA chính là sự cải tiến liên tục. Tương tự như thế, khi Retrospective – cuộc họp cuối của một sprint – kết thúc, cũng là lúc một sprint mới bắt đầu với kế hoạch mới, hành động mới.
Theo cách này, bảng trắng được chia thành các múi, giống như Sao biển với các ô tương ứng
Không dùng. Đây là cách cho điểm từ 1 đến 10 các tiêu chí cần đánh giá. Có lẽ cách làm này phức tạp nhưng “pick brain” được team member và cách thể hiện khá nghệ thuật một cách khoa học. Cách làm Team Radar có thể xem thêm trong cuốn “Agile Retrospectives: Making Good Teams Great”.
Có nhiều cách làm Retrospective. Một trong những mục đích cuối cùng của Retrospective là để nhóm nhìn lại những điểm tốt xấu đã làm trong nhịp trước, tạo tiền đề làm bàn đạp cho việc Kaizen của (những) sprint tiếp theo.
Chúng tôi lựa chọn một biến thể của KPT để thực hiện Retospective. Lý do của sự lựa chọn khá đơn giản: Nó được thực hiện từ nhiều năm nay như một thứ văn hóa ăn và máu của của Nhật.
Đăng lại từ http://labs.septeni-technology.jp/offshore/running-a-retrospective-meeting/
Nguyễn Vũ Hưng's blog on Free and Open Source 