Agile for Freshmen

My first talk in a test event

2013-02-22T05:45:00.001-08:00

Last Wednesday (Feb 20th), I presented at 33th Test Birthday Event in Sao Paulo! It was very cool! A great experience for me...

There's a long story behind, that I should tell you:

I was looking for a first event to start talking, to be more active on this! And then, few weeks ago, a friend of mine (Camilo Ribeiro - QA Consultant and blogger at Bug Bang Blog) told me about this event (33th Test Birthday) and I got interested in go and present something. As I didn't have enough time to prepare my own presentation, he suggested me to use the slides that some ThoughtWorkers presented in another event - Como Mariana se tornou uma Agile Tester.

So I sent this one as a proposal, and Camilo submitted a presentation about Lessons learned with Performance Tests.

Last week we received the list with the talks approved, and I was not included on that... Never mind (I thought!), I'll have more opportunities and even more time to prepare my own presentation and to prepare myself to present!

http://www.iterasys.com.br/aniversariodoteste

But things changed on the last Monday night, when Camilo sent me an email telling that one of the most expected talk of the event had been cancelled and the organizer was asking to include me instead . I got surprised with the huge responsibility that I was assuming by saying ok for that, because I was not preparing myself, and my lack of experience with Waterfall model (and Agile as well!) would made my life hard to compare both models clearly and detailed, following the content of the slides, or talk some bullshit and would not be able to explain! hehehe

Then, I asked Camilo to pair with me, to help me with the waterfall part of the presentation, so that I would be more comfortable to present. Another fear was about our synchronization with the slides, considering that we didn't have time to present together in advance. We were supposed to have an online audience and we had to be synchronized for a clearly understanding.

Anyway, despite all these challenges and fears, we presented for 50 people (online and face audience). It was cool because, even we hadn't tried to present together in advance, we could synchronize the presentation very well, complementing the thoughts of each one when necessary. After the presentation, people came up with some questions related to how to use Agile in distributed teams (teams splited in more than one country, challenges with timezone etc) and also how to make developers more concerned with testing and quality. In both questions we could share our experience at ThoughtWorks, working in projects with distributed teams (San Francisco - Porto Alegre, India - Sao Paulo - Porto Alegre and Sao Paulo - Porto Alegre).

People got interested about ThoughtWorks and gave us a nice feedback about the format of the presentation (according to them, very different from what they're used to see in other events).

Very proud of my first experience in a big event and looking forward to present in Agile Brazil this year!

Six months as a ThoughtWorker

2012-12-31T14:16:00.000-08:00

That’s a long time with no posts here! I must say that I had been amazed during the last six months, after I joined TW.

As I wrote in my last post, I couldn’t ask for better opportunity - I was totally right! I like this feeling of “no regrets” that I have everyday when I reach the office. I’ll start talking about what happened after I wrote my last post. In that time I was working in a project in the national institute for space research. I got a scholarship for Jan. 2011 to Dec. 2012, the duration of the project I was working on. During my time there I applied to some master’s degree classes (Artificial Intelligence and Applied Computing) and I my job in that project was develop a framework in Java, using web services. I learned A LOT during the 18 months I worked there.

Although I was enjoying that, I was really looking for new challenges and opportunities to grow.

I found this opportunity at ThoughtWorks, I applied for a QA role, and I got really really happy when I received my job offer. It was on start of March. However, I was submitting a paper for a conference and I had a deadline to deliver part of the framework in the next months… for this reason, I asked for some time till get my new job. So, finally June came and the time to become a ThoughtWorker as well! Then I left the project before the end of that.

The thing is, joining ThoughtWorks was not only associated with leave my family in Sao Jose dos Campos, fly to another city (Porto Alegre) and start a new life over there… Accept the offer meant being hired in a day and fly on the next day to India for a 6-week immersion program called ThoughtWorks University (TWU)… It sounded a bit scaring in the beginning (mainly for my family – “whatta hell is this company that wants to send you for too far in your second day as an employee???”) _ but this opportunity made me wait desperately for June. I don’t have words to express how much happiness and anxiety I was feeling that time.

I joined TW on June 4^th, and started my journey to India on June 5^th… I’m writing another post about my experience at TWU.

My first day in the company was really funny – people invited the new hires to walk around the office, to meet the co-workers and know about the projects. It was weird – so many new faces observing us… They seemed to be planning something… maybe… wish us welcome, by launching hundreds of nerf darts in our heads? Yeah, exactly that! \o/ Definitely, it was the best way to welcome us, and it made me figure out how amazing is my co-workers

We had a day with a bunch of new hires orientation and we took the time to finish what was pending to our trip.

Six weeks later, I was back to Brazil. The company gave me some days off to organize my stuff to move to Porto Alegre. Actually my stuff were already organized, I took these days to stay at home recovering from jetlag and enjoying the time with my family and also to eat barbecue and my mum’s meal which I was missing so much!

So I moved, found a new place pretty (small) close to the office! I got assigned to one of the projects from the office and started my job as a QA.

During the first weeks it was a bit hard for me… I was far from my family, Porto Alegre’s winter is pretty different from the one I was used to, spend the weekends cleaning my place instead take my time to study and rest was not so cool, cook for myself, pay my bills, do the dishes, the laundries (mainly that time when I haven’t bought a laundry machine yet)… everything was new and hard! =)

