Skip to content

SE Reflection

Jump to bottom
elazimi edited this page May 7, 2016 · 7 revisions

Quality

  • The Agile movement was used for the development our app, Mutirão. Agile helped our team communicate through Scrums. The scrums helped improve the quality of our product because it provided a constant back and forth communication between each team member on what they were working on in pertaining to the project. As each Sprint approached its end, the team would go over which user story was to be prioritized the most. Afterwards, each team member picked a user story to work on. When our meetings could not be held in face-time, the team continued communication through Slack, SMS and email.

Requirements

  • Planning - Assignment - Assigned roles to each member. This helps each member focus on their role.

  • Product backlog refinement - Added new user stories. Updated which u.s were completed/who completed it.

  • Sprint Planning - Assign new user stories to a team member. Discuss what worked and did not work since the last scrum

  • Sprint Retrospective - Reflection on what was completed during the entire sprint 1/2/3

What Worked: Scrums, slack communication, in-depth knowledge of Swift from our primary developers- Evis & Ian.

What Did Not Work: Limited face-time communication, successfully implementing all user stories

Design

Tools Used: : Xcode, Photoshop, Illustrator, Firebase, GitHub, Fabric, Excel, CocoaPods (Dependency Manager)

  • Gabriel was the primary designer, while Evis and Ian assisted too. Gabriel designed the icons and the final UI of the app. It was beneficial to have someone who has expertise in Photoshop and design because the design of the app is very much as important as the functionality. What could of improved was perhaps finalizing the UI earlier than we did.

![design] (http://i.imgur.com/ilQSn2r.png)

Implementation

The implementation of a database was key to our app. We needed one for 2 primary reasons:

  1. Store user info (account profile, picture, email, etc.)
  2. Store events created by users

We chose to implement Firebase as our back-end system. The service offers a NOSQL database that can be used to store and retrieve data. It offers an API that uses JSON for its transactions, so the whole content of the database can be thought as a JSON file. When architecting for Firebase, some design decisions were made. First of all, structures should be as flat as possible, making easy to access data without having to download the whole JSON structure, just by accessing the necessary keys. In order to represent couples data relations, Firebase suggest always using the key (imagine a dictionary) associated with desired data as the ID for the relation. As we can see on the image below, there are two main entities: User and Events. Those entities will mainly hold all the information need for the App. We can see an example of how a relationship between data works in Firebase looking at the fields ‘events_created’, ‘events_participating’ and ‘creator’. The placeholder (event_id or user_id) will be replaced for the actual key that index the user or the event within their respective dictionaries.

Testing

  • Once the first couple beta versions were completed, it was time for test trials to be done. All 4 team members installed the app onto our iPhones and would look for bugs and improvements to implement. Most of the challenges came with the implementation of the Firebase database system.

Evolution

The user stories dictated the evolution and maintenance of the app. Also each user story had a priority of HIGH, MEDIUM and LOW. During the first few scrums, the team put together a product backlog, which signified which feature was to implanted based on importance. As an example, a couple of HIGH priority user stories included:

  • US1 – Main Screen
  • US2 – Add Events
  • US5 – See list of events

User stories 2 & 5 required a database. Thus the implementation of one was put on high importance. Once we got a back-end system to store things like user information, profile pictures and events, we began to focus on misc. features like Share events with social networks. Eventually came all together into our final builds of the app.

![evolution] (http://i.imgur.com/ynfE2pz.png)

Changes

  • The team handles changes by constant communication through either slack, SMS or in-class scrums. Our 2 primary developers, Ian and Evis, handled this mostly in part because they needed to know who was working on what in order to avoid overlapping.

  • What also helped keep the changes organized was the creation of separate branches in our GitHub repository. For example, our Master branch was where we would merge workspaces from other branches like Develop and ProfileView that were used for feature implementation. If all 4 group members would only work off a single master branch, this could potentially create errors.

Team

The team consisted of 4 members:

Evis Brayan Gabriel Ian
evis brayan
Developer Scrum Master Product Owner Developer
el01403n@pace.edu bk29400n@pace.edu gr06604n@pace.edu ic34882n@pace.edu

What worked well was that our developers had vast experience with Swift programming, thus it made the decision easy as to which platform we would use to create our app. Brayan handled all things related to Scrums, Sprint retrospective & and postings on the Github Wiki. Gabriel helped with the early inception of the app and its functions and designs. What could have been improved was a more committed communication which at times felt half-hearted.

Communication

  • The team tried to communicate on a daily basis, especially after the end of Sprint 1. Scrums occurred at least twice a week. Slack communication happened every day, including weekends. What worked well was the available resources that we had (Slack, SMS, email, Skype) What did not work were the late responses early on, but that improved as time went on
Clone this wiki locally