The IncreEdibles Sprint 4 Retrospective

This is Sprint 4 blog post for the IncreEdibles team. Since we have changed our direction of the project. We moved our plan to Theas Food Pantry; we also moved our stories from Trello to Github. We also got the OneCard swipe to work it our program.

On Trello, we have Product Backlog, Sprint Backlog, Doing, Review and Done. We placed all stories into these categories. By doing this we can assign and to keep track with our work. Product backlog is where the bigger features, big stories. Sprint Backlog is where we place all of the stories, we plan to do during the sprint. The last categories are for the progress and review. But by this way, it is difficult to know which story is task or epic stories. We are also work with other team; we don’t know which stories they are doing because we are not on the same storyboard. So we moved into planning on Github, because we are the first to try out this system. We are tester to set the rules of how the classes operate later. We came across a few problems while set this up. The tag feature in Github is good but we didn’t know where to place our stories. There are two repositories, we got confused to where to place stories on CS-448-Theas-Pantry or LibreFoodPantry/Theas-Pantry. After we test and try it, we think that LibreFoodPantry/Theas-Pantry is for big stories such as Epic and Story. And tanks are what we are working on individual, small tasks to make one story/feature. Other problem is branches, we are not used to work together on one project with many people. There are few people including me still confused about branch, but we will figure it out after using it.

Github have many positive features we need to work on this project. We now can create tasks and share between two groups. We can pick and working issue on our storyboard, also we can view other team board. We able to work on your own branch, without change master branch and review each other work. There is still confusion about the way we setup, but we are moving along. Hopefully we have the set of rules, work system so the future classes have better start. For next sprint, I hope to contribute more to this project. This is really way to understand how software development, we will meet roadblock as team communication , product owner … not just the technical side.

Advertisements

The IncreEdibles Sprint 3 Retrospective

This is Sprint 3 blog post for the IncreEdibles team. Since we have changed our direction of the project. We moved our focus to WSU Food Pantry, we thought that creating smaller scale is more effective to learn. We are trying to understand how the food pantry operating. We also need to know more about how our costumer operating. It is not simple, we had some difficulty on the communication. We don’t have direct communication to the costumer.
Since this project is new, even for our customer. It’s still updates and revolving. Our costumer doesn’t know how to implement technology to their project. We need to know what they are looking for, and what feature they are going to need in the future. We got to the first meeting with the costumer recently. That clear a lot more with our understanding with the project. Though our first meeting, we learned how our costumer set up. Although its simple, their way is not as effective. Which is good for us, we can help and problem solving. We run into few problems, as planning. First, our costumer problem with the technology as I mentioned. Second is the Onecard system, we want to know how to implement to our program. What happen when the card swipe? How to get that information to work with our program. It is difficult because it is also sensitive information. It deals with people information; the school don’t want this information to wrong doing. We want to build our program to be more effective and convenience. When person with one card come in, swipe the Onecard will display their info and make easy to input their food outtake. We hope the IT department with help us with that. Third, we still have question about the operation. After the 2nd visit we got more comfortable with your costumer. We feel we can ask our customer. Other food pantry team on other session is also working on similar project. We need to have communication with them, so we have work together. It is also not easy, since they have different timeline. And the online communication, Slack, is not as effective as in person.
In our next meeting we are planning into what are the next step. We will wait the team-fig response, so we know what teams are working on. And how to divide our work and who to help each other. I want to fully understand the food pantry operation. Then we have implemented important feature correctly. The next steps are design and build interface for the website. We want to have an interface design that simple and effective. We want to learn about manage database and print out report as customer want. We want to learn how developers work together in team and on project.

The IncreEdibles Sprint 2 Retrospective

This is the Sprint 2 Retrospective for team The IncreEdibles. We got assign to food pantry development, but we didn’t give any specific task. Big part of our team is design program and listen to the food pantry owner. There are two projects that we are working on, one is the make API that support other project where they can pull any information that they want. The other project is to work with Worcester State University food pantry.
As a group we decided to focus on WSU food pantry since we see more potential in this project. First, we want to know what the important features that costumers want. We learned that setup with costumers is not easy, not just to set the time and place for meeting. We have setup our communication on Slack, but most of the costumers are not in tech they don’t want to install complicate software. They want to have program where simple “plug and play”, so their energy can focus on what important to them. This is the problem that I think we always face with customers. We as developers before the meeting need to have set of question to ask, not all customers know what they want. We had meeting with Joanne, the professor who run the program. She wants to know who goes in and how much they take out the food, keeping track with the amount of food (by weight) is the main feature.
We took notes from the meeting and make email as direct communication that convenient for both parties. These features are important, but we must think of the design future features as program getting update. Features that they don’t think they need at this moment, that mean we must track data. These are sensitive data, we must be caution. The features seem not difficult as keep up with the weight of the food, but we want to have reliable program where it’s simple and easy to prepare/add feature.
There are few techs that our group need to know, OneCard swipe machine, we need to know that it is operative and how to implement to our program. How to export from the “sign up” Google Form. Export form that the costumer can export to submit to Worcester Food pantry. And most important is design our program where it is simple, clean and it do what it’s supposed to do.
Our next step is researching all the techs to make all priority feature work. Make a mock program, and present/sell it to the costumers. In this sprint we want to know how far we can get this program to work. There is other group in different section also look at this program, our problem is time difference and communication. If they have the same direction as us, we should find a way to divide the program into two parts that two group could work on. We find that the communication is one of the biggest problems even with members in the same group.

The IncreEdibles Sprint 1 Retrospective

