aspose file tools*
The moose likes Agile and Other Processes and the fly likes Which methodology best to approach? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Which methodology best to approach? " Watch "Which methodology best to approach? " New topic
Author

Which methodology best to approach?

Kitaro Kutu
Greenhorn

Joined: Apr 30, 2012
Posts: 1
I would like to ask about which one is the best and appropriate methodology to approach. I am currently doing a final year report and had develop an mobile (android) application for the project. The problem is; I am bit confused how do I choose and know if the methodology that I am going to choose is the appropriate one?

A brief about my project; As I said it is a mobile application developing in android platform. It has between 5-6 phases and every now and again I did some iteration on some the phases (e.g coding, design, implementation etc) to make the app ‘better’. Of course this project is run and develop alone so there is no team involve but me.

Can anyone please suggest me if Rapid, Sprint or Scrum be ideal for this? It would be good to hear any suggestion and inputs for you.

Thanks in advance.
Mark
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30960
    
158

Scrum is a team methodology. It doesn't scale down well to being alone because the product owner/team/scrum master roles introduce conflicts. Iterations are still good to do as you have the opportunity to revisit what you are working on.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 5018
    
    8

Actually, Scrum is a process framework, not a methodology -- this is straight from the co-inventor himself, Ken Schwaber. Being a framework, I don't see that you can't use parts of Scrum to manage a single-person project. A daily standup meeting will probably not make sense unless you really like talking to yourself but the practice of daily, weekly, monthly planning can still be used to guide your work. Having a regular retrospective can also be useful. Committing to completing a set of features in a timebox can also be used. Of course, a prioritized backlog is always a good thing, regardless of the size of the team. So I wouldn't say a solo development effort precludes using Scrum but rather that you just have to figure out what makes sense in that context.


Junilu - [How to Ask Questions] [How to Answer Questions]
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 5018
    
    8

BTW, I don't believe there's one "best" approach. It all depends on the context. Scrum is a good process management framework. XP has some really good technical practices. Kanban and Lean have good things about them too. And so do the rest of the Agile flavors, techniques, practices. I subscribe to the assertion that "Agile" is not so much a noun as it is a verb. Agile is a way of thinking and approaching a problem that is guided by a core set of values and principles. (Ok, the linguists among you might argue that I just contradicted myself there by saying that "Agile is a way of thinking" which, technically, makes it a noun but whatever). See also: http://agilemanifesto.org
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30960
    
158

Junilu Lacar wrote:Actually, Scrum is a process framework, not a methodology

Got it.

Junilu Lacar wrote: I don't see that you can't use parts of Scrum to manage a single-person project.

Agreed. But I don't think it is still Scrum. I think it is "elements of Scrum that you like." Retrospectives aren't specific to Scrum. Using the spirit of timeboxing makes sense. The reason I don't think it is Scrum is that I think removing at least one major role (product owner) really changes the experience.
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 5018
    
    8

Good points made by Jeanne re the different experience when developing solo and using parts of Scrum vs. doing Scrum with a team.

As to the OP though, if I were doing a solo project, I would pay attention to using good Agile practices instead of worrying about what particular flavor of Agile I'm using. I would at least have the following:
1. A good understanding of the features that I want to deliver, the order in which I want to develop/deliver them, and the timeframes that I want to deliver them.
2. A good way to track my progress. The old-school stickies on a board should work fine. If you really want to go electronic, there are lots of open source project management / issue tracking applications out there, such as Trac. Rally and Mingle have community versions that teams with 5 or fewer people can use for free. Maybe VersionOne has a community edition too, I don't know for sure.
3. A good development/test environment: source/version control (Git or SVN), a continuous integration server (Jenkins/Hudson)

I would also pay attention to the technical practices I'm using:
1. Doing Test-Driven Development
2. Automating unit and acceptance tests

As for your comment re the "5 or 6 phases" that your solo project has, you mention coding and design as separate activities. Creating a high-level design may be done as a distinct and separate activity from coding but if you practice Test-Driven Development, detailed design, unit testing, and coding are done in lock-step. There is practically no separation between these activities.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Which methodology best to approach?