Khi nào nhóm thảo luận các yêu cầu khi sử dụng Kanban?

Tôi đã đọc một chút về Kanban và tôi hơi bối rối về chủ đề Yêu cầu.

Trong dự án hiện tại của tôi, chúng tôi sử dụng Scrum. Khi bắt đầu một Sprint, chúng tôi có một phiên trong đó BA thực hiện hướng dẫn Câu chuyện và mô tả nó tốt nhất có thể. Sau đó chúng tôi lấy câu chuyện, xem xét nó, thảo luận về nó và chuẩn bị một câu hỏi cho BA cho phiên lập kế hoạch Sprint tiếp theo. Trong phiên tiếp theo, BA trả lời tất cả các câu hỏi và phiên kết thúc với việc chúng tôi đã hiểu các yêu cầu (hầu hết thời gian).

Bước tiếp theo là sau đó chúng tôi sản xuất một thiết kế kỹ thuật và phát triển giải pháp / câu chuyện.

Với Kanban, mọi thứ tôi đọc cho thấy không có Kế hoạch Sprint ở Kanban. Câu hỏi của tôi là tại thời điểm nào (ở Kanban), các kỹ thuật viên và dân kinh doanh ngồi lại với nhau để thảo luận về yêu cầu cho câu chuyện? Trình quản lý sản phẩm hoặc BA không cung cấp hướng dẫn về Câu chuyện trong Kanban?

Với Scrum, BA thường có sẵn trên toàn Sprint để hỗ trợ sự phát triển và tôi cho rằng nó giống với Kanban. Không rõ ràng với tôi như thế nào với Kanban, các tín đồ công nghệ hiểu Câu chuyện nếu không có kế hoạch chạy nước rút.

Bạn nói đúng rằng Kanban không có khái niệm về Sprint hoặc Lập kế hoạch Sprint như Scrum. Đó là bởi vì đó là một phương pháp tinh gọn hơn . Nhiều việc được thực hiện chỉ trong thời gian .

Tùy bạn quyết định cách lên lịch các hoạt động lập kế hoạch, nhưng tôi khuyên bạn nên thực hiện chúng càng gần khi bắt đầu công việc càng tốt. Điều này hiệu quả nhất khi có đại diện của tất cả các bên liên quan chính được nhúng vào nhóm (điều này cũng làm cho Scrum hiệu quả hơn).

Tôi nghĩ rằng sơ đồ này, dựa trên Phân phối Agile có kỷ luật , đưa ra một biểu diễn hình ảnh tốt về quy trình phần mềm tinh gọn:

Các sự kiện của Lập kế hoạch hàng ngày và Lập kế hoạch Sprint được ghi lại trong Phiên họp phối hợp và mô hình hóa bổ sung. Cuộc họp Điều phối giống như Cuộc họp hàng ngày từ Scrum và Phiên họp mô hình hóa bổ sung giống như Tinh chỉnh Backlog và Lập kế hoạch Sprint. Tuy nhiên, bạn có thể đưa một số thảo luận về yêu cầu vào Cuộc họp Phối hợp nếu điều đó có hiệu quả với nhóm của bạn.

Giống như hầu hết mọi thứ trong một quy trình tinh gọn, điều này xảy ra chỉ trong thời gian. Không có bảng thời gian và sự kiện nào không xảy ra trên một nhịp cụ thể như họ làm trong Scrum. Bạn làm công việc khi nó thêm giá trị cho nhóm và các bên liên quan.

Mà bạn có thể so sánh với biểu diễn bằng hình ảnh của một quy trình dựa trên Scrum được mô hình hóa trong bối cảnh Phân phối Agile có kỷ luật:

Thay vì gò bó bản thân trong 2-4 tuần Sprint với kế hoạch khi bắt đầu, đứng lên hàng ngày, và đánh giá và hồi cứu ở cuối, các phương pháp tinh gọn hơn sẽ ban hành các cuộc họp trình diễn, phối hợp và hồi cứu của bạn bất cứ khi nào các bên liên quan nghĩ rằng nó phù hợp .

