Category Archives: Sprint 4

Sprint 4 Retrospective (Capstone)

This sprint, in my mind, one of the most important things that I was able to figure out was getting connected to AMPATH team through the Zeplin app. It seems that someone, perhaps accidentally, disconnected me from the group. Once reconnected, I was able to connect the rest of my group.
Although it hardly was a difficult task, it is hard to overstate how important it is to be on the same page as the team you are building the product for. It could have prevented a lot of wasted time on our end, and it makes it more likely that they get the end product they want.
Probably the most important thing I did in terms of learning about the tools we will be using was creating a “spike.” It is a new term I’ve learned that I will add to my lexicon, meaning to build a prototype of a product, diving deep to learn as much as you can. I touched upon it in my last apprenticeship patterns blog post, on “breakable patterns.”
I failed to make a successful working prototype that did everything I wanted. It seems that I have less knowledge of how all these work together than I thought. This brings to mind the apprenticeship pattern mentioned earlier, “breakable patterns” — I leaned through failing.
I will return to the Angular “Tour of Heroes” the next day or two to fill in the gaps in my knowledge. I don’t think there’s very much that I’m missing, but what I am is important to making it work. I would like to do this as soon as possible to be as much of a useful contributing member of the group as I can be.
Last retrospective, I was optimistic about how much we would be able to do this sprint. In truth, I am a little disappointed that we were not able to complete as much as I hoped. I am still optimistic about what we can accomplish coming up, but I have to bear in mind there are only two sprints left.
I am hopeful we will get a lot accomplished, but I have to be realistic that it might not be as much as I would like. This is the time where I should be thinking about buckling down and dedicating several more hours per week on top of what I already dedicate to this class.
I do have to keep in mind the learning curve we are experiencing when working on a team project like this. It took us a long time to just get the program to build and run on our computers. We didn’t hear what we wanted the final product would look like from AMPATH until relatively recently.
However, I think we are approaching the end of the end of that learning curve. Once our scrum team gets one component finished, I am confident the second will come a lot easier. It is reasonable to hope we are able to do a third, and maybe a fourth if we we split up into smaller scrum teams. Anything beyond that might not be wishful thinking, but I learned my lesson for setting my expectations too high.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

Sprint Review Blog # 4

          Our fourth sprint laid the first real groundwork for the project design and coding. The AMPATH developers have given us more information as to how they want the simple app to look like. It should have a simplistic design within the flow and written code of the app to make sure it works properly. We created a new repository from a more updated version of the original files given to us. The original files were lacking in certain angular development modules so importing certain components and data became an issue quite quickly. The updated files now have those development modules which we have just cloned onto our computers and created a QForm component for the questionnaire form. We had to delete our previous branch known as questionnaire-form because it wasn’t up to date with the new files. We decided it would be easier to create a new branch from the new files and start over in this manner. We created the new QForm component and have laid the groundwork skeleton for how the design should look within our CSS and HTML files. The CSS is giving us issues however, because the form that we imported was vertical in format while the one that shows up when we ng serve is horizontal and slightly unformatted. We will continue to work on these issues to make sure they are ironed out and looking as proper as possible. We debug any issues we come across separately on our own and then bring it to the team if we can’t seem to figure it out. The option of multiple people debugging a problem is comforting and it allows a fresh look onto an engaging topic. I personally enjoy group debugging because it makes the learning experience much more enjoyable. I still think that the hardest part for the future will be to connect each component together and bind them into one final app with the other groups. We’ve already started collaborating with other teams on what information we all will be needing from a mock server. It will be necessary for the future so I think we should discuss how this server will be setup and which development tools will be used. We should also understand how data types will be formatted within this database so as to hold only meaningful information. It would be interesting to see how patient data types are handled at AMPATH but we’ll just have to make our own version based on guessing. I’m now more worried about connecting the CSS and HTML for the final application to make sure everything looks nice and simplistic since we had issues with our own CSS. We want to continue to understand how we should edit and evolve the code already given to us and turn it into the final product that they want. The most important aspect of this design that we decided on seems to be simplicity with functionality. We want to incorporate that using the imported modules while also gaining knowledge on how they designed their app.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

Software Development Capstone – Sprint 4 Retrospective

Over the course of this past sprint, our team has continued to make more progress in providing a functional side navigation bar for the AMPATH mobile application. In fact, at the very end of this sprint, we found that we now have a minimum viable product for this component! Every member of the team had a part to play in this development.

