Requirement Specification vs User Stories • Dave Farley • GOTO 2023

Подписаться 1 млн

Просмотров 4,5 тыс.

50% 1

We’re so pleased to having teamed up with Dave Farley, author of “Continuous Delivery” and frequent GOTO Conferences speaker, for a monthly video series featuring ideas about continuous delivery, DevOps, test-driven development, BDD, software engineering and software development in general.
Find plenty more from Dave on his ‪@ContinuousDelivery‬ channel.
Dave Farley - Continuous Delivery & DevOps Pioneer, Award-winning Author, Founder & Director of Continuous Delivery Ltd.
ABSTRACT
What are software requirements and how do they relate to user stories? Is it requirement vs user story, or user story as requirement? An important part of agile software development is its user or customer focus. Our aim as software developers is to deliver outcomes that our users want or need. To do that it is vital to focus our work on the outcomes that matter to our users. Actually, this is true of any software development, agile or not. Requirements are often used to define the steps to deliver a solution, this is a big mistake. Deciding what our system needs to do is a difficult problem. Designing software well is a difficult problem too. We should avoid trying to solve these two difficult problems together in a single step, by conflating requirements with design.
In this episode, Dave Farley, author of “Continuous Delivery” and “Modern Software Engineering” explores what makes good requirements and how user stories help to improve the quality of requirements whatever the nature of our software development.
CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses
bit.ly/DFTraining
RECOMMENDED BOOKS & LINKS
You can grab Dave Farley's new book 'Continuous Delivery Pipelines' here:
leanpub.com/cd...
David Farley • Modern Software Engineering • amzn.to/3GI468M
Dave Farley & Jez Humble • Continuous Delivery • amzn.to/3ocIHwd
Forsgren, Humble & Kim • Accelerate • amzn.to/367RI5o
/ gotocon
/ goto-
/ gotoconferences
#GOTOxDaveFarley #Scale #Programming #DaveFarley #GOTO #GOTOcon #ContinuousDelivery #Complexity #ProgrammingTutorial #SoftwareEngineering #UserStories #RequirementSpecification
DAVE'S LINKS
www.continuous...
/ davefarley77
www.davefarley.net
Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket at gotopia.tech
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
www.youtube.co...

Опубликовано:

3 окт 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 8

@xorfive Год назад

I feel this talk is missing sufficient discussion on how the user stories are translated into design. A story isn't enough to hand over to a team for implementing. Agile often glosses over or skips the essential step of software design. Design can't just be quickly hashed out at the beginning of a sprint. There are often large architectural requirements that must be met (the whole system must follow certain patterns). Agile doesn't really address these. IMHO until agile acknowleges the missing design step, it's not a complete and functional methodology.

@markwalker3484 Год назад

This observation about the misunderstanding of agile as mandating no design is addressed in: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-UzFpFQgeEyc.html

@philippeparisot6061 Год назад

A team can create design/implementation specs AFTER the US is handed off to them, trust the team, they're trained engineers EDIT: Agile isn't all scrum, you're definition of Agile = sprints is incorrect. The team can totally look at implementation only one US at a time when the team (or part of the team) is ready to implement said US.

@M0rd7ust Год назад

A user story isn't even a handover artifact to "a team for implementing". It's a promise for conversation(s) around the sense as described in the story. Design is an ongoing process, anyway. It's also typically rather specific to the tools used, so "agile" cannot and will not tell you exactly how to design. You'll find about TDD (smaller scale typically) and DDD (for scaling up) if you're interested, though.

@philippeparisot6061 Год назад

@@M0rd7ust okay so you're not aware of BDD? Teams can create their technical tasks in their own time from a user story written in BDD format. I'm surprised you didn't mention this even though you clearly stated TDD and DDD. Look up BDD "three amigos".

@PaulSebastianM Год назад

I think lots of PMs might be triggered or feel outright insulted if they heard this. 😂

@diomepa2100 11 месяцев назад

I would very much disagree that it's a software developer job to extract what the client/end user wants or needs. If PO come with request and design of hot dog birthday cake, that's what we are making, lol. If it turns out the order was hot dogs and cake, it's in the PO job title to OWN that bs product they asked for. You can't have one person make the decisions of what product should be and should do, and then pass the responsibility(blame) to the dev team which built exactly what they were told to build, but it missed the mark. And yes I know PM/PO is not agile concept, but as long as they are running the show, it's their job to figure the requirements.

@jangohemmes352 11 месяцев назад

I in turn, completely disagree with your take. Proper software development involves the developers in deciding on what the software needs. Their input is invaluable. Surely you can agree the company you used as an example would be a lot less dysfunctional if you wouldn't have a team blindly implement a hot dog birthday cake? I think it's a developer's job to own their work. They know too many valuable things to not participate in the decision making process.