http://www.b2ttraining.com/2007/10/01/share-your-agile-experiences-here/ Connecting Business Requirements to Technology Mon, 30 Jan 2012 21:31:56 +0000 hourly 1 http://www.b2ttraining.com/2007/10/01/share-your-agile-experiences-here/comment-page-1/#comment-1072 Jodokus Fri, 12 Oct 2007 07:28:02 +0000 http://www.b2ttraining.com/2007/10/01/share-your-agile-experiences-here/#comment-1072 In my view, a good BA could well play the role of on-site-customer, which is a crucial role in an agile (or any) project. In my view, a good BA could well play the role of on-site-customer, which is a crucial role in an agile (or any) project.

]]> http://www.b2ttraining.com/2007/10/01/share-your-agile-experiences-here/comment-page-1/#comment-1071 Kerber Mon, 08 Oct 2007 23:21:46 +0000 http://www.b2ttraining.com/2007/10/01/share-your-agile-experiences-here/#comment-1071 The term "agile projects" is something really new in the Brazilian systems development environment, but the idea to make always smaller versions to keep scope under control is vivid here. Even working that way, we can't see it working without having BAs on the team because someone has to make things make sense. It's really easy to implement and document a series of small changes, but who's' going to take care of the whole scenario? I have systems that were run that way for years and ended up being a complete mess because no one took care of basic things such as the stakeholders and the respect for theirs interests by the system. Something a BA lives for. The use of agile without BAs or not depends on what kind of service you are offering. If your clients take real care of the system, it's interactions with the business, you may adopt the agile approach and become a small changes supplier. If your clients demand SOLUTIONS, you will need BAs to be your change agents. We work to offer solutions and act like partners, sharing responsibility, so, we designed the area with - 3 BAs: Responsible for scope definition, business use cases, system use cases, entity class diagram and state machine diagrams. 10 Analyst-programmers: responsible for the refined entity class diagram, DAO and MER (database). They are also responsible for the programming and for the pure programmers management. 4 Pure programmers. People seem to be happy working this way because they can focus. Not having pure system analysts is good too because we can slowly transform the programmers with analysis capabilities into system analysts without loosing the programming side. They trust us as the ones who take care of the stakeholders interest while they can focus on the system interests (such as framework issues). Kerber ITBA Digitro Technology www.digitro.com www.kerber.com.br The term "agile projects" is something really new in the Brazilian systems development environment, but the idea to make always smaller versions to keep scope under control is vivid here. Even working that way, we can't see it working without having BAs on the team because someone has to make things make sense. It's really easy to implement and document a series of small changes, but who's' going to take care of the whole scenario? I have systems that were run that way for years and ended up being a complete mess because no one took care of basic things such as the stakeholders and the respect for theirs interests by the system. Something a BA lives for. The use of agile without BAs or not depends on what kind of service you are offering. If your clients take real care of the system, it's interactions with the business, you may adopt the agile approach and become a small changes supplier. If your clients demand SOLUTIONS, you will need BAs to be your change agents. We work to offer solutions and act like partners, sharing responsibility, so, we designed the area with - 3 BAs: Responsible for scope definition, business use cases, system use cases, entity class diagram and state machine diagrams. 10 Analyst-programmers: responsible for the refined entity class diagram, DAO and MER (database). They are also responsible for the programming and for the pure programmers management. 4 Pure programmers. People seem to be happy working this way because they can focus. Not having pure system analysts is good too because we can slowly transform the programmers with analysis capabilities into system analysts without loosing the programming side. They trust us as the ones who take care of the stakeholders interest while they can focus on the system interests (such as framework issues). Kerber ITBA Digitro Technology http://www.digitro.com http://www.kerber.com.br

]]>