For this sprint, we divided each section of the side navigation bar component into parts, such that each of us would have a smaller contribution to complete. Each of the roles were as follows: creating skeleton code for the side navigation bar so that it could provide a template for adding styling and further functionality, fixing the toggle button for opening and closing the navigation bar, adding styling and design based on the uniform style for the rest of the app, determining the type of content that will be displayed and navigated to with this bar, and adjusting the scaling of the navigation bar depending on the type of device used to access the application.

Most of these tasks were able to be completed by the end of the sprint! One of the team members created a blank Angular project on GitLab and provided code for a functioning dropdown navigation menu, which was a great template for our next step to creating the navigation bar.

The next step was figuring out the styling and design for the application overall (which would reflect in the navigation bar). This ended up being Angular Material (powered by Google), which is an implementation of Google Material Design that is compatible with Angular applications. Because the wireframes that were provided from the AMPATH team utilized Google Material Design, it made sense to work with this sort of design. So, using the Angular Material Getting Started guide (found here), I followed the 5 steps to change the skeleton Angular project into an Angular Material project. This first involved using the following command to install required packages: npm install –save @angular/material @angular/cdk @angular/animations. Next, the BrowserAnimationsModule was imported into the Angular project such that animations that come with Angular Material would be supported. Then, the NgModules for each of the desired components of the project were also imported. A prebuilt theme was also added, so that all core and theme styles could be incorporated into the application. This required the following statement in the styling sheet: @import ~@angular/material/prebuilt-themes/indigo-pink.css;. Finally, in order to allow for gesture support in the application, the HammerJS library was installed using the following command: npm install –save hammerjs. With all of these steps in place, we had a project with Angular Material! One of my teammates found a useful video tutorial about Angular Material (found here), and this resulted in even further developments on our navigation bar, in terms of better aesthetic, as well as functional pages to navigate to, and a working toggle button!

This upcoming sprint will be devoted more towards adding more features to this working navigation bar, and these will all be discussed in more detail in the next sprint retrospective.

Thanks for reading!

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Let’s Sprint, Into This Retrospective

Good day my fellow readers! Welcome back to another sprint retrospective. This is the fourth sprint in the AMPATH project. With things kicking off last week, we are into the thick of things working on the project.

With the new sprint, and a new goal in mind, the group decided to tackle the side navigation bar in pieces. As a group, we all sat down and discussed what are the components of a navigational side bar and, what components we should prioritize. As a group, we decided to prioritize the skeleton, button tasks, design, scaling, content, and web view. This, of course, lead to more learning about Angular. The sprint continued on with the group working off of a dummy app that one of the members had made. This is a concept where one makes a dummy or a toy of sorts. This dummy or toy serves no purpose to the project but, acts an environment to learn and mess around in. This way, one can learn in depth about say, for example, an Angular app, without impacting the real and important app in a negative way. You can make mistakes on the dummy or toy, and learn what not to do when working with the real thing. This was quite helpful to everyone on the team. Thanks to the dummy, by the end of the sprint, we had a working side navigation bar with working buttons. We had even worked out a nice design for the side navigation bar. While I was researching scaling, a fellow team member brought up that scaling might not be an issue that we need to tackle at the current moment. Taking time to look at his opinion I came around and began to agree with them. At the stage we were in development, we were developing for one kind of screen, our computer screen. However, we did not realize this until the end of the sprint. During the sprint review in class, we decided to look at the side navigation bar in the current state that we had it. Looking at the side navigation bar, the group started discussing on what devices the app would be used. Doing some quick changes to the side navigation bar, we quickly found that if we wanted to have the side navigation bar used on multiple varied devices, we would need to have the side navigation bar adapt to the screen size of the device. I will admit that after discussing how needless scaling was earlier in the sprint, now finding out made me a little embarrassed. For about half of the sprint I was doing a little less work than I should have been, thinking that my assignment was not useful and I would not need to learn this. This has left me with egg on my face and a bit of catch up work to do.

At the end of the sprint I have come out learning two important things. The first is that while it may not contribute to the project directly, making a dummy to learn about a component is a great learning method. The second is that even if something seems, useless in the current sprint, it is best to continue working on it, as it may be useful later on in the sprint.

That brings us to the end of another sprint review. See you next time readers!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

Sprint 4 Retrospective

For this week, I have finished up Sprint 3 and I would glad to be talking about it.

What I wish I could done throughout this sprint was to finding

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.

Sprint 4 Retrospective

This blog is about our third Sprint. This sprint is a bit better than the last one. I finally think that we are making some progress towards the Food Pantry project.  During this sprint, we did a lot of organization and more planning. We have decided to put our board into Github.

