What is the article about?
For the uninitiated flexible methodologies of software development may seem a chaotic set of actions, the order of which is absolutely unimportant. Want to implement a new feature? You are welcome! Want to redesign the application structure in the middle of project development? No problem. Certainly, such approach could not be called a non-working one. However, a seemingly simple and easy change of direction requires huge work on planning and preparation, which I am going to tell about.
In this article you will find out the stages of project creation, why these steps are important and why the positive result is impossible without the observance of this process.
Preparation
Gather the requirements
The work on every project begins with recognition of main requirements and goals. In our company UX-designers in cooperation with tech-leads and project managers deal with it. Even if a project is at the stage of idea, the customer surely has an image of goals he wants to reach, understanding of business-logic, which is the skeleton of each service, and target audience. This is the most difficult communicative stage, as the degree of customer’s frankness and readiness to search answers for questions he has not given consideration yet are of paramount importance.
We have no recipe for this project stage, because quantity and quality of entering information is often defined by the following: what specialists are going to participate, which questions from our checklist are topical, which format the communication is going to be carried out in, etc. In the working process the competitors analysis is carried out and the main service’s functions are described. The result of the research is a structured document, which contains some general information about the project, description of goals and requirements, competitors’ advantages and disadvantages, and project vision. You can find details about the research in our previous article.
The time for research varies depending on quality and quantity of entering information. That is why we try to establish trusting relationship from the first minutes of communication and stick to cardinal principles of ideas’ nondisclosure, even if there is no such an agreement.
Frameworks and documentation
When the goals are clear, requirements are gathered and we have information to work with, we begin to create frameworks and write documentations. First of all, we try to describe global users’ stories, where we specify possible roles and ways of users’ interaction with the service and with each other. After this we start to create wireframes and/or prototypes, you can read about that in our article (we are not focusing attention on the technical side here).
The main purpose of wireframes is the application structure design and checking the ideas accepted at the development stage. It is a common practice, that a function at the idea’s stage looks much simpler and more attractive, but taking all logical relationships into account it looks bulky and excessive in realization. At this stage exactly comes the clear understanding of how the user will get the necessary result, which processes will take place on the server and which on the interface’s side. All the wireframes are supplemented with each space description and flow reflection with indication of relations between sections and pages.
Development
UI design
The high speed of wireframes creation is compensated by their relative specification, that is why this information is not enough to estimate development. Formally, design development begins at the stage of research, but we put UI design into a separate production stage to simplify perception and coordination process.
So, we have the results of research, design briefs and documented wireframes, which are to be turned into a completed interface. At this stage designers closely interact with developers and find out how precisely their ideas can be realised. Design creation is a deceptively separated process, and there is a great temptation to make changes into pages, which were not supposed earlier.
It is vitally important to overcome such a desire and to follow the drawn-up plan, in order to avoid increasing time for design development and adding new functions, which will have significant effect on the development of the whole project.
Modern sites are seldom developed without adaptive design, that is why while creating UI design we take into account the way blocks will adapt to different screen types. It imposes lots of restrictions, therefore it is necessary to remember about compromise solutions, without which no design is possible. You can get more information related to this in our article about adaptive design, that also has the second part.
Frontend + backend development
After all the work from the previous points is finished, the stage of development planning begins. Before developers start generating kilobytes of code, it is necessary to plan architecture, estimate time for development, gather and choose a team, the members of which have the most relevant experience.
Certainly, it is extremely difficult to describe approaches to development in several applications due to the great quantity of their features. Perhaps, the cornerstone of any project is its time and budget management. Here we are absolutely open to all the approaches and try to warn about the consequences of any decision in advance. The classical flexible approach presupposes a very approximate estimate of the whole project and a detailed estimate of every separate sprint before its start (2-3 week cycle, at the end of which the product obtains a new feature). In this case a backlog is formed (the list of all tasks of the project) and tasks are given an approximate estimate, which becomes more specified before the development at the stage of sprint planning. Such an approach is ideal for big projects, where business requirements can vary constantly under the influence of market tendencies, users’ reaction and other factors.
If we speak about the development with tight budget, any changes in requirements, design or project logic are impossible in this case. Even the least significant change can take the butterfly effect and increase development time dramatically. That is why we always try to gather all additional wishes of our clients on a separate list, which we can deal with after all planned work is fulfilled.
Testing
Testing is an indispensable condition for any project creation. Our specialists start their work at the very early stage of project creation. Many people think, that QA specialists start their work in the course of development, however, they participate in formation of requirements to the project alongside with UX designers, help them analyse and make the description of the project at the initial stage, in advance fix users’ cases, which must be carried out in the finished product.
QA’s basic participation is a part of every project, and this work is not paid by the customer. Such an approach will do for simple projects, being at initial stage or those to be supported by the customers themselves. QA’s expanded participation comes as additional service, which we highly recommend not to neglect, even in case when customer has resources for independent testing.
We suggest the methodology of unified reports formation when developers will be able to quickly work with it, an integrated approach to testing, transparent results of check and timely reaction to changes. QA’s expanded participation allows us to bear responsibility for project’s post-release condition, which includes both corrections and large phases of development. You can find some more detailed information about the QA necessity in the article.
Release and support
The released project only begins its life and is in need of support. We provide a guaranty period for every project with QA specialists’ full participation. The length and conditions of this period are regulated by the contract. The recommended minimum is Server and software support and maintenance, which includes supervision over server’s condition, software relevance and timely updating of safety packages for maintenance of project’s relevant condition.
The expanded version of the package is 24/7 monitoring, which ensures maximum uptime and immediate support. We are ready to fix server’s work any day at any time, if it is out of order.
It should be pointed out, that we have accurate differentiation of work work types, which may be needed. It can be planned software update, critical updates/fixes that make service use impossible, noncritical fixes or new functions addition, which can be carried out without any substantial changes in architecture.
Instead of conclusion
Certainly, any project from scratch hardly ever starts with an idea only. We work effectively with any provided materials and try to preserve project’s vision, even if serious reconsideration of information is required. Every project, even the smallest one, always incurs risks with quite unpleasant consequences.
We know, that clear process plus transparent communication minimize these risks effectively. If our cooperation model makes an impression on you and you are looking for a reliable python developers company - we can do something beautiful together!
