3 ms·

Ask HN: What's your recommended methodology to develop big software project?

7 points by pictur 8y ago

BjoernKW 8y ago
Most software development methodologies - including what's become of some of the supposedly "agile" ones - are a vain attempt at formalising and industrialising a process that's inherently non-industrial. Writing software isn't the same as producing physical goods but instead is similar to designing a product. Therefore I'd recommend design thinking and the double diamond model for design processes: 1. Explore the problem space. 2. Narrow down to the actual problem you want to solve. 3. Explore the solution space. 4. Develop and deliver the appropriate solution from that space. 5. Rinse and repeat. These aren't rigid methodologies but rather general approaches. Furthermore, proactive, goal-oriented communication is essential. The people / roles responsible for designing and developing the deliverables should also be the ones to gather requirements and talk with the users. Additional layers of organizational indirection such as dedicated business analysts often are detrimental rather than beneficial. Relevant communication should be recorded digitally and relentlessly. Requirements only exist if they're available to everyone through some sort of digital system, such as JIRA and Confluence, which are tremendously useful and usable tools if configured for enabling communication rather than for imposing some rigid and often inappropriate process.
croo 8y ago
Make tasks out of requirements then create subtasks all the way down while putting an estimate on every task. On your way you will find r&d tasks, unknowns and potential high risks. You need to communicate about those to mitigate as much as you can. Then communicate and communicate some more. Meanwhile you get a good overall view on the project, it's size and the possible pitfalls. After this you can do the project in whatever methodology suits the project. Big software projects just means that the above mentioned task is dauntingly big. Constant update and refining is needed as the project moves forward and there are a lots of unknowns and lots of different people to talk to. This work needs some kind of a system which includes documenting the communications and upgrading the tasks with new input.

7 points by pictur 8y ago

Most software development methodologies - including what's become of some of the supposedly "agile" ones - are a vain attempt at formalising and industrialising a process that's inherently non-industrial. Writing software isn't the same as producing physical goods but instead is similar to designing a product. Therefore I'd recommend design thinking and the double diamond model for design processes: 1. Explore the problem space. 2. Narrow down to the actual problem you want to solve. 3. Explore the solution space. 4. Develop and deliver the appropriate solution from that space. 5. Rinse and repeat. These aren't rigid methodologies but rather general approaches. Furthermore, proactive, goal-oriented communication is essential. The people / roles responsible for designing and developing the deliverables should also be the ones to gather requirements and talk with the users. Additional layers of organizational indirection such as dedicated business analysts often are detrimental rather than beneficial. Relevant communication should be recorded digitally and relentlessly. Requirements only exist if they're available to everyone through some sort of digital system, such as JIRA and Confluence, which are tremendously useful and usable tools if configured for enabling communication rather than for imposing some rigid and often inappropriate process.

croo 8y ago

Make tasks out of requirements then create subtasks all the way down while putting an estimate on every task. On your way you will find r&d tasks, unknowns and potential high risks. You need to communicate about those to mitigate as much as you can. Then communicate and communicate some more. Meanwhile you get a good overall view on the project, it's size and the possible pitfalls. After this you can do the project in whatever methodology suits the project. Big software projects just means that the above mentioned task is dauntingly big. Constant update and refining is needed as the project moves forward and there are a lots of unknowns and lots of different people to talk to. This work needs some kind of a system which includes documenting the communications and upgrading the tasks with new input.