We created a project board and created issues on github as sprint backlogs or product backlog. This process was not easy since I do not have much experience with creating issues on github. I also find it weird how we create issues and use them as a story, but it is actually pretty efficient when you got a couple groups working on a project. During this sprint, it was a little tough how to separate what is an epic, a story, or a task. We were deciding in the group what is considered a story or a task. Most of the story we made had to be broken into a task so that it is more descriptive.

Another thing that kind of made it hard is that we need to create issues in two github repositories. There is the internal repository for the cs-448 students only which are the two group and there is the LibreFoodPantry which is more for the more serious issues and is available to others. I was not sure what difference is written in the LibreFoodPantry and the cs-448 repository. For now, I think it is mostly tasks that are put on the groups repository and the major stuff like one card scanning are placed into the public repository.

Lastly, we got ourselves a magnetic card reader. We are gonna be using it to get the student or customer’s ID from their OneCard and use it to find their information from the database. It will be stored along with their information. If an ID does not exist in the database, we would prompt them to fill out the intake form. Then we store these attributes into a database. I think we should try to design the database along with the food pantry’s front end. Since it feels like there is not enough task for everybody to do, I would probably try to make a rough draft of database design.

In this sprint, I learned more about agile development. This time we are doing it in github by creating issues. I also learned that I should always try to break down stories that are very vague and making tasks from it. I also learned that the process into creating a project is not as straight forward as it seems, there is a lot of things that have to be considered like which programs to use, what server, and other little things that make up the project. This time, we actually got our hands to a magnetic card reader where we could swipe the OneCard to. We figured out that it takes the ID number that needs to be formatted before it enters the database. Hopefully, we can manage to get it working during the next sprint.

From the blog CS@Worcester – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

Sprint-4 Retrospective Blog

It’s time for Sprint-4 Retrospective Blog Post. As you are probably aware by now, during this semester I will be working on a AMPATH project with a team I was assigned on by my Software Development Capstone professor. As part of our assignment we are assigned to complete a Sprint Retrospective blog post at the end of each sprint. As of Today, April 9th, 2019, we have completed Sprint-4. During this fourth sprint we were able to get everything we intended to get done during this fourth sprint cycle.  For sprint-4 our task involved the following:

  1. Learn about Angular Material
  2. Start working on the left navigation bar for the ampath mobile app
  3. As a team we had to divide the work to start working on the left navigation bar for the ampath app project. The work to be divided: setting up the project in GitHub, working on the left navigation bar skeleton, scaling, design, its content and button.

During this sprint the reason we had to learn about angular material is because it provides a Google’s Material Design Specification. Angular material is a UI component library that is well-tested and reusable for functional web pages and web applications. Since, in our project we are working with angular with the goal to contribute to the ampath mobile app.  Learning about angular material was considered an important steps to getting the left navigation bar started. After I had done the tutorial on angular material I started on our left navigation bar. Where I worked on the design, and minor button function. I generated a routing module, a few sub module and sub component that can be used for button function. During this sprint we was able to make the left navigation bar; however, it still require some tweaks and extra work to it. We decided that for the next spring we would focus more on improving the features in order to have a side bar with custom design and add some function it as well. For this sprint we only had to get the left navigation bar started to have some visual progress. Where next sprint the goal is to have a little more details.

I can say that during sprint-4, I’ve learned a little more about mobile angular doc, and about angular material. While reading and doing tutorial on angular material I learned the benefits and the different type of possibilities that can be done working with angular material. For example, you can use angular material for working on standers app layout, stander design, creating stander navigational tool and etc. Which I found pretty interested and will keep doing further research about it. In light of everything I learnt there is nothing very special that went on that requires details explanations or strategies that would be required for handling things differently next time. That being said this project is proving to be fun and interesting. So far this project is going without a hitch, and it’s not making anything more complicated than it has to be.

Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

Sprint 4 Retrospective

This sprint seems to be the last of nearly entirely research sprints. Now we have the tools we need to get down to business and make some meaningful changes to the code. We have access to the replica of the current, existing system, we’ve gained insight into whether or not we can use AccuTrack, and we learned how we will have to integrate OneCard Scanning. We’ve also organized our story boards to a reasonable state but there is always room for improvement and there are definitely pieces that we are forgetting to add that we’ll come up with on the go. Now it’s time to build stuff.

