|
I'm about to  out of here, holy balls.Working on 1 of several "disciplined agile delivery" teams. The Business, i.e. product managers and project managers are still 100% waterfall. They still want us to do time estimates for every task and story, track time spent, etc. Since Product is waterfall, there is no backlog, there is a project backlog where all the waterfall'd specs were entered into TFS as work items. Then, each team commits someone to the maintenance hunger games as tribute to be the "maintenance person" for that sprint. That means, they are expected to spend 80% of their time pull poo poo from the "maintenance backlog". There is no Product Owner (in the agile sense) or Scrum master and any team could have 3-4 sources that drive prioritization. So, of course there's lots of omgfire emails asking devs to drop everything and fix this thing that everyone ignored for a year and oh no here comes the waterfall deadline and/or Federal auditors. I've been telling these people since I started "this is going to break unless you get some product owners and/or scrum masters". Welp, can't do that because there's too many products with too many product managers and there aren't enough dev teams to dedicate one team to a product. My response has been "Then organize into business units. half these products are basically the same thing, anyway." Meanwhile, I'm staring at a help desk ticket I submitted 6 loving months ago to get IS Security approval for installing Atom on my desktop. Don't get me started on that mess. What they don't know is that I have 2nd interview at a place next week that follows every item on the Joel Test and gives devs Aeron chairs, free lunch every day, and free sodas. (I asked management to consider free drinks for devs and got told "nope, too expensive for a company our size".) But Google/Miscrosoft do it... "we're not doing it, kthx". Not saying that free drinks is the most important thing, but the culture here is pretty toxic. I could see this place being the best place to work in this market in like 5 years, but they've about beaten all the fight out of me, at this point.
|
#
¿
Jan 27, 2016 20:51
|
|
|
|
| # ¿ May 6, 2024 01:30 |
|
|
Messyass posted:Has anybody ever actually had the luxury of a product owner who: Yeah, I've had a PO that did all those, although it was a small team where the PO was also the senior architect and worked closely with the Director (basically the Business) to manage his expectations and do the whole "Okay, we can certainly work on this, but which of these other priorities should get bumped to make room in the next iteration, etc." But really, as a dev, I don't need a PO that does #2 and #3. Dev should have the mandate to make decisions (about implementation, anyway). I don't need daily checkins from the PO, really. My understanding of Agile is that the PO translates requests from the Business into user stories and working with the Scrum Master (if there is one) to groom and prioritize the backlog.
|
|
#
¿
Jan 28, 2016 21:21
|
|
|
Click Beelay posted:Crossposted from the front-end thread as I didn't realize nobody's posted there in a week, sorry! Doesn't sound hosed to me. Sounds like typical programming job. As a backend guy, I would definitely manage expectations about doing frontend work, but with these modern js frameworks, it ends up being a lot like backend code anyway; you'll end up with models, controllers, etc. that follow some very similar paradigms, but instead of making calls against a database, you're making calls against an AJAX service.
|
|
#
¿
Jan 28, 2016 21:25
|
|
|
csammis posted:Decision making by the PO is not supposed to be about implementation. POs need to have the ability to make decisions about prioritization and requirements, and unfortunately I've had far too many experiences where the PO's prioritization is overridden by executives or other jokers who just want to satisfy the latest biggest deal. But that sounds correct. Business sets the priorities. Product Owner is there to make sure the new priorities are reflected in the backlog, not to decide whether or not Priority A is more important than Priority B.
|
|
#
¿
Jan 28, 2016 22:43
|
|
|
pigdog posted:That's actually kind of exactly what PO does. The team does what the PO says needs doing, period (as opposed to CFO or whoever barging in). If a stakeholder absolutely requires the team to work on something, then she talks to the PO and the PO rearranges the product backlog. How the stakeholder manages to compel the PO arrange the backlog to reflect her priorities may vary. The business guy may feel it's very important for the team to drop everything and make a feature, but the lawyers may feel it's even more important to comply with some regulations by some deadline, the security officer may feel it's most important to fix a glaring vulnerability, etc. It's the PO's job to ultimately make these decisions for the team. I see what you are saying, I think, and yeah, you're right. So, in setting up a PO, Dev needs to establish that they're the department that decides when and how things are worked on, then. Which I also believe.
|
|
#
¿
Jan 29, 2016 06:04
|
|
|
Vulture Culture posted:Without digressing into specific ways that CS departments may or may not meet the needs of their students, most CS departments are an absolute shitshow. As a project my final year of college, I did an assessment of the college's curriculum, working with the department secretary. We found that the department didn't even have quantitative data on the students in order to make reasonable decisions about what they should be teaching. They had no idea of who came in to gain a theoretical grounding in computation versus people who wanted to learn skills for a development job, they had no idea what outcomes were for people graduating from the program. They didn't know the math SAT scores of incoming students and they didn't even have the retention rate for how many students who declared computer science as a major were still in the program a year later. We asked to present our findings at their annual curriculum design meeting and discovered they didn't have one (they do now). My previous job was running an on campus team of developers, and we had about 6 full-timers, and about 12-18 students. The best student developers were always the Info Systems majors from the business school, because their curriculum spent significant chunks of time creating software solutions for real-world companies in the local area. The IT major guys were usually pretty good, too. CS majors were good kids, but they could always be counted on to submit pull requests that contained some kind of overengineered, impossible to maintain solution that would be guaranteed to break when faced with edge cases and be super-hard to refactor. Most of my time was spent training them in basic design patterns and un-teaching them some of the horrible habits the CS dept seems to love like monolithic methods and classes, inherit all the things, etc. Like all a modern CS department would need to do is teach C#/java, basic design patterns, SOLID, algorithm analysis (Big O), RDBMS, and stuff like that. Leave the compiler writing and other stuff to graduate courses, IMO.
|
|
#
¿
Feb 1, 2016 19:30
|
|
|
Cuntpunch posted:What I'm saying is that people go so goddamn hung up on these *ideas* without *practical application* that means a drat, that they end up figuring if they can quote SOLID or draw a Factory Pattern, that's all that matters. Want to develop software? Great! It's a cool job! But learn it by *DOING IT* not by *reading about it*. The constant fallback of the bad developer to tropes and terminology just points to me as a failing of spending too much time *reading* about how nails work, rather than hammering wood together. I can't refute what you are saying because, to be fair, I've encountered very few "bad" developers. I've met a lot of inexperienced developers that just needed the right training and experience.
|
|
#
¿
Feb 1, 2016 22:33
|
|
|
ChickenWing posted:Man, I always thought my school had a poo poo CompSci program. It gets a bad rap from a lot of other schools in Canada. tbh, yesterday was the first time I've ever needed to know Big O, professionally. And that was because it was a job interview. They asked me what the Big O was of the LINQ OrderBy method. I guessed polynomial time. I was wrong. It was logarithmic. But they didn't seem to care and I don't care either.
|
|
#
¿
Feb 2, 2016 16:20
|
|
|
Steve French posted:You really should, it is rather important. You're right, at least theoretically. Practically speaking, knowing BigO keeps me from doing stupid things like dumping everything out of a database table unnecessarily or being flippant with nested for loops. But honestly, those were things I instinctively knew to watch out for before I'd ever heard of O(), anyway. Outside of basic uses like that, I've never needed to re-implement a sorting algorithm or anything like that. If I did, I would spend 5 minutes googling and have the most efficient sorting algorithm right at my fingertips.
|
|
#
¿
Feb 3, 2016 16:35
|
|
|
Vulture Culture posted:Our of sheer morbid curiosity, how do people in here feel about the #NoEstimates movement? So, the last place I worked had an Agile coach come in and he flipped out about time tracking, even for measuring costs, which I think is too far. Personally, I think there is value in estimating story points as a measure of how complex you think something might be, and as a team, of course you're going to get estimates wrong, but if you are consistently wrong, you can still come up with a general idea of how much your team can accomplish when you start measuring velocity over several iterations. I think trying to estimate hours is a fools' errand and should be right out. Inevitably, some douchebag project manager will ask, "Why did this feature take a whole week when you estimated it would take 8 hours?" Because programming, bitch. Because QA, mother fucker. gently caress off and die However, I do understand the need to track hours spent after the fact, for purposes of capitalization. Some accounting wonk needs to be able to say, "we spent x dollars on build this project." So, I understand time tracking, but if management is using it for literally anything beyond that, I find another job. This is a job-seeker's market and I don't have time for your 60's era management bullshit. ChickenWing posted:Sometimes I think my job is a little goofy when it comes to their agile implementation, then I read this thread and feel better. Our agile isn't exactly making things better, but at least it's not actively making them worse. I don't think any Agile implementation is going to lack goofiness. If by some miracle a company has The Perfect Agile process, that in itself is goofy as gently caress and probably terrible in its own way.
|
|
#
¿
Mar 10, 2016 18:29
|
|
|
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
|
|
|
|
| # ¿ May 6, 2024 01:30 |
|
|
Bongo Bill posted:Backend developers are paid more than full-stack ones. Reminds me of. btw, thank you for introducing me to PHP CEO. https://twitter.com/PHP_CEO/status/711895081490518016 
|
|
#
¿
Mar 24, 2016 21:01
|
|