This post is a continuation of part 1 of Tips to Successful Software Projects. While part 1 focused more outside of development, this post will focus on tips center around development. So, let’s get started.
Identify the Environments Required for the Project
Something that might get overlooked during the initial phase of a project is the environments the software requires. For example, developers, testers, and business should each have a separate environment to run the software.
It is important to consider what environments your project will need early. Chances are you will need to go through a process to get approvals and setting them up. So, it’s better to have the environments ready early than to start the process when you actually need them.
The number of environments you need will vary depending on the project. However, you should have at least the following environments: Development, User Acceptance Testing (UAT), Staging, and Production.
Centralized Documentation
Important documentation pertaining to the project needs to be at a centralized location. This is important especially if they are constantly being updated. Everyone has their own preferences on how to work, but at the end of the day, all that work should be available in a centralized location.
So, why exactly is this so important? It helps keep information organized and up-to-date. If documentation is scattered across different locations then it is easy for one to get left behind. For example, if a document is at three separate locations after many updates, one might miss an update after a while.
Prepare and Define the Codebase and Project Structure
A codebase that is well organized can go a long way. It helps makes the project easier to navigate and prevents the project from becoming a tangled mess in the future.
There are many things for you and your team to iron out in this phase, but there are definitely some key things to decide on. You should definitely define the codebase structure, file, variable, and method naming conventions, packaging rules, and main modules of the project.
Document How to Set up the Project
Sometimes, setting up for a new project is one of the toughest parts of a project. Getting the development environment right can be difficult even with the assistance of an IDE (Integrated Development Environment). So, it is important to document the process to set up the environment for development.
A way to look at the document is that it contains the information you wished you knew when you start the project. Sure, you have already been through the pain of setting up your environment, but what about other new developers? Do you want them to go through the same process as you did or do you want them to start off running? Also, you might have to revisit the project again in the future and that is when you probably wished you had documented the setup process.
Don’t Save Testing For the End
Don’t make the mistake of saving QA (Quality Assurance) testing for the end. That’s a recipe for disaster because suddenly there will be an influx of bugs and other issues. These issues can influence the direction of development and if you’re already done with development before any testing, it is going to heavily impact the project. So, it’s important to test early and have everyone contribute to testing besides the testers.
Break the project down and work on a small piece at a time. As a developer, make sure the functionality works as intended by doing some testing before merging in your changes. Write unit tests for the code that way you can catch issues early.
Besides developer and testers testing the project while in development, the PM (Product Manager) should definitely test the project while development takes place. This is important because it provides constant feedback of defects and feature behavior. Early feedback to the development team results in the business receiving the product that was envisioned. Think about how much of a disaster it is when months of development have gone by only to find out the features are not what was wanted.
Iterative Development Process
Ensure development adopts some sort of iterative approach. An iterative software process is one that breaks the total work required for the project into small and complete pieces. This means that each of these small pieces makes up a part of the product and is functioning correctly. Until all the pieces are complete, you won’t have a complete system, but the system that is present will be functioning correctly.
Taking the iterative approach helps minimize risk which is critical for a project’s success. As the project develops, stakeholders and the team will be able to see exactly how the system is progressing. It is also easy to determine if the pieces of the system in place is coming together like how the project was envisioned.
So, what exactly are some ways for you to implement an iterative approach? To be precise, there is no definite answer to this because it really depends on the team, stakeholders, and the scope of the project. However, a good guideline is to use one of the Agile Methods such as Extreme Programming (XP), Test Driven Development (TDD), Scrum, Kaban, and etc.
Periodically Review and Make Changes to the Process
A common issue is that a process is put in place and then never adjusts for changes. Perhaps the process initially was working, but there are bound to be inefficiencies and part of it that doesn’t make sense anymore.
Your team should periodically review the process and see what can be changed to improve it. Don’t be afraid to remove a portion of the process if it feels like it is not needed anymore. You can always re-introduce the portion back if the team feel it is necessary again. This doesn’t mean you should have little to no process though because that will lead to chaos. However, having too heavy of a process leads to many inefficiencies, so it’s like a balancing act to find that sweet spot for your team.
At the end of the day, you and your team should strive to have a process that is center towards the product. This will lessen the chance of slipping schedules and individuals working on tasks that don’t bring in value. So, rather than having a static process, it should be a flexible process that adapts over time.
I hope this post was helpful to you. If you found this post helpful, share it with others so they can benefit too.
What are your experiences with successful or unsuccessful software projects?
To get in touch, you can follow me on Twitter, leave a comment, or send me an email at steven@brightdevelopers.com.