Once the requirements are known and you have completed the visual design, you are ready to begin development. This is where you actually start defining the technology architecture and writing the code that will bring your vision to life.
WHAT IS SYSTEM ARCHITECTURE?
Before code comes system architecture. As the name implies, it’s somewhat analogous to building a physical structure. You would be ill-advised to start hammering without understanding how all the boards are going to fit together to support the house you’re going to live in.
When it comes to technology, those boards and nails are analogous to the technologies you’re going to use and where the system will reside.
agile software DEVELOPMENT PROCESS
In the software engineering world, there are multiple development methodologies with names like Waterfall, Spiral and Agile, and each has its strengths and weaknesses. However, Agile has evolved into the de facto standard in most modern development environments — especially when starting a new development project.
There are many reasons for Agile’s popularity in technical circles, but they can all be traced back to the reality that programming isn’t predictable and repeatable in the same way as building a car or a structure. The process for developing technical products must adapt and evolve as unknowns become knowns. Agile allows for quick iterations and feedback so that this adaptation can occur.
Like project management itself, Agile comes in a number of flavors, such as Extreme Programming (XP), Kanban and Scrum.
Let me elaborate more on Scrum.
The general idea is to break a project down into granular pieces and assign a point value to each, which in turn translates into a relative increment of time. For example, if we plan on an engineer having 40 hours of productive time per week, and we assume that each point equates to two hours of effort, then we can assign this engineer 20 points per week. If the project is 200 points, then we can estimate that we’ll be done in 10 weeks.
As already mentioned, software development isn’t as linear as other complex processes, so the actual process never works out quite as it’s laid out, but going through the Scrum exercise does provide an idea of what a realistic timeline looks like.
Development consists of multiple time-boxed iterations that incorporate planning, coding and testing. These timeboxed iterations are known as sprints, and they typically last two to three weeks.
Perhaps the biggest advantage of taking this approach is that breaking the project down into bite-sized pieces allows the team members to see progress on a very consistent basis and evaluate the direction as they progress.
Backlog Creation and Planning
The process starts with backlog planning, which happens once and sets the direction for the development phase. The backlog simply is a list of desired features; it begins with the team, including all product stakeholders, engineering and design resources, documenting all features and user stories.
Initial Prioritization and AGILE Sprint Planning
After the backlog creation the items are prioritized and estimated, and the resulting list forms the basis of the work scheduled for each sprint. The prioritized backlog creation is then used to set the objectives for the upcoming sprints.
You want enough items in each sprint to fit the time box without overloading each sprint. Items can be added to the backlog at any time during the development cycle, but the additions will only be reviewed at the appropriate times during the sprint. The idea is that you don’t want to continually create a moving target in mid-sprint.
Your 10-Day Development Cycle
The development cycle consists of multiple sprints. Each sprint follows a predetermined schedule that looks something like this:
Day 1 – Development Planning/Architecture
The development team meets to discuss the features assigned to the sprint. The features are assigned to the individual resources, and any design/architecture tasks required to complete the features are performed. Many times, features are directly lined up to user stories.
Days 2-9 – Build
The development team works through the assigned tasks to complete the features. Coding, unit testing and internal quality assurance testing occur for each feature. The goal is to complete all of the features assigned to the current sprint.
Day 3 or 4 – Demo of Previous Sprint
The development team demonstrates the results of the previous sprint. This is a live demonstration that focuses only on what has been delivered in the previous sprint. The idea is to be able to frequently gauge progress and fix issues quickly as they occur. Of course, there may be very little to show initially, but the product will begin taking shape over time.
Day 3 or 4 – Backlog Grooming
The project manager meets with the development team to discuss the current backlog list for each sprint. The list is reviewed for content and estimation, and further clarification of backlog items may be necessary. Estimates may also change based on what we learn from completed sprints. Finally, any new features may be added, prioritized and estimated.
Day 10 – Agile Sprint Planning and Reprioritization
At the end of each sprint, the team reconvenes to review the priorities of the backlog list. Based on the new priorities and the velocity of the completed features in previous sprints, the appropriate backlog items will be scheduled for the next sprint.
Getting ready for Deployment
Once the product is ready to test with real users, the release candidate, as it’s called, must be deployed to an accessible location. How that works varies depending on whether the program is a mobile app, a Web app, a desktop app or other.
Over the course of the development cycle, the code lives in various places, but the two most important environments are development and staging, and both are designed to replicate the environment to which the application will eventually be deployed — also known as the production environment — as closely as possible.
When it’s time to deploy a version of the product, the development team does so by moving that version to the staging environment for the specified users to access. Typically, this would initially be done to let some early, “alpha” users provide feedback and to log any bugs that weren’t identified in quality assurance testing. Any bugs found will be incorporated into the backlog and prioritized as described above.
Once a release candidate is approved for release to production, the development team packages it for production deployment.
One Final piece of advice
We strongly recommend that the production environment, or stack, reside on the same infrastructure as the staging stack in order to minimize the number of variables. The less homogeneous the entire stack is, the more likely you are to experience strange behavior and the more difficult it will be to troubleshoot when you do.