But after a month I got used to everything. People are used to be excited about their new job just during the first days or weeks, after that everything becomes a routine and starts to let you bored… In my case was completely different – everyday in the office I face a new challenge, I meet new people (new hires and expats), I have the feeling that I had in my very first day! And that’s what makes me so happy and passionate about my job. The environment in the office is awesome, my understanding about Agile has improved a lot after joining the company - we really do Agile - it's not only about daily standups, work in pairs, send code to the CI server..it's about the way we work, the team is very collaborative, we're always sharing knowledge and another stuff that make us agile.

People in the office are really friendly, it’s possible to hear people laughing and some hipster songs playing during the day… people send spams by email inviting to a beer, to foosball and video games competitions. We work hard, but we can also have fun during and after work time!

Among the role we play into the project we get assigned to, we also have the opportunity to get involved with another activities, such as social impact programs (SIPs) that sustains TW’s third pillar – Social Justice.

In general these SIPs are projects that aim to help people and make the world a better place. Some recent projects from ThoughtWorks Porto Alegre were to help citizens to interact with the candidates on the last elections, and another one to help a village from Porto Alegre with their recycle program… that’s much more than deliver software – the coolest part of these projects certainly is to figure out how this software can change lives, make people grow and get new opportunities to make their lives better.

I’ve been a member of our women in IT group – that’s also part of TW’s third pillar, and that’s our space to discuss actions to make the company a better place for women and to attract more women to IT. I flew to Baltimore – USA on October, to attend on Grace Hopper Celebration for Women in Computing – the world’s largest event for women in computing. There was another opportunity TW gave me to spend a week at the event, attending to some talks, generally about women’s right, leadership and technical themes. I’ll post a post about GHC soon.

I’m also having a great time working on the project I’m currently assigned – and I hope I can finish what I’m writing about my job as a QA soon! (Yeah, I’ve splitted this post in another three that’s not ready yet! This is just the first part! Hahaha)

I’m having a great time as a ThoughtWorker, working with amazing people and having such amazing opportunities.

I’ll share my experiences here more often, write reviews for the books I’m reading and technical stuff that I’m learning.

Quality Analysts and their roles into an Agile environment

2012-04-15T14:06:00.000-07:00

Thanks to the software testing, many drastic changes have occurred on the software development – more and more the development team is getting value from testing, i.e., they are adopting test as a habit, always worried about create test cases in order to verify if what as desired was delivered.

Additionally, the concept of quality analysis in traditional software development is not only related to the write tests just in order to ensure the quality of the product. It’s more comprehensive than this. In Agile, the concept involves the effective software analysis also related to verify if what has already been developed is in total conformity with which has been specified, and, consequently, in according to the customer’s desire.

