This documentation is about Projexa.
But first... Let's talk about our organization:
CodeX is a non-profit organization, founded on October 15, 2018. As the junior company for Computer Science at UFCG, its main objective is to develop high-quality creative and innovative solutions and promote a learning environment, entrepreneurship, and, in conjunction with these endeavors, foster leadership and offer computer science students experiences in other areas such as personnel management, project management, financial management, prospecting, marketing, among others.
Every six months, CodeX carries out a new selection process for new members. If you are interested in being part of our team, keep an eye on our social media, especially our Instagram. In the selection process, we evaluate the participants' hard skills and soft skills through development challenges and, subsequently, interviews are carried out with the candidates. After that, the results of those approved are published and you become a Codex Trainee. After three months of training, if you are interested in remaining at our company, you are signed as an Effective Member of Codex.
Projexa is a dashboard to organize and manage the team and the projects of our enterprise.
With the aim of creating efficient management and centralized data collection, access to leaders and other members of the junior company, Projexa offers an environment for the construction and continuous evolution of a web system, open-source and, mainly, promoted by developers CodeX Jr. internals. The application has a register of members, projects and links, available for viewing by the entire company, as well as management over each one, according to the authorization level of each user.
Main features presented by Projexa, which were developed using Figma.
A president is the person who will manage the entire dashboard, registering it means giving access to others involved in a junior company.
Login as a president, after already registered.
Screen for adding a member to a specific company, in addition to viewing all of that person's data.
Screen to add a specific link with important information for the company, in addition to being able to view, copy this link, delete and edit.
Add a project that is being developed by the company, complete with customer information, details of each member's functions, in addition to the description.
Create an update to a project, in addition to viewing that specific update.
Login as an advisor and viewing possible restrictions.
View an advisor's restrictions, such as not being able to edit another member or delete.
Update views also have restrictions, such as not being able to directly edit or delete unless you are a member of the project.
Viewing a link in the context of an advisor.
Kanban is a visual methodology used to manage projects, offering a clear view of task progress on a virtual board. In our project, it was used to control the workflow from idea to completion. The table has columns representing different stages of the process. Each task is represented by a card that moves between columns as it progresses. Allowing a clear view of the status of each task, making it easier to identify possible problems and plan the next steps.
In this column, we record Issues without complete detail. We haven't done the description and priority mapping yet. They wait to be evaluated and prioritized before being moved to the next step.
The Issues in this column have been prioritized and have priority mapping, but have not yet been voted on for difficulty. They wait for the availability of resources or the completion of other activities to move forward.
Here, the Issues were noted in detail, mapped, voted on and judged important for the current Sprint. They are ready to go and all the necessary resources are available.
At this stage, Issues are being actively worked on. Each team member can sign off on a task, even if they are just studying about it. If for some reason the task cannot be completed, it can be returned to the Ready column.
The Issues in this column have been completed and are undergoing a final review before acceptance to be merged into the dev branch. This is important to ensure the work meets established standards and requirements.
In this final stage, the Issues were finalized, reviewed in the Sprint Review and have already been merged into Main. Therefore, at the end of the Sprint they will already be in production.
We have some tags that can help to organize the issues in Kanban, so let's see how it works:
The one/those who will resolve the issue.
Priority level to resolve the issue.
The difficult/effort level of the issue. (We use a customized Fibbonaci sequence to meansure this level {0.5, 1, 2, 3, 5, 8, 13, 21, ☕}).
Which sprint the issue belongs.
Which repository the issue belongs (Frontend, Backend or UI Design).
The review stage of the issue, which can be "To Review" (when you resolve the issue and wait for the review), "To Correct" (when the reviewer find something that need to correct and move your issue to column "In Progress") and "Merged" (when the reviewer approved your solution and merged at dev branch).
Integer version of Size (all values in size are strings so the github can't use this values to meansure in the graphics).
1 - Identify which repository the issue belongs
- Frontend, Backend or UI Design
2 - Identify the type of the issue
- Which could be: Feature, Fix, Refactor, Docs and Tests.
3 - Name the issue and give a simple description
- Use the previews information you got to name the issue.
- Example: Backend > Docs > Criar o arquivo COLLAB.md.
4 - Select which repository the issue belongs
- If it's a frontend issue,
select projexa-web, else if it's backend selectprojexa-api, else isdashboard-codex-ui-designers.
5 - Select some tags
- Select the tags: Priority and occupation.
- Obs: The size and sprint is discussed in the sprint planning.
6 - Describe the issue in detail
- Explain the issue in detail to discuss in the sprint planning.
7 - Move the issue to backlog
- Now you can put the issue in backlog, but always put in the end of the list to keep the column and kanban organized.
1 - Choose Priority:
- Select an issue based on its priority and your availability.
2 - Assign to Yourself:
- In the 'Assignees' field, add your name to indicate that you are responsible for the task.
3 - Move to "In Progress":
- Drag the card to the "In Progress" column on the Kanban board.
4 - Complete the Task:
- After finishing the work, move the card to "In Review".
5 - Review the Task:
- If necessary, mark the review stage as "To Review" for possible corrections.
After this, your code will be evaluated. If any corrections are needed, it will be marked as "To Correct" and you will be notified. If everything is fine, it will be merged into the main branch and marked as "Merged".
Taking into account that you have already cloned the project and that it is already running on your machine. Before you start making changes, open the terminal, type the commands and create a branch to work on. make sure it is in the root of the project.
for better identification, use the pattern "iss#" + "issue number in kanban" to name the branch [ex: iss#09].
If you are going to work alone on this branch, use the following command and go to step 2:
git chekout -b <branch-name>
If you want to work from an existing remote branch, use the command below and go to step 3:
git checkout -b <branch-name> origin/<remote-branch-name>
This is important so that you can start working in line with updates to the remote dev branch.
git pull origin dev
Now, make the necessary changes to the code.
After making the changes, you need to add and commit the changes. Use the following commands:
git add .
git commit -m "Description of changes made"
Now, push the changes to your remote repository using the command:
git push origin <branch-name>
If the branch is already created in the remote repository, it will update it and you don't need to do anything else, if it is not created, it will create a new branch with that name.
When pushing, if it is a new branch in the remote repository, a link will appear on the terminal
1 - Click on it to be directed to the pull request page.
2 - In the "base repository" field, select the "codexjr-dev/dashboard-codex-api project", in the case of the backend repository repository, for the web repository, select "codexjr-dev/dashboard-codex-web project".
3 - In the "base" field select the "dev" branch.
4 - Copy the link of the page you are on.
5 - Press the Pull Request button.
6 - Open your Issue on the Kanban board and paste the link copied above in the comments.
Projexa is a project that uses the SCRUM methodology, so, we have some teams categories/roles like the SCRUM Master (SM), Product Owner (PO), Quality Assurance (QA), Tech Leader (TL) and, of course, the Developers and the UI Designers. Each one of these categories is detailed below:
The SCRUM Master is essential for implementing and ensuring the use of SCRUM methods in a project. Their roles include facilitating events, removing impediments, coaching, practicing servant leadership, promoting continuous improvement, facilitating communication, and protecting the team from distractions, making them a crucial asset in SCRUM-oriented projects.
The Product Owner acts as a liaison between real clients and the project team, conveying updates to clients and representing their needs to the team. The PO is crucial for ensuring alignment between the team and the client requirements while also keeping clients informed about project progress.
The Quality Assurance involves four key steps. First, the QA team collaborates with the Product Owner to understand the product requirements and user stories. Then, they create test cases and plans to validate these requirements during development. Throughout the sprint, QA continuously tests and verifies the product's functionality, reporting any defects. Finally, they participate in the sprint review to ensure the product meets quality standards and is ready for release.
A Tech Leader serves as the technical authority, guiding the team's technical decisions and ensuring adherence to best practices. They facilitate collaboration, help resolve technical challenges, and maintain product quality by overseeing technical aspects of the project.
The Developers are responsible for turning product requirements into working software. They collaborate closely, self-organize, and continuously communicate to achieve sprint goals. Developers also participate in SCRUM events and maintain a commitment to delivering high-quality products.
The UI Designers are responsible for crafting project prototypes and ensuring the project's visuals are of the highest quality. Their primary objectives are to create designs that not only attract clients but also provide an easy and intuitive access to the system.
Following the SCRUM principles, at Projexa, we value the practice of Dailies and the use of Sprint Planning and Sprint Review, these components of SCRUM are explained below.
It is basically a daily message where you will summarize what you did in the last day it helps the team to keep aligned and promotes mutual help among teammates.
At Projexa, we can be transparent in our dailies and say like "Hello friends, I did nothing about the project yesterday because I spent a lot of time studying to my today's EDA's test". Because of this opening the dailies are not rigid or tiring.
We send one Daily message per day in the week, we do not send dailies on the weekend or in holidays, and we follow this structure below:
*Daily <Current Day>*
1. We use these system of topics;
1.1. To keep it easier;
1.2. To the others;
2. To answer;
2.1. Or pontuate something;
2.2. In our dailies.
3. The teammate that wants to talk about a specific point;
3.1. Just needs to mention the number of the topic;
3.2. And then, it would be clear to everybody;
3.3. What subject is being talked about at the moment.
...
...
Sprint planning in SCRUM is a meeting where the SCRUM team defines the work they'll tackle in the upcoming Sprint. It involves selecting items from the product backlog, setting a Sprint Goal, estimating tasks, doing Poker Planning to set the sizes of the tasks, and creating a Sprint Backlog. This collaborative session typically lasts a few hours and ensures the team is aligned on what to deliver during the Sprint.
At Projexa, the Sprint Planning occurs on the first Tuesday of the Sprint, in the afternoon.
A SCRUM Sprint Retrospective is a meeting that occurs at the end of each Sprint. It's a time for the SCRUM team to reflect on the past Sprint and discuss what went well, what could be improved, and any potential changes for the next Sprint. The focus is on continuous improvement, fostering open communication, and ensuring the team becomes more effective with each iteration.
At Projexa, the Sprint Retrospective occurs on the last Friday of the Sprint, in the afternoon.
A Sprint Review is a meeting held at the end of each Sprint where the SCRUM team presents the work they've completed. The team demonstrates the product increment, gathers feedback from stakeholders, and discusses what was done and what's left to do. It's a crucial step in the SCRUM framework to ensure transparency, inspection, and adaptation in the development process.
At Projexa, the Sprint Review occurs on the last Tuesday of the Sprint (that's when the Sprint ends). Usually it occurs in the night, at the end of a general weekly Codex Jr's meeting.
Typically, our Sprint length is two weeks.