The last ABAA meeting for the year is nearly upon us — 8 Dec 2009. The topic of conversation will be ‘what is a business analyst’s role in an agile world’?

At first I thought this would be a very interesting conversation but the more I thought about it the more I thought it was a little naive to be asking the question in this way. Is there an actual role? … see for yourself . . .

Kanban

• Prescribes no formal roles

ZenAgile

• Samurai – the defender of the project
• Roshi – the project lead, teacher and mentor
• Sensei – the team’s mentor, leader and users’ champion
• Team – multi-disciplinary where its members are chosen based on need

Scrum

• Scrum Master – protector and champion of the team from The Powers That Be
• Product Owner – customer representative and stack prioritiser
• Team – multi-disciplinary based on need

Extreme Programming (XP)

• Tracker - measures and communicates the team’s progress
• Coach – like the Sensei in ZenAgile this is a supporting role that helps a team stay on process and help the team learn
• Tester – helps the customer define and write acceptance tests for user stories in the same way a Product Owner might do in Scrum
• Customer - defines what is the right product to build, determines the order in which features will be built, and makes sure the product actually work
• Programmer - implements the code to support the user stories
• Programmer administrator - manages the programmer environment

DSDM [1]

• Executive Sponsor – commits appropriate funds and resources
• Visionary – initialises the project by ensuring that essential requirements are found early on. The Visionary has the most accurate perception of the business objectives of the system and the project. Another task is to supervise and keep the development process in the right track.
• Ambassador User – the knowledge of user community into the project, ensures that the developers receive enough amount of user’s feedback during the development process.
• Advisor User – the one who represents important users’ viewpoints
• Project Manager – manages the project in general
• Technical Coordinator – designs the system architecture and controls the technical quality in the project
• Team Leader – ensures that the team works effectively as a whole.
• Developer – interprets the system requirements and model it including developing the deliverable code and build the prototypes
• Tester - checks the correctness in a technical extents by performing some testings. Tester will have to give some comments and documentation.
• Scribe – gathers and records the requirements, agreements, and decisions made in every workshop
• Facilitator – manages the workshops progress, acts as a motor for preparation and communication.

RUP

• Well, it has over 30 roles … so let’s not go there

If the essence of agile is simplicity then there’s certainly something wrong with some of these ways of working. The most striking thing in all of these is the lack of an actual, dedicated, business analysis role. There are certainly elements of a standard BA in DSDM’s Scribe and Facilitator roles. The Tester and Tracker roles in XP could also be done by someone with a BA background. Craig Brown of Better Projects has even suggested that a BA could undertake the role of the Product Owner in Scrum. But Scrum, ZenAgile and Kanban essentially take the most appropriate people with the most appropriate skills in order to acomplish a specific task or activity. In these, there is obvious room for a BA role to lead or follow, but no defined role for a BA to play as it’s task dependent.

So what is a business analyst’s role in an agile world? Just like there is no PM role in agile there is also no actual BA role either. In some areas that focus more on software engineering there aren’t even any standard analyst roles but moreover a focus on eliciting customer needs directly. It means that in some agile projects there may not be a perceived need to involve an analyst at all.

In reality, though, someone needs to assist with the following:

• Understanding users’ needs, wants, expectations, capabilities and attitudes
• Communicating and documenting those needs
• Translating those needs to those who will implement the project
• Ensuring that the output meets the needs of users and the strategic goals of the project and, moreover, the organisation as a whole

This reinforces that skills in business analysis are important for everyone in the project and not just a single role as is prevalent in traditional waterfall projects. It suggests that everyone, from the project lead, samurai or scrum master, should have these skills.

So what is a business analyst’s role in an agile world? There is no BA role. But everyone should definitely have a business analysts skills.

M

- – - -

1. http://www.businesspme.com/uk/articles/rh/49/Roles-of-DSDM.html

Software Development Methodology

WhiteHedge Methodology and Models encompasses multiple processes and methodologies to take the surprise out of projects and deliver measurable results for our customers.

WhiteHedge approaches any problem with a proven methodology. Our systematic approach toward solving a problem relies upon informed vision, organized blueprinting, efficient development, effective implementation, technology transfer, and superior maintenance. We recognize that processes and methodology are enablers for the project success; hence we follow processes still remaining flexible.

Our Unique Approach

WhiteHedge Technologies Software Development Methodology

6σ Six Sigma

Six Sigma is a disciplined, data-driven approach and methodology for eliminating defects and improving existing and/or new process. WhiteHedge uses Six Sigma driven approach to develop processes and projects. Working from the business drivers to develop measurable goals for achieving customer expectations.

