Agile methodology or practices interview questions and answers
Agile Development Interview Questions and Answers
| Agile Development methodology Q1 - Q6 | Agile Development methodology Q7 - Q16 | Agile methodology: theme, epic and user story | Pros and cons of agile development methodology and principles |
Q. What are some of the key features of agile development?
A.
- Collective code ownership and freedom to change.
- Incremental approach (e.g. user stories are incrementally implemented)
- Automation (e.g. TDD -- Test Driven Development).
- Customer focused (for e.g. internal and external users and business analysts are your immediate customers)
- Design must be simple. Designing is an ongoing activity with constant re-factoring to achieve the rules of code simplicity like no duplication, verified by automated tests, separation of responsibilities, and minimum number of classes, methods, and lines.
Q. How do you know that you are using agile development?
A. You are using an agile practice when
- You have daily stand-up meetings.
- You use CRC (Class Responsibilities and Collaborators) cards.
- You use timeboxed task boards.
- You use TDD (Test Driven Development), Continuous Integration, regular code reviews, pair programming, automated builds, continuous deployment and delivery, etc.
- You have iteration planning meetings and carry out iterative development.
Q. In agile practice, what does the daily stand up meetings entail
A. Each day, at same time and same place (in front of the task board) the team meets to bring everyone upto date. This meeting addresses SCRUM's three questions listed below
- What have you completed since the last meeting?
- What do you plan to complete by the next meeting?
- What is getting in your way?
Q. What is a task borad?
A. It is generally a white board divided into 3 sections -- To Do, In Progress, and Done. Each task is written on a sticky note, and moved from one section to another to reflect the current status of the tasks. The task board is frequently updated, especially during the daily stand up meetings. Different layouts can be used.
Each task allocated to each team member is timeboxed. You can have variation to the layout as shown below and each sticky not can have points that add up towards the velocity points (calculated by adding up the estimates of the features, user stories, requirements or backlog items that are successfully delivered in an iteration. ).
The task board is also known as the kanban board. Kanban is a Japanese word meaning card or sign. Each card or sign is equated with a user story. Whenever a particular user story is blocked for whatever reason, then the priority is to clear current work-in-process with the help of other team members to help those working on the activity that’s blocking the flow.
Q. What do you understand by the agile term timeboxed?
A. A timebox is a previously agreed period for a particular task to be completed by an individual or team. The key aspect of the timebox approach is that stopping of work when the time limit is reached and evaluating what was accomplished instead of allowing the work to continue until the goal is reached, and evaluating the time taken.
Q. What are CRC cards?
A. CRC stands for Class, Responsibilities, and Collaborators. It is used for rapidly sketching an Object Oriented design and playing out the roles and responsibilities to validate the design. The role play dialog will be something like
Hello, I am a trader and responsible for placing and cancelling buy and sell orders on behalf of my customers. Before placing a trade, I must know my trader details like number, name, address. I need to collaborate with order to fill in the relevant order details.
Q. What do you understand by the term "collective ownership"?
A. Collective ownership, as the name suggests, every team member is not only allowed to change other team member's code, but in fact has a responsibility to make changes to any code artifact as necessary. This means every developer will review code written by others when integrating others' changes from the code repository into their code to familiarize themselves and to identify any potential issues and mistakes. Every developer will be motivated to check in the code progressively and incrementally with proper automated unit and integration test cases as part of the continuous code integration.
Q. What do you understand by the term Behavior Driven Development (BDD)?
A. Behaviour-Driven Development (BDD) is an evolution in the thinking behind Test Driven Development (TDD -- Writing tests before writing code) and Acceptance Test Driven Development (ATDD -- write acceptnce tests, and for many agile teams, acceptance tests are the main form of functional specification and the formal expression of the business requirements). The BDD basically combines TDD and Domain Driven Design. It aims to provide common vocabulary that can be used between business and technology.
The acceptance tests are generally written using the "Given-When-Then" approach. For a given story/context, when some action is carried out, then a set of observable consequences should be obtained. For example, Given that you have enough available cash, when you place a trade within your available cash, then placing of your trades should succeed without any errors.
The acceptance tests are generally written using the "Given-When-Then" approach. For a given story/context, when some action is carried out, then a set of observable consequences should be obtained. For example, Given that you have enough available cash, when you place a trade within your available cash, then placing of your trades should succeed without any errors.
Q. What do you understand by the terms user stories, story mapping and story splitting?
A.
User stories: Dividing up of the customer's or product owner's requirements into "functional increments" so that it can be worked on via the task board. This is done in consultation with the customers, product owners, or business analysts.
Story mapping: When you have a backlog full of user stories, you can select a few of them to work on during the next iteration. This step involves ordering of the user stories. The "map" arranges user tasks along the horizontal axis in rough order of priority and the vertical axis addresses the implementation details. It can be done either on a white board with sticky notes or using tools like Silver Stories.
Story splitting: Before a story is ready to be scheduled for implementation, it needs to be small enough to pass the usual rule of thumb that "a story should be completed within the iteration". So, "story splitting" consists of breaking up one user story into smaller ones, while preserving the property that each user story separately has measurable business value.
Labels: Agile development
posted by Unknown at
10/04/2012 12:57:00 PM
8 Comments:
This isso usefull many thanks
Your posts are helpful and Interesting. You may elaborate a bit more on:
Sprint Planning,
Sub Tasking,
Burndown Charts,
Roles (Scrum Master, Product Owner, Team),
Story Points,
Retrospectives.
Difference between kanban and scrum?
There are many inaccuracies here. A sampling:
What you describe as TDD - "writing tests before code" - is TFD (Test First Development). Test DRIVEN Development goes further than this - not only are you writing tests first, but the test is driving the evolution of the API, so the interface of the Class Under Test is not known ahead of time, but actually emerges during development. Because tests are driving that emergence, the interface is well-aligned with actual usage requirements of the the CUT by a client.
CRC cards are not at all central to Agile development. They are a useful practice in OOD, and may be used by your team very well, but you won't find anyone anywhere claiming that their use is an essential feature of agile. (Well, this IS the internet, so you can probably find someone saying that, but they'd be wrong too.)
You seem also to have missed a huge number of really key points about Agile methodologies. Rather than trying to list them all here, and explain them, I'd suggest you simply delete this entry, or replace the content with a link to some well-known site where Agile methodology is more fully (and more accurately) explained. It's great that you try to cover all the bases here at this site, but in this case your readers are being misled by this post and should seek their Agile knowledge elsewhere.
Interesting and really helpful notes, but then again its hard to get everything right. I really appreciate these kind of aggregated short blogs instead for lengthy documentations (where I sometime end-up loosing time)
Hi,
Thanks for posting this. But, just wanted to make sure that we are explaining the Story Mapping correctly. So, the story mapping you mentioned above refers to the Story Mapping by Jeff Patton? Is that right?
If so, you said ->
"This step involves ordering of the user stories. The "map" arranges user tasks along the horizontal axis in rough order of priority and the vertical axis addresses the implementation details."
Actually, the story mapping is arranging the user tasks (not necessary user stories) on the horizontal axis in sequence of how the tasks were carried out by user. Jeff uses an every day example of how you get ready to come to work. So, you list all the tasks in SEQUENCE of what you did to come to work. So, the horizontal axis does not represent priority but the sequence (or ordering of user's actions - like Wash -> Eat Breakfast -> Transport (either drove, took a bus - basically how you got to the office) -> and do on. He also introduce the concept of "Activity" to group related tasks together. But, let me not divert into that. Instead, let's talk about ...Vertical Axis - it represents priority or other methods to split up an increment within a release or it can be its own release depending on the size of the product.
we usually do the story mapping with a product vision and a list of users for the product and then formulate user stories from the story mapping. but, i think you can do the opposite to get a big picture of how user stories are related to each other. It might need some work on how you represent the user stories in the story mapping. I suppose you start with one type of user and look at the what part of the user story and put them on stickies and then move them around. reminder -> horizontal represent time sequencing (like tell a tale from the beginning till the end ..._ and vertical represents priority representing an increment for a release of the top row is the first increment.
let me know if you have any question or any of the above was not clear.
Thanks for the clarification.
It's really good, it is very easy to understanding instead of reading books, Thanks a lot.
It was based on my experience working in agile projects. Often things are different in practice than in theory. Thanks for your detailed response.
Post a Comment
Subscribe to Post Comments [Atom]
<< Home