Làm cách nào để thuyết phục nhóm của tôi rằng một đặc tả yêu cầu là không cần thiết nếu chúng tôi áp dụng các câu chuyện của người dùng?

9

Chúng tôi đang lên kế hoạch áp dụng các câu chuyện của người dùng để nắm bắt 'ý định' của các bên liên quan theo kiểu nhẹ thay vì SRS nặng (thông số kỹ thuật yêu cầu phần mềm). Tuy nhiên, dường như mặc dù họ hiểu giá trị của các câu chuyện, vẫn có mong muốn 'chuyển đổi' các câu chuyện thành ngôn ngữ giống như SRS với tất cả các thuộc tính, ưu tiên, đầu vào, đầu ra, nguồn, đích, v.v.

Câu chuyện của người dùng 'loại bỏ' sự cần thiết phải có một SRS chính thức như tạo tác để bắt đầu, vậy điểm quan trọng của việc có SRS là gì? Bằng cách nào tôi nên thuyết phục nhóm của mình (tất cả đều là những người CS rất có trình độ - cả về giáo dục và thực tiễn) rằng SRS sẽ bị 'loại bỏ' nếu chúng tôi chấp nhận các câu chuyện của người dùng để nắm bắt các yêu cầu chức năng của hệ thống? (NFR cũng có thể bị bắt, nhưng đó không phải là mục đích của câu hỏi).

Vì vậy, đây là đối số 'luồng công việc' của tôi: Nắm bắt các yêu cầu ban đầu dưới dạng câu chuyện của người dùng và sau đó xây dựng chúng cho các trường hợp sử dụng (được yêu cầu ghi lại ở mức độ thấp, tức là mô tả các tương tác với các nguyên mẫu / mockup UI và là một bài đăng có thể phân phối được triển khai). Do đó, chuyển từ câu chuyện người dùng sang trường hợp sử dụng thay vì câu chuyện người dùng sang SRS sang trường hợp sử dụng.

Làm thế nào tất cả các bạn hiện đang ghi lại các câu chuyện của người dùng tại nơi làm việc của bạn (nếu có) và làm thế nào để bạn đề nghị tôi 'tạo ra một trường hợp' vì không có SRS khi có các câu chuyện của người dùng?

— Bằng tiến sĩ
nguồn

nó sẽ không xảy ra trong một ngày, hãy tiếp cận dễ dàng

— Yusubov

Nếu bạn làm việc cho một nhà cung cấp dịch vụ phần mềm thì SRS có thể không cần thực hiện triển khai mà phải thực hiện "trò chơi đổ lỗi" khi khách hàng muốn giảm chi phí hoặc tranh luận của người cung cấp dịch vụ rằng cần nhiều tiền hơn hoặc cả hai sẽ ra tòa.

— k3b

14

Bước chân em bé. Tiếp tục viết SRS một lúc. Sau đó gọi một cuộc họp và thảo luận về việc họ vẫn phục vụ một mục đích. Có ai còn đọc chúng không? Là thời gian dành cho họ hợp lý? Có một bước trung gian khác sẽ nhẹ hơn?

Bạn không bao giờ biết, bạn có thể thấy rằng bạn đã sai. Hãy nhớ bản tuyên ngôn Agile, chúng tôi tìm thấy nhiều giá trị hơn trong "Phần mềm làm việc trên tài liệu toàn diện", nhưng vẫn có giá trị trong phần sau.

Mặc dù vậy, tôi đoán là bạn sẽ nhanh chóng phát hiện ra rằng mong muốn tiếp tục viết các tài liệu nặng sẽ biến mất khi họ thấy các trường hợp sử dụng chặt chẽ và các câu chuyện của người dùng liên quan như thế nào.

— pdr
nguồn

2

@PhD: Bạn nói đúng. Nó gần như nguyên thủy. Và đó là lý do tại sao bạn sẽ không chiến thắng trong trận chiến này với bất kỳ loại logic nào, chỉ bằng chứng. Bước chân em bé.

— pdr

2

Tôi đã làm việc cho các nhà quản lý đối mặt với sự thay đổi với các bước nhỏ, đó là từ mã của họ cho "chỉ đủ để thất bại nên tôi có thể nói tôi đúng" đây không phải là một con đường dẫn đến thành công bởi vì nó cho thấy sự thiếu hiểu biết cơ bản về phương pháp mới và sự thiếu mua hoàn toàn của ban quản lý, điều rất quan trọng để thay đổi thành công. Điều này nghe có vẻ tốt trong lý thuyết, nhưng trong thực tế, đó là một cái cớ để không thay đổi và tuyên bố chiến thắng mà cách mới không hoạt động và cách cũ làm. Do đó, SRS đã được tái cấu trúc và các câu chuyện sẽ được gắn nhãn là công việc làm thêm và bạn sẽ trở lại nơi bạn đã ở.

