Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
my name is Nathan Lascaux this is my Twitter alias of my IRC tag please note it down because i forgot ibly at the end so yeah please get in touch and give me feedback after this is a presentation but it's all part of the discussion and I just hope to so
add my voice to to this interesting topic so I've been working with Drupal since early 2008 and this is my fourth drupalcon and I'm a seasoned drupalcon presenter I'm passionate about delivering quality applications that meet real business needs
so the last time i was in Prague was for my honeymoon in December 2006 and I fell in love with this beautiful city and I knew that I'd return one day but I didn't know that this would be the circumstance of my return and what Drupal hadn't arrived
yet in my life that came along and Drupal tooth out in in the year two thousand eight and eight and it was a former colleague of mine map fielding who suggested that we might use Drupal to meet the requirements of a project that had a quite a unique feature
set and that we never delivered before and the decision to use Drupal or any framework or CMS is often prompted by a need to deliver a bunch of features that we've not had to deliver before and it's not that when up it's not that we're not
willing to venture into the unknown we've all done that before I mean I've been doing web development for 14 years so you can be sure I've ventured into new ground whether for me at least you know so it's that we acknowledge that the fact that
someone has covered that ground before might actually benefit us and it might actually produce a higher quality of product so the code and features that we use in Drupal core should contrib a far more robust than the code or features that we could hope to
create alone and the fact that this code is tested in the community and essentially in production across many sites it's what it's part of the reason why we can get excited about the the Drupal project and it's what distinguishes it from some other
projects some of us may feel that we can't deliver much without Drupal but it can be done we use Drupal because it has a large and flexible flexible feature set and the way in which the code is distributed and maintained means that our sites features are
being tested fixed and improved to a greater extent that then our own used whether in development testing or production could ever yield testing is an important aspect of what makes Drupal a great platform to work with this is a strong selling point for our
clients they understand this and that's the reason why many of them are attracted to Drupal for the next period we have the opportunity to look at B hat and how it can help us to do to deliver quality in this room we have represented various levels of
experience I'd imagine with over a variety of areas of expertise but we all have something in common and it's Drupal that brings us to this conference today but I'm not going to focus so much upon Drupal because this is a tool that can apply whatever
platform you use but we have that commonality of all being involved in the development of web applications not only do we have many diverse disciplines represented here which should be the case in the DevOps track and I don't know about you but the first
time I come I come across the word DevOps it was it was almost like the first time i came across the word email i just had no no idea what i'm in and please explain it to me and and you kind of like look to point the finger and think is he that helps guy
is he the DevOps guy and then as you learn about it more it's it's rather than it being the role of an individual it's it's a principle that needs to be shared amongst all men members of the team we gather some requirements we develop some
designs and maybe we we build some interactive prototypes and then perhaps we begin development and these are of course loose definitions of far more involved processes but we it's not uncommon for us to sort of check over our work and make sure that it's
working at least how we expect and then when we believe that we've met we've reached the point that we've met our obligation to the client we then show the client and if the client likes what they see then we'll push it to live or we'll
go into the next phase of development each piece of this process might be handled by a distinct member of the team we all were all good at what we do in this room right so when things go wrong and invariably they do who do we blame for this failure maybe the
world the clients expectations they see the the site and they say it doesn't quite work as we anticipated so he's a fault did the client not explain their requirements well enough maybe they didn't even know what they wanted and the loose specifications
document that that was produced as a result was seen as a sort of vote of confidence in your team and they believed in your team so much that they knew that whatever you deliver would just be exactly what they needed and that might have happened for you this
rare phenomenon but the problem with proceeding with this loose specifications document is that it's a weak defense when the clients expectations have not been met for you to say well you didn't tell us you know you didn't explain it and we like
as a developer I would be dissatisfied if I was not involved in delivering applications that met a real business need you know it's not just about delivering something it's about delivering quality so no team effort not in a team effort rather no individual
sex success can compensate for the project failure either completely or in a stage of development just as in a football team there are different roles you know we might the defense might played a really good game the goalkeeper whatever but if the team loses
then then that sting of project failure is is going to you know it's going to be felt throughout no matter how well an individual played so let's set our roles aside for a second what is it that we in the application world do we deliver all of us you
know whatever would specific piece of work that we do we should all have our eye on the prize we should all have a route to success so what is it that we are delivering Theodore Levitt said people don't want a quarter-inch drill they want a quarter inch
hole as each member of the team understands what the real problem is and the real value in the application that were developing then we can begin to engender more quality in the work that we do by the way this is a principle that not only applies to software
development for entertaining any doll we must communicate amongst all stakeholders what the value is in the work that we are doing ultimately the complexity or the time intensity of the work that you've done will pale into insignificance when it the work
that you've done is considered to meet a real business need they of course they're going to pay you for that work but they don't care that it took a long time they don't care that it was really complex if it meets a real business need if you
want to make your client happy then meet that need you know yeah work hard that's part of it in order for us to ensure that we are solving the right problems we need to create a framework to offer assurances to all stakeholders that we are on the right
track this is a good time to talk about Dan north dan north created the first-ever behavior driven development framework or BDD framework and that was called J behave follow followed by a story level BDD framework for Ruby called our behave which was later
integrated into the aspect project and our spec was later replaced by the cucumber project which some of you may have heard of done naughts introducing BDD article appeared in the march two thousand and two thousand and six edition a better software magazine
the idea of behavior driven development evolved is done articulated his response to many of the concerns that he was being based with when encouraging development teams to approach their projects using test-driven development they would ask where do we begin
testing what do we test and what do we not test how much do we test in one go and what should we call our tests and how do we understand why a test fails i hope to cause some of these responses as we look at what be had camberley delivered to us as a BD BD
d framework but i recommend that you all read this article on appalling to in slides key to all of this is that we need to communicate more effectively in our teams what the acceptance criteria are for the work that lies ahead we need a common language one
sure way of not meeting the client's needs is for the development team to have their own way of describing things and they adopt a different language if we cannot make the effort to adequately articulate the expected behavior of our application then we
should not be in the business of developing quality enterprise standard applications we need a ubiquitous language that acts as a vehicle for our communication between different roles in the software project everything that we do should revolve around a business
[ ... ]
Nota: se han omitido las otras 4.532 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.