Chapter One
Keeping It Simple
"Keep It Simple" is really a synonym for "Get a Grip."
If you are reading this book, you probably have some degree of responsibility in getting a website application up and running. If you are reading this chapter and you are searching for a series of steps you can actually assimilate and follow toward fulfilling that goal, then you are in the right place.
First of all, in a software project (and because of its complexity, that is what a website application is), you are either controlled by circumstances or you succeed - but only if you can maintain your grip on things. That''s only if, after receiving all the advice, you are able to fashion your own means of zooming into detail, return to the overview, keep it going, and know at all times where your bookmarks are ... and if you can pilot the process of each layer making up the project, on every front: the purpose, the design, the usability, the navigation, the function, the data, the push and pull and flow of actions and results, the emission and reception of messages, the completion of tasks, the updating, the classification, and relation of content.
Which is to say, if you keep it simple and keep it all in view, or at least know where to look for it, then you can marshal your own approach to truly leveraging a powerful, open-ranging, and dynamically productive framework such as Drupal, the "Community Plumbing" Content Management System framework middleware powerhouse, featuring:
Significant off-the-shelf functionality
Tremendous extensibility through nearly 3,500 contributed modules
Based on one of the most active Open Source communities in existence
Drupal is all of these things.
Add to the mix that Drupal itself is evolving at a fairly brisk pace, as you''ll see in later chapters, and you definitely need to come to Drupal with your own approach.
Because you are using Drupal for world domination (a favorite geek metaphor among Drupaleros), then you had better have a program. And you had better make sure that everyone involved gets on that program and stays there.
Getting with the "Program"
The "program" means that you must start out with a clear idea of how your client defends her interests with the website application in the works. In the program, keeping it simple does not mean splitting it apart and losing the richness of vision, nor does it mean oversimplifying.
This chapter lays out a method that you follow throughout the rest of the book. Then, you can either adopt it lock-stock-and-barrel or roll your own. But we definitely recommend following some kind of Agile approach and have developed a lean, mean methodology checklist. We find that this means, at a bare minimum, maintaining a policy for:
Vision and Scope - The business vision and scope
Visitors and Users - Who''s going to use the website?
User Stories - Narratives telling us what the users are going to use the website for
Analysis and Design - What needs to be done so they can do that?
Planning and Risk Management - When should you do that?
Design and Usability - What should it look like?
Tracking and Testing - Making sure you''re getting what you really want
Technology Transfer and Deployment - Turning over the helm to those who will be managing the website application each and every day
Figure 1-1 shows a basic main process workflow for this book''s example project. The workflow is strongly influenced by Mike Cohn''s book User Stories Applied (http://amazon.com/ User-Stories-AppliedDevelopment-Addison-Wesley/dp/0321205685).
The Perl programming language, in common with Drupal, has been one of the major Open Source success stories of all time, answering a burning need in an intelligent and synthetic way, backed by an extremely active community led by very smart people. And, like Drupal, given a problem, it provides an enormous number of alternatives offering themselves as solutions. "There''s more than one way to do it" has always been their slogan, and the same holds true with Drupal: there is always more than one way to do it. So, of course, you can substitute your own process workflow and find your own solutions along the way. The important thing is to recognize that the development of a website application is a complex process. To get it done right and to leverage a powerful, dynamic, and productivity-enhancing framework like Drupal, you need to develop your own independent approach and method as you gain experience yourself. The method you''ll use throughout this book is a "starter set" you will adapt and tailor to your own needs, as you develop the Literary Workshop community website.
In a nutshell, the main process workflow makes the first task the identification of the customer and, by extension, the business vision and scope of the project as well as the complete list of stakeholders involved. Then comes the identification of the roles - the different kinds of users who will use the site. For each role, you write a series of user stories, identifying all the possible interactions the role will have with the website application. Doing it this way (asking who will use the site, and, for each of the roles, what they are going to do when they interact with it) guarantees that you can cover all the functionality required and come up with a complete list of user stories.
At this point, you have all your user stories, perhaps written on 3x5 cards and spread out on a table in front of you, or on a magnetic board, or taped up to the wall, or whatever. So you can do the planning. This involves making an initial estimate for each user story, taking advantage of the fact that each user story is a semi-autonomous chunk of functionality that can be dealt with independently. Then, you create a way of putting the estimates in context on the basis of the velocity of the team. (Is this our first time? Any extra-special technical areas of difficulty, like dealing with a text messaging gateway, or with specialized web services?)
Next, you are ready to prioritize the user stories. If they are indeed 3x5 cards, this means unshuffling the deck and putting them in order. The two most significant criteria for this should be: which ones does the client think are the most essential, and which ones need to be tackled first because they involve some kind of risk that needs to be mitigated at as early a stage as possible.
This process dovetails into the next important planning task, which is allocating the stories to iterations. You want to have several iterations, at least four to six for a medium site, even more for a large site, following the Agile principle of "frequent releases." One reason for this is so that the client, who should be considered part of the development team, can give really effective feedback in time for the architecture of the site not to be adversely affected by any "surprises" that may crop up: If implementation is straying far from the client expectations of what the website is supposed to actually do, you want to find out about that sooner rather than later. Another is so that work can be expressed as much as possible using the semantics of the solution domain, rather than the problem domain - which means that people can think much more clearly when something concrete is up and running, rather than being forced to work in the abstract.
So now, you have planned your iterations, and you have on the table (and hopefully on the wall), or else entered into your favorite issue tracking system, essentially four to six piles of no more than five user stories (more iterations and more user stories per iteration if it is a bigger website, also depending on estimated team velocity).
Basically, you want to grab the first pile (the first iteration) and implement it. Now, for each planned iteration, or phase (sometimes people group iterations in phases), you use the workflow shown in Figure 1-2.
To do this, you take each story and discuss it, the client takes a major responsibility for writing the acceptance test for it, and you list all the tasks that need to be carried out in order to actually implement the functionality involved in the user story. The acceptance test is basically a semi-formal to formal statement of precise criteria according to which the work has actually been done right.
According to the Extreme Programming website (http://extremeprogramming.org - a great starting point to finding out more about a lot of the methodology we are talking about and using in this book, as is Kent Beck''s ground-breaking work on the subject, Extreme Programming Explained: Embrace Change; http://amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/ 0201616416):
Acceptance tests are black box system tests. Each acceptance test represents some expected result from the system. Customers are responsible for verifying the correctness of the acceptance tests and reviewing test scores to decide which failed tests are of highest priority. Acceptance tests are also used as regression tests prior to a production release.
Essentially "getting your site done right" means that all the acceptance tests pass for all user stories. You''ll be learning about acceptance tests and other forms of testing, like unit testing, below in the book.
In any case, it should be clear that the acceptance tests must be written before any work is actually done. Once written, and all the tasks necessary to implement a given user story are listed, each task can be taken up by a pair (hopefully) of developers. (It''s much more productive for two people to work together on a task, but we won''t get involved in any religious wars here; also, you might be working by yourself, so just be prepared to put on a lot of hats!) The developers will take the task, make an estimate, carry it out, and immediately integrate their work into the development test site. Later, the client will run the acceptance tests for the user story, and if they pass, the work just got done! Otherwise, an issue is raised in whatever issue tracking system you are using (more on this later), and the work is recycled, until the acceptance tests all pass.
Let''s get our lean-and-mean methodology checklist straight now, starting with the task of mapping the business vision and scope.
Starting with a Map for Business Vision and Scope
Experience at succeeding has shown that to achieve the benefits of the "KISS" approach, you actually have to dig down deep to the roots of what is an organic, dynamic process. It is not a question of oversimplification for the sake of simplification.
To succeed, you need to stand "commonsense" on its pointy head, at least for a while, and acquire a deep vision: It is not only that those who lack a business plan will not enjoy financial success. While true, what you are concerned with here is that without first identifying the business plan, there is no way you can build a website application that meets your clients'' needs and fits right into their regular activity. Real needs cannot be translated into an analysis and design, analysis and design into implementation, implementation into a working model for testing, a working tested model into a deployed website application - the website application the client needs will never be born.
In traditional Information Technology terms, this is called a Business Model (see Wikipedia). The importance of business rules is present in the context of Agile Modeling, as well. Business Modeling is a difficult subject to master in its own right, but thankfully, you can cut to the chase here, and draw yourselves a Web 2.0 picture of the relationship between the business rules, the feature list, and the offerings of a website application: a meme map.
For more on Business Models, see Wikipedia at http://en.wikipedia.org/wiki/ Business_model. For more on Agile Modeling, see http://agilemodeling.com/artifacts/ businessRule.htm. For more on meme maps, see "Remaking the Peer-to-Peer Meme," by Tom O''Reilly, http://oreillynet.com/pub/a/495.
A meme map shows the deep relationship between the internal activities of a business or organization, their strategic positioning, on the one hand, and that business'' outward, public face, on the other, including the website applications and their functionality, which is what it is you actually have to develop. Everything is clear at a glance. This is just what you need to get started. Look at Figure 1-3 (which shows a meme map for a Drupal-based Literary Workshop website application) and the comments following it.
At the top, there are three bubbles containing the main public functionality of the website application.
In the middle, the core is shown as a rectangle housing the positioning strategy and guiding principles (which may well differ with someone attempting a similar kind of site, but which will have a big impact on what you will be doing anyway).
Below are the regular business activities housing and forming the material basis and personal interactions supporting the rest.
From this point on, "Keeping It Simple" is going to mean banishing anything that isn''t directly connected to your business vision, automatically and constantly getting rid of the fluff.
Going to the heart of the matter, and keeping that present, will enable you to get a grip right from the start.
There is a website where you can make your own meme maps (Do It Yourself Meme Map Generator, http://web.forret.com/tools/mememap.asp), so you can try it out yourself. Or you can use any diagram drawing tool. Or use pencil and paper (that will work!). In any case, I strongly recommend that you follow along in this book by actually developing your website application as I develop mine. Practice makes perfect.
Who''s Going to Use the Site?
This question really goes to the identification of the actual users of the website itself, and also the users of the website in a business sense.
Perhaps a sector of the back office, for example, will never actually use the site as such, but will be interested in receiving periodic statistics, say, as a weekly email. They must be included, of course, in the list of roles. Here''s a list of roles for the Literary Workshop website application:
Role Description
Workshop Leader The person who actually runs the workshop, decides who to accept, monitors whether members are complying with requirements, and also participates along with the other members
Workshop Member Someone who has joined the workshop and actively participates in it
Publisher Someone publishing a magazine, on and off the site
Webmaster Technical administrator of the website
The main thing is that every possible user of your website application needs to be taken into consideration in order to truly capture the complete set of requirements that need to be met in the implementation of the project. At the same time, a complete list of all interactions with the site (their user stories) for each of these users completes the picture.
What Are They Going to Use It For?
Let''s make a list of user stories, then, for each of the Roles we have previously identified.
What Needs to Be Done So They Can Do That?
You will be taking each user story and doing some analysis and design aimed at discerning what can be reused from the giant Drupal storehouse of core and contributed functionality, and what needs to be added on - perhaps contributing back to the community in the process (you''ll learn why this is a great idea later on in the book).
(Continues...)
Excerpted from Leveraging Drupalby Victor Kane Copyright © 2009 by Victor Kane. Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
