I Huawei cloud DevCloud work, adhering to eat dog food culture, DevCloud team while practicing Lean Agile DevOps, and also using DevCloud tool to practice landing. And I hope that people tell their own stories, to talk about is how do DevCloud DevOps agility, so had to write "I DevCloud" series of idea, the current plan has the following elements:
[I do] needs DevCloud
[I do] estimate DevCloud
[I] do plan DevCloud
[I do] developed DevCloud
[I] do the test in DevCloud
[I] do check in DevCloud
[I do] integrated in DevCloud
[I do] delivery DevCloud
... ...
The use of "I DevCloud" as the theme of the series has two meanings:
• First, DevCloud is the author of the team, so I'll write about DevCloud team is how to do these activities;
• Second, DevCloud is the author of DevOps team where development platform tool chain, so I will describe how to perform these activities on DevCloud.
It should be noted:
• These practices, DevCloud team in practice, it has some exemplary;
• but do not have universal, each team should be based on business characteristics of their own team, the team maturity, processes and methodology of interpretation, to achieve the floor;
· There are a lot of optimization of space, and there is no best practice, only for practice.
In general, software development starting from requirements gathering and analysis, we first series of articles, talked about the demand.
The traditional waterfall development model is based on three assumptions: users know exactly what they want, developers can fully understand what users say demand will not change in the development process.
But in fact these three assumptions do not exist, do it after the needs of communication products, often as a cake in the figure below (laugh without words)
Our user stories to describe demand
Wikipedia says, the purpose of the user story is faster, less consumption to cope with the rapidly changing demands of the real world.
In DevCloud, we are in the form of user stories to record demand. Huawei also used in the past in the form of requirements specifications and use cases, but this way is very tedious, error-prone and time-consuming to write, and speak the truth no one wants to read.
The benefits of using user story is:
• User Stories emphasize dialogue rather than written communication
• The story easier to understand customers and developers
• User Stories moderate size, suitable for iteration plan
• User Stories encourage important thing to do first
• Encourage postpone decisions, consider the details delayed
• Support the development and change with the needs of
The story will focus on the user convert documents from the past to a more practical dialogue, comprehensive documentation of course looks beautiful, but time-consuming and no one to see. Instead, in order to get through the demand to communicate with customers to clarify requirements through collaboration with the user to confirm the demand by frequent releases.
User stories are usually expressed in the following format:
As a <Role>, I want to <Activity>, so that <Business Value>.
As a <character>, I want <event> in order to <commercial value>.
Three-user stories, starting core description of the problem from the perspective of the user, the user's position to think.
Good user story in question is whom do and how to do, not just what to do. As the Who, I want to What, in order to Why. With the Who, Why, What information, How to get ready to come out.
We used to write up on demand, often noted is What (do), but ignored the Who (for whom) and Why (Why do).
The Who-Why-How-What logic model, also happens to affect the structure of the map, on the effects of maps, we look for opportunities to talk alone.
DevCloud support the work item template in Settings -> Project Settings, you can see how the user's three-story, preset in Story work item template, the user can also define their own descriptive information as needed.
We follow the principle of Ron Jeffries proposed 3C
About user stories, Ron Jeffries with 3 C to describe it:
• Card, cards, we use stickers or workshop card written in written user story, then entered into DevCloud become a work item, can be a way to show the card, list or tree structure. Record card on behalf of demand rather than demand, detailed demand content can be expressed in other documents.
• Conversation, the process of discussing proposals are face to face, if you are like members of the DevCloud same geographically distributed, can be (Huawei internal use eSpace, can be voice, video can also chat) over the phone or IM tool, will be an important conclusion in discussing the work item write functions provided in a simple discussion can be carried out directly by the discussion of work items. But keep in mind that the discussion of the text can never replace face to face communication or telephone.
• Confirmation, confirmed that the user does not have the contractual nature of the story, Validation Highlights agreement is based on tests, to verify the user story meets user expectations. In writing user stories workshop, the authentication information can be written on the back story of the card, and then enter the work item. For each test point should be turned into a complete test case, we use DevCloud cloud measurement modules, some of the specific follow-up tests will I do [testing] in DevCloud described in the article. Test cases will be associated with the demand, thus perfectly combine 3C.
Card is to show the form of user stories, we will switch to card view mode iteration, status update is done by dragging the card.
The discussion is to communicate the way, do not let the discussion evaporate during the discussion is the biggest waste of a large amount of information is then lost out; we usually discuss the results recorded in a comment Story work item, or directly in the comments discuss and inform others with @.
Is a way to confirm acceptance, acceptance of information can fill in a description, or you can add a property to complete the field in the template Story work item in the project settings, different specific implementation, and achieve very flexible, so I did not do into pre-project template.
A user story work item, is in fact a demand for entry to entry in the form of a card or show, and can be associated multi-faceted.
• Acceptance of information generated by the test case, will be linked to work items "associated with the use case" in the.
• useful information in the process of dialogue and communication will be generated by Wiki (knowledge sharing), Docman (document collaboration) to save, and can be associated Story work item.
• You can also add an existing file as an attachment work item.
How to create and collect stories?
There are usually several ways to create and collect user stories, of which the first two are most often adopted:
• user interviews
• story writing workshop
• Questionnaire
• Observed
Key user interviews is to find the real user, so the user before the user is a portrait of the interview, which is the process of finding the Who.
"You really develop what I call the function, but it's not really what I want", users often do not know or difficult to accurately express what you want, so the need to communicate frequently, need to be confirmed holding different stages of the product ;
Speaker proffering, will own subjective judgment? Speaker determination, the listener not, will not miss the keywords? Empathy is easier said than done is difficult.
User story writing workshop is to capture the needs of the most effective way, the principle is: Priority quantity rather than quality of priority, encourage everyone output without going to judge the quality of a story; depth rather than breadth-first priority, first a way to go pass, rather than jump on the middle fork in the road.
What users are most likely to do? You may do wrong? What will be confused? What information will be required?
In the workshop the best use of stickers to facilitate interaction, followed by finishing to the tool platform.
Opportunity to observe real users using the product is valuable, you will find the user will never use the product the way you design.
How to split user stories
Demand usually Epic-Feature-Story hierarchically split:
• Epic is usually an important strategic move the company or a huge demand, such as electricity providers to do a website is a Epic.
• Feature usually under the Epic, the user valuable features, users can meet their needs through the use of properties. For example, "electricity supplier site" and "store network search function", features that are often sustained delivery through multiple iterations.
• Story is usually a function of the segment user scenarios, and can be completed in one iteration, Story usually need to meet INVEST principles: Independent independent, Neogociable be discussed, Valuable customer / user value, Estimatable estimable small small, testable testable.
• Story can continue to split into Task, Task is the implementation level, without the need to follow INVEST principles.
Strategy, functions, requirements, tasks, etc. are difficult to categorize in a specific project, or you can simply by month, week, day, hour judged as a unit, usually a Epic Release may span multiple delivery across multiple Feature a Sprint, Sprint Story complete in a rather short Task more usually up to the order of days to hours.
It can be split from Epic-Feature-Story in the project planning in the form of a mind map at a glance.
The same can also be Epic or Feature view, to show the relationship between a tree and split.
Non-functional requirements and technical needs of the class
NonFunctional Requirement, non-functional requirements are often key product / project success or failure is determined, but often easily overlooked.
When the lack of too many non-functional requirements, it is saddled with technical debt, we need to clean technologies through regular class activities.
Typical non-functional requirements include: performance, portability, scalability, availability, ease of use, maintainability, reusability, maneuverability, safety, capacity and so on.
Examples of technical requirements include class: reconstruction, building sustained delivery lines, test automation activities, environmental maintenance and construction, architecture transformation.
We do not have a preset non-functional requirements and technical needs of the class as a separate work item type, item type do not want to work too expansion increases the complexity of use.
Can add fields to identify different types of needs, the better way is to use the Tag label.
Make good use of the combination of tags and filters, can achieve very powerful, tips on using filters, we can open a single topic for discussion.
How Bad Smell bad taste to identify the user story
As low-quality code will be Bad Smell, user stories too have bad taste:
• If you find dozens of pages of hundreds piled in demand in the Product Backlog
• If you find that the demand submitted by the people you communicate through it all, one day suddenly found that demand was realized
• If you find that ranked in the Product Backlog middle and posterior segment of user stories too detailed
• If you find that you depend Product Backlog electronic system, rather than face to face communication
• If you find that story looks like a user requirements specification
• If you find that the target user can not tell the story and bring value
• If you find it difficult to prioritize as many stories (not low high school, but only order)
• If you find that indeed affect the story as a whole between
Some scattered suggestions for user stories
• Demand points have time, ask one more question, "When do you need?", You tend to find each other in fact, I did not count, ASAP is not a good answer, the sooner the better only show mistrust. Although there will be concerns, I still truthfully say, "This function associated with an activity after a month, before this can be achieved, but the need to set aside time to give me a week to verify and repair."
• When the story of prioritizing the need to consider the cost, an important requirement, it may be delayed because of high cost, another approach is to be split.
• Do not worry added to the user story details, follow the last responsible moment raised by Kent Beck (Last Responsible Moment) principle, the details have to wait until the team wrote properties before the start of realization of software features. Prioritization, short, medium, long-term needs of the degree of detail.
• Paper card / sticker, or electronic tools? In the early requirements gathering and guidance, such as writing requirements workshop recommended paper cards, to facilitate interaction and limited text space card guarantee we will not get into the details too early. When the requirements gathering ended, the entry requirements to DevCloud unified platform, demand is not just one dimension Card, multi-faceted information need tools and platform to support the record. While also providing a platform for collaboration between team members, DevCloud remote team collaboration scenario is based on the platform of DevCloud.
summary
The story is speaking out, not written out; the purpose of the story is to stimulate communication spark, user stories story was called, because he had to say rather than write, communication, collaboration and ultimately deliver good demand.
DevCloud demand is not the best practice, but to adapt our own team and compromise choice for product / project situation.
This article does not seek exhaustive presentation point about the requirements and user stories, if you have questions related to requirements, please leave a message to me, I will focus on the answer.
Reproduced in: https: //www.jianshu.com/p/62188de9b18d