Question

For the Unified Modelling Language, what could be the answers to the following?

What lessons did you learn from working on the Project (Grocery system)?

What part of the project was most difficult?

Were GRASP patterns helpful for object design?

As a software designer do you think there are the limits to agile as a methodology? If so what are they? Be sure to explain your answers.

Answer 1

Agile development aims to support early and quick development of working code that meets the needs of the customer. Agile supporters claim that code is the only deliverable that matters, whereas, agile opponents found that emphasis on code will lead to memory loss, because the amount of documentation and modeling done is not enough .There are some limitations to apply agile methodologies .

First limitation of Agile methodologies is that it is not suitable for maintenance, since there is not much documentation for the system. Developers are not concentrating on the documentation as much because the primary goal when using an Agile Methodology is to write software not documentation. Another limitation is that Agile Methodologies depend heavily on the user involvement, and thus, the success of the project will depend on the cooperation and communication of the user. Another limitation is that agile methodologies concentrate work quality on the skills and behaviors of the developers, as the design of the modules and sub-modules are created mainly by single developer. This is because they focus on building systems that solve specific problems, and not the general ones. Agile methodologies work best for teams with relatively small number of members (no less than 3 and no more than 9) , and hence, they will not work well for teams with large number of members.

To get the advantages of applying agile methodologies in the development, there is a set of assumptions that are assumed to be true. To mention some are: cooperation and face to face relation between the customers and the development team; evolving and changing requirements of the project; developers having good individual skills and experiences; in addition to many more. If these assumptions can not be met, it may be better to go with a different methodology for better project outcome.

These methodologies are a useful starting point for many practitioners and, regardless, you’ll need to have a basic reference understanding of them for items you’ll read and discussions you’ll have around your practice of agile. I’ve covered three of the most popular methods below.

Scrum

HISTORY

Scrum actually precedes the Agile Manifesto (2001) by quite a few years, having been introduced by academics in the 1980s. It was later taken up by a group of thought leaders in the ’90s, further evolving in the ’00s to support agile. It now has multiple institutes supporting it and offering certifications.

DEPLOYMENT

While exact figures are a little murky (partly because many companies use multiple methodologies), anecdotally I can say that Scrum is by far and away the formal methodology I see most out in the field.

IRL

Much of what agile teams do today stems from Scrum, even if they don’t explicitly practice it. Examples include the daily standup (or daily scrum) and the roles of product owner and scrum master (I much prefer ‘agile coach’—scrum master evokes the Stanford Prison Experiment for me). The product owner is the lead on supplying input from the user perspective—organizing story writing workshops, for example, and answering questions about user stories.

XP

HISTORY

Extreme Programming (XP) was created by Kent Beck and articulated in his 1999 book Extreme Programming Explained. Relative to Scrum, XP is more focused on how code is actually written and tested.

DEPLOYMENT

While probably not as widely deployed as Scrum, many of its practices are well liked and widely practiced by developers. Examples of this are pair programming (programming in pairs), test-driven development, and an emphasis on continuous integration.

PROJECTMANAGER

• sign up now

The Ultimate Guide to:

Agile — Chapter 5

The Agile Methodologies

by: Alex Cowan

• Ch.1: What is agile?
• Ch.2: Why might you want to go agile?
• Ch.3: Onboarding a Team to Agile — The Process Part
• Ch.4: Onboarding a Team to Agile — The People Part
• Ch.5: Agile Methodologies
• Ch.6: Practicing Agile IRL (In Real Life)

Agile Methodologies

Many (most?) agile guides start with a description the various methodologies, and I think that’s bad. It’s backwards. The methodologies are useful for:

1. Getting started with your practice of agile (and then adapting it to your situation)
2. Finding ideas to solve a particular job/problem you’re grappling with (ex: How might I integrate a part time data scientist into the team?)

Particularly for #2 above, you need a point of view on what you’re trying to achieve and why before you worry about what a given methodology says.

What they’re definitely not good for is mastering a fixed orthodoxy and then focusing your practice of agile on trying to cohere to that orthodoxy—yet this is the role that many of these methodologies end up serving in actual practice. That’s bad for obvious reasons, not the least of which is pretty much the exact opposite of the agile tenet of ‘Responding to change over following a plan’.

If you’re a Scrum enthusiast (or similar), please don’t be mad. It’s not that I don’t like Scrum—I’m just not as into it as you are.

These methodologies are a useful starting point for many practitioners and, regardless, you’ll need to have a basic reference understanding of them for items you’ll read and discussions you’ll have around your practice of agile. I’ve covered three of the most popular methods below.

Scrum

HISTORY

Scrum actually precedes the Agile Manifesto (2001) by quite a few years, having been introduced by academics in the 1980s. It was later taken up by a group of thought leaders in the ’90s, further evolving in the ’00s to support agile. It now has multiple institutes supporting it and offering certifications.

DEPLOYMENT

While exact figures are a little murky (partly because many companies use multiple methodologies), anecdotally I can say that Scrum is by far and away the formal methodology I see most out in the field.

IRL

Much of what agile teams do today stems from Scrum, even if they don’t explicitly practice it. Examples include the daily standup (or daily scrum) and the roles of product owner and scrum master (I much prefer ‘agile coach’—scrum master evokes the Stanford Prison Experiment for me). The product owner is the lead on supplying input from the user perspective—organizing story writing workshops, for example, and answering questions about user stories.

XP

HISTORY

Extreme Programming (XP) was created by Kent Beck and articulated in his 1999 book Extreme Programming Explained. Relative to Scrum, XP is more focused on how code is actually written and tested.

DEPLOYMENT

While probably not as widely deployed as Scrum, many of its practices are well liked and widely practiced by developers. Examples of this are pair programming (programming in pairs), test-driven development, and an emphasis on continuous integration.

“Doing agile well is about choosing, testing and iterating on the practices that turn out to work well for your particular project and team.”

IRL

Many of the practices above are adopted and practiced by development teams and, in practice, it’s usually the developers themselves that are most influential in deciding to adopt these practices. This makes sense (I would say) because the practices deal with their work at a very prescriptive level.

Kanban

HISTORY

This practice originates from work on Lean Manufacturing whose goal is to minimize work-in-progress and build on a just-in-time basis (among other things). It has become popular as a method.