Story points are unique to the team that is doing the work. Basically, a 21 point story for me could be a 3 point story for you.
In of themselves, the points are not important. Just size the stories to some amount of points that is reasonable and then do a sprint. The objective is to get a sense of how much work can be done in a sprint, to help create forecasts of when work will be completed.
At this point, it’s the JVM that is the real value, not the language itself. It would be better if they started to emphasize that more.
0.0.0.0/0
::
What is a “full stack”
My problem is that there are a lot of layers beyond just the “front end, web/REST, database” layers that most people refer to, that are involved with delivering an application.
Like, do you know Angular and also BGP?
Probably not. So, it’s impossible to truly be “full stack” so you’re going need to actually define what everyone is supposed to be responsible for knowing, and also recognize that there are going to be folks that are strong in some areas and other areas less so. Plan accordingly
I’ve been using ConcourseCI because another team manages it and it is integrates with Hashicorp vault.
It’s good. The big advantage is I don’t have to deal with maintaining it.
The downside is their story on GitHub integration is kind of crummy, you have to create your own web hooks because our ConcourseCI instance is too busy for poll based resource checks.
I think it’s YAML.
I’m not happy that it’s YAML but it’s become ubiquitous. Sure, there are lots of other formats that others have mentioned, but I’m sorry most of them are positioned as “it’s better than YAML!” and the fact that everyone is mentioning YAML, even if it’s about the things it does wrong (and boy does it do things wrong) still means that YAML is on everyone’s mind.
It’s very important, so that everyone knows that they are talking about the same thing.
Like, everyone needs to just agree to use the same term, while also not getting into bike shedding around which term to choose.
Your QA team should be building automated regression tests and automating their tests so that they can be run locally as part of the development cycle or as a job in your CI system.
That would decouple this incredibly tight release cycle that you currently have
“How do you know the code you wrote works correctly if there is no test that exercises it?”
Jitsi seemed okay to me
I went through a phase where I dove deep on the internals of the CLR runtime for C# and there’s a great book on the subject. Might need to find an equivalent for the JVM.
I know the garbage collection part of the runtime has had lots and lots and lots of research and papers and study