|
Vulture Culture posted:If your business process involves data flowing across a pipeline, it doesn't matter if the entire pipeline is broken or just a piece of it -- you're down. From that perspective, it often makes more sense to have fewer potential points of failure, provided that the number of eggs in a single basket doesn't cause the cluster to fall over under the load. This comes with added complexity, but then you can architect the individual steps in a pipeline to have no single points of failure. You could alternatively duplicate the pipeline and bucket inputs to the correct pipeline. SPOFs can always be fixed, it's just a question of is the time and complexity worth it :/.
|
#
?
Dec 25, 2016 05:02
|
|
|
|
| # ? May 10, 2024 13:47 |
|
|
FamDav posted:This comes with added complexity, but then you can architect the individual steps in a pipeline to have no single points of failure. You could alternatively duplicate the pipeline and bucket inputs to the correct pipeline. https://www.youtube.com/watch?v=VTUrdizRZyw
|
|
#
?
Dec 27, 2016 03:15
|
|
|
I talked to a dude on another team at work the other day and their version of "agile" was pretty terrifying...
|
|
#
?
Dec 28, 2016 01:59
|
|
|
smackfu posted:[*]As a result of that, code quality is shoddy because acceptance is all that matters. The most frequent of Agile pitfalls...
|
|
#
?
Dec 28, 2016 02:06
|
|
|
Agile failures will never cease to amuse me. The entire point of agile is that you should be adaptable and change as the conditions do. Yet so many of the stories are "we will do agile in this extremely rigid way. Here is our agile process, which is set in stone and will never, ever change."
|
|
#
?
Dec 28, 2016 02:21
|
|
|
Vulture Culture posted:You could also duplicate the entire company so that if one company goes down you still have the other one. It's a trade off? For some companies and products, there's an overall goal to achieve higher availability by any means necessary. This includes isolating workloads and removing as many SPOFs from your infrastructure/application as possible. I even acknowledged that it costs more (in both money and complexity), so I don't get what your opposition is.
|
|
#
?
Dec 28, 2016 02:21
|
|
|
ToxicSlurpee posted:One real problem with UI design is that somebody with design skills probably lacks technical skills while somebody with technical skills probably lacks design skills. People with both are pretty hard to come by.
|
|
#
?
Dec 28, 2016 02:46
|
|
|
ToxicSlurpee posted:One real problem with UI design is that somebody with design skills probably lacks technical skills while somebody with technical skills probably lacks design skills. People with both are pretty hard to come by. I don't have much problem with this at all. I am primarily a UI developer, but have terrible design skills. I work with a designer to does, and he does the main HTML and CSS parts, and I wire it up with functionality. There is some healthy overlap where we can discuss performance issues or how feasible certain design requests are, but I think it works pretty well.
|
|
#
?
Dec 28, 2016 03:43
|
|
|
Anyone in an agency environment have any experience implementing / using Kanban? This place has been traditionally been something of a waterfall chop shop, but I've been given teeth and I'd prefer to not work in that kind of environment anymore. I'm trying to avoid Agilefall and anyone getting the idea that we need to hire a consultant to implement this. Some kind of reasonable middle ground.
|
|
#
?
Dec 28, 2016 04:05
|
|
|
FamDav posted:It's a trade off? For some companies and products, there's an overall goal to achieve higher availability by any means necessary. This includes isolating workloads and removing as many SPOFs from your infrastructure/application as possible.
|
|
#
?
Dec 28, 2016 05:31
|
|
|
my team consists of me and another dude and a few offshore folks our sprint planning is basically: "hey other dude, do these stories i made look appropriate to you" then we do whatever the hell we want for the next 3 weeks the business understands that we are providing value and not to gently caress with us we have no PM and no dedicated product. we fix the poo poo that the product teams can't be arsed (because it's hard) my jira graphs look funny but i solve this problem by schmoozing the jira lady works great so far
|
|
#
?
Dec 28, 2016 06:14
|
|
|
I'm getting dragged into more meetings lately and they're getting more and more pointless. I'm the "interim" scrum master on a "temporary" basis for the last year, which mostly just means I run the standups and am essentially the team lead (though I'm not getting paid any more for that responsibility HA HA HA HA HA). So the real managers with manager salaries schedule me for worthless meetings. The latest one I was scheduled for is an hour to talk about an upcoming requirement. This is easily the most "this meeting could have been an email" meeting yet, in fact the description of the meeting contains everything they'd need to write a goddamn story and get it into the backlog with everything else. Getting real sick of it. I'm actually going to talk to the guy who scheduled this and see if I can stop it from happening; at the very least if he can't provide me with a compelling reason that I need to be there before it actually becomes sprint work, I'm going to just put my foot down and not attend. I've been flexible about these things but I can only go so many days without touching a line of code before I hate everything.
|
|
#
?
Dec 28, 2016 11:52
|
|
|
JewKiller 3000 posted:the business understands that we are providing value and not to gently caress with us If you could write a book on how you achieved this, I'd buy it.
|
|
#
?
Dec 28, 2016 15:09
|
|
|
Iverron posted:Anyone in an agency environment have any experience implementing / using Kanban? This place has been traditionally been something of a waterfall chop shop, but I've been given teeth and I'd prefer to not work in that kind of environment anymore. I did a bunch of agency work using Kanban for a bit. What worked for our team: - Make sure everyone knows what your different columns mean, precisely, and when to move cards where. We had a lot of issues with people not wanting to move a story back to "in progress" after QA found an issue, because "cards all need to move forward!!!". That was dumb. - Groom your boards constantly, mercilessly. The goal of Kanban is to make it so everyone can pick up a card and start working on it with no further input. If you are the project manager or team lead, this should honestly take most of your time on the project. Duplicates need to be removed, priorities re-evaluated, and descriptions updated. The biggest problem I saw was devs being assigned to this role and not wanting to take their time away from coding, and not doing any of it, leading to a lot of cards being wrong, irrelevant, or useless. Having a good Kanban board is a productivity multiplier, but a bad one is worse than nothing. - The second biggest problem was project stakeholders assigning all the cards "top priority", or filling the "On Deck" column with the entire backlog. If everything is top priority, nothing is; your team will have a feeling of what is most important to do now, and will ignore your pile of "top priority" work. The system works if your team is confident that the board is the ultimate authority on priorities and details. If they are not, they will look to other sources of info, like meetings, rumors, or their own ideas of what is important.
|
|
#
?
Dec 28, 2016 17:05
|
|
|
Vulture Culture posted:You could also duplicate the entire company so that if one company goes down you still have the other one. lol if your offsite offline backup isn't embedded in the lunar regolith Just lol
|
|
#
?
Dec 28, 2016 22:09
|
|
|
vonnegutt posted:- Groom your boards constantly, mercilessly. The goal of Kanban is to make it so everyone can pick up a card and start working on it with no further input. If you are the project manager or team lead, this should honestly take most of your time on the project. Duplicates need to be removed, priorities re-evaluated, and descriptions updated. The biggest problem I saw was devs being assigned to this role and not wanting to take their time away from coding, and not doing any of it, leading to a lot of cards being wrong, irrelevant, or useless. Having a good Kanban board is a productivity multiplier, but a bad one is worse than nothing. (I'm not at an agency) We did some Kanban and the part where we threw away sprints was great -- I definitely did not miss Product constantly asking why one developer or another couldn't do a few more points this sprint. But I think Scrum really taught Product that they could mostly sit back and relax between the giant beginning/end-of-sprint meeting, and that didn't work with Kanban. It felt like if we were really doing it right it would be a ton of work for PMs and lots of it not very fun. It's too bad we didn't get to see what that looked like (at least not while I was there). We had plenty of problems where a story would get written and then 3 weeks later it's finally the top priority but all the UI needs to be re-designed because there have been so many other changes in between. I think if the PMs had spent 4 hours every day just going over the 4 stories at the top of the queue we could have gotten some real speed going.
|
|
#
?
Dec 30, 2016 19:41
|
|
|
Oh come on, you can't expect management to do actual work now, can you?
|
|
#
?
Dec 31, 2016 08:33
|
|
|
99% of all my troubles doing development professionally has been due to management being lazy and bad at their jobs. Badly specced requirements, poorly written stories, haphazard semi-scrum/fake kanban/agilefall, inevitable blaming of developers when things go awry. I really wish I worked somewhere that had good management.
|
|
#
?
Dec 31, 2016 16:13
|
|
|
Pollyanna posted:99% of all my troubles doing development professionally has been due to management being lazy and bad at their jobs. Badly specced requirements, poorly written stories, haphazard semi-scrum/fake kanban/agilefall, inevitable blaming of developers when things go awry. I really wish I worked somewhere that had good management. That's just a legend. Such a place does not exist.
|
|
#
?
Dec 31, 2016 16:18
|
|
|
Pollyanna posted:99% of all my troubles doing development professionally has been due to management being lazy and bad at their jobs. Badly specced requirements, poorly written stories, haphazard semi-scrum/fake kanban/agilefall, inevitable blaming of developers when things go awry. I really wish I worked somewhere that had good management. Tasking is something I've learned to fix myself given relatively loose guidelines. Any questions on specs you can just bring up with the relevant party phrased as yes/no questions to dissuade meetings. The issue is that usually they don't know what they want to fully specified detail, so asking them for that just frustrates them while still not giving you what you're after. I'm generally pretty happy with management as long as they can sustain deal flow and/or funding such that they can keep paying me and I have things to do. So about 30-40% of the time.
|
|
#
?
Dec 31, 2016 16:34
|
|
|
leper khan posted:Tasking is something I've learned to fix myself given relatively loose guidelines. Any questions on specs you can just bring up with the relevant party phrased as yes/no questions to dissuade meetings. The issue is that usually they don't know what they want to fully specified detail, so asking them for that just frustrates them while still not giving you what you're after. Yeah it can be difficult. I've done it where a dev was board organizer, and that worked out well for detailed specs, but they were usually lost to the team as a productive coder, due to having to attend all the different meetings. There was also friction between non-devs and devs, as there was the (somewhat correct) idea that the devs were prioritizing things differently than sales would be, preferring things that were well-specced and not going to be horrible kludges. Having non-dev management in charge is better politically, but can be really difficult in practice. Kanban is just a method for collecting and organizing communication, so if your team doesn't have good communication to start with, it's not going to be helped by a bunch of virtual index cards. I think that's at the root of my personal frustration with all these systems - they can't fix bad communication or replace hard work.
|
|
#
?
Dec 31, 2016 18:02
|
|
|
Pollyanna posted:99% of all my troubles doing development professionally has been due to management being lazy and bad at their jobs. Badly specced requirements, poorly written stories, haphazard semi-scrum/fake kanban/agilefall, inevitable blaming of developers when things go awry. I really wish I worked somewhere that had good management. I work at a smallish place and I can keep this from happening by having an impact on managements expectations. The biggest thing as a developer to do is to not let business deadlines affect the realistic deadline. IF the business has a deadline that is too early, you have to tell them that. Estimate your project well. I break my projects down into 3 hours increments when they enter the sprint. All in all, stay vigilant. It's easy as a developer to be a push over, make sure you don't let that happen. It constantly needs to be monitored
|
|
#
?
Dec 31, 2016 18:14
|
|
|
Pollyanna posted:99% of all my troubles doing development professionally has been due to management being lazy and bad at their jobs. Badly specced requirements, poorly written stories, haphazard semi-scrum/fake kanban/agilefall, inevitable blaming of developers when things go awry. I really wish I worked somewhere that had good management.
|
|
#
?
Dec 31, 2016 19:12
|
|
|
Once had several stories where the description was just the vague title stated again. With priority 1. Everything was priority 1.
|
|
#
?
Dec 31, 2016 19:22
|
|
|
Vulture Culture posted:Can you clarify what you mean by "poorly written stories"? There was one where the title was "able to view other users" and the body was "." (Because Jira prevented you from having an empty body!) There were many that (often incorrectly) described how to implement something on the back-end without saying why we'd want to "split [a database query] into two separate queries using promises". There were a bunch of client stories that had no text, just 4-8 photoshopped screen-shots (not wire-frames). The client devs complained enough that that mostly stopped.
|
|
#
?
Dec 31, 2016 20:08
|
|
|
Vulture Culture posted:Can you clarify what you mean by "poorly written stories"? Title: Calculator input form Body: Expectation: Fully-implemented portion of full-stack application that looks exactly like the prototype. Incremental improvement, what's that?
|
|
#
?
Dec 31, 2016 21:43
|
|
|
Pollyanna posted:Title: Calculator input form Ah, sounds like my last job. I quit that place after 4 months.
|
|
#
?
Dec 31, 2016 22:17
|
|
|
Gildiss posted:Once had several stories where the description was just the vague title stated again. With priority 1. Everything was priority 1. The dumbest thing I saw at work was something labeled "high priority" that I was told had to be done quickly because it was a huge deal. So many things going on at work were going to rely on it. It was put on the issue list with a due date of October 31. Well, guess what? I finished it on October 17. It still hasn't been code reviewed at all. It's just sitting there in the queue waiting to be looked at. Pretty annoying but I just kind of shrug about stuff like that at this point.
|
|
#
?
Dec 31, 2016 22:48
|
|
|
rt4 posted:Ah, sounds like my last job. I quit that place after 4 months. I am on that job for four years now.
|
|
#
?
Dec 31, 2016 23:24
|
|
|
Thanks all. Unfortunately the 20,000 ft explanation mostly met blank stares or disinterest.  vonnegutt posted:Kanban is just a method for collecting and organizing communication, so if your team doesn't have good communication to start with, it's not going to be helped by a bunch of virtual index cards. I think that's at the root of my personal frustration with all these systems - they can't fix bad communication or replace hard work. We definitely have this issue. After a recent exodus, every single non-developer in the company is entirely non-technical. From recent conversations it appears that things will stay that way for the next while. We've been through before why this isn't a good idea, but this place has a short memory of late.
|
|
#
?
Dec 31, 2016 23:55
|
|
|
Not gonna lie, the lovely stories are pissing me off enough that they're making me paranoid re: them being turned around on me. I might have to lobby for better tickets just to cover my rear end.ToxicSlurpee posted:The dumbest thing I saw at work was something labeled "high priority" that I was told had to be done quickly because it was a huge deal. So many things going on at work were going to rely on it. It was put on the issue list with a due date of October 31. Yep, this seems pretty typical. 
|
|
#
?
Jan 1, 2017 00:31
|
|
|
Our product owner is also our chief sales engineer, and he spends most of his time doing the latter. It's not really his fault, he was a sales engineer before we started on scrum and they just dumped another full time job on him; of course he's not going to give it the time it needs. But our stories were bad. Our stories were just broad product roadmap objectives that we would have to break down enough to at least think about, during the planning meeting. There were never any acceptance criteria, and nothing was even prioritized correctly. As in, every planning meeting the product owner would change priorities on us, usually after we had nailed everything down. Because he never did product owner poo poo every day like product owners are supposed to. All this made planning excessively painful and frustrating, to the point where I was afraid we were going to lose some of our most experienced people because they really don't have to put up with bullshit if they don't want to. That's changed lately; the rest of the product team has recognized some of the problems and have spent a lot of time the past couple sprints grooming the backlog. They will go through and create well-defined requirements, to the point where they're basically user stories that we can work on and show during review. They will send poo poo that's too vague back to the product owner and get something reasonable. They talk to us ahead of time to get our opinions on things, before planning (the way the product owner is supposed to), so they can come up with decent stories. This effort on their part has turned sprint planning from something I intensely dread to something that's, dare I say it, productive. I still don't like it, it's a long-rear end meeting and those are always draining, but I no longer come away from it hating everything and thinking about finding a new job. The rest of the team seems much more upbeat about the situation too. The process is still far from perfect, but the difference so far has been night and day.
|
|
#
?
Jan 1, 2017 02:49
|
|
|
Did anyone blame the Devs for "missing" things when the stories were quarter-assed? Because that sounds pretty familiar.
|
|
#
?
Jan 1, 2017 04:45
|
|
|
Pollyanna posted:Title: Calculator input form Isn't it expected of you/your team to analyze and break it down further then? I know it's different everywhere but at my place we basically get handed entire features like that and then we break it down into several stories/tasks.
|
|
#
?
Jan 1, 2017 12:57
|
|
|
netcat posted:Isn't it expected of you/your team to analyze and break it down further then? I know it's different everywhere but at my place we basically get handed entire features like that and then we break it down into several stories/tasks.
|
|
#
?
Jan 1, 2017 16:00
|
|
|
netcat posted:Isn't it expected of you/your team to analyze and break it down further then? I know it's different everywhere but at my place we basically get handed entire features like that and then we break it down into several stories/tasks. That is the broken down version. What I end up doing is looking at the parent story and writing down the requirements/my own breakdown in the ticket before I work on it, just so people aren't like "BUT I EXPECTED THIS" because I constantly run into that problem and am extremely sick of it.  I have a question. When is it appropriate to use a Scrum-like approach, and when is it more appropriate to use a Kanban-like approach? I've found that for projects that aren't super heavily structured and are kind of pick-things-up-and-work-on-them like ours, Kanban works way better than Scrum because nobody really knows how much is gonna be worked on and when things will be done. v  v (But we still do Scrum because management is absolutely terrified of not having numbers and estimates and things to judge worth, value, and performance with.)
Pollyanna fucked around with this message at 16:14 on Jan 1, 2017 |
|
#
?
Jan 1, 2017 16:12
|
|
|
Pollyanna posted:I have a question. When is it appropriate to use a Scrum-like approach, and when is it more appropriate to use a Kanban-like approach? I've found that for projects that aren't super heavily structured and are kind of pick-things-up-and-work-on-them like ours, Kanban works way better than Scrum because nobody really knows how much is gonna be worked on and when things will be done. v
|
|
#
?
Jan 1, 2017 17:19
|
|
|
Pollyanna posted:I have a question. When is it appropriate to use a Scrum-like approach, and when is it more appropriate to use a Kanban-like approach? I've found that for projects that aren't super heavily structured and are kind of pick-things-up-and-work-on-them like ours, Kanban works way better than Scrum because nobody really knows how much is gonna be worked on and when things will be done. v Lots of ways to blend between the two. Google: Scrumban
|
|
#
?
Jan 1, 2017 17:35
|
|
|
I've managed to keep sales / product from having too much weight through strategic under-promising and over-delivering. The idea is that you get some of what's being asked for that is actually mapped to "this will make us money and is not just us being jerked around due to a bad sales person being led on by bad prospects" (think trying to hit on a girl out of your league by buying her expensive drinks or even jewelry - that's unrealistic). The over-delivering is a wildcard that was harder and worked on across multiple sprints - sales never looked at our work despite being visible to them, imagine that. This means sales got a random big feature that they weren't actually prepared to sell, so they would try different prospects constantly while they were given assurances of meeting quotas with the promised features. I had a great relationship with the guys in sales and product and wrote product roadmaps based upon actual customer reality instead of a dedicated PM that felt like obligated to put something down to look important or whatever. If nobody's interested in anything besides harder stuff, it's silly to distract a team with shiny BS. I think that sales-eng is probably a far more important dynamic and culture overall than so-called devops.
|
|
#
?
Jan 1, 2017 18:04
|
|
|
|
| # ? May 10, 2024 13:47 |
|
|
Iverron posted:Did anyone blame the Devs for "missing" things when the stories were quarter-assed? Because that sounds pretty familiar. There was some whining from the product owner about tasks being on the board for such a long time, as if he expected vague epics to get done in two weeks just because we were doing two week sprints. But we haven't been officially reprimanded for not getting things done or anything like that. I think that's partly because we do make lots of incremental progress on our tasks (they're just huge epic tasks so at the high-level overview of the product roadmap it doesn't look like it moves very fast). And partly because we're on a skeleton crew and we have approximately 8 years of new development in our "our customer wants this soon" pile, and they know if they start yelling at us about their complete inability to plan or staff correctly, people are just going to get a new gig that at least pays better, and the company is going to be in even more dire straits. It sounds kind of bad writing this out but really the situation isn't really stressful. We are so far underwater when it comes to imminent fetures and overpromises that there's no amount of extra effort we could put in that would even make a significant dent. So it's just, get done what we can get done, and let the business people deal with the consequences.
|
|
#
?
Jan 1, 2017 21:16
|
|