Rational Unified Process- RUP

The Rational Unified Process is a software engineering process that provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end users within a predictable schedule and budget.

PRINCE 2

PRINCE stands for PRojects IN Controlled Environments. It is a project management method covering the organization, management and control of projects. It is widely used in the UK and most of Europe.

For details please look at:
Software Development Methodology

Scrum and Extreme Programming currently dominate named Agile processes. Less well known, but equally important, Agile processes include Crystal, Dynamic Systems Development Methodology (DSDM), Feature Driven Development (FDD)

Today’s typical Agile process, no matter what name you call it, takes the best from the buffet of Agile practices to create a typical process where:

1. Project needs or requirements are expressed in user stories placed in a backlog, and ideally written by Product owners (in Scrum), or customers (in XP) in collaboration with the development team. (Sometimes they magically appear.)
2. Developers give high-level estimates saying how long user stories will take to complete.
3. Product owners arrange user stories into incremental releases that take typically 6 weeks to 6 months.
4. Product owners choose the next stories, highest value first, for each development time-box. The stories chosen need to “fit” into the time-box based on how quickly the team can produce software.
5. At the end of each development time-box the team should have incrementally built some of the product. The team (proudly) demonstrates the finished product to product owners and other stakeholders.
6. The team adds up the development estimates for the user stories completed during the time-box. This is the velocity (from XP) that’ll be used to estimate the amount that can be completed in the next time-box.
7. The team holds a retrospective to evaluate how well they’ve done and what changes could be made to the process to allow things to go better, then the next time-boxed development cycle is planned.
8. Time-boxed development continues through to release — which is a short way of saying “rinse and repeat.”

There’s more common practices, such as daily standup meetings to synchronize the team, and burn-down charts to show development progress

Many links are laced through the essay — but here are a bunch in no particular order:

• Toyota production system
• The Poppendieks on Lean Software Development
• Software by Numbers
• David Anderson on Kanban
• Corey Ladas on Scrumban
• Arlo Belshee’s Naked Planning
• Aaron Sanders Kanban ground rules
• InfoQ article from Kenji Hiranabe on Kanban
• My simple Powerpoint presentation on Kanban

via Kanban development oversimplified: a simple explanation of how Kanban adds to the ever-growing Agile toolkit.

In this bright future the platform in a multi-platform is king by his commercial possibilites.

I’m shifting gears to my previous role as a business analyst within the actual day-to-day functioning of requirements gathering and strategic decision making and I’ve now tested a new rapid requirements engineering workshop.

It is simple and when everyone coorperates, highly effective. It requires everyone in the room to think up a user experience to write down on a post it. A mad rush is generated as post-its go on the wall.  Playing it as a game where the submissions get tokens. No ideas a bad idea, but features gain different units as everyone puts up goals, requirements and experiences with selected look, tone and feel, widgets, integration points, customer touch points, update features, messages, content and promotional activities. The workshop then proceeds to colour code the experiences with as many currently organisational categories as relevant.

Assembling the experiences in an early rudimentary journey is next and then adding essential parts to ensure a fuller user experience over time.  The essential messages may start as simple as possible and are layered up over time.  The main point of the exercise is to focus on essential acquisition-retention customer lifecycle from the most basic if non-existing already.

Delivery of the first two week plan is then possible stating the initial steps to creating the dreamed of customer flow.  The essential point is that user experiences can be in any form, relating to any step at any point or even higher goals, aspirations, moods and reactions.  Nothing is irrelevant, all must be tracked – best using digital cameras, mindmaps, integrated with gant charts integrated with the simpelest task manager wikised structure.

Fransız Cinélive dergisinin yeni sayısında Harry Potter ve Melez Prens filminden Harry, Ron ve Ginny’e ait yeni resimler yayınlandı. İlk resim de Harry kapağı süslüyor. İkinci resimde Harry ve Ron, Profesör Slughorn’u bekliyor.

Bij een familiebezoek aan ‘de grond’ (een oude traditie, al vermeld in deze conference van Gerard ‘Avelgem’ Vermeersch)was het oog van m’n broer gevallen op dit bunkertje op de vage grond aan onze achterdeur, tussen de Voorhavenlaan en de Londenstraat.

Schuilbunker tussen Voorhavenlaan en Londenstraat

