In my book Leveraging Drupal I set out to wed what have always been my career basing best software development process practices with Drupal site building and development. Chapter 1 (possibly the only part of the book not immediately obsolete the moment it was published in February, 2009), entitled “Keeping it Simple”, describes the process you can practice in order to squarely face the varied responsibilities of getting a web app up and running. It names the steps you can follow towards fulfilling that goal. It is still freely downloadable as an example chapter. We will use it to gear ourselves towards implementing a properly prioritized backlog of stories in order to revamp AWebFactory.com .
Now, we could just say, as is increasingly the fashion, “we use scrum”, or “we use agile” and even provide the obligatory life-cycle diagrams. But how do we actually get to that? In what context are we even operating? The only fair starting point for any target app is: Why build it at all?
The Meme Map
This first step is often called “business modeling” and “positioning”. At AWebFactory we believe it actually has more to do with answering people’s real needs in a sustainable fashion in the midst of the current world crisis, in this real world where we all live and work. And this affects how we, yes, do business, and especially how we code. So the first question we need to answer in order to build our target app, AWebFactory.com (and the first questions you need to answer in building yours) is “What right do we even have to build it?” In other words, What makes it unique? What is it about? What’s it for? Who needs it?
If we can answer these questions as a first step in our building process, then we will be free to go on to develop a vision of the scope and feasibility, determine the roles and stories, the backlog, get it done, test it and get it out there (what Sam Boyer calls “done done” DevOps style). If we can answer these questions then we can have a chance of doing that without failing.
So let’s say it again: What makes it unique? What is it about? What’s it for? Who needs it? So how can we do this? Because if you come to AWebFactory and you say to us “We want a clone of site such-and-such” we can only answer “site such-and-such is already out there; what is it you want and need, exactly?” Otherwise we #fail.
What we use to answer these questions is the Meme Map.
At the core in the orange box are the guiding principles. Bubbling up from the list of guiding principles are the public manifestations, the available functionality putting them into practice. And the big orange box of principles sits upon the foundation of the production processes and the context of social relations forming the material groundwork upon which the principles may support the proposed functionality.
The meme map shows how we answer those hard questions. I was about to execute mine using my regular drawing program, when I realized almost by accident that you can do a great job with much greater ease if you use a mind mapping tool for the purpose. In the above MemeMap diagram for AWebFactory now, I used FreeMind.
Roles and Stories
It works out very well, you can visualize the roles alone, and click to open up the user stories associated with each one, and you can have sub-user stories which may be reusable includes, extensions or sub-routines, or just plain detailing.
In my experience this step is essential and can easily spell the difference between success and failure.
Backlog Creation and Prioritization
Although we try not to get locked into tools, we are currently using Pivotal Tracker for backlog creation, prioritization, tracking and for all things related to project communications (outside of assets and major documents stored in Dropbox or Google Drive (we are attempting to overcome the limitation of the permissions and access matrix being tied to a particular Google account)). Pivotal Tracker is one of those tools you bump into on so many projects and which just becomes the natural thing to be using, at first unnecessary to replace, then finally ubiquitous. It’s only then you realize how well it performs its function, even though the main thing is to use any tool you feel comfortable with that gets the job done.
With Pivotal Tracker, you don’t have to artificially create the sprints. You just specify the length of the sprint, and the backlog becomes organized on the basis of which stories are actually started (current sprint), and the backlog automatically gets assigned to future sprints on the basis of the number of points assigned to them and real, monitored team velocity. And you can bring any story into the current sprint just by starting it. Here is a screenshot of the initial sprint (we will be publishing an article with each sprint).
Scope and Candidate architecture
The scope of the project is what actually has to be built, as opposed to what is merely interfaced. If you are integrating with an existing chat program running on an existing server, the interface to the chat program has to be built, so it’s in scope. The chat program doesn’t, it’s out of scope. The scope is best expressed at a glance using UML use case modeling:
Notice the succinctness of vocabulary (there’s something about a use case diagram that makes for that: going to go to Pivotal Tracker and put these semantics in) and the relationship between functional specifications and business objects (some of them related to multiple use cases, others more specific), plus the definition of the application boundary (with some components being inside while others are interfaces to external components).
The candidate architecture (a work in progress during the first sprint but probably already a pretty firmed up list by the end of the second and in the light of its deliverables; impossible to discern without doing at least discovery sprints, so Dear Client, please don’t ask us for recipes for disaster) boils down to what kind of platform the target app will run on, and the target app’s main software components, including to which “tiers” they belong.
Even though this really isn’t going to be known for sure until the analysis and design is completed during the course of each story’s actual implementation, the Architect does need to extrapolate, and in the second sprint confirm, a candidate architecture. She must come up with this scientific hypothesis on the basis of the stories chosen for the first sprint, and also on the basis of the stories presenting the most risk (new methodology, paucity of talent in that area and/or of giant’s shoulders). The candidate architecture itself is represented by a domain model made up of the principle objects (analysis, usually built on use case realization diagrams composed of entities (main business objects), boundaries (interface elements the user interacts with during the story) and controllers (business logic)) capable of implementing the project.
In the case of AWebFactory.com this means:
Will Drupal continue to be the CMS framework?
What classes and Drupal entities (content types, fields and field groups associated with the user and other entity bundles) will likely be involved?
Which core and third party modules will be leveraged as they map to analysis and design objects and classes? Which custom modules will have to be built?
What integration to external components has to be built (payments, project tracking…?)
Which database will be used for persistence? Any others?
Which search architecture will be used (Drupal’s standard, Apache Solr, Google?)
What theming architecture will be used (Responsive panel layouts that come with Panopoly…)
What platform will it run on (Pantheon at last!)
And so on and so forth
So the domain diagram will emerge as the user stories implemented in turn, and will allow us to refine things on a higher level as we progress to the Candidate Architecture we will be working from after about the second sprint.
User experience and wireframes
So let’s eat our own dogfood and make a mobile first wireframe, starting out with keeping it simple, and mapping out to appropriate usability for the larger breakpoints as the sprints go on. So on the basis of the scope and candidate architecture, we have wireframes for the home page, for the services section and individual services, for the work section and portfolio, for the blog section and individual articles, and for the contact page and various forms of contact.
These wireframes will live and breathe throughout the process. They may be a kind of starting point, and then you realize you can’t go on until the scope and candidate architecture is fleshed out a bit more, then you come back to the wireframes, while specifying the different roles that will be interacting with the site, and the stories as ways they will interact, and then come back with more ammunition to embody things in the wireframes a bit more, and so on.
The starting point stands on a couple initial balsamiq wireframe I did based on frabulous input from Bay Area Web Designer Wini Hung (a.k.a. Skinni Wini, evangilist of the power of cute) (who is working on AWebFactory branding and graphic design in general: see nice logo?)
As usual, Auntie Celie and the kids from the neighborhood elementary school will be doing the usability testing.
Now we can say “we use scrum”: in successive articles, and upon this foundation, we will implement the backlog.