Post by Chris MattsAn interesting thread. I wanted to add a couple of points.
1. There is no such thing as an Agile tool. Its how you use it that
counts. I have even used a Gantt Chart in the past on Microsoft
Project. I used a Gantt chart to build a map of the dependencies so
that I could systemetically remove them. Using a Gantt chart for
planning would probably not be that Agile though.
Yes, I know, when I say tool I d0n't mean only a software tool
Post by Chris Matts2. I use UML (like) models within Agile projects. The key is that I
use them to create model to help me find questions and examples. I do
not use them to communicate requirements to the development teams
because they are a lousy way of communicating. They have detail but no
precision in the communication space. They are great for structuring
your thoughts to help you find missing examples. UML (Language) should
be UMT (Tool) as the models are tool and not a way to communicate
effectively.
I and my teams use "sketches", they may be UML-like or no standard every
time they can help us but say that they are UML diagrams is too much.
Post by Chris Matts3. The G-W-T format was created with the express purpose of allowing
non developers to communicate with developers in a way that did not
require the developers to "re-think" the problem. G-W-T is a natural
language expression of TDD with Mocks. I have seen people use
Cucumber/specFlow in a non Agile manner. The two ways I've seen G-W-T
1. A huge pile of examples is developed before development starts.
2. Its an IT only thing with no engagement with the projects
customer. ( This resulted in truly bizarre G-W-T examples )
Yes, sure I know how they born. But they born in an agile context that
is a new way to express a business language to write requirements in a
BDD fashion by Dan North.
I think G-W-T is a very good way, so good that I would like to be able
to drive acceptance tests more directly using them (I know there are a
lot of engineers here thinking that it is not correct but in my embedded
applications I tested this approach and I think it has many advantages)
juste refining their initial content (that shouldn't change if the
requirement doesn't change).
I just collected some stupid problems and sometimes I need to write
similar scenarios too much times so I would like to find a way to solve
these little problems in an elegant way. For these reasons I really
think that some sort of diagram and a dictionary (to use a reduced set
of terms to identify users/actors/devices) or a simple structured table
could help when you have projects with hundreds of features and
scenarios. I don't know how should be done the diagram, I need more time
to think about it or any other solution with an other system, so every
suggestion is very welcome.
But I am still convinced that the development should be very agile so
everything shouldn't require too much effort to be useful and should be
also very very simple, especially the test source code (the part used to
unit test and to acceptance test the final application).
Post by Chris MattsJust saying, you know.
Chris
On Thu, Feb 21, 2013 at 8:05 PM, Massimo Manca
Post by George DinwiddieHi, Massimo,
Post by Massimo MancaPost by Taras KalapunI generate Use Case diagram from names of scenarios in feature.
And I generate Activity diagram for each scenario.
I might later generate state or sequence diagrams from scenarios,
we'll see that.
I just started the work on this.
And about thousands of Gherkin features... In my case, they are
quite high level, and they are around 10-15 for SRS
I really don't understand the usefulness of this approach.
UML has its requirement gathering model, if you like UML you should use it.
UML is not agile at all and not well suited to be used in an agile
context as is BDD. They are alternatives.
UML started as a set of modeling diagrams, and only later tried to
become a means of generating software.
Many people still find value in the communication power of the
diagrams, even if they're not following the UML methodology.
As I said, in an agile context they have a value as sketches and if they
don't need all the details. In this context an engineer using properly
UML diagrams should say that they are missing valuable informations.
And technically there are many diagrams standard and non standard that
may help you to better understand sw behavior and organization without
being heavy as UML diagrams.
The problem is in the general vision: the agile vision, especially for
BDD, is more customer oriented then any other methodology. So who would
follow BDD should think to implement the application from the point of
view of the customer. UML diagrams aren't customer oriented, they are
surely engineer oriented so they should be used only internally to the team.
The second point is that UML diagrams are too much detailed so
personally when could be useful only for team internal communication I
sketch something that could be defined a simplified Activity Diagram or
State Diagram (also id I don't like its "syntax") and so on.
Post by George DinwiddieAnd, sometimes, it's helpful to explain something new in older terms
so that others can understand it.
Yes, this is generally true.
Post by George DinwiddieThe biography of Michael Faraday by L. Pearce Williams described how
Faraday's discoveries were accepted more readily because he
published
Post by George Dinwiddiethem using the prevalent model of the atom, even though he used a
different model to know where to look for these discoveries.
Post by Massimo MancaOf course a UML diagram may be sketched to visually document
the result
Post by George DinwiddiePost by Massimo Mancaof a design also using agile techniques but it mustn't be used
to drive
Post by George DinwiddiePost by Massimo Mancathe design. So multi path activity diagrams, state diagrams and
class
Post by George DinwiddiePost by Massimo Mancadiagrams are used quite frequently also by agile teams.
In my opinion UML is most devoted to design the application
architecture, BDD (also using Gherkin for requirements
gathering) is
Post by George DinwiddiePost by Massimo Mancamore oriented to directly "translate" requirements in executable
requirements driving the development of the application source code
bypassing the architecture design step. In this way it is
difficult to
Post by George DinwiddiePost by Massimo Mancasay when the architecture will be designed, most of the times the
complete architecture emerges day by day. In this way
developers have to
Post by George DinwiddiePost by Massimo Mancadesign little parts of the source code without thinking so much
to the
Post by George DinwiddiePost by Massimo Mancacomplete software architecture from the beginning, it is a
refinement
Post by George DinwiddieWhat I don't understand, though, is why you are arguing about
someone's use of UML on the Cucumber list. Isn't enough that Taras
finds it useful in a particular context?
Yes, for him it is ok, I am interested to understand why he is designing
a tool that to me seems going backward then forward.
Personally I think that we should need to understand better the goals in
terms of sw development in the BDD context.
1. to be able to translate Gherkin features and scenarios to executable
requirements that should describe behavior at a very high level (at
initial stage of development) or at a lower level to be able to drive
more directly the acceptance test steps.
2. A way to specify "semantically" better a hierarchy of
feature/scenarios to don't repeat every time the same steps
3. A way to collect/count every scenario involving the same actor
4. A way to discover if similar actors are the same (some sort of
dictionary)
5. A diagram to show visually interactions, dependencies and relations
between features and scenarios and order of execution of particular
scenarios.
N.B. I used UML driven development for some years but I really don't
think it is a good way to design an application.
--
-- Rules --
1) Please prefix the subject with [Ruby], [JVM] or [JS].
2) Please use interleaved answers
http://en.wikipedia.org/wiki/Posting_style#Interleaved_style
3) If you have a question, don't reply to an existing message.
Start a new topic instead.
You received this message because you are subscribed to the Google
Groups Cukes group. To post to this group, send email to
unsubscribe from this group, send email to
visit this group at https://groups.google.com/d/forum/cukes?hl=en
---
You received this message because you are subscribed to the Google
Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it,
For more options, visit https://groups.google.com/groups/opt_out.
--
Regards
Chris Matts
--
-- Rules --
1) Please prefix the subject with [Ruby], [JVM] or [JS].
2) Please use interleaved answers
http://en.wikipedia.org/wiki/Posting_style#Interleaved_style
3) If you have a question, don't reply to an existing message. Start a new topic instead.
You received this message because you are subscribed to the Google
Groups Cukes group. To post to this group, send email to
at https://groups.google.com/d/forum/cukes?hl=en
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send
For more options, visit https://groups.google.com/groups/opt_out.
--
-- Rules --
1) Please prefix the subject with [Ruby], [JVM] or [JS].
2) Please use interleaved answers http://en.wikipedia.org/wiki/Posting_style#Interleaved_style
3) If you have a question, don't reply to an existing message. Start a new topic instead.
You received this message because you are subscribed to the Google Groups Cukes group. To post to this group, send email to cukes-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org To unsubscribe from this group, send email to cukes+***@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/cukes?hl=en
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.