Lean Startup Conf 2012 / Home. UML 2 Sequence Diagrams. Sequence diagrams are typically used to model: Usage scenarios.
A usage scenario is a description of a potential way your system is used. The logic of a usage scenario may be part of a use case, perhaps an alternate course. It may also be one entire pass through a use case, such as the logic described by the basic course of action or a portion of the basic course of action, plus one or more alternate scenarios. The logic of a usage scenario may also be a pass through the logic contained in several use cases.
Let's start with three simple examples. Figure 1. The reason why they're called sequence diagrams should be obvious: the sequential nature of the logic is shown via the ordering of the messages (the horizontal arrows). Figure 2. The boxes across the top of the diagram represent classifiers or their instances, typically use cases, objects, classes, or actors. Figure 3. Figure 4 presents a complex UML sequence diagram for the basic course of action for the Enroll in Seminar use case. Preemptive commit comments « Arialdo Martini. Rule #1: write commit comments before codingRule #2: write what the software should be supposed to do, not what you did Dan North changed my life You should read his epic post Introducing BDD.
I don’t want to belittle his message when I say that Behavior Driven Development (which has been a real revolution in the IT industry) began with the simple attempt to replace the word “test” with the word “should“. After having being introduced to BDD (and the fantastic Clean Code‘s chapter about methods’ names) I started taking a lot of care of the words I was using in comments, commits, test names and classes/variables/methods’ names. Since I was used to write tests with names like When_foo_happens_Method_bar_should_do_this() I started thinking that I could use the same criteria for my commits’ comments as well. Tell me what the software does (not what you did) When I checkout a commit, I’m interested in what I will find.
I want an answer to the question What is the project behavior, in this snapshot? Top 100 Agile Books (Edition 2012. Agile software development. User Stories: Epics and Themes. Summary Epic- A large User Story, generally too big to fit into a single Sprint.Theme – A set of related User Stories.A story can be associated with one ore more themes.
Any story that belongs to more than 2 themes generally is overkill.You can use “Releases” as themes.The terms Epic and Theme are really only most useful during high level planning like road mapping and Release Planning. Which means they are generally most useful to the PO and stakeholders, and less useful to the Development Team. Exception: Using Releases as Themes is generally useful to the Development Team.It is sometimes easier for stakeholders to discuss and help prioritize stories at the Epic and Theme level.I walk through an example in the full article below.
Intro Epics and Themes are useful when communicating at high level road mapping and Release Planning. Epic Defined Epic – a User Story that is too big to fit into a sprint. Theme Defined. Defining the scope of an epic. Agile teams typically differentiate between “epics” and “user stories.”
In most cases epics are just really large stories that sit far down on your product backlog until the team is ready to flesh them out into more detail. The logical question is how to scope an epic and then break it up into user stories within agile. There are a host of activities that happen between a semi-defined need (i.e. an epic) and a list of defined requirements to be built (i.e. the user stories). The goal in creating an epic to scope out a feature or a project to get just enough clarity around the what and the why and dig into just enough of the how to create a common understanding of what will be achieved with a given set of work.