submitted 6 months ago* (last edited 6 months ago) by Lysergid@lemmy.ml to c/programming@beehaw.org

6 comments fedilink hide all child comments

Hello my fellow, lemons? I have this problem in my current project I’m out of clue how to approach it. Maybe someone had similar experience and can give an advice.

Our requirements captured in JIRA. Throughout years we accumulated thousands of user stories. Say suppose following naive requirements team knows about:

Day 1: create home page
Day 20: create profile page
Day 50: add green footer to all pages
Day 100: create admin page Day 150: change footer color to blue

Now I’m doing refactoring (yes, I know, this is the actual problem) on day 400 and noticed that footer on profile page having green footer. Because requirements are just set of individual statements not consolidated with all history of system no one on the team knows why is that, is it bug or requirement did change on day 300 but we cant find it now.

When I worked in Waterfall we had BRD and FRD stating current actual desired state of system which was “reduced” from individual requirements which were coming in throughout project life. When in doubt devs can check FRD and not only know how system expected to behave but also which are other parts of the system that will be affected. How is it in Agile? To my understanding FRD is not a thing in Agile. Do I need to scan through hundreds of tickets and hope I didn’t miss anything every time i’m doing any non-trivial change to system?

you are viewing a single comment's thread
view the rest of the comments

[-] MagicShel@programming.dev 7 points 6 months ago* (last edited 6 months ago)

The way I've dealt with this before is reference the ticket number in the commit message. Now the only tickets you ever need to review are the ones relevant to the element in question, and only those creating or modifying that particular property, which should be evident in your commit log.

You don't specify a language but I'd assume that is the footer definition/html and any scripts or styles invoked by it.

But once you have an answer, it would be wise to document it in confluence somewhere, even if it's something like "Footer green per request from Director, Mr. Smith" or "Footer color: arbitrary, green to differentiate profile pages. Verify changes with Director."

How to organize the documentation so that it isn't difficult to navigate is another difficult question that is more art than science - one which has never been satisfactorily solved anywhere I've worked once complexity reaches a certain point, but I leave that exercise to the reader.

this post was submitted on 25 Jun 2024

10 points (100.0% liked)

Programming

13405 readers

2 users here now

All things programming and coding related. Subcommunity of Technology.

This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.

founded 2 years ago

MODERATORS

alyaza@beehaw.org

Hexorg@beehaw.org

remington@beehaw.org