While I was searching for some references to write this post, I find a very interesting presentation made by Syed Rayhan from Code 71, about the role of a quality assurance in a Scrum project. During the introduction, he brought some questions about the effective role of a QA. I sent him an email asking for some comments about these questions, and I’ve included his answers throughout my post below.

· Is QA part of the development team?

· Can we fit QA in the same iteration as development?

· Who does QA?

· Does QA costs more in Agile as product seems to change from sprint to sprint?

· Do we need “test plan”?

· Who defines testcases?

· Are story acceptance tests enough?

· When do we know testing is done?

· Do we need to track bugs?

QA plays a dynamic role into an Agile environment – he must be active since the start of the project until the software release, working together with the developers and product owner(s) to define test cases and acceptance criteria. Although Agile testers are developers, they have a specialized set of skills.

Even though, developers can write tests (not only unit one), but QA could have the mindset to write some of the other required tests.

However, in order to increase the success rate of the project with Agile, developers and testers must be part of the development team and need to be fitted in the same iteration, it is good for testers have test automation as their core focus and not only manual testing.

A team organized like this way means more quality to the software, because it will be tested in small pieces, and the team can receive a faster feedback about what is going wrong. The picture below shows the difference between a traditional the software development model and how it could be in Agile.

Traditional Software Development

Agile Software Development

And NO, QA doesn’t cost more in Agile! It may seem that teams spend more time retesting, but it is a necessary evil. The earlier we can catch a bug, the better. We end up spending less time in the long run. In fact, with the right amount of test automation, we would spend less time in testing for the same level in the long run. QA will help the team to verify earlier if what's being developed is exactly what the customer needs/wants, as well as help to track bugs and other vulnerabilities on the software. It means less rework at the final of the project; less chances of exceed the budget and the time.

The QA role within an Agile environment seems to be contradictory, because of the tools and process used are their working tools, as well as all the documentation. But when we talk about documentation in Agile, we are referring to a lightweight documentation, e.g., acceptance tests would help the team to document what's supposed to be developed, and it's the way to have a living documentation. But these acceptance tests aren’t enough to the process: a QA must have his test cases and tests scripts as part of the documentation, in order to help the team or another QA to perform a test that has already been done, without spending time in rewriting that.

Furthermore, it’s also important the bug tracking. Usually teams track bugs after a feature is delivered. During the development of the feature, it depends on the team. Informal interaction between the QA and the developers might be easier.

I extracted a figure from the Syed’s presentation, showing the responsibilities of each role of the team in perform the different types of tests:

The quality assurance plays a critical role to the success of the project; however, it is not the key to ensure the quality. The quality is responsibility of each one of the team, since the requirements gathering till the success of the tests performed by another members of the team (devs, support engineers, performance engineers etc.).

QA works together with the developer, the business analyst and also together with the customer, gathering requirements and writing the acceptance tests, always aware of what’s been developed and ensuring the release of quality software generally every two weeks.

The picture below shows clearly the role of a QA in a project:

The main responsibility of a QA is to make sure that the right software works right.

Since the team is self-organized, QA is not a designated person’s responsibility – it’s a team’s responsibility, and they should collaborate together for the success of the project.

Thus, it’s important that the requirements are very well specified without noises in its writing which may cause misunderstandings. If it occurs, this noise should be mitigated as soon as possible together with all the others members of the team – BAs, developers etc. – this is the main purpose of Agile.

The testers know that the less time there is to test, the less they will be able to test. And the less testing they can accomplish, the less the organization will know about the software before it’s released. Less information means more risk.

About my latest achievements

2012-03-21T17:59:00.000-07:00

Well, after a long time with my blog out-of-date, I have some good news: I'm joining ThoughtWorks Brazil!

