Enterprise-level application development process overview
- How do enterprise-level software projects start?
- How do enterprise-level applications development processes work?
- Code collaboration, testing, releases and support on enterprise projects
How do enterprise-level applications development processes work?
Depending on how requirements are written and how suitable they are split to do agile development, the team may decide to reformat them to epics that consist of user stories.
Epics and user stories are commonly used practices in Agile development for splitting requirements for granulated implementation.
In all previous steps, depending on company maturity, stakeholders, business analysts, product owners, system architects, and other tech leads may be involved.
Depending on how comfortable company management and development teams are, the development methodology should be chosen. Based on my practice there are only two main options and both are agile - scrum, kanban, or a combination.
There is much software that exists to manage such a development process but from my experience, two of the most commonly used for enterprise-level areJira and Azure DevOps.
After at least part of the requirements split into epics and user stories they appear in the prioritized backlog which is the source of work for the development team, so, they take backlog items for grooming and detailed estimation one by one.
Backlog grooming it is the process when all team members involved in the development of particular features should ask all questions and split the user story into tasks from a development perspective; i.e., one user story may be split into multiple database tasks, multiple server-side tasks, and multiple frontend tasks, also may be created a separate task for test cases creation and testing.
Usually, the first tasks for the new projects are setting up development environments, creating infrastructure and project skeletons for microservices, monolith applications, or other parts. Next tasks usually would be adding more libraries and other code for microservices communication, exception handling, database access, unit, and integration testing, and other common things which are mandatory for almost every project.
Depending on the development team size it may be split into multiple squads, usually 4-7 people to decrease communication effort, each squad may have its own backlog. This helps increase focus on particular features or areas and increase parallelism. So there may be 4 squads with developers, 1 squad with testers, and one DevOps squad.
When cloud infrastructure became so popular and many cloud providers appeared in the market with different features and settings, developers had much fewer chances to be good in programming and in infrastructure management, that is why DevOpses appears in the market correspondingly to focus on infrastructure and deployments.
In the case of teams working in a scrum manner, groomed tasks are subject to take into a sprint which has fixed timeframes usually last 2-3 weeks and goes one by one without interruptions. This is required for management to be able to track performance, releases, and vacations, for the team to schedule recurrent events like plannings, groomings, demos, and retrospectives.
When kanban methodology is chosen instead of scrum there are no sprints and user stories are taken usually one by one and placed by tasks on the kanban board where each squad member can choose which task to take individually. Usually, the number of tasks in parallel progress and in each status is limited to increase the speed of tasks flow.
Ideally, before the sprint or on the first day of it developers do planning of tasks sequence to take by each squad member.
At the end of the sprint or at the beginning of the following sprint each squad participates in a demo meeting to share with stakeholders the results of sprint work to get feedback. Also their business analysts or product owners are collecting data to create improvement tasks in case needed.
The retrospective is another important ceremony each sprint where each squad member highlights good and bad things to tune the development process via action items. The most inspiring part there is when the team goes through the previously highlighted gaps to check how it was fixed.