|
Axiem posted:On my previous team, we had a weekly estimating meeting on new stories in our pipeline. To do the actual estimating, we'd all read the card, then raise our hand (or otherwise indicate) when we'd made an internal estimate. We'd then go around in a circle and say our own estimates. This is called planning poker and it's a very common agile estimation tool. The only part you're doing "wrong" is picking the highest estimate. The team is supposed to reach consensus. And yeah you're not supposed to use hours, you're supposed to use relative sizing ("story points"). And that's why you don't share actual hour estimates with management. You say "this is an 8 hour task", management thinks "cool, it only takes one day." Abstracting the actual hours behind relative sizes like story points lets you say to management "we can do 60 points next week, what items that add up to 60 points do you want us to work on?" 60 points might mean 60 hours (unlikely because we don't code 8 hours a day), or it might mean 48 hours. Doesn't matter, avoids the conversation about "if you have 2 developers, I should get 80 hours of stuff per week!" New Yorp New Yorp fucked around with this message at 16:24 on Mar 12, 2016 |
#
?
Mar 12, 2016 16:19
|
|
|
|
| # ? May 9, 2024 22:54 |
|
|
Ithaqua posted:Abstracting the actual hours behind relative sizes like story points lets you say to management "we can do 60 points next week, what items that add up to 60 points do you want us to work on?" 60 points might mean 60 hours (unlikely because we don't code 8 hours a day), or it might mean 48 hours. Doesn't matter, avoids the conversation about "if you have 2 developers, I should get 80 hours of stuff per week!" I'm an Agile believer and proponent, but I've never worked in a shop where the points didn't somehow end up with an implicit conversion to hours/days. The burndown chart should ideally map remaining points to remaining sprint duration in a linear fashion, so the conversion isn't difficult to make. To me, points (t-shirt) seems like a pointless layer of abstraction that everyone just sees through anyway. Even as devs in our planning meetings, the mental math was 1 day=1 point. Everyone pretended that it measured complexity irrespective of time, but that's a lie.
|
|
#
?
Mar 12, 2016 16:34
|
|
|
Points are great because not everyone on the team is as efficient. A team might be able to do 50 points / week, but it might be split between 3 people as 20/20/10. I'd like to second the opinion of using estimation as a way of talking about the work to make sure everyone is on the same page, I often found value in those conversations.
|
|
#
?
Mar 12, 2016 18:16
|
|
|
Vulture Culture posted:Our of sheer morbid curiosity, how do people in here feel about the #NoEstimates movement? By the way, for people working in Scrum teams, how many of you have also estimated the hours for task rather than simply estimating stories? Seems that Scrum community used to advocate estimating hours, but have these days moved away from that.
|
|
#
?
Mar 12, 2016 19:58
|
|
|
pigdog posted:I think it shows promise. The point as far as I could tell is not to bother estimate hours OR points, but only count the stories. The premise is that on average, a team can do X stories per sprint at a greater consistency than estimating points per each story. Provided that the team is also creating the stories, the relative size of each story is relatively consistent, and calculating points on top of that is unnecessary. This is assuming you're essentially breaking down your stories to some manageable and equal level of work. Sometimes stories are "As a Customer, I want a new next gen AAA FPS/MMORPG".
|
|
#
?
Mar 12, 2016 20:21
|
|
|
I'll see your #noestimates, and raise you #noprojects. E: 
Doc Hawkins fucked around with this message at 04:29 on Mar 13, 2016 |
|
#
?
Mar 12, 2016 20:21
|
|
|
B-Nasty posted:I'm an Agile believer and proponent, but I've never worked in a shop where the points didn't somehow end up with an implicit conversion to hours/days. Currently we don't estimate much, we'll give rough 3-days/2-week guesses to the PO to help with prioritisation but she knows how accurate they are so we're cool.
|
|
#
?
Mar 12, 2016 21:11
|
|
|
Skandranon posted:This is assuming you're essentially breaking down your stories to some manageable and equal level of work. Sometimes stories are "As a Customer, I want a new next gen AAA FPS/MMORPG".
|
|
#
?
Mar 12, 2016 21:17
|
|
|
pigdog posted:It assumes the team is breaking down the stories, which should be pretty standard practice. Customer usually just wants a thing, not dick around with stories. I didn't say the customer should be breaking down stories, I said you were. Try reading it again.
|
|
#
?
Mar 12, 2016 21:38
|
|
|
Let me try and rephrase that. If a team can decide how big a story is (i.e. break "I want an MMORPG" down into regular sized stories for that team), then the number of stories done by the team over time ostensibly remains pretty constant. The premise is that the number of stories over time could be used for estimation with better success than having the team also estimate point scores for the stories, and use the average number of points per sprint, as is more common today.
|
|
#
?
Mar 12, 2016 22:07
|
|
|
Doc Hawkins posted:I'll see your #noestimates, and raise you #noprojects.  That video is an ad for Clash Royale, did you mean this talk?https://www.youtube.com/watch?v=Rzglax8LdaM (by the way GOTO Conference on youtube is so great)
|
|
#
?
Mar 12, 2016 22:16
|
|
|
That guy is really obnoxious to listen to, starting out with being wrong about GOTO and then he goes all "me, me, me".
|
|
#
?
Mar 12, 2016 22:42
|
|
|
MrMoo posted:That guy is really obnoxious to listen to, starting out with being wrong about GOTO and then he goes all "me, me, me". It's also a bit too long of a talk, could easily be half the length and still drive the same point. Here's some good videos because I have a playlist full of this poo poo https://www.youtube.com/watch?v=1KRYH75wgy4 https://www.youtube.com/watch?v=kA4-b7hvWhg And I don't know if I can embed this one but this one is real good: https://vimeo.com/9270320 piratepilates fucked around with this message at 22:53 on Mar 12, 2016 |
|
#
?
Mar 12, 2016 22:50
|
|
|
In terms of the # of stories thing, you can build out a little statistical model pretty easily after you have some data to go on. It can really help risk assessments since you can say things like: "We have an 80% chance of completing all these stories in 3 months" "Adding this story brings our chance of completing things by the due date from 80% to 75%" Business people often like hearing things like that since it can give them an economic cost to decisions. (or at least they can be trained to think that way)
|
|
#
?
Mar 13, 2016 15:18
|
|
|
B-Nasty posted:I'm an Agile believer and proponent, but I've never worked in a shop where the points didn't somehow end up with an implicit conversion to hours/days. The burndown chart should ideally map remaining points to remaining sprint duration in a linear fashion, so the conversion isn't difficult to make. To me, points (t-shirt) seems like a pointless layer of abstraction that everyone just sees through anyway. It's fine if each dev has their own mental mapping of points to days or hours. It would be silly not to expect them to, especially for stories where they know exactly what to do. Sizing is beneficial to non-devs (and some devs) who don't make the connection that "effort-to-done" is not a function of just how large the size of the story is, and includes factors that are often unknowable (who will work on it/how well will external teams support us/will our build server go down for a few days/etc.) Everyone has their own opinion about how long something "should" take and stronger personalities will take that opportunity to brow-beat others into estimating for their level of skill (low or high.) Sizing encourages discussion about the complexity of the story itself, which is/should be the focus of the session in the first place. Also, if you use effort get ready for padding/complaining about perceived padding. It also depends on whether you're sizing the backlog or sizing just before a sprint. In backlog sizing using effort estimates is a horrible idea, for sprint planning I see effort estimates as more acceptable if the team is small and mostly equal in skill/knowledge or does a lot of pair programming which smooths out the outliers of "give this to the intern" and "give this to the architect who is slumming with us".
|
|
#
?
Mar 13, 2016 23:06
|
|
|
Axiem posted:On my previous team, we had a weekly estimating meeting on new stories in our pipeline. To do the actual estimating, we'd all read the card, then raise our hand (or otherwise indicate) when we'd made an internal estimate. We'd then go around in a circle and say our own estimates. At my first job, before we had started to do scrum, our team leader had been reluctant to give actual hour estimations to our rather shady project manager we had at one point. So, while she was gone for vacation, he called a meeting with the team and tried to get us to do the estimations with the lead not there. These estimates were totally not going to be used for anything, and certainly management wasn't going to hold us to them like they were set in stone, no sir. He was canned like a week after our lead got back from vacation.
|
|
#
?
Mar 13, 2016 23:20
|
|
|
Reading people talk about estimates is hilarious to me because my company doesn't even know what projects people are working on, much less a method for determining how long something should take. I'm so glad to be leaving. I got an email earlier this week from my manager asking all the devs to 'please add to this list (in the email) what projects you are currently working on and are responsible for.' I asked why there's not a sharepoint or google docs so we can just edit it in and all see the changes and the response was 'not everyone has google access'. Fantastic.
|
|
#
?
Mar 14, 2016 03:19
|
|
|
This is not Martin's best talk, he does quite a few though and this topic has been covered very well by Google too: scaling linearly at Google scale is completely impractical. I can't find a link to the video though Doesn't really explain why all the Node.js based job applications fail miserably, I can't imagine the C samples being concise.
|
|
#
?
Mar 14, 2016 16:05
|
|
|
high scalability.com found this trove of interesting white papers to read.
|
|
#
?
Mar 14, 2016 21:01
|
|
|
The 2016 Stack Overflow survey results were just published (somehow I always miss submitting data in the survey): https://stackoverflow.com/research/developer-survey-2016
|
|
#
?
Mar 17, 2016 15:50
|
|
|
54.5% Javascript on the backend. Edit: AngularJS and Javascript are only 16% correlated Bongo Bill fucked around with this message at 15:59 on Mar 17, 2016 |
|
#
?
Mar 17, 2016 15:56
|
|
|
Bongo Bill posted:54.5% Javascript on the backend. But does it mean JavaScript specifically for backend code - or JavaScript used as a backend developer. I can't figure out which one and just using JS at all as a backend developer would skew it higher.
|
|
#
?
Mar 17, 2016 15:59
|
|
|
piratepilates posted:The 2016 Stack Overflow survey results were just published (somehow I always miss submitting data in the survey):
|
|
#
?
Mar 17, 2016 15:59
|
|
|
Vulture Culture posted:everyone who self-identified as rockstar or ninja should have to wear a "kick me" sign on their back for the rest of their natural lives 
|
|
#
?
Mar 17, 2016 16:00
|
|
|
Pretty interesting that employed full time salaries are higher than self-employed and freelance/contractor salaries. I guess after business expenses the high contracting rates even out versus full time.
|
|
#
?
Mar 17, 2016 16:04
|
|
|
Backend developers are paid more than full-stack ones. Reminds me of.
|
|
#
?
Mar 17, 2016 16:06
|
|
|
Bongo Bill posted:Backend developers are paid more than full-stack ones. Reminds me of. I wonder if that's from a lot of full stack developers doing stuff like agency work or php+minor front-end work that would probably pay lower versus back-end developers that are working for more valuable teams. Like if you were to exclude the full-stack developers that are using PHP I'm guessing the salary difference would even out. I also really like how the female numbers are improving among the young groups, hopefully we'll see a much more equal workforce in the following few years. piratepilates fucked around with this message at 16:11 on Mar 17, 2016 |
|
#
?
Mar 17, 2016 16:09
|
|
|
The gently caress does Angular mean on the backend? Even if they are talking about pre-rendering Angular pages for fast loading, that is still a front-end concern.
|
|
#
?
Mar 17, 2016 16:28
|
|
|
If we want, we'll be able to control for the influence of Satan's own programming language on these statistics when they release the full set. Could title the report "PHP Considered Harmful"
|
|
#
?
Mar 17, 2016 16:30
|
|
|
Skandranon posted:The gently caress does Angular mean on the backend? Even if they are talking about pre-rendering Angular pages for fast loading, that is still a front-end concern. I think they're back-end developers primarily (or by title) who end up doing a bit of angular development in their job, or they do backend development for a project that uses angular. I'm actually really surprised at how prevalent angular is on the survey. I knew it was pretty popular but I figured React and Ember were at least closer to it in usage.
|
|
#
?
Mar 17, 2016 16:35
|
|
|
Angular has hit that point where so many people know it, that it's easier to find talent for it, so companies choose it because of that, which causes the cycle to reinforce.
|
|
#
?
Mar 17, 2016 16:38
|
|
|
Gounads posted:Angular has hit that point where so many people know it, that it's easier to find talent for it, so companies choose it because of that, which causes the cycle to reinforce. Angular2 is also going to crush it this year.
|
|
#
?
Mar 17, 2016 16:42
|
|
|
Skandranon posted:Angular2 is also going to crush it this year. Well for everyone's sanity we can only hope.
|
|
#
?
Mar 17, 2016 16:45
|
|
|
Skandranon posted:Angular2 is also going to crush it this year. We're in the process of porting an angular/dart app over to angular2/typescript now.... it's looking great. Performance is way up without even doing any of the angular2 optimizations. Also... drat YOU GOOGLE FOR DROPPING DART
|
|
#
?
Mar 17, 2016 16:48
|
|
|
Gounads posted:We're in the process of porting an angular/dart app over to angular2/typescript now.... it's looking great. Performance is way up without even doing any of the angular2 optimizations. I've been doing the same. Try to get your app running in a webworker, if you have any performance constraints on the JS side this will probably solve all of them, again without doing anything specific to improve the change detection. Edit: Well, without the Dart part. Been using Angular1 with TypeScript for awhile now, so porting to Angular2 is actually pretty simple. Getting webpack doing everything properly has been the biggest challenge, especially for the webworker part.
|
|
#
?
Mar 17, 2016 16:49
|
|
|
I should clarify "non-functional". In this context, it means an operation which evaluates to the same thing. Django rest framework supports objects called serializers. Someone had written the following: code:code:
|
|
#
?
Mar 18, 2016 23:10
|
|
|
If I was planning on jumping from a full time to a contract job, how much should I be bumping up my expected compensation to account for the fact that I wouldn't have vacation days/benefits/etc anymore?
|
|
#
?
Mar 23, 2016 13:10
|
|
|
ChickenWing posted:If I was planning on jumping from a full time to a contract job, how much should I be bumping up my expected compensation to account for the fact that I wouldn't have vacation days/benefits/etc anymore? I have read somewhere (some blog) so take this with a grain of salt, that what one should do is decide how much they want to make per year, divide that number by 1000 and ask for that much per hour. For example: targeting $50k per year would bring you to $50/hour. If you get to work the entire year, you'd make $100k. Awesome. But the question is: will you be able to work the entire year? What's your expected downtime between jobs? Will you work 40 hours per week or less?
|
|
#
?
Mar 23, 2016 13:16
|
|
|
ChickenWing posted:If I was planning on jumping from a full time to a contract job, how much should I be bumping up my expected compensation to account for the fact that I wouldn't have vacation days/benefits/etc anymore? I did that a few years back. I almost doubled my base-salary in the process. I was lucky that I previously did the hiring at the company I contracted for, so I knew exactly how much I could ask for. Here's a few things to remember: Assuming you're U.S., don't forget self-employment taxes. That's an extra 7.65% gone off the top. Health insurance is loving expensive. (but self-employed people get to write it off their taxes.) Luckily, with the ACA, you don't have to worry about IF you can get it anymore. Contractors have pauses between gigs. Your compensation should pay for the time required to find a gig. You now pay for your own hardware, software, internet, phone, and maybe travel (depending). Public companies often have weird motivations for reducing head count, and contractors don't add to head-count. They're willing to pay a premium for that. (efficiencies of capitalism!) You're negotiating. Ask high, settle lower. I had to form an LLC ($500/year here) I had to get both business liability and professional malpractice insurance as part of the contract, that was another $1500/year gone. (I don't think that's common)
|
|
#
?
Mar 23, 2016 13:36
|
|
|
|
| # ? May 9, 2024 22:54 |
|
|
Gounads posted:I did that a few years back. I almost doubled my base-salary in the process. I was lucky that I previously did the hiring at the company I contracted for, so I knew exactly how much I could ask for. I didn't realize that you were expected to pay for all your own devices, huh. I guess you can write that off though. In fact, there seems to be a ton of stuff you can write off - I guess an accountant won't go amiss around tax time. Any Canadians with opinions? I know at least benefits won't be an issue - OHIP plus my fiancee's benefits means I'm not going to be put out with respect to health stuff. I think my major bugaboos are the potential downtime between contracts and having to account for all of my taxes on my own.
|
|
#
?
Mar 23, 2016 16:50
|
|