軟件需求規(guī)格說明書通用模版

When developing applications there will be requirements that are needed on more than one application. Examples of such common requirements are non-functional, cookie consent and design patterns. How can we work with these types of requirements in a smart way across several applications and teams, without adding bureaucracy and increased lead time?

開發(fā)應用程序時，將需要多個應用程序的需求。 此類常見要求的示例包括非功能性，Cookie同意和設計模式。 在不增加官僚主義和增加交貨時間的情況下，我們?nèi)绾卧诙鄠€應用程序和團隊中以明智的方式滿足這些類型的需求？

It is a common challenge, that we work in silos, developing “our own” application within one organization. Each application has their stakeholders, product owner, scrum master, user experience, business analyst, architect, developers… In the beginning it’s fine if you only have a few applications running, however what happens when you have 10 applications running? Consider each product team spending 8 hours analyzing a requirement, that means the organization is potentially wasting 72 hours on each requirement. And not only is it a waste during the initial development, consider the amount of waste during the full life-cycle from that one requirement.

一個普遍的挑戰(zhàn)是，我們在孤島上工作，在一個組織內(nèi)開發(fā)“我們自己的”應用程序。 每個應用程序都有其利益相關者，產(chǎn)品所有者，Scrum管理員，用戶體驗，業(yè)務分析師，架構師，開發(fā)人員...剛開始時，如果只運行幾個應用程序就可以了，但是當您運行10個應用程序時會發(fā)生什么呢？ 考慮每個產(chǎn)品團隊花費8個小時來分析需求，這意味著組織可能在每個需求上浪費72個小時。 不僅在最初的開發(fā)過程中浪費了資源，還考慮了該需求在整個生命周期中的浪費量。

So why do we implement solutions in silos? The answer is that it’s often quicker. We want to deliver with speed to the market, and it’s often easier and faster to do the solution within the team rather than having to rely on other teams, their priorities and time available. Autonomy in all its glory, but sometimes it makes more sense to work across product teams to ensure we work smart and deliver sustainable solutions. And does it really have to take longer just because we work across several product teams?

那么為什么我們要在孤島中實施解決方案呢？ 答案是它通常更快。 我們希望將產(chǎn)品快速推向市場，通常在團隊內(nèi)完成解決方案變得越來越容易，而不必依賴其他團隊，他們的優(yōu)先級和可用時間。 自治具有其所有的榮耀，但有時跨產(chǎn)品團隊工作更有意義，以確保我們明智地工作并提供可持續(xù)的解決方案。 是否真的因為我們跨多個產(chǎn)品團隊工作而需要花費更長的時間？

我們?nèi)绾尾拍苈斆鞯貞獙鐖F隊的需求？ (How can we work smart with cross-team requirements?)

How can we in practice work to implement these requirements in a smart way to all relevant applications? There is, of course, the Spotify model, but if it’s too big a change or not the route you want to go down, this could be something to try out.

在實踐中，我們?nèi)绾尾拍芤悦髦堑姆绞綄λ邢嚓P應用程序?qū)崿F(xiàn)這些要求？ 當然，有Spotify模型，但是如果變化太大或您不想沿途走的路線，可以嘗試一下。

Someone has an idea or are working on a requirement when they realize that this is a requirement that would bring value to other applications within the organization as well.

當某人意識到這是一個需求，并且會為組織內(nèi)的其他應用程序帶來價值時，他們就有想法或正在研究需求。

All product owners meet to discuss the requirement, perform a quick analysis to determine if it brings value, if it’s achievable and if it’s a priority right now within the organization. They collaboratively make a decision on how to best move forward, they set a course of action. The course of action might be that it should be developed by two teams that will work together on further analyzing and developing the solution.

所有產(chǎn)品負責人開會討論需求，進行快速分析，以確定它是否帶來了價值，是否可以實現(xiàn)以及當前是否已成為組織內(nèi)的優(yōu)先事項。 他們共同決定如何最好地前進，并制定了行動方案。 行動過程可能是由兩個團隊共同開發(fā)，這兩個團隊將共同努力進一步分析和開發(fā)解決方案。

The two product teams collaborate and do a more thorough analysis to determine the smartest and most sustainable solution for the organization as a whole. Once implemented on one application (possibly as a shared component), the other product teams use the created solution for a “quick” implementation on their applications.

這兩個產(chǎn)品團隊合作并進行更徹底的分析，以確定整個組織最明智，最可持續(xù)的解決方案。 一旦在一個應用程序(可能作為共享組件)上實現(xiàn)，其他產(chǎn)品團隊便使用創(chuàng)建的解決方案在其應用程序上實現(xiàn)“快速”實施。

