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

akshitavarma143
akshitavarma143
Different procedures are utilized for legitimate administration of IT administrations, yet ITIL is viewed as the best arrangement of practices for even administration of IT administrations. ITIL is the contraction for Information Technology Infrastructure Library.  In easier words, ITIL is many rules and arrangements for the effective admin...
0 Responses
Rajesh-N
Rajesh-N
What Everyone Must Know about AI in Testing Artificial Intelligence is the buzzword that we frequently keep hearing. Its widespread popularity and influence can be understood from the way industries adopting AI in their organization. Whether it’s Healthcare, Automobile, Banking & Financial Services, or Airlines, many industries have st...
0 Responses
Ashish Adike
Ashish Adike
As a Business Analyst, very often we get into a situation where the Project requires multiple IT Products to be evaluated before implementation and might seek Business Analyst’s recommendation for the same. With the ever-growing range of Products in the market and the marketing promotions associated with some of the products, it’s very ...
0 Responses






Latest Articles

The Business Value of Better Requirements
Jan 18, 2021
0 Comments
 Not every manager is convinced that his team needs to do a better job on requirements development and management or that such an investment will...
Copyright 2006-2021 by Modern Analyst Media LLC