|
im using something relatively bleeding edge that doesn't have much on SO or in google results (which is usually trash anyways), and chatGPT has been useful in this project so far as well
biceps crimes fucked around with this message at 18:13 on Apr 5, 2023 |
#
?
Apr 5, 2023 00:46
|
|
|
|
| # ? May 12, 2024 18:48 |
|
|
Mega Comrade posted:Most of the code across our products sucks.  
|
|
#
?
Apr 5, 2023 03:33
|
|
|
biceps crimes posted:im using something relatively bleeding edge that doesn't have much on SO or in google results (which usually trash anyways), and chatGPT has been useful in this project so far as well I'm actually surprised and happy to hear this, I was worried Chat would become an important tool and favor old language and tools too much
|
|
#
?
Apr 5, 2023 12:58
|
|
|
How do folks (especially devops or other split-resourced groups) go about planning tasks and all that? Any good books/etc or other resources to look into? I work in a halfway ops/dev role at Some Big Tech Company. My team is running into a big deadline and we're...frankly really going to slip this one. I think there's a few major issues, but I'm not sure what the fix is; at the very least I've asked our PM to do a retrospective after the 'launch'. I'm new to software dev in general, but I've worked in IT for quite a long time, but unfortunately I think I'm missing some concepts (and definitely my team as a whole is), so trying to be helpful about this since I know that this is one of the Big Software Dev Issues you'll have to deal with forever. My team is mostly new to the org in the last year. If it helps, we work in Python and we use sprints as our main planning tool / execution cycle. Here's the stuff I can see in retrospective: - Requirements definitions are not well done at all; tasks start as single line 'this should do X' from the lead. This leads to most people never sitting down and hashing out 'what are the actual hard reqs', which in turns leads to a lot of rework and unexpected issues popping up. - The tools we're building are a suite of improvement tools that touch a lot of internal systems; I'm not sure how to go about saying 'everyone working on this project is pretty new to the ten different clients we're using and so it's hard to estimate time' - Going on from the last two: The PM was pushing really hard for people to estimate time, but frankly it was impossible to do. I started at least tracking my time spent and found that some of my estimates were off by like 2-4x. I know from past advice that this is a thing you just get better at over time, but I suspect that the last two issues are making this worse. - At least three folks on my team had never written unit tests before (and I've only been doing it for a year or so)
|
|
#
?
Apr 7, 2023 04:30
|
|
|
I'm on an internal platform team and hears a few things that work for us: 1. Only refined stories can be assigned during planning. 2. Refinement is a whole team activity, done regularly, to make sure that everyone is on the same page about what needs to be done for a given story. 3. If requirements for a story aren't clear, we do a "spike", a spikes only purpose is to identify requirements and create the necessary story(ies) 4. To handle support/unplanned work, we created placeholder stories that are pointed based on a historical average. 5. Management has to be ok with planned work slipping due to higher priority unplanned work. e: bonus number 6, We have a formalized "definition of done" which includes but is not limited to: writing documentation, writing tests, pr review The Fool fucked around with this message at 04:51 on Apr 7, 2023 |
|
#
?
Apr 7, 2023 04:49
|
|
|
Pretty much what the above thing said. I've used in the past an obstinate but very easy method to do it. Combine your first and third issue together. "The estimate for this story is 9 months, given the length of what 'should do X' means that's the only time I'm comfortable in committing that it takes." You want the Lead/PM to actually do their jobs and give you a story that can be worked on. In General: Someone needs to be writing stories. The team needs to be grooming the stories. The team can then estimate / point some set of those stories but even then not too many. Have frequent retrospectives maybe as part of planning maybe not, where you talk about why the estimate was off. Slowly get better at: Writing Stories, Recognizing Ungroomed Stories, Pushing Back on Stories, Estimating Stories, Completing Stories. There's no snake-oil to take, just effort over time. EDIT: In addition to the formalized Definition of Done, some organizations can make good work with a Definition of Ready. IE: A story is ready when: - The PO has written success criteria - The Team has agreed that no open questions remain - The Team has pointed the story in a pointing session - QA has seen the story and is ready to write a test plan etc...
|
|
#
?
Apr 7, 2023 05:16
|
|
|
Hughlander posted:There's no snake-oil to take, just effort over time. Thanks for both responses, singling this out to say - yep, didn't expect there to be a magic bullet, just curious what other folks do. I've been in the ops sort of role for a long time and I've never been on a team that managed to do this well, so unfortunately I don't have a lot of personal viewpoints to bring to this other than a general sense of 'huh I think we're doing it wrong'. I might also chat with our principal engineers in the org as well and try and get their feedback/etc.
|
|
#
?
Apr 7, 2023 06:52
|
|
|
i think i know what Big Tech Company you're at so this is entirely not an option for you, but ime the best experience in this area is to just stop doing scrum entirely sort the backlog so the topmost issues are the most important. communicate the expectation that your job as an IC is to pull the topmost issue you can work and work it until completion. you can have 1 issue in progress at any moment. if you pull an issue that can't be worked you put it in the "CantDo" column and your team lead repairs it and puts it back into "ToDo" this ends up being a large productivity booster for a variety of reasons. one of the best reasons is that the grooming and refinement rituals only happen on demand as needed (because someone pulled an issue they couldn't do, and moved it to CantDo with an explanation why). refinement and requirement seeking become async, which is good, because for split-focus teams the requirements are usually externally sourced anyway. it's a huge waste of money and motivation to have the entire team sitting on a call and agreeing that we need to follow up with someone who isn't here about ticket 123. nobody cares about that poo poo, nobody got a job in computers to fill out jira statuses. ICs are the constraint, so the project management system should largely serve them, and free up as much time as possible so that they can do their job which is to individually contribute.
|
|
#
?
Apr 7, 2023 06:57
|
|
|
Scrum is a compromised methodology. It's an attempt to be as agile as possible while operating under the constraint of management that is hostile in practice to the idea of developer autonomy. If you are doing it, it should be because you have to; if you can work how you want, you can and should do something better than scrum. Some form of kanban describes a more effective way of doing it. Write full-stack stories that are as small as you can stand them while still making the product more useful; it's possible, and desirable, to get them down to such a size that they can be finished on about the order of a day. Not everything tracked needs to be user-facing; tasks which make the team more effective are also valuable, even if they mean nothing to a user. Sort these stories in the order that you want them to be done. Work on whichever unstarted story is at the top of the stack. A visual aid for the board is useful as a rhetorical tool, since that way, all but the dimmest of stakeholders will be able to see that if you move one story to the top, every other story gets moved down. Most commercial issue tracker products are too complicated and will obfuscate the effective principles of story management, because the buyers of this software aren't the ones trying to work with it. Disable as many of its features and restrictions as you can, and turn them back on only when you identify a concrete need for them. Most teams should estimate the size of each story as a regular collaborative exercise. Size doesn't mean anything objective and nobody external should reflect on the accuracy of the estimate. The process of estimating is a trick to make sure that every developer on the team has read the story, identified and fixed any problems with it, and come to an agreement about what it actually means. If your team can do that quality control without the excuse of coming up with an estimate, then there's no need to write down a number, but in my experience most teams don't have that level of discipline. It's effective to review these on a regular schedule, but the point is to do it as often as needed to ensure that the next couple weeks of work have been reviewed. If these estimation sessions often get sidetracked with tangents, trivia, discussing solutions, or other things that make meetings miserable, that could be a sign that the stories need to be tightened up before presenting them, or it could be a sign that the team doesn't understand why they're there. As long as the stories are written in a consistent way and worked on at a consistent pace, the average duration to complete a single story will level out over time, allowing you to calculate forecasts of when any given feature will be completed. These forecasts are remarkably accurate, much better than you can get by asking a person when they think it'll be done. The problem with scrum is that the "sprint goal" concept is antithetical to the consistent pace that makes this forecasting possible; pressure to deliver more than you can comfortably sustain, including things like deadlines, distorts measurements of the team's capabilities to the point of uselessness. If you want something done sooner, increase its priority; if you want work to be done faster, improve the team's skills. The goal is to get the organization's leadership to trust that these forecasts are reliable enough for them to make their own plans against; if they have that trust, there's no legitimate reason for them to try to exert tighter control over the schedule. Stories are the basic unit of this kind of work, and everything you will be doing gets easier as the stories get better. Or, rather, the things that make a story good are anything that makes working with them easier. The most important thing about them is that everyone on the team has a shared understanding of the work they represent. They can always be changed as that understanding improves, right up to the point where they're done; but once they've been reviewed by the team, they should not be changed unilaterally. A story should ideally describe the "what" of the work entirely from the perspective of an end user. End users don't care how it works, so the story shouldn't either; leave the "how" to the developers. Provide implementation suggestions as notes on the story. In order to satisfactorily describe the "what," a story should describe how someone can tell whether it's been done or not, in a clear and objective way. The appropriate level of detail is whatever is effective for the team. Always strive to improve the quality of your stories. All of this depends on continuous feedback. If something isn't working, or if something could be better, every member of the team should be able to say so honestly, openly, and without fear, and should be able to hear things said in the same spirit. This is "psychological safety," and it's hard to attain. Above all else, remember this: Things can be better than anyone imagines. Don't take anything that sucks for granted.
|
|
#
?
Apr 7, 2023 08:02
|
|
|
12 rats tied together posted:but ime the best experience in this area is to just stop doing scrum entirely The longer I work in tech, the more I agree with this. Scrum is fundamentally about trying to make non-functional teams at least somewhat productive, but in the process it hurts productivity of good teams. But because properly leading good teams requires lot of work, trust in your underlings and makes it easier to place blame on the manager, we get cargo cult of scrum.
|
|
#
?
Apr 7, 2023 11:05
|
|
|
Ideally you have someone who is looking at the overall project and saying “hey we are 50% of the way through the schedule and 25% done so what’s the plan to solve that?”
|
|
#
?
Apr 7, 2023 13:07
|
|
|
Falcon2001 posted:If it helps, we work in Python and we use sprints as our main planning tool / execution cycle. Other people have started chiming in on this but I want to be explicit in defining some stuff for you: "sprints" are a concept from a project management methodology called Scrum, which in turn is a flavor of Agile development. Agile development in and of itself is fine and good -- it really just outlines a few simple principles for how you plan projects so you can continually deliver valuable work while responding to evolving requirements over time. However, most organizations cargo cult their way into "agile" or "scrum" and rigidly follow the ceremonies to the point where it obfuscates and eliminates the actual intent, and you are performing voodoo rituals to the sprint gods hoping for a good harvest of completed user stories. Your organization is one of them. Quick example: Scrum does not have a concept of a project manager, and "time" is an internal concept for the team that is irrelevant to people on the outside. What is supposed to be measured is "velocity", which is a concept that is supposed to be completely divorced from time. So if you have a project manager asking you for time estimates, someone has taken a perfectly fine methodology that can work really well and started using it to measure the wrong things in the wrong way. There is no fixing it from the bottom up. You are hosed. They want to measure the wrong things and try to force square pegs into round holes, which will be a never-ending source of friction and stress for everyone involved, all while the people who are misunderstanding what "agile" means get annoyed because their cargo culting isn't getting them the results they expect. You will deal with an attitude of "the Process is god. The Process cannot fail, it can only be failed." Bongo Bill posted:scrum Like, this post. Everything outlined here is 100% correct and will absolutely never happen in your organization. New Yorp New Yorp fucked around with this message at 16:47 on Apr 7, 2023 |
|
#
?
Apr 7, 2023 16:43
|
|
|
Bongo Bill posted:The process of estimating is a trick to make sure that every developer on the team has read the story, identified and fixed any problems with it, and come to an agreement about what it actually means.
|
|
#
?
Apr 7, 2023 18:19
|
|
|
I still say its incredibly common for people to equate velocity with time though, even in the best run shops it happens. And it's really to see why, your velocity is 50 points, you have a 2 week sprint. Then 5 points is 1 Days work! Except that 5 pointer might be 3 days work for a junior and a mornings for a lead.
|
|
#
?
Apr 7, 2023 18:23
|
|
|
they equate velocity with time because velocity requires time to be intelligible. rates of change are inherently measurements of time, it's a reasonable thing to do. "points" is slightly better because it's easier to intuit that they don't fundamentally relate to time. they only practically relate to time because work/time is what everyone actually cares about and what the scrum rituals were supposed to eventually improve if you practiced them correctly. instead of doing a crazy mental gymnastics routine to invent a thing that is only a single step removed from what everyone actually cares about and wants to talk about, you should just adopt a project management framework that acknowledges work/time for what it is, and tries to maximize it.
|
|
#
?
Apr 7, 2023 18:50
|
|
|
On a team whose velocity is consistent, velocity-based time estimates are pretty reliable. However, they are not and cannot be precise. "It'll be done by X week or the next" is something that it can be made possible to say with confidence, but to say "It'll take X days" is a sham.
|
|
#
?
Apr 7, 2023 18:53
|
|
|
Wow that's a ton of great stuff, thanks! I'm taking notes on all this and going to try and bring this up in the retrospective. I have some senior folks I can reach out to for support as well who are pretty sane; and at least my particular group now is pretty reasonable so I think we might be able to make improvements. Are there any good sources I can point to for this stuff that folks are familiar with? Like I think a lot of this is just good arguments on its face but it's always nice to be able to point to a blog post / book or something. Just in case "Hey lead my shitposting forum thinks we do scrum wrong" doesn't work.
|
|
#
?
Apr 7, 2023 18:55
|
|
|
12 rats tied together posted:
I would always urge against time based planning. For it to work you really need to know who is going to be doing each task when you estimate it, otherwise you've not really estimated anything. The second thing it does is introduce constant deadline pressure. For me I feel this is a really an unhealthy pressure to put on the team, I'd much rather have point commitment for the team to think about collective effort. There are ways round both these things with different project management frameworks but I've never really come across one that works.
|
|
#
?
Apr 7, 2023 19:04
|
|
|
Time-based planning is fine, just don't try to do everything time-based. This drives a lot of manager types up the wall, because they really want to believe that there's a single mode of work and everyone can be made to do it the same way. Identify your top commitments to your top stakeholders. Commit to deadlines on those things, try your best to keep them, and communicate out when you think they're going to slip. It's not rocket science.
|
|
#
?
Apr 7, 2023 19:08
|
|
|
A lot of work on software estimation was thrown out once Agile dropped, which sucks. It’s a legitimate skill. Steve McConnell wrote some good books on the matter back in the 90s. One thing he said that I love is that your estimation should be a range of values, a lower and upper bound, and as you work those bounds should get closer and closer until you launch.
|
|
#
?
Apr 7, 2023 19:23
|
|
|
Aramoro posted:I would always urge against time based planning. For it to work you really need to know who is going to be doing each task when you estimate it, otherwise you've not really estimated anything. The second thing it does is introduce constant deadline pressure. For me I feel this is a really an unhealthy pressure to put on the team, I'd much rather have point commitment for the team to think about collective effort. Sure, but the problem is that everyone converts it to time based planning in their heads, because it's what actually matters. Regarding the deadlines, that's a fair point, and I didn't really elaborate on it because I was phone posting: this is what kanban is good at. There are no extra deadlines because the workflow is constant and performed continuously. There is no deadline pressure on ICs because you are limited to 1 WIP issue. The psychological impact of such a system is that you show up to work and you know what is expected of you (pull and work the issue at the top of the queue), every interaction you're supposed to have with the system is provided as a lever with an immediate and obvious impact (move to: "done", "cantdo", "blocked"). Because your WIP limit is 1, everything that would interfere with your ability to act as an IC is a conversation. Priorities changed at the latest SVP cringe meeting and you need to work a different issue? You put yours back into ToDo and leave some notes, and then your team lead re-sorts the tickets list once more so that the top issue is most important again. The result of performing every scrum ritual in the magically correct form where they actually provide value is forced upon the system by these levers. You can't possibly do it right-but-not-right-enough, you can only do it correctly or break the rules. The other effect of the workflow being performed continuously is that metrics can be gathered any time. There's no sprint-end-what-did-you-get-done-this-time team meeting, and there's no quarterly team leads sync where everyone presents a burndown chart that 0 people care about and a handful of people are converting into time estimates in their head. There's just, here's the graph that our software generates for us automatically, with its current values, and if you want to timebox it you can just pick a start and end date arbitrarily and look at it.
|
|
#
?
Apr 7, 2023 19:37
|
|
|
Also worth mentioning, velocity is supposed to be a rough measure of performance by a team over an entire sprint. Your team being able to do 50 points per sprint means that, on average, your team will be able to do 50 points per sprint. Per day averages are pretty terrible as far as I'm concerned, per person velocity estimates are similarly liable to bring out of whack. If your PM doesn't understand this, and tries to set their Gantt charts up to a weekly level of who is working on what, you're going to be set up to fail.
|
|
#
?
Apr 7, 2023 19:39
|
|
|
12 rats tied together posted:Sure, but the problem is that everyone converts it to time based planning in their heads, because it's what actually matters. I forgot to mention that this type of kanban does not involve forecasting. Nobody in the Toyota warehouse is showing up to work every day and revealing a poker card that says they think attaching the door to the car is going to be 3 points. Because your WIP limit is 1, you don't need to cost anything, you just show up and do it. Your velocity is a measurement of the things you actually did, so it's 100% correct. The time it took you to attach the door to the car is tracked by your project management software as the time between the ticket entering "Doing" and the moving to "Done", so it's also 100% correct. The only time you might need more information than this is when your team lead is answering a question like "How long do you think it will take to complete this business initiative"? The good news is, this is time-based planning again, and all of the information your project management software generated for you about the things the team actually did and how long it actually took them is going to be way more useful than the fact that 12 rats tied together was bored at planning poker and just threw up "3 points" for everything so he could go back to his actual job. The other good news is that this is actually an important function of a tech team lead, so it can be part of their job description, which means they can be held accountable for their performance. They will also have a lot more time to develop the required expertise in estimation and tracking when they don't need to perform all the scrum rituals including the ones where everyone talks about which scrum rituals we should stop doing, which ones we aren't doing right, and which ones we were wrong to have stopped doing.
|
|
#
?
Apr 7, 2023 19:55
|
|
|
the part that bugs me about the sprint analogy is that there isn’t really a built in rest period between sprints, you just go right into the next sprint as soon as the current one ends. that’s not how sprinting works!
|
|
#
?
Apr 7, 2023 20:34
|
|
|
HamAdams posted:the part that bugs me about the sprint analogy is that there isn’t really a built in rest period between sprints, you just go right into the next sprint as soon as the current one ends. that’s not how sprinting works! and why do they call it a "stand-up" meeting when everyone is sitting down? and what's the deal with airline food?
|
|
#
?
Apr 7, 2023 20:42
|
|
|
Bruegels Fuckbooks posted:and why do they call it a "stand-up" meeting when everyone is sitting down? As far as I'm aware, this one is because the intent is that everyone should be standing - a standup should be short enough that everyone should be able to stand and chat and give an update, not get comfortable.
|
|
#
?
Apr 7, 2023 22:00
|
|
|
Bruegels Fuckbooks posted:and why do they call it a "stand-up" meeting when everyone is sitting down? because they are doing it wrong and paying lipservice
|
|
#
?
Apr 7, 2023 22:10
|
|
|
i was at a company where our scrummaster got so mad at us consistently going over our allotted standup time that she made us start doing chair pose while we were giving updates so that we'd go faster it worked, and she owned
|
|
#
?
Apr 7, 2023 22:44
|
|
|
What? Like squatting to take a poo poo? Or like the yoga pose? ... both?
|
|
#
?
Apr 7, 2023 22:55
|
|
|
Rocko Bonaparte posted:What? Like squatting to take a poo poo? Or like the yoga pose? like the yoga pose i realize the actual term i wanted is "wall sit" though 
|
|
#
?
Apr 7, 2023 23:11
|
|
|
Rocko Bonaparte posted:What? Like squatting to take a poo poo? Or like the yoga pose? YOU'LL DELIVER YOUR UPDATES FROM THE TOILET OR BY GOD I'LL MAKE YOU PAY.
|
|
#
?
Apr 7, 2023 23:12
|
|
|
Falcon2001 posted:YOU'LL DELIVER YOUR UPDATES FROM THE TOILET OR BY GOD I'LL MAKE YOU PAY. This is good because it won't interrupt my coding or posting
|
|
#
?
Apr 8, 2023 00:12
|
|
|
Erg posted:like the yoga pose this owns. my team was suffering from long standups for a while, namely from one guy on the team that had to dump every piece of detritus out of his skull onto the team. I had x meeting with n. Did a with b. Etc. We'd have team agreements sessions and norming on what stand up is (share progress towards the sprint, identify if its goals are at risk, unblock), and what it isn't (justify your job and give a status update on everything you loving did to sound real busy). Fortunately, he was promoted to management, left the team, and now our standups take less than 5 minutes usually and everyone's laser focused on unblocking people and figuring out if anything has changed in the past 24 hours that will gently caress up the sprint goals being met should have just made everyone do wall sits while on zoom
|
|
#
?
Apr 8, 2023 01:57
|
|
|
standups are a chance to shitpost a bit with colleagues and last from 30-45 mins
|
|
#
?
Apr 8, 2023 04:56
|
|
|
The best time to shitpost with colleagues is while doing ordinary work.
|
|
#
?
Apr 8, 2023 05:32
|
|
|
Doktor Avalanche posted:standups are a chance to shitpost a bit with colleagues and last from 30-45 mins We actually just kind of set our weekly team meeting up to be like : 30 minutes - actual agenda of important items 30 more minutes - time to soapbox or just shoot the poo poo, you can leave if you have poo poo to do
|
|
#
?
Apr 8, 2023 07:32
|
|
|
For where two or more architects
|
|
#
?
Apr 8, 2023 07:34
|
|
|
Falcon2001 posted:We actually just kind of set our weekly team meeting up to be like : I'm stealing this for my department 
|
|
#
?
Apr 9, 2023 15:12
|
|
|
loving kill me if i had to attend a daily hour long stand-up
|
|
#
?
Apr 9, 2023 15:19
|
|
|
|
| # ? May 12, 2024 18:48 |
|
|
biceps crimes posted:loving kill me if i had to attend a daily hour long stand-up if you are in standup meetings for more than an hour a day, it is safe to do literally zero actual work the rest of the day and go play xbox or do mushrooms in the company parking lot or something else fun, because whatever you're working on is never coming out.
|
|
#
?
Apr 9, 2023 16:12
|
|