I passed for a long but enjoyable and challenging hiring process, with many interviews that evaluated not only my technical skills, but also my personal profile, such as my personality, aptitude, attitude and integrity. It was the first time I felt really assessed during a process to join a company (although I haven't have many experiences with hiring process – TW will be my first job!).

For those who don’t know, ThoughtWorks is a global IT consultancy that is really well known in the software development community. It’s being one of global leaders in enterprise Agile development services and seems to work really hard to attract and keep just the brightest, passionate and talented people working there! They take pride on their hiring process and now I understand why. ThoughtWorks inspires companies and professionals around the world by delivering high quality projects and contributing to open source projects.

I have recently accepted their offer and I’m going to start with the company in June, with an awesome opportunity of going to India to be a trainer in an “immersion” process called ThoughtWorks University. It’ll be six weeks learning, facing challenges, and meeting awesome people from different nationalities and culture! I’m really excited to be joining a company with an amazing culture and working with so many brilliant minds!

I had a great time here at INPE, where I had the chance to learning a lot during this year of experience, but now it’s time to give a step ahead and face this opportunity to move from Sao Paulo to Porto Alegre to gain maturity and have the responsibility of live alone, and the most important: to start my professional career in a company like ThoughtWorks - I could not ask for a better learning experience!

I intend to post here my experiences while I’m in Bangalore and when I have a time for it!

So, that’s it! Wish me luck! =)

Business Analysts and their roles into an Agile environment

2012-02-03T18:53:00.000-08:00

The business analyst plays a defining role in creating a single vision for the product out of a diverse set of needs and wishes from multiple stakeholders, by enabling a diverse group of customers to speak with a single voice.

They must constantly ensure that the project is able to deliver the maximum value for customers and adapting to the business needs, and the features requested by the users align with the product’s business goals, especially as the business goals change during the time.

The business analyst has a central role in ensuring that the product screenplay clearly defines the product’s strategic alignment to the business need. The analyst holds shared responsibility in defining the strategic criteria for completion of the project.

The techniques of business analysis don’t change dramatically in the agile environment, but the timing and how they are used do. Artifacts as personas and data models, for example, continue to be employed, but are kept as lightweight as possible. Low fidelity artifacts, such as diagrams, maps, and lists, provide more value to an agile project than long, textual requirement specifications. Low fidelity artifacts are used to build the software for a specific iteration and only need to be understandable to the team during the iteration. On the other hand, Long-lived artifacts should be used beyond the scope of the development. They should be used to communicate what the software does and why it does it.

Agile offers the opportunity for business analysis to benefit from the frequent feedback provided by the business, by reviewing the results of successive iterations with the business stakeholders, having the opportunity to refine the product’s specifications and ensure they are aligned with the business, and identify and reduce risk he project as soon as possible.

In waterfall projects, requirements are developed in their entirely prior to the development phase. As risk elements are uncovered and business needs evolve, certain requirements may change or be eliminated, which results in a waste of work. By providing just-in-time requirements, there is less rework of requirements because only the requirements required for the current release are define in detail and developed.

There are a variety of ways a business analyst can be engaged on an Agile project:

In some projects a dedicated business analyst role is unnecessary. This is not to say that business analyst is not conducted during the course of the project, only that any member, or members, of the overall development team, may do it.
In more complex environments the analyst might be the facilitator, bringing divergent business stakeholders together and helping them speak with a single voice so the project team are not confused by contradictory and conflicting perspectives.
The analyst might act as the product owner/customer representative where they are empowered by the business to make decisions on product features and priority.
The analyst could act as a surrogate product owner, in situations where the business product owner not available.
The analyst might act as the second in command to a business product owner with limited availability.
An analyst could take the role of business coach in an environment where the business product owner in competent and committed, but has limited IT project experience and the rest of the development team are lacking in domain knowledge.

One of the key elements for a business analyst working in an agile environment is the ability to use feedback to drive change. The BA must constantly review requirements with the business stakeholders and ensure that any shifts in business needs are accurately reflected in future iterations of the product. In an agile environment, the success of the business analyst depends on his interpersonal skills as communication, facilitation, coaching and negotiation.