Kanban sẽ cung cấp hướng dẫn để quản lý tồn đọng công việc và tiến độ công việc (WIP) của bạn. Bạn có thể chuyển sang các kỹ thuật và phương pháp khác để triển khai chính xác các hoạt động khác vì Kanban thường im lặng với các hoạt động đó.

Bạn hơi hiểu sai / hiểu sai những gì cuộc họp Lập kế hoạch Sprint làm trong Scrum mà tôi nghĩ là nguyên nhân của sự nhầm lẫn của bạn. Một cuộc họp Lập kế hoạch Sprint thường là nơi sai lầm để tìm ra các chi tiết của câu chuyện. Khác với một số điều chỉnh cuối cùng và chạy nhanh để đảm bảo không có mối quan tâm nổi bật nào có thể ảnh hưởng đáng kể đến các ước tính, những câu chuyện được xem xét nên hầu như đã sẵn sàng để đi. Từ đó, Sprint Planning thực hiện những gì nó nói trên tin: nó lên kế hoạch cho những gì sẽ có trong giai đoạn nước rút sắp tới. Nếu bạn không có nước rút, thì không cần Lập kế hoạch Sprint.

Vì vậy, khi nào các chi tiết của câu chuyện được xác thịt? Thông thường thông qua Backlog Chải chuốt hoặc liên lạc liên tục trong các lần chạy nước rút trước đó. Mục tiêu ở đây là để có đủ sự rõ ràng để có thể đưa ra ước tính hợp lý tự tin. Điều này không đòi hỏi mọi chi tiết phải được giải quyết trước thời hạn. Cho dù bạn cố gắng bao nhiêu, sẽ luôn có những câu hỏi được đưa ra trong quá trình thực hiện. Mục tiêu trong Scrum là cho các câu hỏi xuất hiện trong quá trình thực hiện là tương đối nhỏ (về cơ bản, đủ nhỏ để chúng không ảnh hưởng đến những gì ước tính sẽ có).

Trong Kanban, ước tính là tùy chọn. Nếu bạn ước tính, thì có khả năng bạn sẽ làm một cái gì đó tương tự như Scrum theo nghĩa là trước khi câu chuyện được thực hiện, nó sẽ được thảo luận để đưa ra ước tính. Nếu bạn không thực hiện ước tính, thì hành vi thực tế cũng tương tự ngoại trừ việc bạn không thể thảo luận về một câu chuyện cho đến khi nó được bắt đầu.

Theo kinh nghiệm của tôi, tôi thường làm việc với các nhóm sử dụng cách tiếp cận giống như Scrum cho sự phát triển chính và sau đó chuyển sang cách tiếp cận Kanban hơn cho giai đoạn bảo trì. Làm việc trong giai đoạn bảo trì có xu hướng rời rạc hơn, và những câu chuyện được xác định rõ ràng hơn ab initio và quy mô nhỏ hơn. Trong giai đoạn phát triển chính, các câu chuyện thường bắt đầu ở cấp độ cao và cần được tinh chỉnh và chia nhỏ để đạt đến điểm mà chúng có thể được chấp nhận cho một lần chạy nước rút. Bắt đầu những câu chuyện như vậy trong bối cảnh Kanban có ý nghĩa rất nhỏ và hoàn toàn nhấn chìm các số liệu của bạn.

