Scrum và các nhiệm vụ không song song


8

Chủ scrum hiện tại của tôi là một tín đồ thực sự, người không sẵn sàng nhúc nhích với các hình thức chính thức của scrum. Tôi không muốn điều này nghe có vẻ khó chịu, tôi thực sự hỏi về giải pháp chính thống cho vấn đề này bởi vì tôi đã giải quyết thành công các vấn đề với anh ấy trong quá khứ bằng cách kể lại những điều chính thức.

Ví dụ hiện tại về một vấn đề thường xuyên mà chúng ta có là có một số phụ thuộc thứ tự giữa một số câu chuyện của chúng ta. (Đặc biệt, một phần của quá trình phát triển sử dụng chương trình của bên thứ ba mà chúng tôi chỉ có giấy phép chỗ ngồi duy nhất.) Có một số tác vụ thiết lập cần thiết được liên kết với điều này đã được tập hợp thành "Câu chuyện thiết lập" và sau đó chúng tôi có 6 nhiệm vụ có thể làm theo bất kỳ thứ tự nào.

Vấn đề là ở lần chạy nước rút hiện tại, chúng tôi đã kéo vào Câu chuyện thiết lập và một trong những câu chuyện tiếp theo, tại thời điểm đó tôi đã nói rằng chúng tôi không thể lấy thêm bất kỳ câu chuyện nào trong nhóm này, mặc dù nước rút của chúng tôi chưa đầy một nửa. Có những câu chuyện không liên quan trên hồ sơ tồn đọng được ưu tiên thấp hơn nhóm này mà tôi đề nghị chúng ta có thể đưa vào nước rút. Tuy nhiên, tất cả đều được ưu tiên bên dưới những câu chuyện trong nhóm này. Tại thời điểm này, bậc thầy scrum tuyên bố rằng chúng ta nên vung "Nhiệm vụ thiết lập" và hoàn thành nó nhanh hơn, đây là một cuộc xung đột mà chúng ta đã có trước đây và anh ta đã đào sâu vào.

Vì vậy, trong nửa đầu của lần chạy nước rút này, hai nhà phát triển và tài nguyên thử nghiệm đang theo dõi tôi làm việc thông qua trang web cấu hình của nhà cung cấp bên ngoài, tải xuống tài nguyên và xáo trộn các xung quanh. Trong suốt thời gian đó, tôi biết rằng chúng tôi có một bản phát hành sắp tới trong ba lần chạy nước rút và chúng tôi có thể nhận được gần như toàn bộ công việc tồn đọng mà PO muốn thực hiện, nhưng chúng tôi sẽ không làm vì những công việc đó đang được thực hiện trong khi mọi người ngồi xem (er, swarms) nhiệm vụ thiết lập cho câu chuyện ưu tiên cao nhất.

Chủ scrum của tôi nói rằng mối quan tâm duy nhất của chúng tôi là hoàn thành những câu chuyện mà chúng tôi chấp nhận cho lần chạy nước rút. Điều mà tôi hiểu, nhưng tôi cảm thấy như chúng ta đang làm thất bại tổ chức lớn hơn bằng cách không truyền đạt "việc đóng gói thùng xấu" mà sự ưu tiên mà chúng tôi nhận được từ chủ sở hữu sản phẩm đang gây ra.

Vì vậy, làm thế nào chính thức là các vấn đề phụ thuộc giữa các câu chuyện và các câu chuyện nối tiếp vốn được xử lý bởi phương pháp luận?


Giới hạn cấp phép của bên thứ ba này là một thực tế của cuộc sống và nên được sử dụng làm lý do để sắp xếp lại các câu chuyện và hủy bỏ cuộc chạy nước rút này và bắt đầu một câu chuyện mới. Nhiều như mọi người có thể muốn một tính năng / câu chuyện cụ thể được thực hiện trước tiên, điều đó sẽ không xảy ra và thật vô nghĩa khi mọi thứ phải chờ đợi. Swarming là một giải pháp mà Scrum Master nên đề xuất, nhưng nhóm nên quyết định có nên làm điều đó hay không. Tôi không nghĩ có bất cứ điều gì trong luật của Scrum sẽ ngăn chặn điều này.
JeffO

@JeffO Chúng tôi đã cố gắng đẩy lùi một chút và về cơ bản có một bài giảng về việc bỏ qua mong muốn của chủ sở hữu sản phẩm. Đã có một số cuộc nói chuyện về việc sử dụng Scrumban tại một số thời điểm trong quá khứ và chủ scrum của tôi rất phản đối điều đó vì PO không có quyền kiểm soát. Đó là một phần của rối loạn chức năng đặc biệt của chúng tôi chỉ ra rằng swarming là không phù hợp trong tình huống này được trả lời bằng cách tràn ngập nhiều người hơn.
Ukko

