|
I've never done pair programming in a professional environment, but it's always been nice in school for a bit of a sanity check. I have a bad habit of overcomplicating things, so it's good when I miss something simple and someone points it out to me and looks at me like I'm daft. It also helps when you get the occasional "why did you do X like that", so that you can actually analyze your reasons and talk it through.
|
#
?
Apr 18, 2016 14:36
|
|
|
|
| # ? May 10, 2024 17:34 |
|
|
Is pair programming something people actually spend a majority of their working hours doing? Standing over a coworker's shoulder and going over something every once in a while is fine but doing it all the time sounds like the most miserable thing in the world.
|
|
#
?
Apr 18, 2016 14:51
|
|
|
Yep, places that are all-in on extreme programming will do 100% pairing. You do not touch code by yourself unless someone is out or you have an odd number of developers assigned to a project temporarily. If you don't like pairing, those companies would not be a good fit for you, but different strokes for different folks. It's got to be a rough transition for a company that switches to that though.
|
|
#
?
Apr 18, 2016 15:37
|
|
|
I am very pro-pairing and I've only worked extensively at places that do it near-100% of the time. There are big trade-offs (for one thing, as others' responses show it's a recruiting filter) but I still think it's almost always worth it. Maybe my tune will change when I try the next big methodology fad.
|
|
#
?
Apr 18, 2016 16:13
|
|
|
I work for a huge insurance company (designer with dev knowledge/exp) and our delivery team is on agilefall with the development team completely walled off from us. We also are suppose to switch desks a lot and can't keep anything personal anywhere. I'm still sitting where I planted my butt 1.5 years ago. This is what you don't do.
|
|
#
?
Apr 18, 2016 16:51
|
|
|
cheese eats mouse posted:I work for a huge insurance company (designer with dev knowledge/exp) and our delivery team is on agilefall with the development team completely walled off from us. That sounds awful. BTW am I recalling right that you're in KY? Get on the louisville.io slack and look in #jobs.
|
|
#
?
Apr 18, 2016 17:07
|
|
|
revmoo posted:That sounds awful. BTW am I recalling right that you're in KY? Get on the louisville.io slack and look in #jobs. Oh nice I didn't know there was a slack. I've asked to switch teams to one that's more in line with my interests. Right now it's selling lovely Medicare to seniors. Moving into more health and wellness. I'm sure you know where I'm talking about now. Do you go to the Build Guilds at all?
|
|
#
?
Apr 18, 2016 17:09
|
|
|
Is it true in any sense that a story point very coarsely translates to a man-week? I know it's bad news to make a direct correlation, but I'm dealing with a magnitude issue here. Somebody in the organization is claiming this is how grown-ups do this in the industry, and I think they're talking out their rear end. I always heard a more rough correlation to hours. That is, people try to plan to a more fine granularity. My previous jobs might have been messing that up, but that's what they were all trying to do. Yadda yadda points are abstract, I know, but when you have somebody else saying that your story points have to be Fibonacci and can only go as high as 13 points, whether they're more like weeks or hours suddenly matters a lot more for deciding when you have to break down work more.
|
|
#
?
Apr 18, 2016 17:41
|
|
|
Rocko Bonaparte posted:Is it true in any sense that a story point very coarsely translates to a man-week? I know it's bad news to make a direct correlation, but I'm dealing with a magnitude issue here. Somebody in the organization is claiming this is how grown-ups do this in the industry, and I think they're talking out their rear end. I always heard a more rough correlation to hours. That is, people try to plan to a more fine granularity. My previous jobs might have been messing that up, but that's what they were all trying to do.
|
|
#
?
Apr 18, 2016 17:44
|
|
|
Rocko Bonaparte posted:Is it true in any sense that a story point very coarsely translates to a man-week? I know it's bad news to make a direct correlation, but I'm dealing with a magnitude issue here. Somebody in the organization is claiming this is how grown-ups do this in the industry, and I think they're talking out their rear end. I always heard a more rough correlation to hours. That is, people try to plan to a more fine granularity. My previous jobs might have been messing that up, but that's what they were all trying to do. Doing story point = specific time is completely losing the point of the agile/scrum point system and you may as well go back to traditional estimations at that point and lose the fibonacci sequence numbers. The team I was on that did it the best had kind of basic tasks associated with each number to give a general idea of how much effort it would take.
|
|
#
?
Apr 18, 2016 17:45
|
|
|
Rocko Bonaparte posted:Is it true in any sense that a story point very coarsely translates to a man-week? I know it's bad news to make a direct correlation, but I'm dealing with a magnitude issue here. Somebody in the organization is claiming this is how grown-ups do this in the industry, and I think they're talking out their rear end. I always heard a more rough correlation to hours. That is, people try to plan to a more fine granularity. My previous jobs might have been messing that up, but that's what they were all trying to do. When you first start, some people pick an estimate=point size like that at the very beginning since they have nothing to compare a point to. IMHO a week is way too big. You're essentially saying you'll never have a story less than a half point / 2.5 days. After sizing a card or two, they should then throw away that idea and go relative sizing then on out, but they rarely do and it becomes a big mess. A better way to bootstrap the sizing is to look across a bunch of user stories. Figure out what an average one looks like. Give that a point value somewhere in the middle of the scale and then go relative from there on out.
|
|
#
?
Apr 18, 2016 18:14
|
|
|
KoRMaK posted:Also, whats the point of being that strict? The more strict things get the less creative/innovative I get. My best ideas come from letting me let my mind wander for a bit: a walk, driving, playing guitar, etc
|
|
#
?
Apr 18, 2016 18:26
|
|
|
The places I've been the guideline was always roughly 1pt/hour, probably max out to 6-8 for a very productive day with no meetings
|
|
#
?
Apr 18, 2016 18:27
|
|
|
Munkeymon posted:The places I've been the guideline was always roughly 1pt/hour, probably max out to 6-8 for a very productive day with no meetings I usually use 1.5 hours per point as my starting point, and an individual story size shouldn't be more than 8 points.
|
|
#
?
Apr 18, 2016 18:30
|
|
|
Rocko Bonaparte posted:Is it true in any sense that a story point very coarsely translates to a man-week? I know it's bad news to make a direct correlation, but I'm dealing with a magnitude issue here. Somebody in the organization is claiming this is how grown-ups do this in the industry, and I think they're talking out their rear end. I always heard a more rough correlation to hours. That is, people try to plan to a more fine granularity. My previous jobs might have been messing that up, but that's what they were all trying to do. A story of 1 point is supposed to be the simplest user story possible. So something like "update colours" or "make button print text", but in terms of your project. It should also be more a measure of relative complexity, not pure time. The reason you use Fibonacci numbers, and that can't (shouldn't) go higher than 13 is because the higher you go, obviously, you know less and less about WTF you're supposed to be doing. So 4 necessarily goes to 5 to reflect this uncertainty, and anything higher to 8, for the same reason. At 13, you're basically at the point where you have no clue and should really spend some time breaking the story down into smaller components that can be better understood, instead of trying to get it all done in one go.
|
|
#
?
Apr 18, 2016 18:31
|
|
|
Everyone does it differently even among different projects. Where I work, we use 1/2/4/8, where 8 is too big to be a single story and needs to be broken up. And a 4 isn't going to be more than two pair-days. But I sometimes join another group that will point 0 for trivial stuff (like wording changes or minor restyling.)
|
|
#
?
Apr 18, 2016 18:50
|
|
|
Skandranon posted:So 4 necessarily goes to 5 to reflect this uncertainty
|
|
#
?
Apr 18, 2016 18:58
|
|
|
I worked at a place for a bit that if a bug was discovered in a feature you built, it came back into your sprint as a 0-point task that had to be done alongside whatever else was in your todo list. So dumb...cheese eats mouse posted:Do you go to the Build Guilds at all? No. I pretty much leave work at work and don't do too much outside of the office. I rather be out riding my motorcycle or turning wrenches than talking shop.
|
|
#
?
Apr 18, 2016 18:59
|
|
|
Okay I'm not too surprised by the answers. I think I have a better question anyways. Once the smoke clears on planning and you have closed the story, how much time do your smallest stories tend to take, and how much time do your largest stories tend to take? I'm curious if there's a common granularity here. Note that I am saying nothing about points here, but I suppose I will just show my hand for full disclosure. I'm thinking too that 1 point roughly corresponding to a week is way to coarse. You can argue it doesn't matter, but I'm not allowed to do 0.5, and zero is troublesome for calculations. I'm suspecting that a lot of people wind up with the smallest user stories being about a man-day of work. That's not even necessarily a full 8 hours.
|
|
#
?
Apr 18, 2016 19:02
|
|
|
revmoo posted:I worked at a place for a bit that if a bug was discovered in a feature you built, it came back into your sprint as a 0-point task that had to be done alongside whatever else was in your todo list. So dumb... As much as I'd love to program outside of work to increase skillsets that I don't get to implement in the office, I find it really hard to get excited about doing any programming once I'm home. Except for the one form of programming that I know I will never get to do professionally, but which is my real passion in development, which is AI.
|
|
#
?
Apr 18, 2016 19:03
|
|
|
Rocko Bonaparte posted:Okay I'm not too surprised by the answers. I think I have a better question anyways. Once the smoke clears on planning and you have closed the story, how much time do your smallest stories tend to take, and how much time do your largest stories tend to take? I'm curious if there's a common granularity here. Note that I am saying nothing about points here, but I suppose I will just show my hand for full disclosure. I'm thinking too that 1 point roughly corresponding to a week is way to coarse. You can argue it doesn't matter, but I'm not allowed to do 0.5, and zero is troublesome for calculations. I'm suspecting that a lot of people wind up with the smallest user stories being about a man-day of work. That's not even necessarily a full 8 hours.
|
|
#
?
Apr 18, 2016 19:10
|
|
|
Vulture Culture posted:Pedantry: 4 isn't a Fibonacci number That is entirely what I meant.... you use Fibonacci numbers because the exponential increase indicates how unknown things get. You are locked to integers, so if you cannot agree something is a 3, you must jump up to 5, because it is next in the Fibonacci sequence, and if you can't agree on 5 you must jump to 8.
|
|
#
?
Apr 18, 2016 19:19
|
|
|
Vulture Culture posted:There's no such thing as an 8-hour person-day of development work unless your team members don't talk to each other or their management, don't have meetings, don't do code review, don't meet or talk with users, don't work with vendors, don't respond to emails, don't support production issues, and don't context-switch. Get this dumb fallacy out of your organization immediately, because it's one of the easiest to disprove. Sorry, I was trying to say that but I wasn't specific enough. What I was meaning is that I figured the smallest stories were a full "man day" of work, which is even finer than a full 8 hours specifically because of all that overhead. In contrast to being forced to make user stories be a full week long, it's quite a difference. In fact, I just had to deal with some confusion that arose from having to make really large user stories that would have normally been paced differently due to having to aggregate everything into a giant, one-week-ish block.
|
|
#
?
Apr 18, 2016 19:27
|
|
|
Skandranon posted:A story of 1 point is supposed to be the simplest user story possible. So something like "update colours" or "make button print text", but in terms of your project. It should also be more a measure of relative complexity, not pure time.
|
|
#
?
Apr 18, 2016 19:35
|
|
|
Cicero posted:How do you measure how complex a programming task is if not in how much time it will take? Points are nice for being able to roughly assess the complexity of different work in relation to each other without necessarily knowing how long any one of them will take. So I might not know if activity X may take 2 hours, but it sounds like it is half as complicated as activity Y. I eventually figure out activity Y will take 4 hours, and hence I can make a base assumption that activity X will be something like 2 hours. Well, it may not be a linear correlation like that; practice will show what it really is. At the end of the day, people do want to know how long it will take to do something, and they're asking that from people that either don't know and/or don't want to commit to a number right away. Having points gives planners some currency to use that keeps everything moving. My situation with this is I'm being compelled to have my lowest possible number for a story point correspond to the kind of work that normally takes us a week. It's kind of loving up some stuff because now we're throwing stuff together that would normally be three user stories that get interwoven with other work. It starts to look like two user stories have circular dependencies when those dependencies are completely managed.
|
|
#
?
Apr 18, 2016 19:40
|
|
|
Cicero posted:How do you measure how complex a programming task is if not in how much time it will take? It is a fuzzy thing, but that's sort of the point. We are poo poo at estimating. The idea of story points is instead of trying really hard to stick to a hard metric and failing, you make fuzzier estimates and then you get a rough projection over multiple sprints how many fuzzy points you can accomplish. Mapping them onto hours just sets your max to 40 and people getting upset you didn't accomplish 40h of work ergo you are slacking, and obviously leads to padding. The whole point is to have an abstract layer so you can stop obsessing over these things. It's a better direction, but not perfect.
|
|
#
?
Apr 18, 2016 19:55
|
|
|
quote:it sounds like it is half as complicated as activity Y.
|
|
#
?
Apr 18, 2016 20:00
|
|
|
Cicero posted:But why does it sound half as complicated? Because to me, when I think something sounds half as complicated, that's because it feels like it'll take half as long. I guess to me "complexity of a task" and "how long it will take" are effectively the same thing. I think of it in terms of the character of a task, like for like. So adding buttons to a page is roughly equivalent, even if one requires 3x the markup. It should be more a measure of unknowns, not a measure of how much typing is needed or time that must be invested.
|
|
#
?
Apr 18, 2016 20:03
|
|
|
Cicero posted:How do you measure how complex a programming task is if not in how much time it will take? It's a fun game Agile aficionados like to play. You see, X points can't be mapped onto Y hour/days of week, because there are so many variables (meetings, team variability, etc.). This conveniently ignores that after a certain amount of time, you'll have a rough idea for a given team and environment what the points -> time mapping looks like (note: this is literally the concept of velocity). Some people get really frustrated when you try to turn points into time though.
|
|
#
?
Apr 18, 2016 20:06
|
|
|
Skandranon posted:It is a fuzzy thing, but that's sort of the point. We are poo poo at estimating. The idea of story points is instead of trying really hard to stick to a hard metric and failing, you make fuzzier estimates and then you get a rough projection over multiple sprints how many fuzzy points you can accomplish. Skandranon posted:I think of it in terms of the character of a task, like for like. So adding buttons to a page is roughly equivalent, even if one requires 3x the markup. It should be more a measure of unknowns, not a measure of how much typing is needed or time that must be invested.
|
|
#
?
Apr 18, 2016 20:13
|
|
|
Cicero posted:But why does it sound half as complicated? Because to me, when I think something sounds half as complicated, that's because it feels like it'll take half as long. I guess to me "complexity of a task" and "how long it will take" are effectively the same thing. Yeah, you thought it would take "half as long," but you never said exactly how long. That's where the points come in. They give planners some relative method of sizing work without having to get into a war over the actual time. Now, in practice, you are making the plans and you are doing the work, so you have a pretty good idea of what it means. However, the points help with the program managers and like that make this thread's title unfortunately appropriate. 
|
|
#
?
Apr 18, 2016 20:31
|
|
|
baquerd posted:It's a fun game Agile aficionados like to play. You see, X points can't be mapped onto Y hour/days of week, because there are so many variables (meetings, team variability, etc.). This conveniently ignores that after a certain amount of time, you'll have a rough idea for a given team and environment what the points -> time mapping looks like (note: this is literally the concept of velocity). Some people get really frustrated when you try to turn points into time though. LOL yeah pretty much. "Points don't equal time!!!!!!" *adds a specific amount of points to each two-week sprint*
|
|
#
?
Apr 18, 2016 20:44
|
|
|
I just had to explain why we estimate story points in terms of hours instead of just putting down the hours. Super relevant to this conversation  revmoo posted:LOL yeah pretty much.
|
|
#
?
Apr 18, 2016 20:49
|
|
|
I mean, the whole point is that if you add a specific amount of points to the two week sprint, you can evaluate how you did at the end. Didn't finish all those stories? Then do less points in the next sprint. Finished early? Add more points to the next sprint. It's pretty natural in its adjustment. Yes, you can do the same exercise with hours, but once you start saying you can do 70 hours of work in 80 hours, you might as well call those 70 hours 70 points.
|
|
#
?
Apr 18, 2016 21:12
|
|
|
smackfu posted:I mean, the whole point is that if you add a specific amount of points to the two week sprint, you can evaluate how you did at the end. Didn't finish all those stories? Then do less points in the next sprint. Finished early? Add more points to the next sprint. It's pretty natural in its adjustment. The problem is, that no one outside of a dev team ever wants to operate that way. They want everything done in number of hours with firm deadlines 3 months in advance. Doubly so if you do anything related to physical products. Of course there is a lot of variability just with people to make turning points into man hours worthless.
|
|
#
?
Apr 18, 2016 21:33
|
|
|
baquerd posted:It's a fun game Agile aficionados like to play. You see, X points can't be mapped onto Y hour/days of week, because there are so many variables (meetings, team variability, etc.). This conveniently ignores that after a certain amount of time, you'll have a rough idea for a given team and environment what the points -> time mapping looks like (note: this is literally the concept of velocity). Some people get really frustrated when you try to turn points into time though.
|
|
#
?
Apr 18, 2016 21:42
|
|
|
JawnV6 posted:For a given team, in a given two weeks, you can produce Y points. Anything more fine grained is destined to failure, and any other consumer of points will destabilize it. The "convenience" of the ignorance is enforcing the abstraction layer at which it works. I'm all on board with points, and the Fibonacci numbers have built in ranges and can convey uncertainty. I just object to people who can't handle it when someone points out that a 3 point story is typically e.g. 2-4 days worth of work, or that 1 point story should generally be completed within a day. It's helpful to baseline things in reality, and comparing stories to stories can be useful, but so can comparing stories to actual time. Consider two stories, one has been sized at 3 points. The next story is being talked about, and everyone agrees it's substantially larger and sizes at 5 points. If you look at actual time anticipated, maybe 5 points at a week's worth of time minimum (for example) doesn't actually make sense because no one thinks it will take that long, and instead the earlier story should be re-sized down, or explored further.
|
|
#
?
Apr 18, 2016 21:55
|
|
|
revmoo posted:No. I pretty much leave work at work and don't do too much outside of the office. I rather be out riding my motorcycle or turning wrenches than talking shop. Yea I was trying to figure out if we've inadvertently met. I know a lot of the guys in that slack through BG meet ups.
|
|
#
?
Apr 18, 2016 22:03
|
|
|
cheese eats mouse posted:Yea I was trying to figure out if we've inadvertently met. I know a lot of the guys in that slack through BG meet ups. I'm sure we know people in the same circles, it's a pretty small industry. I've worked @ TLH/Ooh/Ind if you know what any of those places are. Currently work for an Infosec company out of state (thank GOD. A lot of the local companies are poo poo).
|
|
#
?
Apr 18, 2016 22:07
|
|
|
|
| # ? May 10, 2024 17:34 |
|
|
Jumping on the earlier topic: we used to do pair programming at my office, and I rather liked for specific tasks. It was handy when we didn't know precisely how to architect a solution but knew what we wanted. We never end up writing a LOT of lines of code, maybe 100 at most. The biggest thing is designing what kind of models we want in our solution and figuring out what the best way to save and modify those would be. Revisiting a topic I touched upon even earlier: a lot of the work that I do (when I'm not on fire covering for people) involves long-running background tasks. We've got workers that are supposed to churn through terabytes of text data and run LDA. That takes a long time and leaves tickets worth three or four points in the sprint for months. It's kinda' bugging me out to see my tickets still open across two months. Not sure if there's a better way to handle it.
|
|
#
?
Apr 18, 2016 22:40
|
|
