|
12 rats tied together posted:I worked at a place where we did pure kanban in trello and it was fine. Individual contributors don't need any of the features in JIRA or Azure DevOps, IME those mostly exist as a stand-in for having an actual project management process. Is pure kanban just like "here's the stuff we need to do, in order of priority" but without sprints?
|
#
?
May 12, 2021 18:52
|
|
|
|
| # ? May 9, 2024 16:52 |
|
|
Yes there are ~3 promises made while doing "pure kanban" which isn't really a thing, but I feel like it needs the descriptor because the term kanban has been hijacked to also mean "the thing you click on to look at your tasks in jira". The promises are: The backlog is sorted such that the top issues are the most important issues. Individual contributors will pull the top issue, self assign it, and move it into "in progress". Individual contributors will not exceed the limit on the "in progress" column. For an IC, you work one or two issues at at a time, depending on what your team agrees on. You pull either the top issue from the "to do" column or you pull something you had previously shelved in the "blocked" column. You can work with your coworkers and manager to decide if you should pull something they had shelved in the blocked column or the top issue. The one vs two issue distinction generally depends on how long it takes to do code review and to actually merge and ship your changes. Teams with longer integration cycles had extra columns for things like "awaiting code review", "running in staging", "awaiting production deploy", etc. For two extreme points of comparison the devops team had todo, in progress, done, and the data platforms team had columns for "waiting for next week's ETL job to validate" and similar. For the team lead and the PM, you make sure that the backlog is sorted. You can re-sort the backlog at any time. If I had to describe it in a single phrase, it's basically lazy-loaded scrum. You do mostly the same things, for mostly the same reasons, and it produces mostly the same value, but you don't need to do any of the meetings and the focus areas are wholly decoupled from each other so they can both run at a higher level of accuracy. You only need to discuss whether or not to pull the top issue vs pulling a shelved issue when it comes up, and the only people who need to discuss it are the IC doing the pulling and the IC who previously shelved an issue. You never need to cost anything, you can run whatever reports and assign whatever arbitrary values you like to aspects of the workflow at any time, and you can use any tool for it instead of needing to find the right report type in JIRA or whatever.
|
|
#
?
May 12, 2021 19:20
|
|
|
prom candy posted:Is pure kanban just like "here's the stuff we need to do, in order of priority" but without sprints? Pretty much, you also limit the number of in progress tickets a IC is working on. I like kanban, it's pretty clear cut and low overhead. Votlook fucked around with this message at 20:30 on May 13, 2021 |
|
#
?
May 12, 2021 19:37
|
|
|
The big upside of Kanban is that you don't need to have a plan for the next two weeks. That makes it a very good fit for R&D projects, where you don't always know anything beyond what your current task is.
|
|
#
?
May 12, 2021 19:55
|
|
|
A MIRACLE posted:Ayyyyyyy Why? I don't love JIRA but it's no big deal to mark a ticket as in progress and add some details or questions as you do work. It's a decent centralized source for discussion and keeping stakeholders aligned. We've had tons of big arguments at my company with people espousing views like the above quote, and when pressed, the best argument I got was because it "takes too long" and "hurts developer productivity" which I think is hyperbolic, considering I spend maybe 15-20 minutes a week in JIRA keeping my tickets up to date.
|
|
#
?
May 12, 2021 20:45
|
|
|
It's (kanban) is great for ops teams and other interrupt-heavy, external-dependency laden workflows because you can just be blocked by 2 month lead time on getting a server shipped and move the ticket for that into the blocked column for 2 months. That's not against the rules, you don't have to "spill to the next sprint" every 2 weeks for the next 8 weeks or whatever, it just sits there as a piece of work in progress that is blocked until it is no longer blocked. The entire point of the workflow is to identify things that are doing this and make them visible to project management, so they can actually project manage, instead of being JIRA report touchers, so it being a big ugly red box in your blocked column is a feature of the process.
|
|
#
?
May 12, 2021 20:49
|
|
|
prom candy posted:Is pure kanban just like "here's the stuff we need to do, in order of priority" but without sprints? yeah. there's also stuff like limiting how many items people can work on at a time, no prescribed release dates, etc. it's a pretty logical framework. kanban and scrum unfortunately CAN coexist, and then can have sprints and demos every two weeks combined with having to put your tasks on a board. don't bring up that up to your atlassian™-enthused overlords - you want the atlassian™ branded kanban, not the atlassian™ branded scrum.
|
|
#
?
May 12, 2021 21:26
|
|
|
12 rats tied together posted:It's (kanban) is great for ops teams and other interrupt-heavy, external-dependency laden workflows This was a life-saver when I was on the catch-all "Infrastructure" team that had all the sysadmins on it, plus two developers. It never made sense for the sysadmins to sit in on sprint planning with us developers or vice-versa and we were always massively under-pointing our sprints to leave room for the maintenance tasks and firefighting that came up constantly. Once we switched to Kanban, we just hummed along while our PM occasionally pinged us about tickets so they could flesh them out and get them in the queue. The only additional thing we needed was a better Triage funnel so our "Unprioritized" and "Ready" columns wouldn't have hundreds of tickets in it.
|
|
#
?
May 12, 2021 21:44
|
|
|
I think the common perception among developers of Kanban as a simpler, less process-driven or formal alternative to Scrum is pretty far from what Orthodox Kanban is like. I work with a Kanban enthusiast and he argues for a full value stream with loads of columns for everything including task specification, design and analysis steps, multiple swim lanes all with their own WIP limits (how many tasks in progress at once) and class of service guarantees (how long should a task take) and a ton of metrics. He argues that the default Jira and Trello Kanban boards with To Do-Doing-Done are more like Scrum than they are like Kanban. To make matters worse, all new user stories/features are handled using an involved Scrum process and everything that comes with that so I get to experience the worst of both worlds. thotsky fucked around with this message at 22:54 on May 12, 2021 |
|
#
?
May 12, 2021 22:51
|
|
|
The point of all that is so you can see the process and figure out where your bottlenecks exist, where queues build etc. So if he's crazy for all the details because he's getting good data to help improve things that's awesome. Good for him. What I have found is that you can be pretty generic with your dev team columns because the real problems with flow and wip are before dev with how ideas are shaped and after dev in the release process. Usually this leads you back to functions full of people who really kind of suck and have a vested interest in their lovely ways. So real progress is not made but we sure do get mad at teams for not "meeting their commitments" to features no one really wants that the company can barely release. A very tidy shoebox inside a dumpster. I've only worked for hopeless legacy companies, tech and non-tech so idk what it's like at faang of cool kid startups co's.
|
|
#
?
May 12, 2021 23:06
|
|
|
Eh, maybe it does. I'm skeptical. You can spend a lot of time engineering your process, and get plenty of metrics out of that, but your power to affect things is ultimately limited to making a recommendation to your boss about how much work your team can handle and how that work should be presented. Even if we assume that the boss in question is on board with taking direction from the team on this, the entire process is super vulnerable to all of the same things that make estimation such a waste of time. One unforeseen and significant complication, maybe a technical issue or a staffing issue, and your metrics are close to worthless. Maybe the project lead, product owner or team has a habit of kicking the ball down the road, spending most of their time assigning or solving tasks that are easy; when you're suddenly faced with the elephant in the room it's not like having a finely tuned lead time is going to make any difference. Sure, these issues will always be issues; it's not Kanbans fault, but it does give me the impression that a lot of the theory-heavy parts of Kanban are just as much wishful thinking and busywork as the stuff people talk poo poo about Scrum for. Some of the simpler stuff is alright though. Trying to limit people to working on one thing at a time, and incentivizing QA is nice. Keeping your to-do list a manageable size seems to help morale a little bit. I don't really think you need more than a single lane to do that though. thotsky fucked around with this message at 00:50 on May 13, 2021 |
|
#
?
May 13, 2021 00:42
|
|
|
thotsky posted:I think the common perception among developers of Kanban as a simpler, less process-driven or formal alternative to Scrum is pretty far from what Orthodox Kanban is like. I work with a Kanban enthusiast and he argues for a full value stream with loads of columns for everything including task specification, design and analysis steps, multiple swim lanes all with their own WIP limits (how many tasks in progress at once) and class of service guarantees (how long should a task take) and a ton of metrics. He argues that the default Jira and Trello Kanban boards with To Do-Doing-Done are more like Scrum than they are like Kanban. the real problem in software projects is rarely the process itself, it's the people. process is a convenient whipping boy - if you blame having mediocre developers, poor requirements, or unforeseen technical issues, that's admitting fault in your leadership. however, if you blame the development culture, you as a six month manager can portray yourself as bringing light to the savage waterfall followers - and any project setbacks can be blamed on your organization's new transition to agile. it's the same principle behind rain dances and religion. strangely enough, you will get strange followers of the various agile religions that follow the procedures with zeal. i have not had good workplace experiences with any of them - they prefer to talk about how to do software development instead of actually doing it. i like my super minimalist interpretation of kanban where i put the cards on the wall, but i don't pretend that my ritual card shuffling can keep the demons of software failure at bay - like occasionally, you're going to have to write some code to make the problems go away, or at least send an email to someone who knows how to do that. perhaps the zealots got jobs at trendier places that serve beer in the kitchens and paid 200k+ a year writing entirely in functional languages and i'm the cranky one, who knows.
|
|
#
?
May 13, 2021 02:04
|
|
|
I work at a place that's on an ongoing company-wide "agile transformation journey" since a bit over a year back now, and it's all just cargo culting and enforcing ceremonies without understanding their purpose. We do two week sprints but never estimate work and it's pretty much accepted by now that we never plan to finish what's in a sprint - at best, it's "we'll work on these things". About 60% of all stories (everything is a "user story", of course) in a sprint are spillover from the previous one, and my team consists of developers on my project, developers on another project where we depend on each other but never touch each other's code, full-time manual testers and "business". We're bloated, we don't actively collaborate on most things, and we're still all in all the ceremonies together so they take forever and focus mainly on aspects that don't matter to me. Also every three month period is a Super Sprint with big-picture goals for every team that are set during the two or three days of 100% meetings known as Big Room Planning. Attendance is mandatory for all, like I care what all the other teams are working on and am somehow, as an individual developer, meant to keep track and plan my work in relation to that. My team has a PO and a Scrum Master, none of whom have done that kind of work before. Their roles are muddled together so one never knows who to contact about anything, they sure don't do the things I would expect of those roles, and when meetings go long because there's no consensus on a decision neither will ever step in to make a final call. When I said they should do that seeing as their roles are kind of leadership roles I got very strong pushback on that claim. "We're agile", they said, "there are no leadership roles". Cool, yeah, then enjoy every meeting turning into an endless bike shedding session. I've become the team's "accessibility champion", not because I'm an expert in any way but because nobody else gives a poo poo and I do. Now if only they'd start listening to me that might mean something beyond me just attending conferences on company time, but at least I'm learning stuff I can use if I ever move on. Which I probably should, huh? (Also, favorite moment this year: someone doing a presentation showing a slide with their team on it, saying "as you can see, we're quite a diverse group". Pictured: eight white people at around the same age. At least half of them were women, I guess that's what the presenter thought made them diverse?) Woebin fucked around with this message at 09:13 on May 13, 2021 |
|
#
?
May 13, 2021 08:16
|
|
|
My team claims to use kanban but we don't have a prioritized backlog and do weekly sprints. It's basically pure bedlam, but I have more important things to worry about than that part of process or explaining to people that they're wrong.
|
|
#
?
May 13, 2021 09:09
|
|
|
Woebin posted:My team has a PO and a Scrum Master, none of whom have done that kind of work before. Their roles are muddled together so one never knows who to contact about anything, they sure don't do the things I would expect of those roles, and when meetings go long because there's no consensus on a decision neither will ever step in to make a final call. When I said they should do that seeing as their roles are kind of leadership roles I got very strong pushback on that claim. "We're agile", they said, "there are no leadership roles". Cool, yeah, then enjoy every meeting turning into an endless bike shedding session. I would blame the PO in this case. I think a scrum master can legitimately say it’s not their job to make decisions, just to facilitate the team. But the whole point of a product owner is to make decisions about what to work on!
|
|
#
?
May 13, 2021 12:44
|
|
|
Both systems have their pros and cons. My new place is much more kanban and I vastly prefer it. It still has issues, such as non fleshed out tickets making it into our lane, which I then have to punt back etc. But the majority of the pain points arnt on me, and if it's a choice of that and loving scrum with all its pointless meetings, ill take kanban any day.
|
|
#
?
May 13, 2021 13:37
|
|
|
Rubellavator posted:Made a comment on a junior dev's pull request asking him to use something instead of null for a bunch of test values and he changed all the values to "something". I use names from The Walking Dead, pi, 867-5309
|
|
#
?
May 13, 2021 15:25
|
|
|
Mega Comrade posted:Both systems have their pros and cons. My new place is much more kanban and I vastly prefer it. It still has issues, such as non fleshed out tickets making it into our lane, which I then have to punt back etc. But the majority of the pain points arnt on me, and if it's a choice of that and loving scrum with all its pointless meetings, ill take kanban any day. What if you had kanban but without the prioritized backlog and you kept all the scrum meetings 
|
|
#
?
May 14, 2021 12:35
|
|
|
leper khan posted:What if you had kanban but without the prioritized backlog and you kept all the scrum meetings And you spread your tasks over multiple boards that must all be maintained individually.
|
|
#
?
May 14, 2021 13:35
|
|
|
thotsky posted:And you spread your tasks over multiple boards that must all be maintained individually. And those multiple boards don’t interact because your group is adopted DevOps a year ago while the teams that actually ship product and enter issues from customers use JIRA and have used JIRA for a really long time, and you either can’t connect them because both systems are a hellscape or you won’t because you want all teams to adopt ADO 
|
|
#
?
May 14, 2021 14:22
|
|
|
We have adopted a core platform-first approach and every functionality you write should be abstracted and generic enough that a completely separate team should be able to reuse it for their own purposes. Also can you make sure you support use cases for this, this, this, this, and this team? Thanks.
|
|
#
?
May 14, 2021 14:34
|
|
|
My workplace had one accidental success with reusing code in another team and figured that we could make/save a bunch of money by Platforms-ing our way out of every problem. It is going exactly as well as you’d expect. [nervous glance at massive set of high-level willing departures]
|
|
#
?
May 14, 2021 14:35
|
|
|
The argument of “write code that works, then extract a platform out of it” v “write platform code first, then write your first app on it” took up most of my conversations with my boss last year. I liked the former, especially when I was working in a new domain. He felt the opposite.
|
|
#
?
May 14, 2021 17:25
|
|
|
Writing the platform first would break "you aren't gonna need it" which is something I usually try to stick to. You'll almost certainly get it wrong, or not fit your requirements exactly, and then you pay the cost of initial implementation plus the cost of carry until the codebase is actually needs-fitting (which is not actually guaranteed to ever happen -- a poorly built platform could just be an unbounded cost stretching forever into the future). "Building the platform first" is a bad idea about 99% of the time, however, writing platform-capable code is just being a good developer. e: of the two disaster scenarios here, "everyone builds their own ladder" vs "multiple competing platforms", the second is also much worse. It's much easier to find emergent patterns that are worthy of platforming from those ladders than it is to deprecate one platform in favor of another. 12 rats tied together fucked around with this message at 17:44 on May 14, 2021 |
|
#
?
May 14, 2021 17:40
|
|
|
When I say “platform first”, it’s not so much “write code for functionality/apps that are relatively self-contained”, I mean “write code that is magically generic enough to fulfill the needs of an engineering team on the other end of the organization and that you’ve never heard of”. e.g. replacing an old, bad part of the internal-facing business domain systems with a new, shiny part and then being asked “hey how come this isn’t usable out of the box for the front-end web devs?”
|
|
#
?
May 14, 2021 18:33
|
|
|
Cause bitch if you ask me, a “who would want to sell to this person” engineer, to do the work to replace a crappy part of that system, and a quarter later ask me why I didn’t solve any work for the “how do we make phone calls to people” team, that’s too loving bad, man. Should have made that part of the goddamn requirements.
Pollyanna fucked around with this message at 18:47 on May 14, 2021 |
|
#
?
May 14, 2021 18:36
|
|
|
Hey any of you use Winappdriver with Apium and or work with Revit? We are developing a Revit plugin and it takes 100 years to find any elements on the page because of how it is structured. I come from web testing with Selenium so this is all new to me and would appreciate and tips.
|
|
#
?
May 14, 2021 18:42
|
|
|
Well I'm starting a new position in a week, where I'm the principal engineer on a completely greenfield project. Wish me luck 
|
|
#
?
May 15, 2021 15:35
|
|
|
Ghost of Reagan Past posted:Well I'm starting a new position in a week, where I'm the principal engineer on a completely greenfield project. Good luck! I’m only recently in that position as of late last year/early this year, but definitely get a handle on the stakeholders, the expectations for the end state of the project by said stakeholders, and (if you’re replacing a brownfield codebase) the boundaries around what you’re replacing. Remember: computers are easy, people are hard. Let us know what you learn!
|
|
#
?
May 15, 2021 15:49
|
|
|
I'm frustrated by my org's QA folks. I don't think it's unreasonable to ask that devs and QA collaborate to develop and document an explicit test plan with steps and behavior to be validated in order to reliably cover all our bases, have a record of doing so, and be able to reuse it the next time. But folks just come up with some broad areas to look into and "poke around at", resulting in everyone covering the same obvious paths and neglecting less-obvious poo poo we'd have known to look for with just a bit of forethought. Getting anyone to update the E2E test suite is also near impossible. We waste so much time on manual regression testing that would easily and consistently be addressed with E2E test cases, freeing everyone up to do more useful work!
|
|
#
?
May 17, 2021 22:27
|
|
|
You need a detailed and comprehensive checklist if you want 100% coverage for manual UI testing. Every action you could possibly take and every screen you could possibly access need to be accounted for in the testing instructions. Steps like "Open settings by clicking on X button in Y control panel", "Change Z configuration to [new invalid input]", "Click Save Changes button," "Verify that invalid input notification appears and changes are not saved", etc. We did this at my old job (dreading writing one at my new job), and it was tedious as gently caress but worth it because the QA contractor would hit everything in the UI and do a better job at catching stuff than the devs because he wasn't noseblind to all the known bugs and whatever we didn't feel like fixing or had forgotten about. One problem we had with the manual testing checklist was that it was initially very poorly organized and required a lot of extracurricular actions to achieve the condition/state necessary to perform the next step. Like, the "delete widget" test step was followed by a "change widget setting" step, so the tester would have to create a new widget in order to test changing the setting. Would have been better to have your change setting steps come before your delete widget step. I tried to prioritize fixing this, but I don't think I was able to before I left the company. On the bright side, no longer my problem.
|
|
#
?
May 17, 2021 23:29
|
|
|
Cugel the Clever posted:I'm frustrated by my org's QA folks. I don't think it's unreasonable to ask that devs and QA collaborate to develop and document an explicit test plan with steps and behavior to be validated in order to reliably cover all our bases, have a record of doing so, and be able to reuse it the next time. But folks just come up with some broad areas to look into and "poke around at", resulting in everyone covering the same obvious paths and neglecting less-obvious poo poo we'd have known to look for with just a bit of forethought. How big is your project and updates? How well staffed is your QA team and what other things are they working on? Test plans that truly cover every component of software, or even a critical path are difficult to craft in a way that makes everyone happy. Development and QA both want confidence, but how you achieve that and what's realistic to achieve depends a great deal on the kind of software you build, and your QA departments maturity and depth. Speaking for games, expecting compete end-to-end testing is not happening. The plan is frequently to figure out what stuff is more likely to fail, and regress the most important systems. This is also coming from a very well-oiled QA team and other teams in the industry are uh...much worse. If your software has a more manageable number of possible states on it's critical path than a game, then some kind of automation may be a more ideal approach. Regardless, this is a complex process, but one that is better navigated when Dev is explicit about what it expects out of QA, and QA works with dev and better explains the limitations of the department and what's reasonable within a given time frame. Expect a lot less if your QA is mostly temp and contract.
|
|
#
?
May 17, 2021 23:35
|
|
|
Queen Victorian posted:You need a detailed and comprehensive checklist if you want 100% coverage for manual UI testing. Every action you could possibly take and every screen you could possibly access need to be accounted for in the testing instructions. Steps like "Open settings by clicking on X button in Y control panel", "Change Z configuration to [new invalid input]", "Click Save Changes button," "Verify that invalid input notification appears and changes are not saved", etc. We did this at my old job (dreading writing one at my new job), and it was tedious as gently caress but worth it because the QA contractor would hit everything in the UI and do a better job at catching stuff than the devs because he wasn't noseblind to all the known bugs and whatever we didn't feel like fixing or had forgotten about. manual ui testing is the crack cocaine of quality assurance - it's the quickest and cheapest way to get the job done initially, but the results are not reliable, it starts taking more and more time and money to get the same effect, and it starts costing an enormous amount of time and money later. if you think you can guarantee that there are no regressions through manual ui testing, you're smoking crack.
|
|
#
?
May 18, 2021 02:17
|
|
|
Bruegels Fuckbooks posted:manual ui testing is the crack cocaine of quality assurance - it's the quickest and cheapest way to get the job done initially, but the results are not reliable, it starts taking more and more time and money to get the same effect, and it starts costing an enormous amount of time and money later. if you think you can guarantee that there are no regressions through manual ui testing, you're smoking crack. Guess what happens when your worst devs get put on automation duty? You end up with a monstrosity of Cucumbers and Gherkins and BDD DSL FUBAR with over 1500 public static global state variables that guarantee it can never run anything in parallel!
|
|
#
?
May 18, 2021 03:53
|
|
|
Bruegels Fuckbooks posted:manual ui testing is the crack cocaine of quality assurance - it's the quickest and cheapest way to get the job done initially, but the results are not reliable, it starts taking more and more time and money to get the same effect, and it starts costing an enormous amount of time and money later. if you think you can guarantee that there are no regressions through manual ui testing, you're smoking crack. I'm assuming it would be in addition to unit and integration tests. Probably should have stated that. Manual testing is nice to have for catching weird workflow bugs and confusing procedures and such that programmatic tests won't necessarily catch.
|
|
#
?
May 18, 2021 03:56
|
|
|
Yeah how I remain employed is primarily through knowing all the weird stuff about our system so I can put the fighting fish (conflicting and inconsistent business logic) in a tank together.
|
|
#
?
May 18, 2021 05:02
|
|
|
So I assume none of you are QA engineers then?
|
|
#
?
May 18, 2021 05:42
|
|
|
RC Cola posted:So I assume none of you are QA engineers then? My boss described me as a "test engineer" to someone today when I'm really a regular tester with a knack for using scripts to set up test scenarios. (I have no experience in the thing you were asking about, sorry!)
|
|
#
?
May 18, 2021 15:18
|
|
|
RC Cola posted:So I assume none of you are QA engineers then? I'm most definitely not, but have a vested interest in setting up decent manual UI testing procedures because I am a UI/UX person and it's the kind of testing that is most helpful for uncovering UI/UX bugs/issues.
|
|
#
?
May 18, 2021 15:25
|
|
|
|
| # ? May 9, 2024 16:52 |
|
|
Have a project that we're trying to wrap up. For context, I work in utilities trying to help companies identify all kinds of insights on utility poles. So we have to deliver a photo of each pole, as well as any other processing artifacts to the client. Easy enough right? Just buy an external HDD, copy everything onto it, mail it off and it's their problem now, right? Nah, that's not acceptable. So we draft up a hosted solution using an S3-like cloud storage solution. Threw together a little image gallery web app for it even. Nah, that's also not acceptable. So I guess we're just gonna have to mail it to them again, but this time with the web app on the hard drive? Even though there's no way they're realistically going to thumb through all 1 million image files. Clients. 
|
|
#
?
May 18, 2021 17:15
|
|