Không có vai trò "Nhà phân tích kinh doanh" chính thức nào trong Scrum hoặc Kanban. Đó là nhóm phân tích và ước tính câu chuyện. Nếu Sprint Planning là lần đầu tiên nhóm phát triển nghe thông tin chi tiết về các câu chuyện thì có gì đó không ổn. Tôi không nói rằng bạn không thể sử dụng BA hoặc mọi nhà phát triển cần có mặt trong mọi cuộc họp thu thập yêu cầu, nhưng một sốđại diện của các nhà phát triển nên xảy ra tại một số thời điểm trong quá trình thu thập yêu cầu trước Kế hoạch Sprint. Một BA thường không đủ hiểu biết về các chi tiết của việc thực hiện để biết chi phí của mọi thứ hoặc những câu hỏi nào có thể có tác động đáng kể đến chi phí. Điều này có nghĩa là có thể có các chi tiết có thể ảnh hưởng mạnh đến các ước tính sẽ không được công nhận cho đến khi nhóm phát triển nhìn thấy chúng. Hơn nữa, các nhà phát triển có thể cung cấp hướng dẫn về các phương pháp hiệu quả hơn về chi phí hoặc đề xuất các tính năng tương đối dễ thực hiện nhưng có thể tăng thêm nhiều giá trị cho người dùng. Điều tôi nghi ngờ có thể xảy ra trong trường hợp của bạn, đó là các nhà phát triển đang hỗ trợ BA khi BA đang thực hiện thu thập yêu cầu (ví dụ: trả lời các câu hỏi cho BA hoặc cung cấp một số thứ tự ước tính cường độ), và điều này gần như thay thế Backlog Groom. Ngoài ra, bạn đang thực hiện công việc (ví dụ: công việc bảo trì) tự nhiên đến trong các gói tương đối nhỏ, trong trường hợp đó Kanban có thể là một quy trình phù hợp hơn.

Tôi đang chỉnh sửa câu trả lời của mình dựa trên phản hồi tôi nhận được để tiếp tục giúp bạn hiểu cách thức và thời điểm bạn nên làm việc trong giai đoạn Yêu cầu và Lập kế hoạch Sprint của Sprint của bạn; cũng như áp dụng Phương pháp Kanban cho các quy trình hiện tại của bạn. Đối với mục đích trả lời của tôi, tôi đang sử dụng các thuật ngữ "Kanban" và "Phương pháp Kanban" thay thế cho nhau, bởi cả hai đều có nghĩa là các khuyến nghị của Phương pháp Kanban. Tôi hi vọng cái này giúp được.

Đầu tiên, bạn không nên thay đổi bất cứ điều gì về quy trình xây dựng / phát triển Yêu cầu của bạn "cho Kanban" - vì Kanban không đưa ra bất kỳ đề xuất nào ở đó. Tất cả những gì Kanban khuyên là bạn nên hình dung các quy trình hiện tại của mình, bao gồm quản lý Yêu cầu và Lập kế hoạch Sprint, thực hiện Giới hạn WIP và quản lý Lưu lượng. Sau đó, thực hiện bất kỳ thay đổi nào đối với quy trình của bạn dựa trên các tắc nghẽn và cơ hội cải tiến được quan sát.

[Tôi thực sự khuyên bạn rằng, nếu bạn chưa có, xin vui lòng đọc cuốn sách - " Kanban: Thay đổi tiến hóa thành công cho doanh nghiệp công nghệ của bạn " của David Anderson, người tiên phong của Phương pháp Kanban. (Từ chối trách nhiệm đầy đủ - Tôi là người đồng sáng lập tại một công ty sản phẩm Kanban. Tôi cũng là một Huấn luyện viên và Huấn luyện viên Kanban được chứng nhận của Đại học Lean Kanban.)

Kanban tự nó không phải là một phương pháp quản lý dự án / phát triển phần mềm. Nếu không có một quy trình hiện có, bạn không thể áp dụng / triển khai Kanban. Đó là một phương pháp giúp bạn cải thiện theo cách tiến hóa (dần dần, không phá vỡ) bất kể quy trình hiện tại của bạn là gì. Trong trường hợp của bạn, đó là Scrum. Vì vậy, bạn thực sự nên áp dụng Kanban trên các quy trình Scrum của mình để giúp nhóm của bạn cải thiện việc phân phối phần mềm. Sự kết hợp của điều này được biết đến phổ biến là Scrumban.

Bạn sẽ bắt đầu bằng cách làm theo 3 nguyên tắc cơ bản của Kanban -

1. Bắt đầu với những gì bạn làm bây giờ
2. Đồng ý theo đuổi sự thay đổi tiến hóa, gia tăng
3. Tôn trọng các quy trình, vai trò, chức danh và trách nhiệm hiện tại

Sử dụng những nguyên tắc này làm nguyên tắc chỉ đạo của bạn, sau đó bạn triển khai các thực tiễn tiêu chuẩn của Phương pháp Kanban - đó là -

1. Hình dung quá trình hiện tại của bạn (và công việc đang diễn ra)
2. Giới hạn WIP (Đang tiến hành)
3. Quản lý lưu lượng
4. Làm cho chính sách quy trình rõ ràng

Bắt đầu với 4 thực hành này. Có 2 thực tiễn khác được định nghĩa trong Phương pháp Kanban mà bạn có thể xem xét khi bắt đầu và xử lý. Đó là (5) Thực hiện các vòng phản hồi và (6) Cải thiện & phát triển hợp tác, sử dụng Phương pháp khoa học.

Đây là một bản tóm tắt nhanh chóng - cuốn sách sẽ thực sự giúp bạn hiểu rõ hơn về những điều này. Ngoài ra còn có Hướng dẫn Kanban toàn diện có sẵn trên trang web của chúng tôi.]

