|
Scrum™ has been calling them "sprint forecasts" not "sprint commitments" for years now to address the implications of a "commitment". Failing to complete all the tasks (or completing way more than expected) is a failure of estimation. At retrospective you should try to work out why the forecast was off, unexpected absences are obvious but for stories that blew out (or were overestimated) the dev team should consider what assumptions they made that led to that. From there either take steps to address that (eg. new policy of getting all copy to legal for approval before a story is ready to be brought into a sprint) or just keep it in mind for future estimation (eg. anything touching external system X takes a lot more integration testing that expected). Estimates improve over the lifetime of a project as you learn more this way. The idea of working in sprints is that the development team know what they're expecting to work on over a set time period and locks out the product owner from chopping and changing priorities daily. If you've worked somewhere where the PO can walk in and say "just had a meeting with client X, we need feature Y now, drop everything else" as a regular thing you will appreciate that. The length of a sprint should be decided by the product owner based on how quickly they expect priorities to change, if things are fairly stable they might be happy with one month sprints, if they're expecting to make lots of changes as the project develops then one week gives them more flexibility but forces work to be broken into smaller chunks (with some overhead). (If there is a huge shift in business priorities then can be a valid choice to cancel a sprint and immediately start a new one, this shouldn't happen often and the PO has to accept that all work done in the cancelled sprint is effectively lost and that time is wasted.) As with all things the actual planning requirements and interactions between people change for every project so try to be reasonable about things. Scrum is a framework for getting teams into agile development and away from a multi-month waterfall model, both in terms of regular delivery of features and feedback loops but also in terms of redefining the expectations and relationships between the development team and the product owner. Once a team is more mature you're able to assess which bits are working for you and what you'd like to change.
|
#
¿
Dec 23, 2015 11:28
|
|
|
|
| # ¿ Apr 28, 2024 08:35 |
|
|
Xarn posted:This is also how you can tell whether a team is doing Agile or agile. Sadly I think its much more common for this to never happen than it is for it to happen. Che Delilas posted:In particular I'm not fond of the meetings that bookend each sprint - they're long and tiring and in my specific case our product owner is not fully participating, which is kind of a problem. There are reasons, but I know this will need to get addressed or this process won't work. I think it's mostly an education thing, scrum has been sold as "do these things, be successful" but most of the value is understanding the issues that those processes are there to solve. Changing your process is okay as long as you know what the original point of the process was for, and you understand how the changes help your team while still achieving the original goals. Not meaning to pick on you Che Delilas, you do sound like you've got the right idea. If you aren't getting the value you expect out of your ceremonies then that's something to discuss at retrospective, make sure everyone is aware of what you should be achieving there and work together to find a way to make that happen. Maybe you change the process, maybe you just reschedule some of your recurring meetings, maybe you do some of them more ad-hoc when the PO is available (but have a way of tracking/ensuring it happens).
|
|
#
¿
Dec 23, 2015 15:59
|
|
|
Ender.uNF posted:The non-joke answer is to gain enough experience to know how to manage upwards, build consensus among key team members, then just start doing poo poo the way it should be done and use your built-up social and technical capital to make the team follow. Then act like it's always been done this way and why are you rocking the boat now coworker peon Bob and/or manager PHB Stacy? The sheep will follow. Ender.uNF posted:You can build a poo poo-ton of capital by looking for highly desired features that haven't been delivered yet then doing them on your own without telling anyone (thus no opportunities to gently caress it up or say no). It requires doing a poo poo-ton of homework, being able to put on your designer and product hats, and making absolutely sure you are delivering something of high value to the business. You also need to reveal it in the appropriate context (eg where the sales team or CEO sees it before middle management can claim credit for it or squash it). Watch for people who want to hitch themselves to your success-wagon and use them to legitimize the process (eg the PM who feels frustrated and knows you can get things done; your next cowboy feature then becomes an official feature "requested by product"). There are so many ways this goes wrong, and the fantasy that you'll do some reveal to C-level and they'll all think you're a diamond in the rough and make you the new management is a joke.
|
|
#
¿
Jan 24, 2016 11:52
|
|
|
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
|
|
|
Munkeymon posted:Not necessarily. I'm a consultant employed full time by one company and working at a different company, as in I show up at the client and put in eight hour days that my company bills the client for. If I'm not billing hours I'm supposed to show up at the home office and work on something relevant to my professional education, which can be getting paid to tinker with personal projects if you want it to be. I'm pretty happy with the arrangement so far because I can change jobs often without the stupid bullshit involved in actually changing jobs in America or the resume stains and that's been great for networking so far. I'm sure all of this varies by agency but I don't have to travel and I get paid for overtime if the client is even willing to allow overtime - so far they haven't and I'm enjoying my actual 40 hour weeks. The downsides are that I feel like a temp in that I have a hard time caring a lot about stuff like culture, socializing and team building and generally am not treated quite as well as the FTEs as far as office furniture and equipment, but some places are penny wise pound foolish like that.
|
|
#
¿
Mar 29, 2016 18:22
|
|
|
The idea is more like "cover all branches" not "all inputs". If you're testing something that takes two integers you should be thinking about things like the a < b, a > b, a == b, one zero or negative, both zero or negative, both high enough to overflow if you add them. Obviously it always depends on what you're doing, but you should aim to exercise all the different paths in your code. Sometimes it's also worth putting tests in that you think are obvious if makes it easier for others to check their assumptions about your code too. Disclaimer: You always need to consider the effort vs provided value when you're writing tests.
|
|
#
¿
Oct 10, 2016 16:41
|
|
|
In defence of estimates/velocity: Good estimates can help with feature prioritisation in time sensitive projects. Good estimates can give you projections of estimated completion dates. Doing estimates as a group can be useful to share knowledge and expectations (especially if everyone isn't involved in grooming). Tracking expected/completed work in a sprint and reviewing it with the team can help reveal problems in your estimation, or to surface distractions or impediments the team had to deal with. Sometimes falling velocity can be useful to force issues with management eg. "our tech debt is getting to painful levels", "we have to support this other team too much", "we had too many bugs need to spend more time on testing". It is misused constantly though and what you should push when people get lovely about velocity is: Failing meet the sprint forecast is either due to incorrect estimates or misunderstanding of the team's availability that sprint.
|
|
#
¿
Jan 5, 2017 19:56
|
|
|
Swearing can also be a team inclusion thing. Eg. if you don't swear when upper management or other departments are around but within your own team you do. A group can show they trust or accept you if they're willing to swear in your presence where they wouldn't otherwise.
|
|
#
¿
Jan 12, 2017 20:05
|
|
|
I've seen resumes with keyword sections divided roughly as "strong in", "capable in", and "interested in". It's a good way to show you're doing more than one thing but are self aware enough to rate yourself. edit: this is probably more suited to the Newbies/Oldies get a job threads.
|
|
#
¿
Jan 24, 2017 20:41
|
|
|
I'm only involved at a technical interview stage so I don't know about HR / recruiter preferences. Ideally you seperate the things you can go into depth in like "I work in Java every day, I can talk about the jvm, standard tooling, best practices, libraries etc." and your more incidental stuff like "I have done some work on small Python projects or scripting and am happy reading and writing it but I'm pulling up a reference a lot and can't tell you the current best web framework". It helps make your past experience clear and gives you more to talk about without opening yourself up to someone asking you c++ minutiae. "I've read a bunch about this but haven't had a chance to try it" probably shouldn't be on a resume unless it's clearly a "I'm interested in blah" and that aligns with the job posting.
|
|
#
¿
Jan 24, 2017 21:43
|
|
|
lifg posted:So what is the value of estimating points over estimating hours? Also at the end of the sprint when the forecast was wrong the discussion is "why did we only complete 17 points not the 24 we expected?" not "why did you lazy fucks only work 226 of the 320 hours in the last fortnight?". AskYourself posted:I find myself being the scrummaster of a small team as the boss asked me to help introduce Agile to the team. I've been very relaxed about it as I've experienced this transition a few times already.
|
|
#
¿
Jan 31, 2017 08:40
|
|
|
lifg posted:So if you assign story points, does that mean that you don't estimate hours? In this thread, yes, they become directly translatable to hours. The goal is for it not to work that way though, they should be a measure of expected effort. That might include things like working with other teams or coordinating with other parts of the organisation that you can't really estimate hours on. If you want to do estimates for the team to coordinate around and to communicate relative sizes to a manager without committing to points or velocities then S/M/L/XL instead of points can work. I should say that on my current project we have a really good PO and we do no estimates.
|
|
#
¿
Jan 31, 2017 18:19
|
|
|
Khisanth Magus posted:Was wondering if I could get some advice from this thread. A month or so ago our only Sr developer was fired(which is a very long story, but the short of it was that he brought it on himself), and next week our manager is interviewing 2 candidates for the open position. The kicker is that he would like me and one other team member to also interview the people, both to ensure that they actually know their stuff and that they would be a good fit for the team. Neither of us have ever interviewed anyone before, and most of the interviews I've been on the other end of have been complete bullshit. I don't see any real value to asking someone to code some algorithm on a whiteboard. So I was wondering if anyone knew of any good resources I could read to find good interview questions for a Sr dev position. "I see you've done some angular and some react, which do you prefer?" "If you were starting a new project, why would you pick one over another?" "Have you run into any problems with that one?" "Are there situations where you'd recommend the other one?" "Anything else you have to be aware of when starting out a new project with that / introducing it to a project?" It's a good check that they've actually used the technologies, a couple of years ago everyone did a five minute tutorial on angular then put it on their CV. You also get to see what sort of tradeoffs they consider and how well they can communicate the technical choices they would make.
|
|
#
¿
Feb 23, 2017 17:31
|
|
|
State provided health care, reasonable social safety net, 37 hour work week, five weeks paid leave as standard?
|
|
#
¿
Mar 9, 2017 23:01
|
|
|
Ask them to pair review it with you.
|
|
#
¿
Aug 9, 2017 21:47
|
|
|
Single point of return doesn't really help though if you're declaring a local "ret_val" variable at the top and conditionally setting it in a bunch of branches. You still have to trace through the logic to see which assignment happens in each case and you don't even get the assurance that it's the final value and nothing else will mess with it.
|
|
#
¿
Aug 21, 2017 23:07
|
|
|
Messyass posted:Although they are quite rare, competent product owners do exist. If you need a dedicated external person to unblock things for your team then you don't have everything you need in your team to deliver the product. That person could be providing real value and it's probably fine for them to be the SM as well but it's not a requirement of the SM role that they run around doing that stuff for you.
|
|
#
¿
Oct 2, 2017 18:25
|
|
|
Specifically for C# you should get a license for Resharper which will give you lots of hints about where the newer features will cut down on code and where you don't match the standard naming conventions. Aside from some of the really out there LINQ translations you should pretty much always follow it's suggestions. For project level layout it's down to experience and exposure to different projects though.
|
|
#
¿
Dec 6, 2017 18:29
|
|
|
vonnegutt posted:honestly did you ask any questions in your interviews at all Seriously quote:How big are your teams?
|
|
#
¿
Dec 9, 2017 12:52
|
|
|
Portland Sucks posted:My tech lead is finally starting to come around to the idea of not intentionally writing poo poo code (aka. it's better to copy paste than write functions because then you can see the code on the screen right away!). Anyone know of any good, concise, documents on good fundamentals of code design I can either give him or use as a training aid to dig us out of this hole? Simple starting points are code review where you question anything that isn't immediately obvious. Whether it's making longer variable names, adding comments to explain for external constraints (eg. 'this external library/hardware needs poking twice before it works'), simplifying control flow, or pulling repeated code out to functions, you goal should be the most understandable code possible. Function extraction, patterns, and objects all follow from making maintainable code in different settings but they aren't a magical goal in themselves.
|
|
#
¿
Dec 29, 2017 21:53
|
|
|
If you don't need a complicated build set up (eg. output of this build feeds into these three builds) I'd aim for a simple hosted service like Travis or AppVeyor, otherwise you're looking at TeamCity or similar. And a paid GitHub account for (a), (b) and (g). It's pretty straight forward to tie those sort of build solutions into the GitHub pull request process so you can have your tests run and report coverage as part of the code review process if you set them to run in the build. If you need a more complicated issue tracker then JIRA is the big one, I'm not sure what the options are halfway. For the perf testing I think you'll need to give us a bit more information about what you're expecting to do/automate. If you can get away with not self-hosting I'd always recommend that. Otherwise you will run into crap like the git server running out of disk space, dealing with patching your build agents, provisioning new servers when you want to run more concurrent builds...
|
|
#
¿
Jan 15, 2018 17:20
|
|
|
comedyblissoption posted:I've personally had the displeasure of working under a milder version of this failure. If you finished working on stuff early in a sprint, you were encouraged to find a tiny (often low value) story you could squeeze into the sprint instead of getting started early on the next big thing. We'd miss deadlines working on stupid bullshit instead of high priority items because of this foolishness. Using sprints as short term deadlines also goes against the intention. Failing to meet the sprint commitment should be seen as a failure of estimation, not of delivery. That's the one you see misinterpreted/abused the most though because it's the easiest to measure for management. I don't do scrum anymore and I don't know why you wouldn't be allowed to get a head start on the higher priority items though 
|
|
#
¿
Aug 30, 2018 23:44
|
|
|
sunaurus posted:A happy story Good places do exist. I'm in a similar situation where the level of product and engineering culture, tooling, and support are fantastic and there's always a focus on improving. It's to the level that our less experienced developers don't appreciate how lucky they are to have the autonomy and productivity we do. I'm trying to work out if there's a good repeatable way to find places like this without just word of mouth. This one I found nearly four years ago by searching job listings for a specific automated deployment system because I figured if they were using that they must be fairly advanced. I'm not sure what I'd use these days, I think a lot of the management/product side of the culture matters a lot but that's much harder to read from the outside.
|
|
#
¿
Mar 13, 2019 00:29
|
|
|
ultrafilter posted:This. Everything that's written down is a paper trail that can be used to justify a firing. In the happy case having informal feedback processes is good for your own development, but they're also much harder to use to argue for raises.
|
|
#
¿
May 6, 2020 18:42
|
|
|
CPColin posted:I remember one time they handed me a laptop to do the coding exercise on and it was a loving Mac so I knew precisely none of the keyboard shortcuts. "Uh. How do you bring up the Dev Console? This keyboard doesn't have an F12 key."
|
|
#
¿
May 26, 2020 17:04
|
|
|
Prism Mirror Lens posted:Using “key/value” as a shorthand for “user-facing string/internal value” is pretty common. I guess it varies which way round people choose to say key and value... but if you call the string the value and the value the key I don’t want to work with you
|
|
#
¿
Jul 29, 2020 17:34
|
|
|
The ones I’ve been part of have been two days inside company time. Not many “features” ever made it into being adopted by teams to make it to production but some cool internal dev tools came out of them. The value was always a couple of days developing with sometimes new tech with a mix of people you didn’t normally work with.
|
|
#
¿
Sep 3, 2020 08:01
|
|
|
Pedestrian Xing posted:Well doctors get paid based on how many tests they run, why should developers be any different? If you've got the team on your side (or maybe only loop in the lead) can you just measure it for a week or two? Rough hours of each of those for the team then take it to whomever and say 35% of time is on these new responsibilities which means what would be a two month new work estimate will now be three months. Probably worse with context switching and prod emergency situations.
|
|
#
¿
Sep 16, 2020 20:04
|
|
|
Also late to the PM chat but my experience with a few good PMs has been that they've been able to bring the team along on why something is being built. For example "We're building this new onboarding flow because we know if customers integrate with this feature they are twice as likely to renew their contracts, and currently only 30% of new customers enable this". That will also let you use the knowledge and creativity of the team to achieve that goal rather than them just plugging away at "As a customer, when I click Get Started button I will begin the integration wizard so that I can integrate". Step one is obviously having leadership support for your teams working at goals like that and not feature checklists from sales, step two is getting good at data and experimentation to be able to decide what the most impactful thing to build is for any given goal. @johncutlefish on twitter is good in this space.
|
|
#
¿
Sep 16, 2020 20:34
|
|
|
Vulture Culture posted:SLI/SLO are interesting, but I feel like they're of principal use to business that already have pretty robust decision-making processes. Where they really shine is when you want to transition operations away from central ops and onto product teams, and you need the right guardrails in place to ensure product teams can own their own availability while keeping reliability and feature development in tension. This is really well stated and helpful, thank you.
|
|
#
¿
Nov 3, 2020 21:58
|
|
|
HappyHippo posted:Presumably they could be donated or given away? Places I've worked have sold them to a corporate reseller at a discount who I guess refurb them and resell them.
|
|
#
¿
Feb 24, 2022 17:49
|
|
|
We’ve got a halfway solution where our team which is responsible for multiple products (within a larger organisation) has them in a single repo using turbo/yarn workspaces. In practice it allows multiple deployable projects to reference “@lib/design-system” and our other reusable pieces without having to split them out and actually package/version them. It works well enough and we do have builds that trigger only on certain paths that means slower moving services aren’t bothered often. We are full into typescript across everything though which makes the tooling easier.
|
|
#
¿
Jul 9, 2022 18:16
|
|
|
Is the pain point Rails, or it being a monolith, or the single SQL database? What do you want to be better or easier once you've fixed this?
|
|
#
¿
Aug 7, 2022 14:09
|
|
|
prom candy posted:The pain point for me is 90% Rails. I want end to end type safety and a language with better DX. And no more inheritance nonsense and no more magic. I've been using Rails for 15 years so it's not like I don't understand it, I just don't believe it's a good solution for 2022's problems. In that case I would start finding pieces you can cut off and make into another service, but keep the same data store for now. When you have a new big feature or rework of an area, see if you can draw a line around that part of the data model and business logic and try to build it out as a separate service. Maybe it's the user profile functionality, let the rest of the code still join for presenting search results if you need, but get an agreement that this new service "owns" the tables involved and is the only place you can write to them or do migrations. (You can always create a new db user for the new service and set up table permissions if that helps with discipline.) Then you build your typed datamodels for the users and profiles and whatever in the service that owns those tables, and present the new version of those API to your apps. That should give you an idea of how nice or not it is having a separate service. You'll have to address having two sets of logs, monitoring and alarms, deployments and all those fun things so don't underestimate the overhead setting up the first one of these. Tying it to ongoing feature work will make it easier to say something is "done" for now. Further down the road you can think about splitting the data up, once the data models and ownership are more defined it will be easier to think about what needs to be colocated or has interesting data access patterns. You also might find it's fine just migrating slowly to another monolith.
|
|
#
¿
Aug 7, 2022 17:31
|
|
|
Falcon2001 posted:I wish someone could explain to me what the benefit of scrum is supposed to be (over a simple Kanban priority system), as I've never worked in an environment where we weren't randomized enough the idea of 'commit to what you're doing for the next two weeks' is just ridiculous. Maybe it's just a different team setup thing? Scrum came out as a reaction to dev teams being pulled in many directions at once, like situations where VPs, sales, various project managers etc would all walk up to your desk and demand status updates or expect work done immediately. The point of the PM role was to centralise decision making on that to take those fights away from the dev team. Locked sprint length with capacity planning etc was meant to give teams certainty of priority for a set time. Ideally it was to force stakeholders to commit to priorities, not hold the team accountable. You can see this a bit in the literature that the sprint length should be decided at the start of the project around how often the stakeholders would like an escape hatch if they need to change direction. If your team and organisation are mature enough to deal with kanban there’s no on paper reason scrum would necessarily be better. It was intended to improve places that were even worse.
|
|
#
¿
Jun 7, 2023 13:02
|
|
|
prom candy posted:For PRs how do you handle a scenario where you have a bunch of tickets that are pretty closely related? Like for example today I have to add a screen which is a list of things and then there are a few extra tickets for simple things that you can do with each list item. My preference would be to batch these all into a single PR because otherwise I'm going to wind up waiting around for approval between each one, because one step is dependent on another. Would you just stack like 3-4 tickets into a single PR if the changes are simple enough? The reason they're 3-4 tickets is because when we get into it QA and Design Review it's annoying to have one larger ticket getting kicked back and forth and keeping track of the requested changes. If you go back to the point of PRs being a risk reduction (of bugs, misunderstandings, miscommunication, and siloed knowledge) then it’s really about what is easiest to review/understand. If you can do it in one hit go for it? Or if you’re making peoples jobs easier with a few that match your tickets do that.
|
|
#
¿
Jul 10, 2023 16:11
|
|
|
|
| # ¿ Apr 28, 2024 08:35 |
|
|
SurgicalOntologist posted:For context, we're a small startup (30-40 total), already generating revenue but not enough yet to fully support the business, funded by industry partners not VC, all the engineers are 100% remote though most are in commuting distance to the office, several are abroad. Comp target for now is basically 50th percentile in the market, which is enough to assemble a good team but doesn't make it easy. I guess for the COL question, the easiest would be to get market data from the candidate's market, but so far we only found a way to get data from our home market. I work for a similar sized company in EU with people also in the US. Most of the team is fully remote and they don’t have any COL adjustments, and have consistent salary points for each level (so no bands, every 3.2 engineer is paid the same). We’ve since moved for my partners work (she’s in academia) and I can’t accept my work suddenly being worth less to the company because I’m remote from a different place in the same timezone.
|
|
#
¿
Feb 26, 2024 19:53
|
|