Why I still use use cases XP pretty much banned use cases, replacing them with the similar sounding “user stories” (see A user story is to a use case as a gazelle is to a gazebo (discussion: Re: A user story is to a use case as a gazelle is to a gazebo)}, and as a result agile zealots have been happy to dump use cases in the trash (along with their project managers, estimates, plans, and architectures). Scrum did similar, using the “product backlog” instead of user stories. Yet as I go around projects, I keep running across organizations suffering from three particular, real, painful, and expensive problems: User stories and backlog items don’t give the designers a context to work from – when is the user doing this, and what is the context of their operation, what is their larger goal at this moment? Use cases are, indeed, heavier and more difficult than either user stories or backlog items, but they bring value for that extra weight. In particular, use cases fix those three problems. Very expensive, very bad. s.
Java Behavior-Driven Development with JBehave This video explains how to do Behavior-Driven Development (BDD) with JBehave in a Java software development context. In BDD, Product Owners and team members focus on the problem domain and develop a common language for expressing a product’s desired behavior as stories and acceptance test criteria. Developers can then map the stories and criteria on their test code to verify application behavior. The video presents the concept of BDD and how to write user stories. It then discusses the differences between unit testing with JUnit and BDD. Video Producer: San Francisco Java User Group Video source and presentation slides Related Posts:
How To Implement Scrum in 10 Easy Steps When I first encountered agile development, I found it hard to understand. Okay, I might not be the brightest person you’ve ever met! But I’m not stupid either, I think :-) There’s a myriad of different approaches, principles, methods and terms, all of which are characterised as ‘Agile’. And from my perspective, all this ‘noise’ makes agile software development sound far harder, far more scientific, and far more confusing than it really needs to be. For this reason, I favour the Scrum agile methodology. Sure, it’s great to have a deep understanding of the underlying values and principles of agile development. Sure, it’s great to have a thorough understanding of why Scrum works. Sure, it’s great to know lots of case studies where Scrum has been applied and try to relate them to your own individual situation. But, fundamentally, I believe you can implement Scrum without all this knowledge. In these 10 posts, I outline specifically how to implement Scrum in 10 easy steps: Kelly.
Applying Use Cases in Agile: Use Case 2.0, Slicing and Laminating To incrementally develop and deliver products using agile software development, requirements are gathered and organized into a product backlog. A requirement technique that is used in agile software development is use cases. Some techniques to apply use cases for managing product requirements in agile are use case 2.0, slicing and laminating. Shobha Rangasamy Somasundaram and Amol Sharma wrote a blog post about can formal requirement methods work for agile in which they compare the usage of requirements between waterfall and agile software development: In traditional software development or waterfall process, the following methods are used during the requirements phase - brain storming, questionnaire, modeling, prototyping, observation, focus group, survey, reverse engineering, interview, document analysis, workshop for joint application development (JAD) - collaboration & domain model creation. Andy Hayward explored different requirement techniques in a series of blog post.
Is there a test case management solution which supports BDD? Hi Everyone, I have been digging all over the web for 2 weeks now and I have yet to find any information on this topic. I come from a more traditional model of software testing. Example: using a tool like HP Quality Center, we would import requirements, then write and link test cases to all requirements. These test cases would then be grouped into test suites then at the time of test execution we would create a test run then pull in X number of the test suites we wanted to run. Then of course each test would have a Pass or Fail, any detected bugs would be logged and the Fix-Build-Test process would loop multiple times time the product was ready to ship. From this perspective, to me BDD really breaks this whole traditional design. If all the "test" are now written in feature files and user story acceptance criteria, NOT inside a test management tool. Using the BDD process, I cannot get an understanding on how I can do this. We are a .Net shop so I want to use a tool like SpecFlow. Thank you,
promisedata - Data for reusable SE experiments What is PROMISE? PROMISE= PRedictOr Models In Software Engineering. Mantra= Software management decisions should be based on well-understood and well-supported predictive models. Collecting data from real world software engineering projects is problematic. Frequently asked questions: FAQ1: How to reference this data? T. FAQ2: How to view the data? Just read the on-line files. FAQ3: This repo reports "Sorry, truncated results. View the data via the simpler web-based Subversion interface. e.g. see FAQ4: How to read/write comments on the data? Go to the on-line wiki. FAQ5: How to report a bug with the data? Add an issue. FAQ6: How to contribute new data? Place it on-line somewhere then report new data. FAQ7: How to meet the PROMISE community? Come along to the annual conference on predictive models in SE 2012: co-located with ESEM'12
What Characteristics Make Good Agile Acceptance Criteria? | Segue Technologies - Custom Software Development, Professional Website Design, Information Technology Good Acceptance Criteria will help get your Agile project from “It Works as Coded” to “It Works as Intended.” Read on and see how. A User Story is a description of an objective a person should be able to achieve, or a feature that a person should be able to utilize, when using a software application. User Stories have been classically written in the following form: As an <actor phrase > I want <action phrase> so that <outcome phrase> For example: As an Administrator, I want to be able to create User Accounts so that I can grant users access to the system. A User Story cannot stand alone. What Are These Acceptance Criteria and What Makes a “Good” One? Microsoft Press defines Acceptance Criteria as “Conditions that a software product must satisfy to be accepted by a user, customer or other stakeholder.” These criteria define the boundaries and parameters of a User Story/feature and determine when a story is completed and working as expected. An Example
Step Away from the Tools This may seem odd coming from someone who spent months coding a BDD tool, but seriously… put it down. Step away. BDD has taken off in the last few years, and lots of people have approached me for help. Many of the questions I get are along these lines: These don’t seem worded quite right. What do you think? Don’t start with BDD, and definitely don’t start with the tools. Start by having conversations, engaging both testers and business stakeholders or their proxies (analysts are good here). BDD is focused on discovery. Dan wrote a blog post introducing Deliberate Discovery some time ago. Conversations help us discover things. You don’t have to stick to the BDD format to have those conversations. There are other things than scenarios which you can discover through conversations, though. The conversations often help to engender trust between stakeholders and the development team. Business stakeholders are just the same, only busier, and harder to get hold of. BDD isn’t about the tools.
Estimation is at the root of most software project failures | Rob Bowley I believe estimation, and the way it’s regularly misused, is at the root of the majority of software project failures. In this article I will try to explain why we’re so bad at it and also why, once you’ve fallen into the trap of trying to do anything but near future estimation, no amount of TDD, Continuous Delivery or *insert your latest favourite practice here* will help. The simple truth is we’ll never be very good at estimation, mostly for reasons outside of our control. However many prominent people in the Agile community still talk about estimation as if it’s a problem we can solve and whilst some of us are fortunate to work in organisations who appreciate the unpredictable nature of software development, most are not. I recently tweeted something which clearly resonated with a lot of people: It was in response to this article Mike Cohn posted proposing a technique for providing estimates for a full backlog of 300(!) Right? Wrong. 1. 2. Estimates are rarely ever just estimates