This is an article from the series "2 mins dev's notes" from github-based blog about dev's daily routine challenges.
Intro
Sometimes, in small companies, it happens that the team leader gets a better offer and leaves the company, leaving their subordinates at the start of a new project. And often, this can put developers in a difficult situation since developers may not have the management experience to organize themselves and confidently start a new project.
The question arises, what to do in this case? What to do when you are the only possible candidate for the team leader position? And you don't mind taking it, of course 😄
Improvise. Adapt. Overcome.
Jk. The very first thing to do is to decide on your role. It is worth mentioning that the position of the developer in the company and their role in the project can be quite different.
For example, a developer is hired as a senior engineer. But on a specific project, they perform the role of a project manager. They often communicate with stakeholders, discuss tasks with the team, plan sprints, and distribute tasks among team members. Or another example, a QA engineer can often play the role of a business analyst, clarifying all project requirements and maintaining documentation.
So this is an important moment when starting a new project. The basic set of roles depends on the project, but most often, at the start, there is always a business analyst, architect, project manager, and designer. These are the roles/people that allow you to determine what exactly needs to be done for the customer.
If at the start of the project it is clear that there are more roles required than people are, then most likely, someone will play more than one role. Accordingly, it is necessary to familiarize yourself with what each role implies.
What's next?
After people have taken their roles, the question arises. According to what scenario will these roles be played? This refers to the principle which will be used in building the processes in the team. I'm sure everyone has heard about waterfall and agile.
More often, preference is given to agile methodologies, such as scrum or kanban, since it is considered that the waterfall is already outdated and often the customer himself may not know what he wants, so a flexible approach with constant feedback is required.
Just in such cases, the business analyst and/or architect at the initial stage may not be able to gather all the requirements for the project. But the base set must still be prepared and then we can say that we have collected the requirements for the MVP, the minimum valuable product, the minimum version of the product that can still demonstrate the basic capabilities.
Typically, such a set of requirements is written in the form of stories, because the human brain perceives stories more easily than diagrams. The story might look like this: "As a user, I want to add products to the cart." The story should include a person and a description of what that person can do.
After the list of such stories is sorted depending on their importance, you can begin to implement them.
Usually, by this point, it is already obvious which technology stack is suitable for the implementation of the project. Therefore, stories are cut into tasks, and tasks are taken by developers to work.
And as you can see, the coding itself comes last, because it is more important to be able to choose a tool for a task than a task for a tool.
Conclusion
The whole text above we can squash into the following steps:
- determine your role
- determine what you should do in this role
- learn a new framework while waiting for the basic requirements gathered
- participate in compiling, estimating, and planning user stories
- help divide stories into tasks
- get to work
Top comments (0)