2

Kinh nghiệm của tôi không phải là số ít, nó đã hơn 22 năm trong ngành, hầu hết là tư vấn. Vì vậy, tôi đã làm việc với nhiều người quản lý và ra quyết định hơn hầu hết mọi người trong cùng một khoảng thời gian. Quan điểm của tôi là cách tiếp cận các bước bé này là một cách tiếp cận thất bại, chỉ có cam kết của quản lý cấp trên đối với sự thay đổi và triết lý đằng sau sự thay đổi sẽ dẫn đến việc thực hiện thành công. Nếu các đồng nghiệp của anh ta không bị thuyết phục, hãy để họ tiếp tục làm những gì họ muốn sẽ không thuyết phục được họ, điều đó chỉ nuôi sống chúng ta vẫn cần cách cũ và cách mới là một sự lãng phí thời gian.

1

@JarrodRoberson Tôi chỉ muốn thêm rằng những trải nghiệm của tôi phản ánh chặt chẽ hơn của bạn. Có hai loại người, và do đó có hai loại người quản lý, người bảo thủ và người chấp nhận rủi ro. Phe bảo thủ đương nhiên không thích thay đổi và rủi ro. Khi họ tìm thấy một mô hình hoạt động, thậm chí là kém, họ gắn bó với nó. Khi thay đổi bị ép buộc hoặc ép buộc họ, họ vô tình phá hoại nó bằng cách cố gắng thực hiện các bước bé . Đây là lý do tại sao lần duy nhất tôi từng thấy công việc áp dụng Agile thực sự là khi nó được dẫn dắt bởi những người chấp nhận rủi ro.

— maple_shaft

2

@maple_shaft: Bí quyết là tiếp tục tiến về phía trước. Nếu một thay đổi gia tăng không hoạt động, không nhất thiết phải thực hiện lại bước tương tự, hãy xem xét lý do tại sao nó không hoạt động ... giống như có thể bạn đang dành quá nhiều thời gian, viết một tài liệu vô nghĩa. Bây giờ tôi sẽ thừa nhận rằng cần một người quản lý giỏi để nghĩ theo cách đó, và hầu hết sẽ chạy trở lại vùng thoải mái của họ. Nhưng, theo cùng một lý do, điều đó không có nghĩa là lựa chọn duy nhất khác là thay đổi mạnh mẽ. Một người quản lý tồi sẽ làm hỏng nó lên.

— pdr

6

Sử thi là giữ chỗ

Trong bất kỳ phương pháp luận Agile nào, khái niệm về Epics sẽ nhiều như bạn cần cho một Đặc tả yêu cầu, chủ sở hữu địa điểm là thứ bạn cần ở cấp độ đó. Những mục đó sẽ được ưu tiên liên tục, bất kỳ chi tiết nào cũng bị lãng phí công sức nếu yêu cầu được ưu tiên thấp trong một thời gian dài hoặc thậm chí không bao giờ được thực hiện. Tài liệu về nó và quản lý tài liệu xung quanh nó sẽ là một sự lãng phí hoàn toàn thời gian. YAGNI mở rộng cho các hoạt động yêu cầu cũng như các hoạt động mã hóa.

Công cụ là bạn của bạn!

Nếu bạn sử dụng một công cụ thích hợp để thu thập và quản lý các câu chuyện của người dùng, thì bạn có thể tạo Đặc tả yêu cầu từ họ. Một đặc tả yêu cầu là một tài liệu giả tạo tạm thời dù sao, nó không phải là một tài liệu sống, nó là một ảnh chụp nhanh các yêu cầu kịp thời. Và không bao giờ đồng bộ với thực tế.

Tự động tạo tạo tác

Các câu chuyện của người dùng có thể được xuất từ một công cụ thích hợp có giá trị hơn bất kỳ tài liệu tạo tác tĩnh nào bất cứ lúc nào. Cá nhân tôi thích Pivotal Tracker để theo dõi Câu chuyện của người dùng, tôi thậm chí đã viết một bộ plugin MoinMoin bằng Python để xuất bản tất cả các Câu chuyện khác nhau và trạng thái của chúng trong Wiki (chứa các ghi chú chi tiết của nhà phát triển và các câu chuyện tương tự về câu chuyện), dữ liệu trực tiếp luôn luôn tốt hơn dữ liệu tĩnh.

