A user story is one or more sentences in the everyday or business language of the end user that captures what the user wants to achieve. For e.g.
As a front desk representative, I would like to make a room reservation quickly.
As you can see they are
From the user/role (front desk representative) perspective
Goal oriented (make a room reservation quickly)
But they lack details like various flows (payment etc), acceptance criteria, non-functional requirement specific (what does quickly mean in the e.g. story?). You create sub-stories to provide more details.
Are there tools that can guide you how to convert the idea of web app (or mobile app) into a list of stories/iterations in a successful way?
Tools like Rally and JIRA allow you to organize stories, sub-stories, sprints/iterations etc.
Some kind of visual representation of states, features or functions (and its relationships) where you can specified functional, non-functinal and technical specs, so after that you can create stories?
These tools provide rich text editors that help us write the stories. Sometimes you have a requirement that doesn't fit as a story
A use-case
User interface guidelines
A list of business rules etc.
Then write something else. Tools like JIRA provide provision for attachments.
so after that you can create stories?
** Stories should be the first activity that should happen. That is the whole point. It is not the after thought. Stories is the way of forcing you to think from a user and goal perspective so you are writing software to meet user goals. **
Stories represent requirements, they do not document them. - Rachel Davies
Agile approach encourages just enough architecture with continuous refactoring.
The sprint delivery team generally includes all the necessary stake holders like business analyst, tester, architect, dba, developers. They collectively are responsible completion of a story/sprint and at the end of the spring, you would have a production ready deployable application. Idea is to incrementally add features.
As you can see from the team composition architect/lead are also involved in each sprint. He, with the help of the team will architect and design just for the stories that are part of the current sprint/iteration (Just enough architecture, Emergent Design). The stories they pick for first sprint are either high risk or architecturally significant ones.
When it comes to design, mostly it is brainstorming and paper or black board based. Idea is to use code as the reference documentation as much as possible and build collective knowledge across the team by pair programming etc etc.
So you wouldn't end up with a poor quality software. You would in fact have the minimum code base that can exercise the stories (you are not accumulating code base for future requirements or nice to have features). Somewhere I read that only 40% of the features built are every used by customers.
发布评论
评论（1）
你必须在这里改变你的思维过程。
用户故事是最终用户的日常或商业语言中的一个或多个句子，它捕获了用户想要实现的目标。例如
正如您所看到的，它们是
但它们缺乏诸如各种流程（付款等）、接受标准、非功能性特定需求（快速预订房间的功能）等详细信息。例如故事中的意思？）。 您创建子故事以提供更多细节。
什么才是好故事？
投资：独立，N可协商，V有价值，E可估算，< strong>小小，可测试
是否有工具可以指导您如何将网络应用程序（或移动应用程序）的想法转换为故事列表/成功的迭代
像 Rally 和 JIRA 这样的工具可以让你组织故事、子故事、冲刺/迭代等。
状态、特性或功能（及其关系），您可以在其中指定功能、非功能和技术规格，然后您可以创建故事？
这些工具提供了富文本编辑器，可以帮助我们编写故事。有时，您的需求不适合故事、
然后编写其他内容。 JIRA 等工具提供附件功能。
那么之后您就可以创建故事了？
** 故事应该是第一个应该发生的活动。这就是重点。这不是事后的想法。故事是迫使您从用户和目标角度思考的方式，因此您正在编写软件来满足用户目标。 **
敏捷方法鼓励足够的架构和持续重构。
冲刺交付团队通常包括所有必要的利益相关者，如业务分析师、测试人员、架构师、dba、开发人员。他们共同负责完成一个故事/冲刺，在春季结束时，您将拥有一个生产就绪的可部署应用程序。想法是逐步添加功能。
正如您从团队构成中看到的那样，架构师/领导也参与了每个冲刺。他在团队的帮助下将只针对当前冲刺/迭代中的故事进行架构和设计 (足够的架构，紧急设计）。他们为第一个冲刺选择的故事要么是高风险的，要么是具有架构意义的故事。
当谈到设计时，大多数都是基于纸或黑板的头脑风暴。想法是尽可能使用代码作为参考文档，并通过结对编程等方式在整个团队中建立集体知识。
这样你就不会得到质量低劣的软件。事实上，您将拥有可以练习这些故事的最小代码库（您不是为了未来的需求而积累代码库，也不是为了拥有功能而积累代码库）。我在某处读到，所构建的功能中只有 40% 可供客户使用。
You have to change your thought process here.
A user story is one or more sentences in the everyday or business language of the end user that captures what the user wants to achieve. For e.g.
As you can see they are
But they lack details like various flows (payment etc), acceptance criteria, non-functional requirement specific (what does quickly mean in the e.g. story?). You create sub-stories to provide more details.
What makes a good story?
INVEST : Independent, Negotiable, Valuable, Estimatable, Small, Testable
Are there tools that can guide you how to convert the idea of web app (or mobile app) into a list of stories/iterations in a successful way?
Tools like Rally and JIRA allow you to organize stories, sub-stories, sprints/iterations etc.
Some kind of visual representation of states, features or functions (and its relationships) where you can specified functional, non-functinal and technical specs, so after that you can create stories?
These tools provide rich text editors that help us write the stories. Sometimes you have a requirement that doesn't fit as a story
Then write something else. Tools like JIRA provide provision for attachments.
so after that you can create stories?
** Stories should be the first activity that should happen. That is the whole point. It is not the after thought. Stories is the way of forcing you to think from a user and goal perspective so you are writing software to meet user goals. **
Agile approach encourages just enough architecture with continuous refactoring.
The sprint delivery team generally includes all the necessary stake holders like business analyst, tester, architect, dba, developers. They collectively are responsible completion of a story/sprint and at the end of the spring, you would have a production ready deployable application. Idea is to incrementally add features.
As you can see from the team composition architect/lead are also involved in each sprint. He, with the help of the team will architect and design just for the stories that are part of the current sprint/iteration (Just enough architecture, Emergent Design). The stories they pick for first sprint are either high risk or architecturally significant ones.
When it comes to design, mostly it is brainstorming and paper or black board based. Idea is to use code as the reference documentation as much as possible and build collective knowledge across the team by pair programming etc etc.
So you wouldn't end up with a poor quality software. You would in fact have the minimum code base that can exercise the stories (you are not accumulating code base for future requirements or nice to have features). Somewhere I read that only 40% of the features built are every used by customers.