Software Development Process Anno 2010
Let's play. I am a software developer that works as a consultant and you have a task for me.
First, what task is it? For some tasks, you are better off choosing someone else.
First, what task is it? For some tasks, you are better off choosing someone else.
- For a specific need in your existing IT infrastructure, i.e. network, hardware, operating system, virtualization, web services, internal systems, portal: You'd better contact your systems engineers or system administrators. If you don't have enough manpower to implement the current need, I can join your crew and get up to speed fast.
- For a specific need in your existing IT presence, i.e. element of your web site, discussion forums, mailing lists, web design, web marketing: You'd better contact your web site administrator, designer and marketeer. Again, if you don't have enough manpower right now, I can join your crew.
- For a specific need in something new or for unspecified needs within a vision and strategy, I can start helping early on and assist all the way toward a complete solution.
Among my favorite project structure and project artifacts you'll find:
Third, how can we improve the quality of the product?
- Team members working close together, with easy and frequent access to project owner
- Design goals w/operational and usage guidelines
- Product prototype; PHP, Spring Roo
- Stories; functional or capacitive requirement descriptions within a context; WHEN do WHO needs WHAT
- Visualize progress; measure project velocity
- Maintain progress; daily stand-up meetings
- Unit testing; JUnit
- Continuous integration; Hudson; CruiseControl
- Version control; CVS
- Familiar development environments; Eclipse or -derivative like STS
- Monthly or bi-weekly project deliveries w/retrospectives meeting
To start with, we would have a talk and agree on the project details and maybe even sketch a rough interface idea and a rough system design. If the domain language or domain space is unclear, I would need a domain concept map to clearly understand what we're talking about. For unspecified needs, some needs and possibilities talks could reveal good product areas and a product growth talk could reveal phased product launches to be better for business. Delivering a project directive would give necessary mandate and direction to the project lead.
Third, how can we improve the quality of the product?
- Quantify the goals. The more we can quantify the goals, the better quality will the project deliveries be, Gilb argues convincingly. Study the quantified goals to find out exactly what you are going to make. With such quantification, testing and validation become simple. This also make less bugs. To reduce bugs, avoid making bugs in the first place: Do not code stuff which is not really needed.
- Good design matters. To get there, use the quantified goals and spend much time designing and prototyping. It is easy to forget key usage requirements; who hasn't heard of big projects that make products that are useless or less useful in certain circumstances? A new ticketing system for our local bus company is one example; 10 million € spent over 10 years give a system that is taking 30 seconds for the bus driver to process one way tickets, which is far too long. Or a system supplier who hadn't tested its system on real size (huge) data.
- Tailor to context. Get the new product coordinated with existing infrastructure, product portfolio, marketing efforts and last but not least, the users.