Wiki đã trở thành một tài liệu trực tiếp về tất cả các cửa hàng / yêu cầu và trạng thái hoàn thành và ưu tiên của họ với các chi tiết và nhận xét và dữ liệu meta khác.

Cách tốt hơn một tài liệu Word khổng lồ ở Sharepoint, liên tục được gửi qua email và không bao giờ cập nhật, đảm bảo rằng mọi người đều có phiên bản khác nhau và không đồng bộ với mọi người khác!

Câu chuyện của người dùng phong phú hơn trường hợp sử dụng

Câu chuyện sử dụng có giá trị hơn nhiều so với Ca sử dụng vì họ nói TẠI SAO .

Định dạng Câu chuyện của Người dùng: As a [ROLE] I [ACTIVITY] so that [WHY]biểu cảm hơn nhiều so với Các trường hợp sử dụng giống như The System [shall/shall not/may/must] perform [action](trong đó hành động là biểu đồ luồng).

Với Câu chuyện người dùng, bạn có WHO muốn làm gì đó, bạn có CÁI GÌ họ muốn làm (có thể chỉ ra một sơ đồ / tài liệu chi tiết hơn cho các nhiệm vụ phức tạp) và bạn có phần quan trọng nhất TẠI SAO họ muốn thực hiện hoạt động này.

Nếu bạn có cái thứ nhất, cái thứ hai là hoàn toàn dư thừa và tốt nhất là chỉ có tiếng ồn. Một đặc tả yêu cầu chính thức truyền thống từ phương pháp Thác nước không có chỗ trong môi trường Agile.

Đến cuối cùng

Nếu quản lý của bạn không cam kết thay đổi, bạn sẽ không thành công với phương pháp mới. Tôi đã làm việc cho một công ty hơn 100 tỷ đô la một năm, họ đã không thực hiện các bước nhỏ để chuyển sang Agile / SCRUM, họ chỉ nói, toàn bộ công ty đang chuyển sang đây, đây là cách làm mới, đây là cách làm mới Khi việc đào tạo của bạn theo cách mới sẽ bắt đầu, đây là những công cụ mới mà chúng tôi sẽ sử dụng, đây là ngày chúng tôi bắt đầu thực hiện mọi thứ theo cách này. Nó làm việc cho họ trong vòng chưa đầy một năm. Tôi đã làm việc để thực hiện điều này trong các công ty nhỏ hơn với cùng một thành công.

Lời cam kết

thực hiện các bước bé , bất kể thay đổi là gì, là một công thức cho sự thất bại. Đó là một từ mã để quản lý mà họ lặng lẽ không đồng ý và đang tích cực thiết lập cho bạn thất bại. Họ đang nói rằng tôi không tin vào điều này đủ để cam kết với nó, vì vậy tôi sẽ cho phép bạn làm đủ để thất bại / không thành công , theo cách họ có thể nói họ đã cố gắng và nó không hoạt động và cách họ quản lý làm việc chỉ tốt thôi Cam kết một phần cuối cùng dẫn đến thất bại.

Trong trường hợp của bạn, có lẽ họ lặng lẽ không tin vào Câu chuyện của người dùng và sau một thời gian thực hiện, cả hai sẽ bắt đầu khẳng định đó là Câu chuyện người dùng vô dụng và không phải là SRS, và sẽ cố gắng ngừng viết Câu chuyện người dùng , sẽ chỉ dẫn bạn về phía sau không chuyển tiếp.

— kmote
nguồn

bạn sẽ khá ngạc nhiên, những câu chuyện của người dùng được quản lý bởi một công cụ có thể (và không) xuất nó theo yêu cầu. Tuy nhiên, mối quan tâm dường như là 'dịch' các câu chuyện của người dùng sang ngôn ngữ SRS của "hệ thống sẽ ...", v.v. và KHÔNG để nó là câu chuyện của người dùng.

— Tiến sĩ

1

Chà, nếu cúp máy là thuật ngữ "sẽ / phải / có thể" mà bạn có lẽ đang nhổ vào gió với những người đó. Câu chuyện của người dùng nói với WHO / WHAT và quan trọng nhất là TẠI SAO cần phải làm gì đó, hữu ích hơn nhiều so với các trường hợp sử dụng tĩnh, điều này sai hơn trong hầu hết các trường hợp.