Tại sao người kiểm tra không làm việc với các bài kiểm tra và / hoặc kế hoạch kiểm tra của họ? Kiểm thử là một hoạt động nên được bắt đầu trước khi mã sẵn sàng.
Bryan Oakley

@BryanOakley Câu trả lời mà chủ scrum của tôi đưa ra là vì họ có thể có một ý tưởng tốt và đào tạo chéo. Cá nhân, tôi thấy nó là một sự lãng phí, chủ scrum của tôi cảm thấy như chúng ta nên tránh các silo kỹ năng. Tôi nghĩ rằng chúng tôi là chuyên gia trong lĩnh vực của mình, nhưng anh ấy nói rằng mục tiêu là để chúng tôi có thể nhảy vào và giúp đỡ lẫn nhau.
Ukko

1
@Ukko: đó thực sự là một câu trả lời OK. Mục tiêu chính là đảm bảo họ thực sự không làm gì cả. Miễn là chúng là một phần của quá trình từ đầu nước rút đến cuối, đó là tất cả những gì quan trọng. Quá thường xuyên kiểm tra được để lại cho đến cuối nước rút.
Bryan Oakley

Câu trả lời:


6

Vì vậy, làm thế nào chính thức là các vấn đề phụ thuộc giữa các câu chuyện và các câu chuyện nối tiếp vốn được xử lý bởi phương pháp luận?

Như với bất cứ điều gì khác trong Agile: Individuals and interactions over processes and tools

Nếu quy trình của bạn không phục vụ bạn, thì bạn đúc nó thành một cái gì đó hữu ích. Đối với điều này, tôi sẽ kéo theo những câu chuyện ưu tiên thấp hơn (hoặc một số khoản nợ kỹ thuật / tăng trưởng cá nhân có thể không nhìn thấy trong hồ sơ tồn đọng) cho đến khi điều kiện tiên quyết được xóa. Tất nhiên, giả sử rằng bạn đã thực hiện sự chuyên cần của mình và đó thực sự là một điều kiện tiên quyết khó khăn và nhanh chóng. Đối với nhiều thứ, giao diện và giả có thể bỏ chặn công việc cho đến khi điều thực sự sẵn sàng.


Tôi sẽ hoàn toàn chỉ ra các Cá nhân và tương tác qua các quy trình và công cụ . Tôi hoàn toàn ủng hộ việc kéo công việc, nhưng điều đó rất khó chịu, một lần nữa bởi vì chúng tôi đang đi ngược lại các ưu tiên của PO. Điều buồn cười là dường như đó là một chủ đề sắp xuất hiện khi tôi mô tả điều này.
Ukko

2
@Ukko - ưu tiên là ưu tiên, không phải là hàng đợi.
Telastyn

1
@Ukko: Cách Scrum chính thức để giải quyết vấn đề đó là nói chuyện với PO nếu họ sẵn sàng ưu tiên lại một số công việc để hoàn thành công việc tồn đọng sớm hơn. Tôi vẫn phải gặp một PO không sẵn lòng làm việc với nhóm theo cách như vậy.
Bart van Ingen Schenau

@BartvanIngenSchenau nhắc đến PO rung chuông. Đó là một điều không được xác định rõ ở đây. Chúng tôi không có vai trò PO tốt trong tổ chức, có một nhóm BA đóng vai trò PO nhưng họ không phải là PO thực sự. Trong trường hợp này, BA đang chịu nhiều áp lực từ ban quản lý về chức năng cụ thể này và cô ấy rất sợ khi chúng tôi chạm vào một câu chuyện "ưu tiên thấp".
Ukko

3

Một trong những tính năng của kanban, mà tôi tin rằng đã chảy máu vào scrum, đó là toàn bộ quá trình tối ưu hóa cho nhóm chứ không phải cá nhân. Nói cách khác, sẽ không có tội gì nếu ai đó trong đội không hoạt động trong giai đoạn nước rút.

Nếu toàn bộ nhóm chọn điểm X, điều đó thực sự không quan trọng (với các bên liên quan) cho dù một người có làm tất cả công việc hay nếu công việc được chia đều. Vì vậy, nếu chủ sở hữu sản phẩm hài lòng với số điểm được đưa vào chạy nước rút (và đây là cuộc gọi của chủ sở hữu sản phẩm, không phải là chủ scrum!) Thì đó mới là vấn đề.

Tất nhiên, điều đó đang được nói, nếu một số thành viên trong nhóm không trực tiếp tham gia vào câu chuyện đầu tiên, họ có thể bận rộn viết các bài kiểm tra hoặc làm bất cứ điều gì họ có thể trên các câu chuyện khác.

Như một lưu ý cuối cùng, bậc thầy scrum có ít việc "đào bới gót chân". Bậc thầy scrum nên làm việc cho bạn để loại bỏ các rào cản về năng suất, không thiết lập các rào cản. Nếu toàn bộ nhóm cảm thấy họ có thể kéo theo một câu chuyện ưu tiên thấp hơn khác, đó là một quyết định cho nhóm thực hiện; chủ scrum không có tiếng nói cuối cùng trong vấn đề này.