Acting like the “bridge” between the development team and the customer, the business analysts should constantly think as a customer, primarily on the time of:

Acceptance and evaluation criteria definition
Business rule analysis
Functional decomposition
Interface analysis
Non-functional requirements analysis
Problem tracking
Prototyping
Requirements workshops
Scenarios and use cases
Scope modeling
Survey/questionnaire
SWOT analysis
User stories

Agile business analysis is related to increase the delivering of business value to the customers of the project/product to be developed. To be productive on an agile team, business analysts are active participants, if not the actual facilitators of planning, analyzing, testing, and demonstrating activities.

Business analysts play a key role in facilitating a shared understanding of the business need for the project with all the stakeholders. It is the role of the business analyst to ensure there is a share, agreed vision of the product across the entire team. This requires the analyst an extremely high level of skill in communication, facilitation, and negotiation. In addition, they should have the ability to listen and understand feedback from all stakeholders and use this feedback to drive the changes required to the requirements and priorities of the project. In the agile environment, understanding and synthesizing perspectives alongside the ability to hold successful conversations replace the need for formal, detailed, long-term artifacts such as requirements documents.

In a brief, Agile Business Analysis is about ensuring the right information is available to the development team in the right level of detail at the right time so they can build the right product.

To read more about Business Analysis, I recommend the BABOK® Guide as a great source! Enjoy!

The Art of Gathering Requirements

2012-01-14T14:48:00.000-08:00

On the Waterfall model, software requirements are gathered together with the customer on the beginning of the project, and become pages and more pages of documentation. However, customer’s needs and wishes changes during the project, thus, lots of those requirements gathered, in most of situations, have already been developed, are lost.

Instead the Waterfall model, on Agile, requirements, wrote down as user stories, are gathered all over the project. In addition, Agile methodology values the face to face communication. When it doesn’t happen, the requirements were gathered ambiguously and wrongly. A good example of this is illustrated bellow.

User stories are short descriptions of functionalities that the customer wishes in its software. Generally, they are write in small index cards, in order to write just the necessary on that in a low level detailed, because the stories tend to change over the project. Some stories, called constraints, act as checkpoints/test criteria on the project.

User stories can be gathered through some ways:

User interview
Questionnaries
Observation
Story Writing Workshop

Story Writing Workshop

A story gathering workshop can be composed by the follow steps:

Get everything on the table

Identify the customer
Define the Project
Create the inception deck
Analyze the NOT list – a document, part of the inception deck, which is defined together with the customer, in order to specify what’s in and what’s out of scope on the Project, as well as those customer’s expectations that haven’t been decided yet. It’s important to keep the team focused on the real desire of the customer.

Brainstorm

Define roles and personas
Create mockup screens
Create flows and other design elements

Write the user stories
Brainstorm everything else

Create User Acceptance Tests (UAT)
Create the production support documentation

After these steps, everything should be writing down in cards and then they must be prioritized and treated as deliverables for the project. As we are talking about Agile, all these deliverables will be splitted into iterations and, working together with the best practices of Agile methodologies, will ensure the quality of the product and the client satisfaction.

Kanban Resources

2012-01-08T13:34:00.000-08:00

Follow bellow some resources to get start with Kanban. Enjoy!

Books:

1. Kanban: Successful Evolutionary Change for your Technology Business

2. Custom Kanban: Designing the System to Meet Needs of Your Environment

2. http://www.kanban101.com/what-is-kanban/

3. http://www.methodsandtools.com/archive/archive.php?id=104

4. http://agile.dzone.com/news/defining-kanban

Kanban - An Overview

2012-01-08T10:34:00.000-08:00

What is not Kanban?

A project management method (like Scrum)
A process (not necessarily)
Iterative

So, what the hell is Kanban?

Kanban (kahn-bahn) is a philosophy created by David Anderson for product development that has been applied for software development for about nine years. It isn’t restricted to the approach to the Lean Concept of Toyota Production System, though it follows its directives, like the continuous flow and also the improvement, through a culture called Kaizen.