The first thing we did the sprint was something that actually happened at the very tail end of the last sprint, we gained access to a working replica of the existing system with help from Michelle, Beaulieu, the graduate assistant for the food pantry project. This let us see what flaws there are in the existing system as well as an idea of the complexity that the food pantry workers are familiar with. From obtaining access to this system, we learned about several new stories/epics that we’ll need to add to the growing list of things to do. This included additional fields/questions for the intake form as well as an entirely non-existent report system that we thought was somewhat integrated already. There are other small examples of things that we caught but those are the highlights.

I also met with Bridget Joiner from the student affairs office and discussed theproject. She was the liaison between Joanne and Laura Caswell, the person in IT who was setting up the system within AccuTrack for the food pantry. From this meeting, I learned that it was unlikely that we would be able to integrate with AccuTrack at all but that it was also a good idea to meet with Laura Catwell to get confirmation and possibly hands-on experience with the AccuTrack system. Following this meeting I met with Laura and confirmed that it was not possible to use the AccuTrack system and I also learned that the food pantry workers never bothered to learn the AccuTrack system so the lack of utilization won’t make a difference. I also learned that the level of communication between all parties was poor to say the least but this was a lesson to develop better communication in the future with all parties involved. Laura also confirmed that we could use a scanner and how to access the ID numbers on the card.

Next was the big move from Trello to GitHub issues. While everything has been moved from Trello to GitHub this is an ongoing process and we’re continuing to improve our system as we go along. We’ve decided that anything more than a task belongs on the LibreFoodPantry repository and all tasks should be on the one specific to our sections. We’re continuing to make organizational decisions regarding specific wording, tagging, and branches.

We’ve also obtained the scanner and confirmed the pattern that occurs when scanning OneCards for future integration of the device.

I also spent some time trying to correct some version mismatch problems with my local system and the current code that was on GitHub as of yesterday. There seems to be a new push from the other group that will hopefully resolve these issues, as the old version they had pushed used older versions of software.

This sprint was productive but not in ways that we expected. We expected to have more done regarding the actual software but instead we learned much more about the future and the long term goals of this project. We would have needed to have these conversations at some point so getting them out of the way now is not a bad thing. Hopefully by the end of the next sprint we’ll have some more developed, working software to discuss.

GitHub links to both repositories mentioned:

https://github.com/LibreFoodPantry/Theas-Pantry

https://github.com/cs-worcester-cs-448-sp-2019/Theas-Pantry

 

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.

WSU x AMPATH || Sprint 4 Retrospective

Sams Ships (12)For this sprint wrap-up, we discussed how we are trying to move on based on our team planning meeting. One of my teammates, Kristi, along with Professor Wurst, tried to check out an idea they had and continued to bounce ideas back and forth with one another until they came to a conclusion.

Overall, I’d say we are continuing to plan out our next steps and work on something new. A new development was a suggestion by one of my teammates based on what we already have to work with. The suggestion was that we should wait for the other group to push what they need and then we can seamlessly build upon it. If the other group (who are working on the sidebar and navigation bar) add their work, it would help us have a better base.

We have to carefully analyze how the components are going to go together and get through to make sure that they are not just getting thrown in. If we plan things out more, it will make the process more efficient. I think taking a step back to look through angular was helpful because it allowed us to learn something new at our own pace. It’s nice to not have to rush on what we are doing; especially when the concepts are newer. This will help us deliver something even greater for our client, who is Greg from AMPATH.

There is also the approaching team presentation that we are going to be focusing on to explain our work and what is happening. I think it will mainly be focused on the search bar and our experience with learning angular or the concepts that introduced us to it.

On top of what we have been doing, I have been continuing looking up resources to learn more for our project. I think Codecademy is a good reference for learning AngularJS, https://www.codecademy.com/learn/learn-angularjs. It is actually one of my preferred sites for reviewing programming languages to sharpen up on things I may have forgotten or for learning new ones in general.

It has been a great experience being able to work with a solid team so far this semester. I wonder how much we will accomplish by the end of it! I think learning about communicating within a team is so important, especially since we will all be graduating very soon and entering roles that require consistent communication.

Overall, the only thing I would say I would have proceeded to do differently is come up with another way to “work smarter not harder” when it came to figuring out the process for the search bar. There were not necessarily any fails because our continued work dealt more with the planning behind the work instead of testing to see what worked for us. I am very excited to continue moving forward with this project in the few weeks we have left!

Some advice for others who are going to work on things includes:

  • Having an open mind on what they would like to do because things are always changing
  • Understanding what the client wants is important because at the end of the day, they will be the ones who need to use this software
  • Try to make sure teammates are on the same page with you on what is happening that week

 

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

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.

From the blog CS@Worcester – Nhat's Blog by Nhat Truong Le and used with permission of the author. All other rights reserved by the author.