- Typical development process
- Waterfall model
- Agile methodologies
- Extreme programming (XP)
- Dynamic systems development model (DSDM)
- Feature-driven development (FDD)
- Our approach
- Instead of a conclusion
When you take a big plunge and go for collaboration with a web-development team, you fairly expect your project to be done on time and within budget limits. But then it comes - a workflow approach that team sticks to.
In this article we’re going to tell you about the main workflow approaches in the web-development.
After reading this article you’ll be able to tell the Waterfall from Lean, Kanban from Scrum, and you will speak the same language with a developer.
First of all, let us describe the typical development process on the example of our company, assuming it’s the development from the scratch.
STAGE 1. MEETING WITH CLIENT
ADCI Solutions’ project manager (PM from here) and a client’s representative discuss the client’s needs (or the specifications if clients already know what they want), following amount of work and do the planning.
STAGE 2. PROJECT RESEARCHES
PM passes the tech documentation and specifications to the Lead Developer, make the project aims and requirements clear. Then Lead Developer does the assessment of the existing website. The client is expected to provide access credentials to the existing website.
Afterwards the Lead Developer do the report to the PM, who, in his turn, discuss all the features and details with the client.
STAGE 3. WIREFRAMES AND PROTOTYPES CREATION
Following is the work on the wireframes and prototypes in collaboration with the client and the team’s designer.
STAGE 4. DESIGN
We create not only a desktop version, but also a mobile one.
STAGE 5. BACK-END DEVELOPMENT
Initial installation and configuration go first. Then developers set up all necessary settings of modules. We make sure every website page was approved and client had gone through demo versions of every feature on the website. This was a little hint from the development side to you as a client: check and test all the options. There are no minor ones when it comes to the website usage. Believe us, your website’s visitors will notice every teeny-tiny bug.
Stage 6. Front-end development
Depending oh the project, the front-end and back-end development can go either in parallel or the back-end is followed by the front-end. Front-end developer implements all visual features and makes sure everything is pixel-perfect and that website is cross browser compatible.
Stage 7. Quality assurance
Remember the hint from the stage 5? Never ever omit the testing stage. We have a pyramid testing system, which means that from the beginning of web-development we start doing unit tests, then we add the integration test. After the integration test we move to the functional and UI tests and end up with manual tests.
Stage 8. Launch
The bugs discovered at the QA stage are being fixed, team finalizes everything and sets final settings.
Stage 9. Post launch QA and maintanance
Besides maintenance and support, the dev-team usually teaches the client how to use a website, manage it and add content, etc.
Now when you know how your project is being done, we can proceed to the working methodologies.
The Waterfall development model is supposed to be rather conventional.
Though there’s no word “agile” (read on to learn about it) in this model, it still works in particular projects. The waterfall is a linear-sequential life cycle model. It means one stage goes only after the previous was completed. The first Waterfall model designed by Winston W. Royce in 1970 included 5 stages.
- Requirements: identifying client’s needs.
- Design. Substage “Logical design” is about designing the product independently of any hardware or software system. Then Physical Design steps up and the developers turn Logical design into particular technology (depending on client’s requirements and specification).
- Implementation: coding the applications.
- Verification: client’s approvement.
That model works well for simple short-perioded projects with clear and rigid specifications. If your project is unlikely to stay the same as was documented at the “Requirements” stage, than you’d better ask the development-team to stick to one of the Agile group’s methods.
Agile development is an iterative approach to development. Unlike the Waterfall, the Agile methodologies assume rapid delivery of the product and the constant replanning and reprioritizing. There are no exact stages; time is time-boxed into sprints. A sprint is a time allocated for particular tasks and defined deliverables. The tasks’ value are supposed to be defined by a customer, who’s deeply involved into development process. A sprint is usually measured in weeks.
The Agile approach is all about customer’s presense and controlling (not necessarily physical). The customer should be ready to dedicate some time for reviewing sprint outcomes, assessment and (re)prioritizing. Client can test basic product version before the final release or even put a basic version to the market. That’s really great approach for the markets where being first means everything. Also client can change the project requirements on and off.
There’re plenty of Agile subsets, all designed according to Agile Manifesto:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
Scrum is an agile framework of managing projects.
In Scrum it’s the team who decides how task should be implemented, the documentation and specification writing is being omitted. Client doesn’t spend time on paper work, he or she just specifes what should be in outcomes.
The Scrum team is being overseen (not controlled!) by a Scrum Master and a Product Owner (PO). The Scrum Master is a kind of a coach that helps development team to deliver the high-quality product. The Scrum Master is not allowed to give direct tasks to the Scrum team members. The PO is a client-side representative, who reflects the customer’s vision and prioritize the “wish list” of the tasks at the beginning of the sprint.
Again, time is boxed into sprints (2-4 weeks). As soon as sprint is over, team must present a ready-to-market app / product. The Scrum sprint starts from creating the Sprint backlog: several tasks that team will turn from idea into a coded solution.
A Sprint is accompanied by daily Scrum meetings, where all the team members plus Scrum Master and PO gather to discuss what has already been done and how they can empower the delivery. Each meeting is limited up to 15 minutes. If the PO can’t take part in a meetup, his role usually goes to the Scrum Master. But since we have Skype and loads of chats there’s no problem with communication.
The sprint is ended up with a retrospective: team members, the Scrum Master and the PO talk on the outcomes, what’d been done and what hadn’t, and how the next sprint can be more successful. And, as already mentioned, the item made during the sprint must be shippable.
Lean is about creating a value with less work. It’s not a methodology or a process: it’s a set of principles. The PM must define the Lean development process himself - according to Lean principles. Lean focuses the team on delivering value to a customer, and on making the delivery - “Value Stream” - efficient. There’re 7 main principles that Lean is based on.
No unnecessary code should be written or useless functionality implemented. Therefore requirements must be clear and precise. Still the documentation is supposed to be a waste. Also, both a client and a developer should be it touch and react as quickly as possible not to force each other to waste time on waiting.
A developer keens to create a unique solution.Those solutions must be tested as soon as code is written. It means, the developer doesn’t wait for a particular stage to find out the bugs and fix them. Thus the development goes in cycles “Design - Programmed - Tested - Integrated - Delivered”.
Deciding as Late as Possible
The development team should focus on the full project overview and not go into details at first. That’s why composing the values list is over writing the requirements and documentation.
Delivering as Fast as Possible
The faster delivery is the faster a client can assess the created value and ask for some changes (if needed). The Lean evangelists prefer to do smaller batches of work since it doesn’t involve that many people and can be done quicker.
That’s why don’t expect your Lean developer to implement all the features at once: it’s long, resources wasting and can be not what you need (look at the principle Deciding as Late as Possible).
Empowering the Team
The ideal team looks at the whole project, not at its separate parts and is eager to learn new. By the way, communication with you - a client - is one of the motivational aspects for team members. Each iteration is followed by a discussion between the PM and the team: what was slowing the team down? how can developers work better? Something like the retrospective in Scrum.
Building Integrity In
Developers want to reach two kinds of integrity: perceived integrity and conceptual integrity.
Perceived integrity is what a customer experiences when the product work the way the client expected: the system solves the problem, reacts well on changes. Functional and acceptance tests help to find out whether the system is integrated or not from the client’s point of view. So be ready as the client to get asked frequently to test a product and give a feedback.
Conceptual integrity for a developer means that understanding the problem and solving it go in the parallel, information is released as soon as it appears (even before the complete information is available) and communication is held preferably face-to-face. To sum up, the client is aware of what is happening, how issues are being fixed and what’s more important - the client knows that the information is always up-to-date.
Seeing the Whole
The most important thing in Lean approach - to see how parts work as the whole and that all the team members are responsible for the project’s issues. Thus getting rid of a bug caused by a particular person not necessarily will keep the system healthy.
Kanban is a method helping the product delivery. It’s pretty alike Scrum, but with few differences:
- no roles within a group;
- work isn’t boxed into sprints and being delivered continuously and one task at a time;
- changes can be made anytime while the sprint’s tasks are strictly defined.
All in all, Kanban is built on three ideas:
- visualization of the workflow;
- limiting the amount of the work in progress for the sake of efficiency;
- the tasks from the backlog go strictly one after another.
XP is believed to be one of the most controversial agile methodologies. It has many things in common with Lean, Kanban and Scrum: alotted time (1-3 weeks), continuous testing (Lean), continuous planning (Scrum), customer involvement, small releases (Kanban). Some authors consider Scrum is the subset of XP.
The XP practices are the following:
- Planning Game (instead of short iterations);
- Small Releases;
- Customer Acceptance Tests;
- Simple Design;
- Pair Programming (instead of code reviews in other methods);
- Test-Driven Development;
- Continuous Integration (instead of Integration tests in Lean);
- Collective Code Ownership;
- Coding Standards;
- Sustainable Pace.
Crystal methodoly absorbs the principles mentioned above: frequent delivery and continuous improvement, customer’s involvement and testing. There’re seven subset methods: Crystal Clear, Crystal Yellow, Crystal, Crystal Orange, Crystal Orange Web, Crystal Red, Crystal Maroon, Crystal Diamond and Crystal Sapphire. They’re used depending on the team size, system criticality, and project priorities.
Since that methodology is not that wide-spread, we won’t overwhelm you with too much information on this methodology.
DSDM framework uses the famous Pareto principle - 80% of the system can be deployed in 20% of time. It’s oriented at a rapid product delivery. Won’t you be surprised to learn than DSDM goes for a client and a team collaboration, frequent delivery and integrated testing?
One thing that put DSDM out of the Lean and Scrum line is that the tasks can be removed from the backlog if they constrain the delivery of more important features.
FDD is rather a process than a methodology. Again it’s a short iteration (about two-week long), which has a particular feature developed as an outcome.
ADCI Solutions’ team strives for delivering the best product for the each client. That’s why we compose a brand-new project team every time we start a project. We do our best to implement agile methodologies in the development process, and try to be as flexible as possible.
A project team usually consists of a Project manager, backend, frontend developers and a web-designer if needed. We believe that backend, frontend and web-desigh work should be strictly divided between the team members. Each developer reports on the workflow process to the Project manager, whose main responsibility is distributing the tasks and making sure the work is being done within a schedule. The Project manager is the one in charge of communicating with a client. The PM, in his turn, provides the client with the information about the project and gives the client's feedback to the team.
We use Skype and BaseCamp to interact with remote clients.
That’s what the most popular development frameworks look like. Go for the Waterfall approach if your project is quite simple and short and requirements are clear.
In any other cases we’d suggest you to choose a team that uses any of the Agile methodologies: they’re flexible, easily changeable and give both the team and the client enough freedom.