Its goal is to help the team to make an efficient delivery of value over the project, through some purposes:

makes the supply chain process visible to everybody,
limit the work in progress (WIP)
help work to flow

The practice of limit the work in progress makes the process different from the cascade model, where lots of work is done and no value is delivered. This is a good way to identify bottlenecks and improvements points, as well as to avoid the buildup of tasks in some point of the process.

The main idea of Kanban is to not think about time boxed iterations, but to have a continuous process. It values the team collaboration and support them to have focus and a sustainable pace.

The definition of Kanban in Japanese is related to billboard, wall – stuff that, through a mapping on the supply chain, makes those visible to everyone.

Some stories are selected on the backlog to be sticked on the first column of the production line shown on kanban using post-its, for example. This production line is defined by the team members, who are responsible for the many steps of the project, like development, quality assurance, infrastructure and so on. The first step located on the left of the kanban shows the stories to be built, and the first one located on the right of the kanban shows the stories that was done. During the course of the project, these stories will move over the wall, from the left to the right, and more stories to built will being sticked, but always respecting the WIP limit.

Kanban doesn’t prescribe roles, there’s no a specific role to perform a determined task. Then, it’s less prescriptive than the software development methods, like Scrum.

For an organization that is getting started with Agile, the use of Kanban should be a great way to start – it is easy to install, softer, can be used in conjunction to any software development lifecycle, like Scrum, XP and Waterfall, and is less invasive than Scrum, for example, which causes a strong impact on the organization – changes the hierarchy and the roles. For this reason, Kanban should have more chances to be accepted because it can be it can be adopted gradually, and also helps the team to see the process like a queue and not like a network.

The project that I’m working, the team prefers to use RUP with the Waterfall model. By studying Agile, I’ve tried to convince them to use this set of practices, but they were still quite resistant to use it. Then I tried to start using Kanban, and it worked! After that, we started to use some of the practices of XP, and I hope I got some other advances over the time.

Scrum - An Overview

2012-01-02T10:50:00.000-08:00

In opposite what most people think, Scrum is not a process. It’s a framework for Agile Project Management.

Scrum splits the organization into small, self-organized and cross-functional teams, and the work into small and concrete list of deliverables organized by priority and estimated effort for each task. This framework organizes the time of the project, by sorting the work into iterations. For each iteration, the goal is to deliver a functional code to the customer, get his feedback and then update the release plan and its priorities, and consequently, make the process optimized.

There are two figures that support Agile Development Teams – The Scrum Master and the Product Owner. The Scrum Master is seemed like a coach who helps the team to reach the highest level by using the framework. The Product Owner acts like the customers/users, in order to help the team to develop the right product.

An Agile project starts with a list of features to be developed over the iterations, which are organized on the Product Backlog. Each iteration on Scrum is called Sprint, and it doesn’t have more than a month long to deliver the features (shippable features - coded and tested). Each Sprint starts with a Sprint Planning Meeting in which the Product Owner prioritizes some features of the Product Backlog for another “to-do” list for that Sprint, called Sprint Backlog.

A DailyScrum Meeting is made day by day over the sprint and requires the attendance of all the team members. And then a Sprint Review is done by the end of each Sprint to show to the customers, stakeholders and other interested people on the project what functionalities were made and also to get some feedback that will be helpful for the next Sprint.

Another Scrum’s artifact is the Burndown Chart, which provides a better overall view of the project’s progress, showing it in the form of story points completed, as well as changes to the number of story points planned for the remainder of the release. It’s a great way to show to the customer when the work is on date or late, and help the team to plan the next Sprints in case the team would not be able to build the planned features within an iteration. These charts should be big and posted in visible areas where everyone can see them. You can see below a sample of a Burndown Chart.

There are some Burndown Charts Templates to help the organization start to use this artifact.

