But what do you mean with workflow here? How the code works on a given task, i.e. the program logic?
Or are we talking more organizationally, so how the development team works together in respect to Git, bug tracking, documentation etc.?
Or more practically: Sometimes my product owner person will go a bit cray-cray and say that I should put something into Confluence. And then I don’t do that, because Confluence is garbage and well, it’s not like they’ll ever find out, if it’s in Confluence or not. No one ever finds anything in Confluence anyways.
Maybe Confluence could be salvaged, if I wanted to use it, but none of the devs look in there, so it’s effectively /dev/null. I may as well just not document it at all. Or rather document it in a place that people actually check.
There are frameworks for this but not actual flows. As @Ephera said, you need to use what works best for the team. So what make an assumption, suggest it to the team and give it a try, if it works, keep doing it, if it does not, try fix or improving it until you find out what works best for you.
You need these elements in almost all projects
Global architectural design
Systems design
WBS (Work Breakdown Structure)
Ticketing system where an issue is an atomic non divisible task
Set of status for each issue
Definition of done
RACI matrix
Daily meetings
Some rules or guidelines to describe quality of code, the stack, techniques, how to chose and add dependencies, etc. Lint and SAST, static analysis, etc. fall in here.
deleted by creator
But what do you mean with workflow here? How the code works on a given task, i.e. the program logic?
Or are we talking more organizationally, so how the development team works together in respect to Git, bug tracking, documentation etc.?
deleted by creator
Well, I don’t think you should design that. The team knows best how it works together most effectively. Let them discuss these points.
If you want raw theory on that, there’s this: https://en.wikipedia.org/wiki/Tuckman’s_stages_of_group_development
TL;DR: Any team necessarily needs to go through certain stages. You can’t skip them by e.g. designing a workflow for them.
Or more practically: Sometimes my product owner person will go a bit cray-cray and say that I should put something into Confluence. And then I don’t do that, because Confluence is garbage and well, it’s not like they’ll ever find out, if it’s in Confluence or not. No one ever finds anything in Confluence anyways.
Maybe Confluence could be salvaged, if I wanted to use it, but none of the devs look in there, so it’s effectively /dev/null. I may as well just not document it at all. Or rather document it in a place that people actually check.
There are frameworks for this but not actual flows. As @Ephera said, you need to use what works best for the team. So what make an assumption, suggest it to the team and give it a try, if it works, keep doing it, if it does not, try fix or improving it until you find out what works best for you.
You need these elements in almost all projects