|
CPColin posted:I mean, for a certain value of "shouldn't," that's kind of true. On an ideal team, everybody should be able to handle every ticket and everybody should come to similar values when estimating their points. In the real world, yeah, you're pretty sure the team member who implemented Feature X is going to have a couple of sprints where they get assigned all the Feature X bugs. There are 3 of us on the team, and wildly different technologies behind 10 or so different moving components. There is C++, Python, Django, Ruby, Java, and some Node.JS. The C++ is the biggest and oldest beast, and I am unfamiliar with the codebase of around 400,000 lines. At the same time, I can handle the Python, Django, and Ruby. I was assigned a ticket that would take the team lead around 8 points (4 points per day) to track down a bug in the C++ code and write a test to fix it. I'm all for fixing the bug, but 8 points is the dumbest thing, and when I brought it up to him that when we assigned the ticket those points, I was under the assumption he was going to work on that ticket.
|
#
?
Jan 23, 2020 17:35
|
|
|
|
| # ? May 16, 2024 20:58 |
|
|
Tei posted:I don't know what is this point value system for? care to elaborate or point me somewhere? On our team, 4 points == 1 day of work. It's arbitrary.
|
|
#
?
Jan 23, 2020 17:36
|
|
|
Apparently there is a functioning fork of JUCE that can be transpiled to javascript with emscripten, and as someone who briefly had to work on making a C++ file format library work with emscripten for a web proof-of-concept I think that sounds like a horrible time for everyone involved. Possibly a less horrible time than writing a native reimplementation of all that audio synthy stuff, but a horrible time nevertheless.
|
|
#
?
Jan 23, 2020 17:41
|
|
|
ratbert90 posted:On our team, 4 points == 1 day of work. Like if I solve 20 points of bugs a monday I don't have to return till the next week? I still have no idea what this point system is about Is to calculate the productivity of people solving bugs? Is to fire people that is not productive? Theres two ways to fix most bugs and the faster one is 90% the worst option. A system that push people to fix bugs has fast has possible has to create a horrible codebase made entirely of workarounds
|
|
#
?
Jan 23, 2020 17:48
|
|
|
It's a metric for a manager to be able to say 'this set of tasks will take about x days to complete'. They've heard often enough that it's very hard to estimate with accuracy how long software development tasks will take, so rather than asking people to estimate how LONG anything will take, they ask how many POINTS it is of effort... and then translate those points exactly to a timespan anyways.
|
|
#
?
Jan 23, 2020 17:54
|
|
|
At it's best it's supposed to help allocate work in a way that lets everyone on the team be more productive. Sally can handle 20 points this week, while Bob is working on something else as well and can only handle 10 points this week. If we determine that we have 40 points of work, something will have to wait until next week. It almost never works out this way.
|
|
#
?
Jan 23, 2020 17:54
|
|
|
Tei posted:Like if I solve 20 points of bugs a monday I don't have to return till the next week? Well hey there partner. Let me tell you about the wonderful world of AGILE DEVELOPMENT AND DUMB loving METRICS. Hargrimm posted:It's a metric for a manager to be able to say 'this set of tasks will take about x days to complete'. They've heard often enough that it's very hard to estimate with accuracy how long software development tasks will take, so rather than asking people to estimate how LONG anything will take, they ask how many POINTS it is of effort... and then translate those points exactly to a timespan anyways. This.
|
|
#
?
Jan 23, 2020 17:55
|
|
|
ratbert90 posted:Except in some very rare cases, with C++ >= 14 you shouldn't manage memory. Using std::unique_ptr and std::shared_ptr does not mean that you're "not managing memory." Those are tools to manage memory, which make it easier to write code that explicitly defines lifetime and ownership and avoid mistakes, and they're extremely useful, but saying "you don't need to manage memory in C++ >= 14" is the same as saying "you don't need to manage memory in mark-and-sweep GC'd languages". Of course you do, you just use different tools to do it. If you don't understand how new and delete work and scope/lifetime/ownership, you're going to have just as nasty bugs using smart pointers (because you're going to use them wrong)
|
|
#
?
Jan 23, 2020 17:56
|
|
|
ratbert90 posted:The C++ is the biggest and oldest beast, and I am unfamiliar with the codebase of around 400,000 lines. ratbert90 posted:On our team, 4 points == 1 day of work. I'm sure you know this already, but both of these are indicators that the current process is a bad fit for your team. Estimating points is meaningless when you have to know/assume who will get the tickets ahead of time. Having a team be responsible for features that some team members are unfamiliar with is just asking for trouble. Equating (story) points with estimated time is just enabling management to butt in. Again, I'm sure you know this already, but if somebody is imposing this process on you and calling it "Scrum," they're wrong. At my previous job, they gave us a week of Scrum training and then told us that was how it was going to be. We'd spend the usual four hours doing backlog refinement and sprint planning, then each go into our separate offices and work on stuff in our separate silos. It was stupid and wasteful. I left for my current job after only four months.
|
|
#
?
Jan 23, 2020 17:56
|
|
|
CPColin posted:I'm sure you know this already, but both of these are indicators that the current process is a bad fit for your team. Estimating points is meaningless when you have to know/assume who will get the tickets ahead of time. Having a team be responsible for features that some team members are unfamiliar with is just asking for trouble. Equating (story) points with estimated time is just enabling management to butt in. Yeah, you are preaching to the choir right now my dude and I completely 100% agree with you. I am seriously thinking about looking for full-time WFH again. I miss it so much. Edit* My team lead also thinks it's perfectly fine to require merge requests for all branches except for RC branches for some reason. FlapYoJacks fucked around with this message at 18:00 on Jan 23, 2020 |
|
#
?
Jan 23, 2020 17:57
|
|
|
Too many estimates! Estimates on time, estimates on complexity... *puts hand on your shoulder, looks intently into your eyes, lowers voice to an urgent whisper* No estimates.
|
|
#
?
Jan 23, 2020 18:13
|
|
|
Doc Hawkins posted:Too many estimates! Estimates on time, estimates on complexity... Chris Roberts has had great success with the "no estimates, only dreams" method in Star Citizen.
|
|
#
?
Jan 23, 2020 18:20
|
|
|
ratbert90 posted:My team lead just tried to tell me that you shouldn't have the expectation of who get's what tickets beforehand before they get assigned a point value. You're supposed to point them with the entire team and any disparities worked out?
|
|
#
?
Jan 23, 2020 18:22
|
|
|
The Fool posted:At it's best it's supposed to help allocate work in a way that lets everyone on the team be more productive. Thanks for your answer it reminds me one time I tried to measure a task difficulty in points, it died quickly has they wanted to translate it into hours
|
|
#
?
Jan 23, 2020 18:30
|
|
|
|
|
#
?
Jan 23, 2020 18:33
|
|
|
Ola posted:
If you select any of the first 3, the requirements will change magically and then you will get complaints it's taking too long.
|
|
#
?
Jan 23, 2020 18:36
|
|
|
To be honest the harder task are these that are poorly defined in a domain that is new for everyone. I work on a small company where sometimes we choose to do things on the unkwown, like develop software in java or male a phone app. These things require time to do + time to learn how to do it + build the en enviroment
|
|
#
?
Jan 23, 2020 18:40
|
|
|
Tei posted:To be honest the harder task are these that are poorly defined in a domain that is new for everyone. Ideally the task should be as broken down and as detailed as it needs to for an accurate estimate of work to be made. It never happens in practice, of course. But to your problem: research tasks are a thing, and they can be time delimited: "this week Bob is learning how to create an Android app to the best of his abilities". Next week, hopefully Bob can do a better job of breaking down the Android app tasks and estimating them. And the week after, Bob will be fixing all the bugs that were found in the lovely code he wrote.
|
|
#
?
Jan 23, 2020 18:49
|
|
|
Ola posted:
https://www.youtube.com/watch?v=NpYEJx7PkWE
|
|
#
?
Jan 23, 2020 18:52
|
|
|
ratbert90 posted:On our team, 4 points == 1 day of work. lol there's ur problem
|
|
#
?
Jan 23, 2020 19:06
|
|
|
also, that's not even a fibonacci number
|
|
#
?
Jan 23, 2020 19:08
|
|
|
If you’re not gathering your whole team around a hooker, grabbing each other’s butts, and pushing until you all fall over in the mud, you’re not doing scrum properly
|
|
#
?
Jan 23, 2020 19:17
|
|
|
I used to give stories four points to try to irritate the Scrum Master enough that they'd end the meeting. Good times.
|
|
#
?
Jan 23, 2020 19:22
|
|
|
JawnV6 posted:lol there's ur problem Let's check in w/ Goodhart "When a measure becomes a target, it ceases to be a good measure."
|
|
#
?
Jan 23, 2020 19:29
|
|
|
JawnV6 posted:Really though, you shouldn't be pointing based on who gets the ticket. It's an artifact of the lovely points=days equivalence that's pushing you to do it. Preaching to the choir again.
|
|
#
?
Jan 23, 2020 19:34
|
|
|
ratbert90 posted:Preaching to the choir again. I can be quoting your story for the benefit of posters like Tei who seem unfamiliar with Agile going off the rails like this.
|
|
#
?
Jan 23, 2020 19:38
|
|
|
ratbert90 posted:My team lead just tried to tell me that you shouldn't have the expectation of who get's what tickets beforehand before they get assigned a point value.
|
|
#
?
Jan 23, 2020 19:41
|
|
|
JawnV6 posted:I can be quoting your story for the benefit of posters like Tei who seem unfamiliar with Agile going off the rails like this. Yea, I am thankfull of all experiences. Living in a small company mean I don't know how the other 99% of software developers work
|
|
#
?
Jan 23, 2020 19:54
|
|
|
JawnV6 posted:I can be quoting your story for the benefit of posters like Tei who seem unfamiliar with Agile going off the rails like this. Tei posted:Yea, I am thankfull of all experiences. Agile can be good for specific things. This is not that specific thing.
|
|
#
?
Jan 23, 2020 19:56
|
|
|
CPColin posted:Again, I'm sure you know this already, but if somebody is imposing this process on you and calling it "Scrum," they're wrong. ah yes, "Scrum" works but any time it doesnt work its actually "Not Real Scrum" so it doesnt count
|
|
#
?
Jan 23, 2020 20:51
|
|
|
That's neither what I said nor what I meant.
|
|
#
?
Jan 23, 2020 20:57
|
|
|
Story estimation is a way to reveal whether or not the whole team agrees on what needs to be done and has given at least a little thought to how to do it. For forecasting when something can be done, you can often ignore the estimate and just go based on the total number of stories (though this requires that the stories be written in good faith, as small as possible while still being complete. And it takes months before you have enough information to base the forecast off of). A lot of managers don't like being told that they can't have everything they want, so a lot of bullshit has been invented as a way to trick them into thinking they're getting it.
|
|
#
?
Jan 23, 2020 21:24
|
|
|
more falafel please posted:Using std::unique_ptr and std::shared_ptr does not mean that you're "not managing memory." Agreeing with this. One of the nastiest C++ bugs I ran into was caused by passing a lambda which captured this, but sometimes the struct passing the lambda would get moved before the lambda was called, thereby invalidating the captured this pointer. Smart pointers are great and I used them religiously, but you still have to worry about memory management even when using them.
|
|
#
?
Jan 23, 2020 22:00
|
|
|
ratbert90 posted:Agile can be good for specific things. When your manager who does not work directly on the product defines your team's process as agile, you are no longer agile.
|
|
#
?
Jan 23, 2020 22:45
|
|
|
more falafel please posted:Using std::unique_ptr and std::shared_ptr does not mean that you're "not managing memory." Those are tools to manage memory, which make it easier to write code that explicitly defines lifetime and ownership and avoid mistakes, and they're extremely useful, but saying "you don't need to manage memory in C++ >= 14" is the same as saying "you don't need to manage memory in mark-and-sweep GC'd languages". Of course you do, you just use different tools to do it. If you don't understand how new and delete work and scope/lifetime/ownership, you're going to have just as nasty bugs using smart pointers (because you're going to use them wrong) This just seems like semantic quibbling, I don't think that poster meant "I never have to think about memory again" but rather "smart pointers make memory management trivial in most cases". C++ still gives you the tools to make a big mess if you don't know what you're doing and don't care to learn, that's like... that language's mantra or something
|
|
#
?
Jan 23, 2020 22:59
|
|
|
Story: As a Product Manager, I would like it so that whenever I open the app, I see Feature that has been requested by sales team.
|
|
#
?
Jan 23, 2020 23:09
|
|
|
Story points are because people suck at deadlines and time estimates. If you can trick people into not thinking about deadlines and time estimates, you can figure out when they'll be done without them freaking out. You can do this with little pain and not much overhead from everyone involved. Or you can say that one medium t-shirt equals six Alice hours and continue dicking around for two weeks because hey, we have a whole month to get this done, leave me alone!
|
|
#
?
Jan 24, 2020 03:42
|
|
|
The idea is that they become more useful over time. So you estimate in story points consistently as a measure of the task's "complexity". Then after a few sprints you can start to get an idea of how quickly tasks of X complexity can be completed and what the story point capacity for the team is over a sprint. Of course, then you end up with some managers who just treat it as X points = Y hours and the whole effort is wasted and you may as well just go back to estimating hours like a chump.
|
|
#
?
Jan 24, 2020 04:53
|
|
|
Sprints are bad because they are deadlines and the whole point is to stop with the deadlines. Absolute estimates are also deadlines and therefore bad.
|
|
#
?
Jan 24, 2020 06:01
|
|
|
|
| # ? May 16, 2024 20:58 |
|
|
pokeyman posted:Sprints are bad because they are deadlines and the whole point is to stop with the deadlines. Absolute estimates are also deadlines and therefore bad. Sprints aren't supposed to be deadlines. They're supposed to be small blocks of time that help you measure what got done and estimate what might be possible during the next sprint. A fixed deadline might be necessary to a project, but it has no business being defined in a sprint.
|
|
#
?
Jan 24, 2020 06:18
|
|