Một ngoại lệ có thể được tạo ra nếu nhóm còn trẻ và vẫn đang học scrum, nhưng nếu nhóm trưởng thành, toàn bộ quan điểm của scrum là trao quyền cho nhóm chứ không phải là người quản lý.


1

Theo cách tôi thấy, bạn có hai vấn đề khác nhau:

  1. Cách tối ưu hóa năng suất của nhóm bạn.
  2. Làm thế nào để đặt hàng sản phẩm và chạy nước rút tồn đọng dựa trên phụ thuộc.

Đối với năng suất của nhóm bạn , tôi có thể thông cảm với Scrum Master của bạn: Tôi đã tìm thấy, do bản chất con người, rằng hầu hết mọi người muốn giữ cho mọi người bận rộn, thay vì tối ưu hóa toàn bộ nhóm. Bận rộn không bằng năng suất. Nhàn rỗi có thể là điều tốt nhất cho một thành viên trong nhóm làm tại một thời điểm nhất định.

Về vấn đề cụ thể của tác vụ thiết lập: điều này nghe có vẻ như là thứ gì đó nên được tự động hóa. Đưa ra bài viết của bạn, nếu tôi làm việc với nhóm của bạn, tôi muốn dành chút thời gian để tìm hiểu điều gì đang xảy ra với quy trình thiết lập này vừa tốn thời gian vừa chặn, vì nghe có vẻ như là một ứng cử viên chính để cải thiện hiệu quả của đội.

Tôi cũng hy vọng, ở mức tối thiểu, bạn không phải là người duy nhất trong nhóm có thể làm điều này. Nếu bạn có một ngày nghỉ, tôi hy vọng nhóm có những người khác có thể xử lý quá trình thắt cổ chai này. Swarming có thể là một cơ hội để đảm bảo rằng nhiều người học cách làm điều này.

Giả sử rằng bạn có sự phụ thuộc không thể tránh khỏi giữa các Mục tồn đọng sản phẩm (PBI), tôi sẽ coi tất cả các PBI phụ thuộc là bị chặn cho đến khi giải quyết phụ thuộc chặn. Nói chung, điều này có nghĩa là để các PBI bị chặn ra khỏi Sprint. Vì bạn có quyền kiểm soát phụ thuộc chặn, tôi có thể thấy việc đưa PBI phụ thuộc vào nước rút, nhưng đó có vẻ là một động thái rủi ro. Trong Lập kế hoạch Sprint, tôi thường chỉ mong đợi xem xét các PBI không bị chặn.

Tuy nhiên, điểm mấu chốt là tìm ra những gì hoạt động tốt nhất để cung cấp phần mềm làm việc có giá trị, được thử nghiệm, hiệu quả nhất có thể.


0

Quy tắc số 1 để xây dựng hồ sơ tồn đọng nước rút của bạn (thêm các mặt hàng tồn đọng sản phẩm hoặc PBI) phải tuân theo nguyên tắc ĐẦU TƯ cơ bản:

  1. Độc lập: PBI nên được khép kín, theo cách không có sự phụ thuộc vốn có vào PBI khác.
  2. Thỏa thuận: PBIs, cho đến khi chúng là một phần của phép lặp, luôn có thể được thay đổi và viết lại.
  3. Có giá trị: PBI phải cung cấp giá trị cho các bên liên quan.
  4. Có thể ước tính : Bạn phải luôn có thể ước tính kích thước của PBI.
  5. Nhỏ: PBI không nên lớn đến mức không thể lập kế hoạch / nhiệm vụ / ưu tiên với một mức độ chắc chắn nhất định.
  6. Có thể kiểm tra: PBI hoặc mô tả liên quan của nó phải cung cấp thông tin cần thiết để có thể phát triển thử nghiệm

Có vẻ như Scrum Master của bạn đang buộc nhóm phá vỡ quy tắc đầu tiên, tất cả các câu chuyện trong một lần chạy nước rút phải độc lập - bạn sẽ làm gì nếu bạn bị chặn trong một câu chuyện mà bạn cần hoàn thành để đóng bất kỳ câu chuyện nào khác? Bạn có thể sẽ thất bại trong nước rút trong trường hợp này.

Tôi đồng ý rằng lập trình bầy / cặp là một cách tốt để cộng tác và chia sẻ kiến ​​thức trong nhóm - nhưng nếu không cần phải vung tay vào thứ gì đó như thế này, thì tôi sẽ dùng súng của bạn và trích dẫn ĐẦU TƯ :)

Sao chép từ Wikipedia: https://en.wikipedia.org/wiki/INVEST_(mnemonic)

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.