Điều quan trọng để tập trung vào tình huống của bạn là hình dung (trên bảng Kanban) những gì bạn đang làm ngày hôm nay. Quy trình Yêu cầu hiện tại của bạn phải được tuân thủ trong quy trình Lập kế hoạch Sprint hoặc một số bước phụ bạn có thể chọn để trực quan hóa. Trên thực tế, bảng Kanban của bạn nên phản ánh kế hoạch Sprint như một giai đoạn cụ thể của quy trình phát triển tổng thể, tiếp theo là thiết kế kỹ thuật, nhà phát triển và thử nghiệm, tùy theo từng trường hợp.

Trong khi các câu chuyện của người dùng đang trong giai đoạn lập kế hoạch nước rút, bạn sẽ làm theo các bước trong đó như BA cung cấp cho bạn thông tin chi tiết, các nhà phát triển chuẩn bị câu hỏi và trả lời chúng trước khi câu chuyện chuyển sang giai đoạn thiết kế công nghệ và hơn thế nữa.

(BTW, nếu quy trình Yêu cầu của bạn có bất kỳ khía cạnh thượng nguồn nào có thể được coi là một phần của lập kế hoạch lộ trình hoặc chải chuốt tồn đọng, có toàn bộ chủ đề "Thượng nguồn Kanban" giúp bạn quản lý tốt hơn các hoạt động ngược dòng chi tiết như chúng có thể tồn tại ngay hôm nay. Bạn hoặc BA / PO của bạn có thể xem xét sử dụng bảng Kanban ngược dòng riêng để quản lý tất cả hoạt động đó.)

Luồng bảng Dev Kanban của bạn có thể trông giống như bên dưới -

Backlog -> Lập kế hoạch Sprint -> Thiết kế công nghệ -> Dev -> Kiểm tra -> Tích hợp -> Xong

Mỗi giai đoạn có thể có các cột phụ "Đang thực hiện" và "Hoàn thành" của riêng chúng - mặc dù nếu một nhà phát triển duy nhất thực hiện tất cả các giai đoạn, bạn có thể không cần các cột phụ đó ở mỗi giai đoạn. Nếu bạn cảm thấy điều đó quan trọng, bạn có thể chia Sprint Planning thành 3 giai đoạn phụ - Chi tiết câu chuyện, Làm rõ và Hoàn thành, do đó có khả năng bạn có thể nghiên cứu các tắc nghẽn trong từng khía cạnh của công việc. Ví dụ, trong nhóm nhà phát triển riêng của chúng tôi, việc xem xét mã có thể là một nút cổ chai thường xuyên!

Vào cuối chu kỳ chạy nước rút 2 hoặc 3 tuần của bạn, tất cả các câu chuyện của người dùng đã hoàn thành có thể được ra ngoài tập thể - và bạn bắt đầu với tập truyện tiếp theo từ Backlog.

