Project Management

Without being aware, we are project managers quite often in our lives, sometimes at work and also in our private lives when we manage our time, money, or the future. In this article, we will focus on project management for software products, a place where AppSeed, being a company that builds software, is active on a daily basis. Long story short, project management involves overseeing and coordinating all aspects of the software development process from initial concept to final delivery. Here's a concise overview:

Planning: Defining project scope, goals, timelines, and resources
Requirements gathering: Identifying and documenting user needs
Design: Creating technical specifications and user interface designs
Development: Writing and testing code
Quality assurance: Ensuring the product meets quality standards
Deployment: Releasing the software to users
Maintenance: Ongoing support and updates

Project managers typically use methodologies like Agile or Waterfall to structure the development process. They're responsible for team coordination, risk management, budget oversight, progress tracking, and resource allocation.

This article is not about the perfect strategy but is more like our way of doing this task which directly affects client satisfaction, costs, the mental health of the team, and the quality of the end product.

Custom Development Service - Provided by AppSeed

Initial Communication with the Client

The first step in every project is to get contacted by the client who usually communicates a summary of what is expected in terms of features, and technology used. Once this first step is consumed, in the following days the communication with the client is focused on gathering all the inputs to clarify the future end-product and real-life use cases.

A good way of breaking down the features is to write use cases for each interaction between users and the product. This technique is known as Behaviour-Driven Development where the product is analyzed from the usability point of view. A popular framework built around this project is Cucumber. Here is a use-case that respects the Cucumber use-case pattern:

Scenario: As an existing user, I want to log in successfully.

Given the user is on the Home page

When the user navigates to the Login page

And the user enters the username and password

Then the successful login message is displayed

This use case is a snapshot of a successful login process where we have a simple pattern composed of the following parts:

Scenario: the short information of the use case
Given: specify the context
When suggests the actions performed by the user
Then clause is the expected result of the current use case

By applying this breakdown to all product features, we can have quality input for the QA team (the testers) and the developers. This phase, for medium to large projects, might take a few days to a few weeks until all actors involved in a custom development effort agree on the document.

Communication Funnel

Communication across the team and also with the client can be done in many ways from video calls, chat, email, or documents. At AppSeed calls are considered an exceptional way to communicate being a funnel that blocks resources at the same time.

The usual way is to use a Discord group or server where the information is disseminated in topics/channels like development, deployment, PRs.

Project Documents (technical specifications, testing plans) are another important way of structured communication where all parties can update or add comments. For this, we are using Google Shared Documents where the information is saved and synchronized in the cloud.

The technical solution and test plan

Ok, now that we know what the product should provide we can move in two directions, both equally important:

#1 - Writing the test plan
#2 - Developers write the technical specifications

The test plan, usually written by an experimented tester or QA Lead, needs to mirror all the use cases in test actions. In the and, after the document completion and approval by the project manager and the development tech lead is released under a v1.0 version, and the read-only version [ usually a PDF ] is saved in the project directory for later reference.

Developers, on the other hand, represented by their tech lead will provide the technical solution that is also approved by the project manager and also the client.

Having the above steps approved, the development can start with the most important features using small iterations, usually weekly iterations.

Setting Up the Repository

In order to have a good exit for any software project, the source code repository needs to have a simple, intuitive structure, build and deployment scripts, and a comprehensive README file that explains all the necessary steps to set up the project in any environment.

Branching Strategy

At AppSeed, we are using most of the project's three working code branches, each one with a specific role

Main Branch

Represents the production-ready code. The rules applied to this branch:

Only stable and tested code should be merged into the main branch.
Direct commits to the main should be avoided. All changes should go through pull requests.

Staging Branch

Represents a stable state for testing before release. The rules:

Merged from development once a set of features is ready for testing.
Used for integration testing before merging into the main.

Development Branch

Represents the latest development changes. The rules:

Developers create feature branches from development.
Frequent integration with feature branches to identify and resolve conflicts early.

