Câu trả lời này được viết từ quan điểm của một người có hệ thống quản lý hiệu suất như vậy được đặt xung quanh một nhóm Agile; giống như bạn, mọi người trong nhóm nhận ra sự khó khăn / vô dụng của các mục tiêu SMART lâu năm được áp dụng cho nhóm Agile, khi mà khi hoạt động đầy đủ, việc triển khai Agile có thể được coi là vốn có / đã là SMART.
Không, thực sự! Gọi một cách hợp lý hóa sau đây nếu bạn cần (nếu logic là một nửa ...), nhưng việc giải thích nó cho các nhà đánh giá bên ngoài tổ chức ngay lập tức đã tạo tiền đề cho "mục tiêu" thực tế mà chúng tôi đưa vào hệ thống quản lý hiệu suất.
- S cụ thể : trong mỗi kế hoạch chạy nước rút, nhóm đồng ý về một nhóm nhiệm vụ cụ thể cần đạt được và cam kết thực hiện chúng. Các nhiệm vụ (và câu chuyện của người dùng), trả lời các câu hỏi về những gì tôi muốn hoàn thành, mục đích / lợi ích của việc hoàn thành mục tiêu, ai là người tham gia, nơi nó diễn ra và các ràng buộc.
- M để đo lường được : danh sách các nhiệm vụ này, cộng với sự di chuyển của vé trong suốt giai đoạn nước rút, từ phát triển đến đánh giá mã đến QA để phát hành (hoặc bất kể luồng của bạn là gì), trả lời các câu hỏi về bao nhiêu công việc và khi nào nó sẽ được hoàn thành .
- Có thể đạt được : các nhóm Agile hoạt động thường không cam kết với một thứ gì đó trong giai đoạn lập kế hoạch trừ khi có thể đạt được rõ ràng - tất cả các phần đều ở đó để biết cách thực hiện nó
- R có liên quan : những câu hỏi như nó có đáng không, có đúng lúc không, nó có phù hợp với những nỗ lực khác của chúng ta không - câu chuyện và nhiệm vụ không bị kéo vào cuộc đua nước rút, và cam kết, trừ khi câu trả lời là có cho tất cả những câu hỏi này ( thường là ... YMMV)
- T cho thời gian giới hạn : một lần chạy nước rút nhất thiết là giới hạn thời gian, có thể là 2 tuần, 3 tuần, nhiều hơn hoặc ít hơn.
Nếu bạn hiểu / thuyết phục bản thân rằng công việc hàng quý của bạn (và do đó là công việc lâu năm của bạn) là một mục tiêu SMART lớn và bạn biết rằng bạn đang đạt được mục tiêu của mình vì nhóm đang hoạt động tốt, vận tốc là tích cực, các bản phát hành đang diễn ra , sau đó bạn đi đến điểm câu hỏi của bạn, cuối cùng là làm thế nào để dịch một quy trình SMART thành một bộ các mục tiêu SMART vì lợi ích của người khác.
Tôi đã có thể làm điều này thành công trong quá khứ bằng cách viết một cái gì đó với tôi trông mơ hồ và, tốt, không thông minh lắm, nhưng thực tế là hoàn toàn chấp nhận được đối với người khác.
Một vài ví dụ đã vượt qua muster ở nơi khác đối với tôi:
"Tôi muốn phát hành một phiên bản mới của WidgetMaker ba tháng một lần trong năm tới, bằng cách tuân theo quy trình phát triển phần mềm nội bộ của chúng tôi, để phù hợp với lịch trình phát triển sản phẩm tổng thể (blah blah)."
"Tôi muốn tăng tốc độ phát triển của nhóm lên n% từ khi phát hành A đến phát hành B, bằng cách tập trung vào các thay đổi gia tăng cho quá trình chải chuốt tồn đọng, để tăng hiệu quả của chúng tôi và giảm sự chậm trễ trong việc vận chuyển sản phẩm."
Bạn biết và tôi biết rằng đây không phải là những nguyên tắc chỉ đạo của nhóm phát triển thực tế của bạn, nhưng chúng không hoàn toàn không liên quan và theo kinh nghiệm của tôi là những thứ xuất hiện thực sự THÔNG MINH và hữu ích cho những người bên ngoài tổ chức trực tiếp của bạn (không có hoàn toàn dối trá hoặc hoàn toàn khập khiễng).