Trong một khoảng thời gian, bạn có thể quyết định rằng một số thách thức khi thực hiện Scrum (rò rỉ câu chuyện, thời hạn nước rút bị bỏ lỡ, v.v.) có thể được xử lý bằng cách loại bỏ một số ràng buộc / quy tắc của Scrum - có thể xuất hiện đặc quyền đối với một số. Bản thân chúng tôi thực hiện các bản phát hành 4 - 6 tuần - và không làm Sprints. Nhưng cũng tốt không kém, bạn chỉ có thể tiếp tục làm việc với Sprints và Phát hành. Trong expperiece của chúng tôi, đây là nơi Kanban giúp bạn quyết định điều gì phù hợp với doanh nghiệp hoặc nhóm của bạn và áp dụng hoặc sửa đổi các quy trình giúp bạn phân phối công việc của mình theo cách tốt nhất có thể, giúp tối đa hóa lưu lượng, thông lượng / vận tốc và giảm thời gian giao hàng ( đến giờ đi chợ).

Cho dù bạn quyết định loại bỏ Sprint và chỉ thực hiện Phát hành và khi đã xây dựng đủ số lượng tính năng (hoặc sửa lỗi hoặc kết hợp cả hai) - hoặc liệu bạn có giữ Sprint hay không - Kanban sẽ giúp nhóm của bạn hoạt động trơn tru hơn, loại bỏ tắc nghẽn và cải thiện hiệu suất thời gian chu kỳ. Nếu điều đó giúp bạn thực hiện các bản phát hành thường xuyên hơn, từ đó giúp bạn nhận được phản hồi của khách hàng nhanh hơn, thì bây giờ bạn đang chuyển sang trạng thái có thể gọi là trạng thái "nhanh nhẹn hơn", nhưng có thể không nhất thiết phải phù hợp với định nghĩa cổ điển của phương pháp Scrum.

Tuy nhiên, nếu mục tiêu kinh doanh được đáp ứng tốt hơn, khách hàng sẽ hạnh phúc hơn và nhóm của bạn có thể hoạt động tối ưu, thì bạn sẽ đạt được mục tiêu thực hiện Kanban.

Hi vọng điêu nay co ich. Nếu bạn có bất kỳ câu hỏi nào, tôi rất vui lòng trả lời chúng.

Để đặc biệt trau dồi câu hỏi của bạn ...

điểm nào (ở Kanban) làm cho các kỹ thuật viên và dân kinh doanh ngồi lại với nhau để thảo luận về yêu cầu cho câu chuyện? Trình quản lý sản phẩm hoặc BA không cung cấp hướng dẫn về Câu chuyện trong Kanban?

Phương pháp Kanban do David Anderson tiên phong không chứa đựng một thực tiễn hoặc khuyến nghị cụ thể khi hoạt động này xảy ra. Câu trả lời mà bất kỳ học viên Kanban nào cũng sẽ cung cấp là ban đầu khi bạn áp dụng Phương pháp Kanban , bạn nên thực hiện hoạt động này giống như cách bạn thực hiện trước khi bạn quyết định phát triển cách bạn quản lý công việc. Nếu bạn thực hiện nó cứ sau 2 tuần, bạn nên tiếp tục thực hiện sau mỗi 2 tuần.

Nhóm của bạn sẽ khám phá nếu có cơ hội và giá trị trong việc thay đổi lịch trình. Hãy nhớ rằng lịch trình 1 tháng nhanh nhẹn hơn 1 năm, lịch trình 2 tuần nhanh nhẹn hơn 1 tháng, 1 tuần nhanh nhẹn hơn 2 tuần. Suy nghĩ này cuối cùng được chúng tôi chỉ trong thời gian như là sự nhanh nhẹn nhất . Trở nên nhanh nhẹn nhất không phải là điều kiện mục tiêu trước khi bạn bắt đầu.

Với Scrum, BA thường có sẵn trong suốt Sprint để hỗ trợ sự phát triển và tôi cho rằng nó giống với Kanban. Không rõ ràng với tôi như thế nào với Kanban, các tín đồ công nghệ hiểu Câu chuyện nếu không có kế hoạch chạy nước rút.