There's another artifact widely used, called Burnup Chart - it's more complete than Burndown chart, because it shows two measures that a Burndown Chart doesn't: how much work has already accomplished on the project and how much work is remaining. Some people say that the first one is easier to understand, and should be better to use it to get start, however, the Burnup Chart is better to track velocity, find trends through the past iterations, as well as predict the completion date of the activities of an iteration.

Then, although Burnup Chart are more complicated than Burndown Chart, it shows essential information that is kept hide on the last one, and avoid the team to discover late a possible delay.

So, instead of a large group, spending a long time building a big thing, Scrum helps the organization to have a small team spending a short time building a small thing, but integrating regularly to see the whole.

XP Resources

2012-01-02T08:09:00.000-08:00

Follow below some great resources to get start with XP. Enjoy!

Books

1. Extreme Programming Explained: Embrace Change

2. Planning Extreme Programming

3. Extreme Programming Pocket Guide

Related Sites

1. http://www.extremeprogramming.org/

2. http://en.wikipedia.org/wiki/Extreme_programming

3. http://xprogramming.com/book/whatisxp/

4. http://c2.com/cgi/wiki?ExtremeProgrammingCorePractices

5.http://www.slideshare.net/aniruddha.chakrabarti/agile-practices-extreme-programming

6. http://www.informit.com/articles/article.aspx?p=30187

Scrum Resources

2012-01-02T07:44:00.000-08:00

Follow bellow some great resources about Scrum. Enjoy!

Books

1. Agile Project Management With Scrum

2.Agile Software Development With Scrum

Related Sites

1. ScrumReading List

2. From Scrum to Kanban

3. http://www.scrumalliance.org/

4. http://www.mountaingoatsoftware.com/topics/scrum

5. http://en.wikipedia.org/wiki/Scrum_(development)

6. http://www.mountaingoatsoftware.com/scrum/alt-releaseburndown

7. http://blog.acunote.com/2009/09/new-features-improved-burndown-charts.html
8. http://guidewiredevelopment.wordpress.com/2009/01/29/burn-up-and-burn-down-charts/

9. http://www.nearinfinity.com/blogs/lee_richardson/forget_burndown_use_burnup_charts.html

XP - EXtreme Programming - An Overview

2011-12-31T13:06:00.000-08:00

XP is one of Agile processes, which consists of a set of roles, strong principles and values that was born at the final of 90’s on USA.

Extreme Programming is based on simple rules, and they look like a jigsaw puzzle, on what nothing has a complete sense by itself, but when the pieces are combined together it can make sense.

One of the main purposes of XP is the customer satisfaction, and it’s possible through on of its practices – on-site customer. It results in a constant and fast response to changes, even late on the life cycle of the project.

Additionally, XP teams are collaborative and self-organized – managers, developers and customers work together in an equal partnership in a simple, but effective environment. The improvement during a life cycle of a project is made by five essential values – simplicity, courage, respect, feedback and communication.

“Extreme Programmers constantly communicate with their customers and fellow programmers. They keep their design simple and clean. They get feedback by testing their software starting on day one. They deliver the system to the customers as early as possible and implement changes as suggested. Every small success deepens their respect for the unique contributions of each and every team member. With this foundation Extreme Programmers are able to courageously respond to changing requirements and technology.” - Extracted from http://www.extremeprogramming.org

XP doesn’t establish fixed roles for the members on the team, because the main purpose is to achieve the success through the skills each one have to offer. Fixed roles could interfere on the goal of that each one have to do its best. Although they don’t have a fixed role, I’m gonna write bellow a brief of the responsibilities of some of the members of a XP team.

Project Managers

Project managers are the bridge between the team and the customer. They ensure the communication inside and outside the team – so they act like a facilitator on the communication of the project, and ensure the customer attendance on the planning meeting, as well as a prompt communication.

They also monitor the team progress, and also motivate them by seeing the quality of the product they are developing. For this, project managers must do an external pressure and communicate what is happening for all the engaged members on the project.

Product Managers

Product managers define stories which help the product to be coherent and harmonic, as well as define priorities and make some clarification all over the project and reduce the scope when the team is late for some reason.

Users