Development Environment

A recommended way of coding the product is to use an environment closer or identical to the one used in production that mirrors the versions of the programming languages, libraries, and toolchains. For instance, if the product runs on Python, we try to stick in our workstations to the same version used in the deployment server:

Python 3.12
NodeJS 20.x
Yarn, PNPM versions

Of course, the product technical solution might include other tools and libraries like the latest version of Tailwind, Yarn .. etc.

The idea behind this approach is to stay closer to the production environment and avoid or minimize the runtime or LIVE deployment errors.

LIVE Deploy - CI/Cd for development

In almost all projects, before going LIVE for development and testing, the sources are Dockerized for better isolation between the server and runtime environments.

Usually, the repository that is saved in GitHub, is linked via the GitHub actions to the development server where the product is deployed LIVE at each update of the MAIN branch.

Writing the CI/CD scripts at the beginning of the project might be a time-consuming task that usually takes 1 or two days, but the benefits are important because the testing team can validate the changes and the newly developed features directly on the LIVE server, without spending time with the local set up of the project at each update.

Sometimes, the early validation of the development might require a Database Seeder, a tool that injects test data into the product for feature validation speed up.

A seeder is optional but usually recommended. At AppSeed we use DB seeders for almost every custom project.

Development Sprints

With all the above components in place, might be a good way of doing weekly development sprints where the work is balanced like this:

3 days development. Usually scheduled at the beginning of the week
Merge the code in the MAIN branch - This triggers a LIVE deploy
1 day for tests on the LIVE Deployment Server
1 day for fixes, if any issues were raised by the QA team

Having this 5-day development cycle, the at point the product can be tested LIVE by the client, project manager, testers, and also developers.

Task management and progress tracking can be done these days with many tools [ paid & free ] but our choice is GitHub Projects which is free and usually covers entirely the control and is also integrated with the Repository Issues Tracker.

For PAID alternatives, feel free to take a look at Trello, ClickUp, Asana, and the list can be super long. The thing with a good tool is to have a clear view of the project's current state and active tasks.

Tests (Features and Regressions)

The development is validated usually by a tester who follows the test plan written and approved in the early stage of the process. An important aspect of the tests is to run the full test suite at each merge of features into the MAIN Branch.

This is mandatory because sometimes adding new features might affect the existing features already validated in the previous testing sessions.

The time allocated to the tests might increase once the product is getting more complex but a part of this testing effort can be automatized via end-to-end tests using scripts.

Automatized tests

Having tests is always recommended because by running a well-written test suite with good code coverage we can spot issues quite fast. Sometimes automatized tests are scheduled outside the working schedule, at midnight or at the beginning of the working day followed by a test report extraction available for all team members.

Unitary Tests

Developers are usually responsible for writing unitary tests for the most critical parts of the software where a bug has affected many features or simply has an important financial impact with a bad effect on the client and business logic.

Acceptance with the Client

Getting closer to the final product delivery, the product enters into the acceptance phase with the client which basically validates all delivered features as agreed in the contract during the initial communication phase.

This phase might require supplementary coding and testing sessions until all required features are shipped with the production-ready quality. Having a good and controlled process, this phase should be closed quickly and the product should go LIVE with a closed monitoring timeframe.

Production Deployment and Warranty

The product being LIVE needs close monitoring based on the real-world usage that might involve new factors like high traffic, security attacks, use of the platform in unorthodox ways like unloading big files, and other unexpected things.

The first two months of a new service are recommended to run with verbose runtime logging at all levels, a technique that helps to debug faster any runtime error.

The above process, currently used by AppSeed, can be obviously improved by adding more steps, improving communication, consolidating the testing aspects, and other things conducted by the experience of the project managers.

Thank you for reading! To get in touch with us, feel free to access:

👉 Support Page - chat with the team behind AppSeed
👉 Custom Development Services section and get a quote