Hij mailde me vandaag deze interessante link naar een site in verband met de Belgische Schuilbunkers in de Gentse Haven met info over dit schuilbunkertje en de reeks waar het deel van uitmaakt.   Het blijkt een ingang te zijn naar een grotere ongrondse schuilkelder, die dateert van na de tweede wereldoorlog, tijdens de koude oorlog dus.  En officieel zouden deze bunkers nog steeds niet buiten gebruik zijn gesteld…

Ik neem graag deze oproep over van de bezieler van de website bunkergordel bruggenhoofd Gent:

Mocht u nog meer van deze bunkertjes in de Gentse haven weten staan, mag u mij steeds contacteren. Ik sluit namelijk zeker niet uit dat er nog zijn. Heeft u nog oudere foto’s van vroeger van dezelfde bunkertjes, zijn deze zeker ook altijd welkom als aanvulling (scans zijn voldoende, ik hoef de originelen niet. info@bunkergordel.be

Als het op 30 juli 2009 door de deputatie goedgekeurd ruimtelijk uitvoeringsplan RUP 143 Voorhaven – Loods 20 gerealiseerd wordt, zal deze stille getuige van de koude oorlog verdwijnen. Vooraleer het zover is zullen we hem wel nog eens exploreren.  (andere stukken van het rup : feitelijke toestand, stedenbouwkundige voorschriften en toelichtingsnota,  goedkeuringsbesluit deputatie)

Rupert Grint bir gençlik dergisinde 2008 yılının Hottest Stars listesi’nde 31. sırada yer aldı. Ayrıca Rupert’ın kızlar hakkındaki görüsleriyle ilgili de küçük bir alıntı var;

“Bence konu kızları anlamaya gelince oldukça anlayışlıyım. Birkaç tane kızkardeşim var bu yüzden onların bana biraz yardımcı olacağını düşünüyorum.”

I have worked with various organisations to implement BPM solutions at both Enterprise and Departmental levels. A common challenge that I often come across is that both Business and IT don’t always understand how to apply itterative development approaches to support a BPM implementation.

As practitioners, I find we tend to take these types of approaches for granted but customers often need some education, especially if they have not used anything but Waterfall. The most common issue I find with Waterfall is that it instills a mind set of “Big Bang” project/solution delivery i.e. ‘know it all the build it and finally test it all’.  

With greater pressure on both Buisness and IT to show value and returns quicker and more consistently, itterative approaches have demonstrated their value with much better ROI and a lower unsuccessful implementation risk ratio, especially if an organisation is new to BPM. 

Various itterative approaches exist and the more commonly known one in my experience is SCRUM, XP, Agile and RUP. To help educate novices what its all about I thought the following resources may be useful.

Ken Schwaber co-developed the Agile process, Scrum. He is a founder of the Agile Alliance and Scrum Alliance, and signatory to the Agile Manifesto. Ken has been a software developer for over thirty years. He is an active advocate and evangelist for Agile processes.

 Further Reading (oldies but goodies):

• Iterative development requires a different perspective
• Development Methodologies Compared
• NewMethodology

-

Muhammad Qasim, is an Enterprise Architect with over 9,800+ hours of System Designing, Modeling & Architecting exposure with an over-all 16,500+ hours of technical solutions development. He has also been attached to Search Engine Optimization industry for over 8 years now, and holds the title of “SEO Guru” & “SEO Expert” of Pakistan.

Completed his BS from Preston University & received his Master from the same in Databases. He is a member of the IASA (International Association of Software Architects) and a Practicing Member of WWISA (Worldwide Institute of Software Architects) and an oath taken member of CAEAP (Center for the Advancement of the Enterprise Architecture Profession). He is also a PMI (Project Management Institute) and honorary certified Ecommerce Consultant from Institute of Certified eCommerce Consultants.

Currently he is employed with MNET Services Pvt. Ltd in the cadre of Enterprise Architect (One of the largest switch of Asia). His areas of Interests are Model Driven Architecture, .NET, Design Patterns, xtreme Programming, eCommerce, Merchant Services, Web 2.0 Technologies, Portal Solutions(Web sphere, Share point, Oracle Portal), Agile Methodology, and Service Oriented Architecture. Presently working on ITIL to PMI process alignment.

He has been providing consulting services in the past to Corporate Industry, on System & App Security, SEO, Systems Architecture, Project Rescue, Development methodologies, and process implementation of MSF, CMMI & ITIL. Being part of the banking solutions design & implementations like, CAMS, LOS, Network Management, ESB, enterprise portal and core banking system Gap Analysis to Implementation provides a protean touch to his knowledge areas in all banking operations and delivery channels.

He has also played driving role in development new products and services in the areas of ATM & POS channel. Designed & architected products like Funds Transfer, Mobile Topups, etc. Reengineering existing products with customer centricity prespective and also introducing new channels like SMS & mobile banking services.

Specialties: SCRUM, MSF, Zachman Framework, SOA, AGILE, XP, ITIL, ITSM, MDA, TOGAF, RUP, CMMI, TQM, Basel, COSO, CoBIT. ————– J2EE, .Net technologies, XML, XSLT, Oracle Developer, SQL Server 2k/05/08, Oracle, Erwin, MS-Access, MS Visio, MS Project, Project Server, Biztalk Server Sharepoint Portal, IBM Websphere, Tuxedo, Rational Rose, Rational XDE, Rational EA, ORACLE ESB, IBM ESB, ORACLE Fusion, Euronet, Visa, Mastercard, & ATM & POS related products.

Pra começar, dois pontos abordados no primeiro capítulo do livro de XP.

1. Histories, será que são melhores que casos de uso?

   1. O que dizer da programação por contrato, pré-condições, pós-condições. Eu as via como algo que trazia mais segurança de que o caso de uso teria sucesso quando fosse implementado.
   2. Se os casos de uso mostravam a utilização do sistema sob o ponto de vista do usuário, por que isso seria melhor ou pior do que as histories

Por favor, podem jogar pedras no pato.

Hoje (17/09/2009) vou apresentar um estudo na Uninove sobre o conceito e a aplicação do extreme programming em projetos de pequeno porte. O XP é um assunto um pouco extenso, portanto vou resumir aqui seus objetos de acordo com a minha pesquisa.

Desenvolver software é uma atividade que tem particularidades de acordo com o projeto envolvido, porém sempre repete certos padrões que exigem a atenção do desenvolvedor. Como a repetição de padrões pode ser identificada e existem vários desenvolvedores sempre discutindo sobre o mesmo problema, surge então a necessidade da definição de um ou vários métodos para resolver estes problemas.

Método Tradicional
·    Foco em processos e algoritmos;
·    Priorização do tempo para documentação;
·    Análise preditiva.

Método Ágil
·    Foco em pessoas e requisitos;
·    Priorização do tempo para implementação;
·    Análise adaptativa e iterativa.

No dia 11 de fevereiro de 2001, em Utah, EUA, 17 especialistas em desenvolvimento reuniram-se para debater assuntos calorosos e como resultado deste encontrou surgiu um manifesto que mudou para sempre a forma de ver os processos de criação e engenharia de sistemas. Era então proclamado o manifesto ágil.

Após este manifesto, as metodologias ágeis começaram a tomar força e hoje conhecemos o Scrum, o FDD, o Crystal e, particularmente, o XP (extreme programming), que é o foco deste trabalho.

O XP é uma metodologia usada por equipes pequenas e médias, comportando aproximadamente entre 3 a 10 pessoas, integradas em um mesmo local físico ou à distância, para desenvolvimento de pequenos ciclos de entrega.

Ao todo, TELES (ver bibliografia abaixo) enumera em sua visão 13 práticas e princípios que devem ser seguidos estritamente para que o extreme programming funcione. São enumeradas abaixo:

·    Cliente presente
- O cliente é peça fundamental e deve estar sempre presente durante o projeto para orientar a equipe sobre suas necessidades de software.
·    Jogo do planejamento
- O cliente define as prioridades enquanto que os integrantes da equipe de desenvolvimento estipulam prazos e metas, em um jogo de planejamento para controle de cronograma.
·    Stand up meeting
- Reuniões curtas de no máximo 15 minutos são executadas diariamente para divulgação do que foi e do que será feito no dia de trabalho atual. Problemas no desenvolvimento não entram nessa reunião e para eles um espaço à parte é reservado apenas com os integrantes envolvidos na solução do mesmo.
·    Pair programming
- A programação é feita em duplas, estimulando o aprendizado, a divulgação do conhecimento, a integração da equipe e a atenção constante na codificação
·    Desenvolvimento orientado a testes
- Teste antes é um dos lemas do XP. Todos os objetos vão possuir classes de testes (unitários ou globais) para aumentar a qualidade da elaboração do sistema.
·    Refatoração
- Código mal escrito ou de difícil compreensão deve ser reescrito para melhorar a legibilidade da fonte.
·    Código coletivo
- Todos podem alterar código de todos. A confiança na equipe é um das bases do XP e nenhum tipo de egoísmo deverá ser aceito. Para isso o código coletivo trás a integração, onde todos no desenvolvimento sabem como os códigos foram escritos.
·    Código padronizado
- O padrão facilita que o código seja coletivo. Se todos programarem da mesma forma, a compreensão da codificação será iminente.
·    Design simples
- A simplicidade em TUDO faz com que o XP seja uma metodologia leve e de fácil adaptação.
·    Integração contínua
- Os códigos escritos nas semanas posteriores são integrados aos códigos escritos nas semanas anteriores, fazendo com que o sistema além de modular, seja também consolidado, apesar de parecer uma contradição. A integração contínua também diz respeito ao envolvimento de todos os membros da equipe no projeto, estimulando a participação e a proatividade.
·    Metáfora
- Às vezes, entender o jargão da informática é um tanto complicado, por isso o XP prega que usemos sempre as metáforas a fim de que tanto nosso cliente como nossos colegas de trabalho consigam entender sobre o que estamos discutindo.
·    Ritmo sustentável
- “O jogador tem que ter dicernimento, porque o jogador, ele faz parte da equipe” (Muricy Ramalho cover, no pânico na tv)
Assim como os jogadores fazem parte da equipe, a equipe tem que se conscientizar de que ela é composta pelos jogadores e se eles estão indo mal, significa que a equipe está indo mal. O trabalho do conhecimento é feito por pessoas que precisam ser motivadas (estou falando aqui de qualidade de vida) para ter um bom trabalho. O XP diz que o serviço não deve exceder 40 horas semanais, 5 dias por semana, horas extras devem ser evitadas ao máximo e uma boa remuneração sempre ajuda.
·    Releases curtos
O sistema é feito modularmente, priorizando as funcionalidades que o cliente definir, porém o prazo dos releases não deve ultrapassar 2 semanas. Caso ultrapasse, é sinal de que essa história de funcionalidades poderia ser resumida para que o sistema tenha menos traquitanas inúteis, seja simplificado, mais modular e seja entregue rapidamente.

O XP auxilia na solução de problemas comuns vivenciados, estudados e documentados desde a década de 80 por engenheiros de software e empresas interessadas na produção de sistemas. Ele faz com que haja um vínculo importante entre a equipe de desenvolvimento e o cliente; entre os próprios membros da equipe e também entre as funcionalidades de um sistema, que neste contexto chamamos de histórias.

Ele simplifica e padroniza o código, tornando-o coletivo e de fácil entendimento, valorizando assim o trabalho dos profissionais que o produziram. Diminui consideravelmente a burocratização, fazendo com que as entregas sejam rápidas e, além de melhorar a qualidade do sistema com a refatoração, também libera recursos humanos com mais facilidade para o início de novos projetos, fornecendo constantemente novos desafios para as equipes.

Vou ver se, após a apresentação, consigo disponibilizar os slides e o documento entregue.

Clique com o botão direito do mouse aqui e escolha “Salvar link como” para baixar os slides da apresentação (PDF – aprox. 23MB – é demorado para conexões lentas)

Um abraço a todos os visitantes.

–

referências:

AZEREDO, João F Azeredo e, Responsabilidade dos Fabricantes de Software por versões Beta no Ordenamento Jurídico Brasileiro. Artigo, Universidade de São Paulo, USP, 2004

BECK, Kent, Extreme Programming Explained. Embrace change. 1st Edition, ISBN: 0201616416, Paperback, 1999

BROOKS, Frederick P., No Silver Bullet: Essence and Accidents of Software Engineering, Computer, Vol. 20, No. 4. 1987

COCKBURN, Alistair, Agile Software Development, Draft Version, Highsmith Series Editors, 2000

PÁDUA, Elisabete M M de., Metodologia da pesquisa. 10ª ed. São Paulo: Papirus, 2004

SOARES, Michel dos S., Metodologias Ágeis Extreme Programming e

Scrum para o Desenvolvimento de Software. Revista Eletrônica de Sistemas de Informação ISSN 1677-3071. Minas Gerais: Universidade Presidente Antonio Carlos, 2004

TELES, V M ., Um estudo de caso da adoção das práticas e valores do extreme programming. Rio de Janeiro. 2005

UNINOVE, Sistema de bibliotecas Prof. José Storópoli, Manual para elaboração de trabalhos acadêmicos, São Paulo, 2008

_____. Manifesto for Agile Software Development, Computer, 2001. Disponível em: http://agilemanifesto.org/ (Língua Inglesa) ou http://www.manifestoagil.com.br/ (Língua Portuguesa)

_____, Software Engineering. Report on a conference sponsored by the NATO Science Committee 1968, NATO, 1969