Help the team to write the stories and to make decisions about the project domain. They are important because they have the domain of the business, and should contribute with the project with the experience acquired on the last projects. In XP projects the customer is involved all over the time, giving feedback in order to ensure the correct implementation of the functionalities that could generate values for the organization.

In XP projects, the customer satisfaction and his feedback is more important than lots of pages of documentation and all the bureaucracy. The customer is present on the project since its start until the end, working together the team, giving feedback and defining the requirements not all at once at the beginning, but for each iteration, ensuring the possibility to changes on the project even late.

Agile, in a brief

2011-12-29T08:29:00.000-08:00

Agile is a set of best practices which are used on software development in order to improve the quality of it. Among these practices, we could mention eXtremeProgramming (XP), Kanban, Scrum etc.

We can use these practices together, or even combine just some of its directives. Agile methodology has a flexibility that it’s hard to find in another techniques, like Rational Unified Process (RUP), for example - while XP doesn't need all of the RUP artifacts.

The foundation of Agile came from the Agile Manifesto – a meeting where some software developers experts, like Martin Fowler and Kent Beck wrote a document defining approaches for agile software development. Based on it, were established the twelve principles behind Agile Software.

Agile, in a brief, values the simplicity, the quality of the software, small and continuous releases, as well as the customer working together release by release, to ensure the “this is what I really wanted” in the final of the project.

I'm gonna give a specific focus for these practices in another posts, as well as establish a comparison between them.

Agile Resources

2011-12-28T16:51:00.000-08:00

Follow bellow some resources that I’ve read to learn about Agile. This is a great way to get start! Enjoy!

Books

User Stories Applied for Agile Software Development

The Agile Samurai

Related Sites

1. Agile Software Development

2. Agile Manifesto

3. AgileJournal

4. IBMRational e-book: Agility@Scale

5. ModernAnalyst.com

6. Agile Software Development - A Gentle Introduction

A report about what had changed since the use of Agile

2011-12-28T15:14:00.000-08:00

First of all, I’m gonna write about how the project I’m working was conducted until I've started to learn and use some agile practices, and what had changed since then.

The purpose of the project I'm working on is to develop a framework to spread forecast data through Web Services, in a easy way to provide answers for the frequent asked questions made by the people interested (TV channels, universities etc.). My project started on January 2010, as usual, with lots of work. In the beginning we had to set all the development environment, like the application server, IDE, DBMS to be used and so on. None of our tasks were organized, prioritized as they should be. We had lots of work, but not an established deadline, defined responsibilities or some point that gives us a right way to follow, a sequence to do the tasks. Additionally, the code we wrote was full of bugs (mainly because the design and lack of tests TDD) had lots of bugs and the classes had lots of useless methods. I had just a little experience with software development that time, and a basic knowledge with programming; that’s the reason why I didn’t get start since then to use good practices to make my project better.

I have worked with some senior developers which give more value to the quantity of work than the quality of it…So, in these situations, the product is a code non tested with lots of defects (until now it’s been hard to make their minds to use a test suite in order to reduce the bugs and improve the quality), non established goals (like a unknown amount of work for a long term) and a non continuous integration environment (which results in troubles and unnecessary work on the time to deploy).

By using some of the agile best practices, like making a list of deliverables, setting deadlines, priorities, working in pair and using the WIP (Work in Progress) limit (from Kanban template for software development), we had some improvements that make our work more organized and productive, besides it has helped us to have more focus in our activities.

My goals for the next year are to set up the continuous integration environment and our test suite to do some user acceptance tests (UAT), now to improve the quality of our final product.

Just to get started

2011-12-28T11:53:00.000-08:00

I confess I’m a little bit afraid in starting to write a blog to talk about an subject I’m studying and discovering day by day, but I found this way to share the knowledge that I missed when I didn’t know anything about Agile. Because I’m not an expert, my intention here is to introduce some basic topics and concepts, for a better understanding and a first light to get use Agile, and also show you the difference using the traditional software development and agile software development, through practical examples.