Phương pháp Kanban như một tư duy và một tập hợp các thực tiễn không đặt ra bất kỳ điều kiện hoặc ràng buộc nào đối với sự tồn tại của một cuộc họp Lập kế hoạch Sprint, Sprint hoặc bất kỳ thực tiễn nào khác. Nó hoàn toàn tôn trọng một nhóm Scrum và thực tiễn của họ. Nếu bạn có một cuộc họp ngày hôm nay nơi Techies thảo luận về câu chuyện, bạn sẽ tiếp tục có cuộc họp đó, sử dụng cùng một lịch trình.

Tôi không thể có lương tâm tốt cho bạn biết lịch trình sẽ / nên / có thể là gì nếu không hiểu nhóm của bạn và tổ chức xung quanh nó. Nếu bạn không thực hiện các hoạt động này ngày hôm nay, có nhiều nguồn thông tin khác để dạy bạn cách thực hiện các hoạt động này. Phương pháp Kanban có thể cung cấp hướng dẫn về việc dạy bạn khám phá nếu lựa chọn của bạn là lựa chọn tốt.

Xin vui lòng đọc các bài viết blog trong hai loạt này. Một từ bản thân tôi và một từ Steve Porter, thành viên nhóm tại Scrum.org.

Không có gì trong Kanban ngăn chặn Scrum - Dave White - WesternDevs.com

Scrum và Kanban - Cùng nhau mạnh mẽ hơn - Steve Porter - Scrum.org

Hầu hết những gì Mahesh Singh nói trên đầu là từ tài liệu đào tạo được công bố của Lean Kanban Inc. Vì vậy, thực sự ... không có gì để tranh cãi ở đây. Nói chuyện với bất kỳ AKT hoặc KCP và anh ấy / cô ấy sẽ nói điều tương tự.

Đối với câu hỏi ban đầu về nơi bạn có thể làm rõ yêu cầu, có nhiều lựa chọn khác nhau:

1. Bạn có thể làm những gì bạn làm hôm nay nhưng bằng cách hình dung và đưa các bước đó vào một luồng giá trị, xác định những trở ngại của bạn. Sau đó, thực hiện một thay đổi và xem cách nó hoạt động. Cộng đồng Toyota Kata gọi đây là thử nghiệm nhân tố duy nhất.

2. Thực hiện một Hội đồng thượng nguồn về tinh chỉnh yêu cầu, phân tách, thiết kế tương tác / UX, v.v. Trong nhóm của chúng tôi, chúng tôi chia Chủ đề thành Epics, thực hiện chu trình thiết kế UX đầy đủ và chỉ sau đó chia nó thành câu chuyện. Sau đó, những câu chuyện được ưu tiên bằng cách đưa tất cả các bên liên quan vào một cuộc họp. Sự kết thúc của dòng giá trị này dẫn đến những câu chuyện được ưu tiên, tinh chế. Điều đó tạo thành tồn đọng của chúng tôi cho nhóm phát triển. Trên thực tế, luồng này mất rất nhiều thời gian chu kỳ, chủ yếu là do phải mất thời gian để chuyển từ yêu cầu cấp độ Epic sang khung dây trong Phác thảo hoặc Zeppelin cho nhóm Dev.

3. Nếu bạn không có luồng giá trị hoặc thời gian chu kỳ đáng kể để chuyển đổi thứ gì đó từ yêu cầu sang câu chuyện được tinh chỉnh, thì bạn có thể chỉ cần có một giai đoạn trong luồng giá trị Phát triển của mình (như làm rõ Yêu cầu). Tuy nhiên, Scrum không mong đợi mức độ rõ ràng cao để ước tính và đột nhập vào các nhiệm vụ. Vì vậy, cho dù bạn có làm một cuộc họp trước cuộc họp lập kế hoạch Sprint hay thực hiện cuộc họp lập kế hoạch Sprint mở rộng, nó sẽ phụ thuộc vào nhóm và tổ chức của bạn.

Nếu chúng ta nhớ các nguyên tắc và cởi mở với các thực tiễn được xác định, chu trình Kiểm tra và Thích ứng sẽ trở nên dễ dàng hơn nhiều.