Building Something From Scratch: Week 4
Welcome! The day that I publish this blog is the last day of the building something from the scratch phase. I have a lot of things to talk about and lots of learning to share.
Learning
This last week we learned about the importance of communication on agile teams. During the project, we worked on functions that depend on the work of other teammates, here communication was key, the ability to share our work, give ideas, give solutions and help other members.
This week I learned the importance of debugging, test, pair programming, and working constantly so you don’t have to rush with the important things. That’s actually one practice that the team had during the project that helped us have our work ready for the demonstration along with the correct functionalities, and free of bugs.
We worked constantly also on documenting each sprint and commenting on our code. That helped the team to save time having to explain things to allow others to work. Being that everything was commented on, documented, and very well explained during the meetings, no one had any problems working on their tasks.
We also tried to answer very quickly when someone had problems with certain tasks to help them on time, we were always available to do pair programming to solve problems, which was also key to success during this week.
In the end, I learned a lot of debugging code as a team on big pair programming sessions where we constantly participate to find a simple solution for our problems. Without this synergy, communication, and active participation, we wouldn't have finished our project.
Technical Things
This last week I learned about CI (continuous integration) and how this methodology works with the objective of helping development teams. CI is a software development strategy that helps teams to develop code faster and at the same time ensure quality.
This strategy is about creating and committing small amounts of code every day (one or more times in a single day), then through a CI tool the code is built and tested automatically, this happens before merging in the repository of the team. As it can be guessed, when code fails tests or building, it is fixed and debugged quickly.
There are other software development strategies that can be useful to know for future reference, you can compare them with CI below:
- Continuous integration: Automate testing and building of a project for each commit done.
- Continuous delivery: This refers to have an application that is always ready for deployment. In this case, it might be necessary a manual deployment.
- Continuous deployment: Refers to automate the building, testing, and deployment of a project. This means that if the code passes tests and is built without any problems, it is going to be deployed, all without any intervention.
CI improves productivity, implies producing higher quality code, increases customer satisfaction, and keeps developers happy and motivated, among lots of other benefits.
Conclusions
In a nutshell, I learned the importance of documenting your projects and how this helps to save time, not only for the current team working but for future teams that might continue the project.
I learned the importance and utility of daily standups and how communication is crucial to allow your team to know in advance how are you doing with your work and any problems, so these problems can be solved on time with the help and cooperation of all the team.
I also learned about the power that ownership has to motivate a team, to give their best, being responsible for what they do, and take pride in that also. I learned a lot from my colleagues, their way of working, coding, and communicating.
Thank you for reading, have a great day!
