Week 7

 Agile and Plan-and-Document (Waterfall) processes differ mainly in how they handle planning, flexibility, and development flow.

In a Waterfall approach, the project is planned in detail upfront, with clearly defined phases such as requirements, design, implementation, testing, and deployment. Each phase must be completed before moving to the next. This makes it structured and predictable, but also rigid—changes are difficult to incorporate once the project is underway.

In contrast, Agile is iterative and flexible. Work is divided into small increments (sprints), and requirements can evolve throughout the project. Teams continuously develop, test, and get feedback, allowing them to adapt quickly to changes or new insights. Agile emphasizes collaboration, customer feedback, and working software over extensive documentation.

Another key difference is communication and feedback. Agile involves frequent interaction with stakeholders and regular reassessment of priorities, while Waterfall typically involves less frequent feedback, often only after major phases are completed.

Overall, Waterfall works well for projects with stable, well-understood requirements, while Agile is better suited for projects where requirements may change or are not fully known at the start.

Comments

Post a Comment

Popular posts from this blog

Week 3

 Week 3 Learning Journal Git is really useful for managing source code. One good thing about Git is that it keeps track of all the changes you make, so if something breaks you can go back to an older version. It also makes it easier for multiple people to work on the same project at the same time without messing up each other’s work. Another helpful feature is branching, where you can work on new ideas or features separately without affecting the main code. Git also shows who made changes and when, which helps when trying to figure out problems. Even though Git is helpful, merging code is not always perfect. Sometimes Git can combine code without showing any errors, but the program still does not work correctly because the changes do not fit well together. This is called a logical conflict. Git also cannot fix situations where developers write code in different ways that do not match. Another problem is when people do not communicate well, which can make merging harder and more con...
Read more

Week 8

  Week 8 Learning Journal Understanding Core Concepts Instead of Memorization One of the most important things I learned in this course is the value of truly understanding concepts rather than just memorizing information. At the beginning, I relied more on memorization, but I found that I would forget things quickly or get stuck when problems were slightly different. As I started focusing on understanding the reasoning behind concepts, I became more confident and flexible in applying what I learned. I chose this because it completely changed how I approach studying and made learning more meaningful. Problem-Solving Strategies I learned how to break down complex problems into smaller, manageable steps instead of trying to solve everything at once. This included identifying what the problem is asking, organizing information, and solving step by step. This approach reduced mistakes and made difficult tasks feel more achievable. I chose this because it improved both my accuracy ...
Read more

Week 4

One of the most interesting things I learned from Software Engineering at Google is how seriously Google treats code reviews as a core part of engineering culture rather than just a formality. I was surprised to learn that code reviews are not only about finding bugs, but also about improving code readability, maintainability, and ensuring long-term ownership of the codebase. In particular, the idea that reviewers focus on whether future engineers will understand and be able to maintain the code stood out to me. This shifts the mindset from just “making code work” to “making code sustainable.” I also found it interesting that Google encourages small, frequent code reviews instead of large ones, which helps improve quality and efficiency. Overall, this changed how I think about collaboration in software development - code is not just written for machines to execute, but for other engineers to read, understand, and build upon.
Read more