Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Agile Analysis ...  New to Agile
Previous Previous
 
Next Next
New Post 8/30/2009 8:34 PM
User is offline sagar
1 posts
No Ranking


Re: New to Agile 

 Hello Phill

I hope it is already been 4 months for you working on Agile methodologies

I just joined this group and I could see your question but could not find any satisfying answer so I would like to share what I know

1. Agile is a Methodology (Not a model or a framework) under which you have different models such as Extreem programming, Scrum and DSDM etc. but most prominently used models are Extreem programming and Scrum

2. Agile is known as Light weight model because it has No or less documentation present in it.

3. Agile best suits for the projects where the delivery of the application or the product is immidiate in nature.

4. Through Agile methodology you actaully deliver a project or a part of a project with in short periods

5. Here Developers are kings and they run the whole show and client interaction (participation is the project)  is high and feed backs are rapid

6.some times the product can be developed and delivered to the client with in 30 days

7. Code it self is the documentation and their by further enhancements in future might take little longer

8. By this methodology one can give a quality product but their will always questions arises on it's architecture and design ( it will not have robust architecture i.e scalability and extendability of architecture).

I got some content this might help you

 

Best practices for increasing the agility of documentation:

  1. Writing

  2. Simplification

  3. Determining What to Document

  4. Determining When to Document

  5. General

 

 

I am trying to throw some light on this and do write me if you need more information.

regards

Sagar

 
New Post 9/1/2009 11:18 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: New to Agile 

Craig:

I agree with you that context diagrams and regular dfd's are perfect for agile modeling.   But it seems that about 99% do not.   Many  think dfd's are mainly  for big waterfall projects.

Tony

 

 
New Post 5/27/2010 6:46 AM
User is offline Phill O
2 posts
No Ranking


Re: New to Agile 

Well I am now getting on for nearly 18 month working with Agile. In that time i have learnt it, moved jobs ang implemented it into a dev team. It is working really well, and the out put is seeming to be of greater quality and less time needed to develop. We have bought licences for VersionOne which has been really useful as the team lean agile really quickly due to the way the tool works. Just the business next who need to get to grasps with it.

I kind of agree that 'Just Enough' is a little missleading, i have come across one of two product owner eho use it as an excuse of getting out of documentation. I like to document, but keep it simple. Just so i have soething to sign off against.

I have implemented the formal way of writing userstories, here in my new place, which is prooving successfull. The dusines are starting to think much more about their requirements, and what is it there actually trying to achieve. Format of userstories are: "as a [customer] i would like [request] for the following [reasons]".

Anyway keep sharing best practise is that i am learning. Sprint retrospectives are great for capturing dev feedbeack, and sharing with other product owners.

 
New Post 5/30/2010 6:42 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: New to Agile 

Hi:

So what exactly does a BA do on an Agile project?  Something more concrete that "just enough", "update only when it hurts", or "document with a purpose".  

Tony

 
New Post 11/29/2010 7:43 AM
User is offline Michael - VCMG
1 posts
No Ranking


Re: New to Agile 

Hi,

I look at "Agile" as more of a philosophy rather than a specific set of guidelines - it's a style of dealing with projects rather than something that replaces the traditional waterfall model.  Ultimately, in my opinion, everything boils down to the Software (or System) Development Lifecycle - SDLC.  If we take a look at it, it has some very concrete steps:

Analysis -> Design -> Implementation -> Maintenance -> Planning -> Analysis -> Design -> Implementation -> Maintenance -> Planning -> Analysis .....

Notice, that I've tried to represent this as a cycle - where the first step can either be Analysis, or may be Implementation or, may be you come on board onto a project where you are within the stage of Maintenance ... it doesn't matter - what matters is that first and foremost you recognize which stage of the project, you've arrived in.

Each of these steps are a context within themselves and each require the need for a Business Analyst.  If we are talking about each of these steps within the "Agile" context and we abide by the "Agile" mantra: "Just barely good enough", I usually follow these steps:

1. Identify first and foremost the bigger picture for the stage you are in.

2. Identify all the actors within the bigger picture.

3. Identify the responsibilities of all the actors ("actors" may not mean people - it may mean anything that has an impact on the system you work with - so it can be processes, people, other systems etc....)

4. Break down the bigger picture in stage 1 by the responsibility of each actor you identified in step 2

5. Break down each of the actor's responsibilities and / or tasks identified in step 3 into actions (where each action is defined as a set of pre-conditions which result in a set of post-conditions based on a number of variables or constants passed to the actor for a given task).  Of course you need to identify what each of the pre-conditions / post-conditions are based on the variables or constants passed to the actor for the tasks you've identified and so on ....

What you will notice yourself doing is eventually drilling down from a very general scope to a very narrow scope through each iteration as you simply try to identify the "Just barely good enough" components / modules / actions / whatever that make the system operational within the scope of the SDLC stage you found yourself in.

Ultimately, I see the responsibility of the business analyst to be the individual who makes sure that the scope of the project meets the overall expectations of the top project stakeholder.  With the approach I try to use above, I generally manage to have a much better contextual understanding from a big picture perspective, as well as a low-level understanding of whether the project as is, meets the requirements within the SDLC stage I find myself in.  If not, as a business analyst, you should communicate to the team that you see gaps which have the potential to affect the ultimate goals of the project.

You will also notice that as you drill down from above, you will have a much better understanding of the system and as such will be much better equipped to design test scenarios which will ultimately decide if the project is being implemented in a way satisfying business requirements.

I hope that I've posted something which adds value to the general discussion - this is a topic which could go on for a lot longer than this post ....

Cheers,

Michael

Sr. Business Analyst @ Fidelity Information Systems

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Agile Analysis ...  New to Agile

Community Blog - Latest Posts

Context:  Intro Change Request Definition Reasons for CRs Adaptive, predictive and mixed projects Flow of processing change requests Change Management Workflow Tools and Techniques 1. Intro  The World will never stop changing, as well as human needs and desires. The business environment evolves continually. An or...
For many people, a career in business systems analysis can be an ideal opportunity to use their skills in technology and business. Business systems analysts bring together the best of both worlds – technical know-how and business acumen – to help organizations become more efficient and effective. Here are some of the key benefits of pur...
There is no doubt in my mind that curiosity nurtures the mind when it comes to T shaped skills.  T shaped professional are specialist in something(the vertical line) and also have a wide range of skills and knowledge in a broad range of subjects(the horizontal line) and are are highly sought after in the workplace.  I’ve recently...

 






 

Copyright 2006-2023 by Modern Analyst Media LLC