The product owners update all product owners on status and inform about the chosen solution that are being implemented so that they can prepare their teams for what’s coming. Once all applications has implemented the requirement the requirement is set to done. The team does a quick retrospective to learn and adapt.

產(chǎn)品負責人向所有產(chǎn)品負責人更新狀態(tài)，并告知他們正在實施的所選解決方案，以便他們?yōu)榧磳l(fā)生的事情做好準備。 一旦所有應用程序都實現(xiàn)了需求，就將需求設置為完成。 團隊進行快速回顧以學習和適應。

Benefits from working this way

這樣工作的好處

• Transparency and cross-team collaboration
  透明度和跨團隊合作
• Smart and cost-effective
  精巧且具有成本效益
• Speed in delivering critical changes on all applications
  加快在所有應用程序上交付關鍵變更的速度
• Align tech solutions and user experience
  調(diào)整技術解決方案和用戶體驗

順利過渡到這種工作方式的先決條件是什么？ (What are the prerequisites for a smooth transition to this way of working?)

Stakeholder alignmentWhen delivering software, we deliver something the customer needs, that is technically feasible and sustainable and that works for the business. So why is there still so much politics involved? Most commonly due to team or product bonuses which leads to misalignment, endless discussions and incorrect priorities. Bonuses should only be based on total company success. This makes the decisions easier and everyone working towards one common, unified goal.

與利益相關者保持一致在交付軟件時，我們交付客戶需要的，技術上可行且可持續(xù)且對企業(yè)有效的東西。 那么為什么還涉及這么多的政治？ 最常見的是由于團隊或產(chǎn)品的獎金而導致的偏差，無休止的討論和不正確的優(yōu)先級。 獎金僅應基于公司的整體成功。 這使決策更加容易，每個人都朝著一個共同的統(tǒng)一目標努力。

We are in this togetherCompany culture must be about the best for the company in totality. You get rewarded when you work for the best sustainable solution for the whole organization. There are, of course, times where speed is more important than quality, for example when performing proof-of-concept, to allow for early feedback, but then once you know you are building the right thing we need to take a step back and look at the best solution for the company.

我們在一起，公司文化必須對公司整體而言是最好的。 當您為整個組織尋求最佳的可持續(xù)解決方案時，您將獲得獎勵。 當然，在某些時候，速度比質(zhì)量更重要，例如在進行概念驗證時，可以及早反饋，但是一旦您知道要構建正確的東西，我們就需要退后一步，為公司尋找最佳解決方案。

Team missionTeams want to know they are working on creating value, they want to be proud of what they are developing, they want to work smart and rest assured that they are contributing to the overall organization in the best way possible. Contribution to the bigger picture has to be part of the culture and be part of each teams mission statement, cross-team collaboration should be noticed and rewarded.

團隊使命團隊希望知道他們正在努力創(chuàng)造價值，他們?yōu)樽约旱陌l(fā)展感到自豪，他們想要聰明地工作，并放心他們以最佳方式為整個組織做出了貢獻。 對大局的貢獻必須是文化的一部分，也是每個團隊使命宣言的一部分，跨團隊的合作應引起注意和獎勵。

Let data and learning lead the decisionsThe challenge with working across teams is that more people are involved which leads to more opinions and ultimately to longer lead times. But with an agile mindset, basing the decisions on data and learning, it shouldn’t have to end up with endless discussions. The requirement that brings highest value is the one we work on first and the team that will tackle the initial solution is the team that is most fit to do so at that moment in time.

讓數(shù)據(jù)和學習來領導決策跨團隊工作所面臨的挑戰(zhàn)是，需要更多的人參與，這將導致更多的意見并最終導致更長的交付時間。 但是，基于敏捷的思維方式，將決策基于數(shù)據(jù)和學習，就不必結束無休止的討論了。 帶來最高價值的要求是我們首先致力于的，而解決初始解決方案的團隊是當時最適合這樣做的團隊。

It’s important to clarify, that not everything is a common requirement. Your organization needs to decide what is and what is not; it should only be treated as a common requirement if it brings value by analyzing and delivering them in a cross-team collaborative way.

需要澄清的是，并不是所有的東西都是一個共同的要求。 您的組織需要決定什么是什么，什么不是。 只有通過以跨團隊協(xié)作的方式分析和交付價值來帶來價值時，才應將其視為一項共同需求。

我很想聽聽你的故事 (I would love to hear your story)

If you have faced or are facing a similar challenge, I would love to hear your story.

如果您面臨或正面臨類似的挑戰(zhàn)，我很想聽聽您的故事。

翻譯自: https://medium.com/@wiveka.goransson/generic-requirements-challenges-and-opportunities-9ec8c712840a

軟件需求規(guī)格說明書通用模版

總結

以上是生活随笔為你收集整理的软件需求规格说明书通用模版_通用需求挑战和机遇的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。