This is the end of term submission for my CS-250 class. Below are the questions to reflect on after completing the course.
- How do I interpret user needs and implement them into a program? How does creating “user stories” help with this?
- Interpreting user needs is typically much more difficult then just asking the user what it wants. Normally, the process of interpreting needs is a long one, and is done upfront. The user stories generated from this process are extremely important, because it allows the interpretation of needs that the leadership of the project agreed upon to be disseminated to all the members of the team, such as developers and QA. That way, an idea of the user's needs can stay consistent from team member to team member.
- How do I approach developing programs? What agile processes do I hope to incorporate into my future development work?
- I normally use two different approaches while developing depening on my environment. If I am working on a personal project on my own time, I tend to be more loose with conventions and processes, and things like version history and planning can get a little messy. On the other hand, when I am working on projects related to my job, I make sure to follow all agile practices, as those are what my workplace follows. This includes sprint planning, retro, and standup meetings, using user stories daily, and keeping the end product constantly building. In the future, I plan on collaborating more in my person projects, and I hope to add some of the more applicable items of agile, such as story boards and user stories, as I believe they are very useful for keeping track of work and maintaining a consistent vision.
- What does it mean to be a good team member in software development?
- I believe that being a good team member in software dev is similar in some ways to being a good driver. A large part of being a good driver is acting predictably, not neccesarily politely. When driving up to a stop sign, the act of letting someone else go before you even though you stopped first messes up the entire flow of traffic as everyone around you were not expecting that chain of events. The same applies to working on an agile team. Agile is very good at compartmentalizing work into individual sections, so in order to be a good team member, you simply need to do the tasks specific to you, and trust the system. An agile team that is handing off and picking up working seamlessly can work like a well oiled machine.