2

-1: Không hoàn toàn không đồng ý với hầu hết câu trả lời, tuy nhiên, nói rằng và SRS là "Đặc tả yêu cầu là một tài liệu giả tạo tạm thời, dù sao nó không phải là tài liệu sống", vì vậy, sai lầm là cho thấy sự thiếu hiểu biết đáng lo ngại. SRS là dành cho, hoặc nó được sử dụng như thế nào khi được thực hiện đúng cách - thường chỉ có trong các nhà phần mềm mô hình thác nước kế thừa ngày nay.

— mattnz

5

Một SRS là một tài liệu chết ngay khi nó được xuất bản. Tôi đã viết chúng từ năm 1990. Chúng giống như một kế hoạch chiến tranh, chúng không bao giờ tồn tại trong lần tiếp xúc đầu tiên. Và họ không bao giờ theo kịp việc triển khai thực tế, trừ khi bạn có một nhóm các nhà văn chuyên dụng liên tục chỉnh sửa điều đó và thậm chí sau đó là sai vì sự ngắt kết nối với sự thay đổi liên tục và các nhà phát triển luôn đi trước tài liệu và không phải lúc nào cũng nói với chủ sở hữu tài liệu những gì đang xảy ra. Các công ty dành 1000 giờ để viết những thứ như vậy và các tài liệu được đặt trên kệ và mục nát trong khi quá trình phát triển bắt đầu.

3

@JarrodRoberson +1 cho bạn. Thật vậy, mattnz cũng đúng khi SRS được coi là một tài liệu sống, nhưng sau đó bạn gặp phải một số vấn đề sản xuất quan trọng mà khách hàng yêu cầu phải thay đổi, trong khi làm việc trên một hoặc nhiều bản phát hành phân nhánh của cơ sở mã, giải thích sai các nhà phân tích kinh doanh, nhà phát triển và QA ... những gì bạn còn lại là một tài liệu không phải là sự phản ánh đúng đắn của hệ thống ngay bây giờ, nhưng cũng không phản ánh đúng nhu cầu của người dùng. Câu chuyện của người dùng thực sự được thông qua bởi các công ty quan tâm đến khách hàng hơn hệ thống.

— maple_shaft

0

Tôi sẽ thử và sử dụng sự hài hước.

Bắt đầu với http://www.halfarsedagilemanifesto.org/

Nói về điều này trong một thời gian ( chuyển hướng )
và nói về ý nghĩa của các xung đột trong đó ( thảo luận mở ),
sau đó sau đó chuyển sang tổ chức của bạn ( trụ cột )
và kiểm tra SRS và liệu nó có hợp lý với thiết lập dự án mới không .

Sau đó, tôi sẽ kết luận (hoặc có thể trong một cuộc họp khác) bằng một cuộc thảo luận về sự thay đổi trong cách tiếp cận lại: SRS và xem liệu bạn có đồng thuận hơn không.

Vào cuối ngày, bạn cũng bị hạn chế bởi ngân sách và phục vụ dân kinh doanh nên có thể bạn sẽ vững hơn một chút về những gì được sử dụng, nhưng điều này thực sự phụ thuộc vào ngành, quy mô công ty, yếu tố tổ chức và nhiều các yếu tố khác như vậy.

— Michael Durrant
nguồn

5

Hãy thật cẩn thận. Sẽ chỉ hoạt động nếu đồng nghiệp của bạn rất an toàn & bạn có mối quan hệ tốt với họ. Nhiều người khó chịu nếu bạn sử dụng sự hài hước để nói với họ rằng họ đã sai & giấu giếm.

— MarkJ

-1

Thuyết phục mgmt để thoát khỏi SRS và bắt đầu sử dụng các câu chuyện của người dùng về cơ bản giống như việc thuyết phục mgmt để áp dụng Agile. Có những thống kê hấp dẫn về những lợi ích năng suất của Agile. Một ví dụ là bài thuyết trình VersionOne đã đưa ra tại một hội nghị năm 2013. Hiển thị mgmt dữ liệu ngành này và nếu chúng là loại nghe, bạn có cơ hội.

— Joe
nguồn

1

Xin lỗi, đó không phải là nhiều câu trả lời. Bạn nói 'hiển thị số liệu thống kê' và thậm chí không cung cấp liên kết.

— Jan Doggen

và viết những từ và câu hoàn chỉnh ...

— jwenting