Week 2 — Agile Development in Println, and Implementing Login-Logout

Published in

println-mic

6 min readMar 21, 2018

Just fresh fun stuff to keep you engaged

Hey, there! In building Println, we are using Agile Methodology as our development framework. Aside being mandatory for the Software Projects course, Agile has been helping us to keep on track on our progress to reach our goal.

What is Agile?

Being one of the most popular frameworks used in tech companies today, Agile focuses on delivering products in fast, iterative, and agile way.

Agile is a software development method where works of developing a product is divided into short phases (called sprints) with each sprints focuses on certain deliverables, adaptive of changes in requirements, and frequent reviews and assessment.

Agile Methodology is created as software business is now highly competitive, those who cannot keep up faster than the others cannot survive. This is why there is Agile Manifesto, the basic concepts of Agile explained.

Agile Manifesto

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

Building our Product: Project Vision and User Stories

The scrum journey in Println starts by planning our main product. Using Business Canvas, our team with the Product Owner (Microsoft Innovation Centre), listed down problems and ideas which we wanted to focus on. As Println is not completely new in our faculty (we have, not one, but two similar existing products widely-used by students), the stakes are really high if we wanted to stand out. From our meeting with the PO, we made our project vision, defining our objectives, goals, and our limitations.

On ideation phase, our hipster created mockups for Println, which are amazingly pretty, tested our mockups to some friends, and asked for feedbacks.

After planning our objectives, we started to plan on user stories. What do users want to be able to do within Println? Why do they want that? And how are they going to achieve that? These users stories keep us to focus on building features our users really need. Some examples of user stories in Println are:

As a user, I want to be able to upload a file to Println, so I can print it or save it for later.
As an administrator, I want to be able to see my printing statistics, so I can make monthly reports to my boss.

Sprint, Product Backlog, and Tasks

A sprint, in software development, means a set of period where a team works on a few backlogs, based on priority. Meaning, sprints are periods where we focus on developing certain features planned in the beginning of sprint period, called Sprint Planning. How long is a sprint? This depends on the Scrum Master, I know some companies doing a sprint weekly, biweekly, but in Println, we are doing it monthly, taking other college courses into account.

Wait, what’s a Scrum Master? No, it’s a who. A scrum master is someone responsible to lead or facilitate the whole scrum development process. They are the moderator on our meetings.

Before babbling about sprints and its flow, one important term needs to be explained. Product backlog. It is a more concise version of a user story. Product backlog is a list of items needed to exist in a product. It is a medium of how business people communicate with engineers on what needs to be built. Therefore, it has to be concise, descriptive, and easy to understand. No heavy technical terms. A single item in backlog is called PBI, stands for Product Backlog Item. Every PBI has a weight, or story point, or just point, to represent the difficulty of the item. In Println, we use the Fibonacci story point system, within the range 1–8. When thinking of each point, each of our member give estimates on a PBI. There were moments where one of us give 2 points, while the other gives 8. In this case, each of the extreme points giver would explain their estimation, why, and what aspects they think are important. This discussion helps us agree on a number for each points, and understand underlying problems that we might not have thought of before being pointed out by the other members. One unique motto Println members do on giving points are “fear of the unknown”, where we may give bigger points on items we do not know how we would implement yet, so it can give us rooms for learning and exploration.

Alright, so how does this sprint thing works? It all started with a sprint planning. In sprint planning, we discuss on what product backlogs are prioritized to develop in this period. This is why, on Scrum Board (explained below), PBIs are sorted by priority, highest to lowest. Each planning, we pick n items from Product Backlog, n depending on their points and our capability, and put them on Sprint Backlog. These items are our goals of the current sprint.

We define our Sprint 1 goal as “User can upload a file”, as we have so many PBIs on our Backlog. We also define our Definition of Done.

As a PBI is still too vague for us developers, we break them down into Tasks. Each task needs to be done in approximately 6 hours. We made 40 tasks throughout 6 PBIs. In Tasks, we use technical terms to define functions, tests, and implementation of a feature.

Scrum Board and the Not-so-Daily Meetings

A daily meeting, standup meeting, or scrum meeting, is a regular meeting among scrum team and their master to report their progress. In Println, we don’t do this everyday, instead we report every Tuesday and Thursday. There will be 8 meetings in one sprint.

Each daily meeting, we report on what we’ve done, what we are doing, and what task we will take later. We also clear up some technical confusion (like what parameters our front-end developers want us to accept, whether there is any request on the JSON Response format, etc.), ask for probably some advice when we are stuck on a problem, and synchronize our minds.

On each implementation we make, we need to make sure our deliverables follow the Definition of Done, task-wise or PBI-wise. One of the hardest Definition of Done for me to implement being 100% code coverage, of course, since we need to make sure all statements, all branches are covered. With all sweat and tears, we refactor codes, we check on logic, and finally managed to get 100% code coverage on every file we write.

Sprint Review and Retrospective

At the end of our sprint, we will face Sprint Review. A sprint review will be attended by the scrum team, scrum master, and stakeholders. In this case, our product owner (MIC), and our lecturers. We will demonstrate our deliverables (what we built on said sprint), and our stakeholders will decide whether to accept our product. PBI-wise, every items on the sprint backlog needs to be Done, by putting them to the Done Tasks, and obey our definition of done.

Retrospective is also a time when instead of reviewing the product, we review ourselves, and the team. We report on what we learned during the sprint, what we need to improve, and our improvement plan next. We also review our team work, how we communicate with others, or if there was problem within the team that slows down the development process.

The Dirty Codes

What have I learn these two weeks?

Mocking a REST request for testing, consisting of REST nature, request and response headers, request & response body, and status codes
Django REST Framework: Model — View — Serializer, how they work, and how to implement them
Django Auth: Extending their login and logout functionality, Permissions classes, and Token Authentication
Software Deployment: What you should do when your deployment SaaS has bug in their codes, setting environment variables and integrating database, adding migration as a release build before running applications

Yesterday, pip and setuptools were updated to newer version. Heroku Python buildpack upgraded their pip, but forgot to upgrade their setuptools. Hence, an error on our backend deployment (frustrating!).

Integration with Client: Cross Origin Resource Sharing setup

Without CORS setup, client automatically rejects resources (including JSON responses) without Access-Control-Allow-Origin header. In Django, we can specify which Origin are accepted (with ALLOW_ALL, fixed sets, or regex!) using django-cors-headers. This problem was found when we tried to integrate our backend with the client code.