For our project Software Development Capstone course, we got assign to working on food pantry. After we got to know our group members, we started to research about food pantry. We looked at how the data stored, what kind of software there are and what steps we need to take. At first, we meet our first problem, our project still in the early stage we didn’t know what customer are looking for. We took one by one step to set up our operation. We set up slack for our communication, we also have channel to communicate to other schools and food pantry owner. For planning and assign job to team members, we use Trello. We set up different stage of development “Product Backlog”, “Sprint Backlog”, “To Do”, “Doing”, “Review” and “Done”. We agreed on this setup is best for our operation, this way we know how doing what job and what been done and coming up. Next, we looked at what software and technique that require for this task. We know that we are using JSON file from USDA’s website as data base. We need to set up API able to read and get the information we need from JSON file. In order to get specific information as customer want such as what type of food, their expiration date and create report. We agreed using java for this project. Since most of us comfortable with it. That is most of back-end data that we are working with. ( https://catalog.data.gov/dataset/fsis-foodkeeper-data )

We need to host API where can be access online, there are a few options with paid and free. We chose Heroku since it is free, and we feel comfortable with it. To setup Heroku we need an account and set up app on our computer. They have good information on their Documentation Page. ( https://devcenter.heroku.com/ ) We are planning to set up mock-up test for JSON parsing and front end, where we can test and see how our project work. We figure since we still at early stage, we don’t know how other set up their front end. We can set up our own and make sure it would work.

Although at the beginning we didn’t know where we supposed to do, we weren’t used to project in early stage. I feel much better now that we got more ideas about what to do. This has been interesting, we learned about how the team set up in software development. We have good members that take on the job, I am still learning and trying to help. It is excited and fun to figure it out, next at the food pantry meeting with customers. We will have better idea of what they are looking for.

Why Doctors Hate their Computers

This blog is about the article “Why Doctors Hate Their Computers” by Atul Gawande, from the November 12, 2018 issue of The New Yorker. This article gives inside experience from doctor’s perspective about software system in the medical field. There are a lot of interesting point in this reading, its touch on point of view from the hospital admission, doctor and software designer. How each department want the software system to benefit them, while there is conflict between. In this reading, I understand where they are coming from and their difficulty adapting to the system. Most of the points in the article are from doctor’s perspective on software, and I am reading as the software developer. This is useful to understand from the customers. We as the developer, listen and understand from customers is crucial. We need to know how to make software useful and convenience, without too much hassle of using it.
The first point of the tensions caused the system to make doctors’ lives harder, the software release in large-scale at one time. Everyone in the hospital must attend hours of mandatory computer training. Most of attendant don’t want to be here, while they need their time to doing their actual job. Time is one of the important in the medical field, one doctor job to see and treat many patients. Rather meet patient face-to-face get personal, they are on computer checking the list. One system does not work for every doctor. Each doctor has their own way of working. System should be release and update slowly as developer work with the hospital/doctors.
The system design to benefit everyone, but I feel the real customer for the system is not just the doctors. The administration wants to keep track with all the work, the choices were more political than technical. The patient benefit from check list of safety hospital must do, but their records are not connecting between different system. They must answer same question every different visit. The doctors are the last people who are benefit, it seems while they are the operator, they have to follow the system. They must change their way of work to be beneficial to the system.
The lessons from the implementation of this system does not apply to only Electronic Medical Record systems. These lessons apply to all software development, how to find the balance of beneficial and drawback. The reading does show more interesting details that I didn’t think of. There are no big parts that I disagree of, there are lot of points from the doctor’s perspective. There is seem like two sides, I want there is mix between developers and users in make these systems. Less political and more of work together, time is important to doctor so make time use on computer similar to the amount time that they normally spend. Flexible software, we have AI smart enough to learn the way of individual doctor work. We have Google Assistant work for every phone why not work for each doctor. Look at the habit of individual doctor and build base on it. Doctor need to help developer to understand and find the solution that benefit both. The system should just an add-on to the existed work, the main idea is to support not to change.

Apprenticeship Patterns Chapter 1, 2-6 Introductions

This is blog post about the introduction of the concept of an apprenticeship pattern from the book “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye”. This first chapter explains what is Software Craftsmanship, what does it mean to be an Apprentice, Journeyman, and Master. The word Craftsmanship is what I expect as programmer, we train our skill though practice and get better overtime. The mindset Craftsmanship is to be an Apprentice, we should have the attitude that there is better/smarter/faster way so our thought progress will always be finding better way. While we learn from our peers and more experienced developer, we also learn how to learn. When we progress through Craftsmanship, another focus would be the connection within and outside of team. As we know, communication play big role in software developer, the journeyman’s responsibilities are wider than those of an apprentice. Mastery involves performing all the roles of an apprentice or a journeyman as well as focusing on enhance the skills.  What is Apprenticeship and Apprenticeship Pattern? Apprenticeship is a way to learn to be a professional software developer, focus on how to be skilled software developers and work with others. Apprenticeship Pattern is the collection of patterns from the experiences of about 30 practitioners, these patterns offer guidance to someone on the way of improving progress of their career.

The introduction the remain 5 chapters we get to see many patterns. These patterns are the important to be Craftsmanship, it is cover from how to be humble, learn to learn others and how much more we need to learn etc.. I think “Empty the Cup”, “Walking the Long Road” and “Accurate Self-Assessment “chapters are good for the beginner and to all software developer. Although I haven’t read most of the patterns, they seem straight forward with the setup: context, problem, solution, and action. I am sure there will be patterns that will help me in the future career. After the reading there is not so much change my opinion, about the topic. I have a mindset about software developer, and this book is make clear, also show me more ideas in this career. Overall the main focus of this book is how to be better at our skill and career. The chapters I mentioned above seem most relevant to me. So far I don’t have any disagree with this reading. This is a good guideline for the aspiring software craftsman, we find the balance in our learning not too full as the cup of tea or become big fish in a small pond.