6 Tips for Successful Development Projects

There are many concepts and methods to keep in mind when running successful development projects. The six tips below for successful development projects have changed our projects in a positive way.  Some we’ve used for many years. Others, we’ve used for just a few years. What they all have in common is that they’ve all organically grown and improved as our project requirements change.

Today, we’ll talk about:

• A structured process
• Regression testing outlines
• A code framework
• A code repository
• A staging server

A Structured Process

What tasks are being worked on? What’s the priority of those tasks? What tasks are ready for review on staging? When will each task go live? These are just some of the questions that need processes built around them to run a successful project.

A method that works well for me is the following:

Create a board known as a Kanban board to track each task in the following categories.

1. Backlog or tasks that are not being worked on This category contains all the tasks we ever want to do. This is also a great place to add all the ideas your client has during meetings. You can then review each to determine when they should be worked on.
2. Sprint or tasks in progress. We typically work in one-week sprints, meaning we create a list of tasks from the backlog to complete within the next week.  Then, each Friday we review the following:
   1. Which tasks were completed.
   2. Which tasks were not completed.
   3. Why tasks were not completed.
   4. Impediments the team ran into during the week.
   5. Once we have discussed and clarified these details, we then create our sprint for the next week.
3. Review on staging. Once QA (quality assurance) is complete, the task gets moved to the review on staging category. The client is notified that they can review and provide feedback on this task before it goes live.
4. Going live. Once the client has signed off that the task is complete on staging and works as expected, the task is moved to the going live category and scheduled with a date. (More on scheduling tasks going live below.)
5. Live. Once the task is pushed to live, it’s moved and dated to the live category. Then, we always have a record of when it went live.

Create a schedule for tasks going live.

We plan and schedule tasks to go live once a week on a specific day for each project. This way everyone, including the client, knows that tasks will be pushed live on a specific date each week.

Create a schedule to review each week’s sprint with the client and development team.

As described above, we plan our meetings each Friday to review how the week went and plan for next week. Again, everyone, including the client, is always aware of what’s going on and when.

Regression Test Outlines

Regression testing is the process of testing aspects of an application after code changes have been made. This ensures any new functionality has not broken existing working functionality.  We start creating these outlines as we develop the application. We typically create regression test outlines for specific areas, as well as overall functionality. The regression test outlines are then used in our QA process to ensure we are doing everything we can to limit bugs and issues. We also regularly update these outlines as the application grows and new aspects need testing.

Detailed Project Blueprint

Just as we need a blueprint to build a house, we need a blueprint to build web applications. Blueprints are created by meeting with the client. In these meetings, we review all items and functions the client would like to include in their project. We can then map these in priority order, from most important to least important. Then, we estimate the time for each task. This allows us to determine what needs to be done in Phase 1 (initial launch) and what can be added to a Phase 2 or Phase 3 after the initial launch. A detailed blueprint is also valuable for the client since they can reference it to verify the outlined tasks are completed.

A Code Framework

The framework you use is not that important, as long as you are using a framework. A framework’s primary advantage is making code logical and clear today and far into the future, regardless of the actual developer writing the code. A framework outlines stand practices for code development. This lessens confusion when reviewing code. Also, this diminishes a new developer’s onboarding time, meaning they can be more productive, much more quickly. If you want to learn more about frameworks, I’ve also written about the benefits of using a PHP framework.

A Code Repository

All custom code, at least for now, is written by people, and people make mistakes. A code repository like GitHub or bitbucket allows a team to create code, commit (meaning save it) to the repository. The repository keeps track of all changes made in the code by each developer. Then, if there are issues or bugs, the repository allows the code to be reverted, or reset, to the last known working version. This allows the site to be fixed fast. Then, the development team can focus on the issue/bug on the staging server without affecting the live server.

A Staging Server

A staging server allows the development team to work, make changes, test, and run through QA (quality assurance) without the concern of taking down or causing issues on the live site.  Think of it as a place to work and experiment on functions to add to the application. Ideally, the staging server runs on the exact same server as the live to ensure if it works on staging, it works on live.

We have used these six tips for development projects over the years. We’ve revamped and updated them as our clients’ needs and the complexity of their applications have grown.  This is by no means a complete list, but they are the six I find most integral to our development projects process. They help us get the best end product for our clients, and I hope you’ll give them a try yourself.