6 ms·
What do you use that does lead to a good piece of software?
by midasz 3y ago
What do you use that does lead to a good piece of software?
- SideburnsOfDoom 3y agoIndividuals and interactions, over processes and tools.
- slivanes 3y agoBy focusing on the product rather than the process.
- midasz 3y agoHow does that work? So you've already went through the steps of figuring out a process, or do you just pick one and stick with it - accepting shitty parts? What's the process?
- oneshtein 3y agoYou should start with the developing of the product as is happens, then use Continuous Improvement process to improve the development process. You can use SCRUM/Kanban/SaFE/LeSS, hybrid or other Agile methodology, or no process at all, but it will not help when people are not trained to be proper part of the process. For example, a PM may replace SCRUM meeting with a status meeting, because it makes his job easier, while PM or other M should not attend a SCRUM meeting at all, unless called in by engineers. The proper moment for interaction between PM and engineer are beginning/end of a ticket, sprint review, and sprint planning.
- phkahler 3y ago1) Come to work. 2) Look at the current state. 3) Decide what the product needs from you. 4) Do that. 5) Use git. Steps 2 and 3 may involve communication. Step 5 is tracking changes. Have a PM that tracks main things people are working on and estimated dates (not dictated dates). This is how my current job works and we are unbelievably productive.
- whstl 3y agoI would argue that 3 and 4 already imply 5! :) And IMO it also implies things like CI/CD.
- JackSlateur 3y agoYou failed as soon as you think "process" A process is a hardcoded way of do thing, which is deficient because it cannot react to an ever-changing world A better way to handle things is by defining "what" should be done, not "how" it should be done
- Kim_Bruning 3y agoI have the opposite view. Everything you do -up to and including taking a leak- is a sort of process. Perhaps you don't think that particular example should be a corporate process, but that's not my problem :-P . You can compose processes to get things done. Processes can be made mutable or flexible by eg. incorporating decisions or iteration. Especially iterated processes can be very powerful (you can get a lot done with them). Thinking of things in terms of processes instead of in terms of component steps each time frees your mind to worry about other stuff. Compare it with dividing a program into functions. Once you've wrapped a task in a function, you can then design using the function, rather than worry about how to write the code from scratch each time. Same with process thinking: you don't have to get bogged down in particulars all the time. That said, maybe you're thinking of the "Befehlstaktik" vs "Auftragstaktik" [1] approach to doing things. In which case we're arguing definitions instead (which can be easily resolved). [1] https://en.wikipedia.org/wiki/Mission-type_tactics https://en.wikipedia.org/wiki/Mission-type_tactics
- PradeetPatel 3y agoHaving clear requirements, good communications with key stakeholders and empower the enginees.
- midasz 3y agoWhat if the requirements are super clear but they change? When do you find out and what happens then? I've personally never had a project where the requirements were 100% clear and stayed exactly the same. Even when writing a v2 of an existing project from the ground up things tended to be unclear and subject to change.
- oneshtein 3y ago> What if the requirements are super clear but they change? You need to communicate with stakeholders then, to change requirements, explain mistakes, set new goals, and reprioritize tasks. Agile (SCRUM/Kanban/etc.) are designed with frequently changing requirements in mind. In SCRUM, this is done at sprint review/sprint planning stage. In Kanban, it's continuous process.
- nudgeee 3y agoThe point is to use what ever works best for your team, not blindly follow some process that may or may not necessarily work for you. Just as product requirements can change, so can the way we work. Just like there is not one singular product that solves everybody’s needs, there isn’t necessarily one process that does that either.
- lll-o-lll 3y agoSounds like you need a process that can be flexible, able to respond to change, some might say… agile ;-) I kid, but I think the early proponents of Scrum and similar were trying to achieve a loose framework to do exactly what you’re talking about. The modern incarnations of these can be horrific, but the original intent was always to empower teams to make their own process. Ahh well. Like so many good ideas (democracy, constitutions), you only really know how well they function once people are actively trying to subvert them. Scrum et.al. have failed in the face of corporatocracy. I honestly don’t know if decentralised structures (i.e. teams empowered to run themselves), can ever survive in large corporates. Which is a pity. Cities grow, but companies die. You have to jump off the dying colossus to find the new company that hasn’t yet succumbed.