May 23 2012
May 23

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

AWebFactory MemeMap 20120521

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

Roles and User Stories for AWebFactory 20120521From the Meme map as input (together with anything else we can lay our hands on), we can extrapolate the roles and stories. I was so hepped up on FreeMind that I just used that again.

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.

Initial backlog for AWebFactory 20120521With 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:

AWebFactory scope 20120521

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).

This scope is what they call in CMMI the baseline. Not a bad idea even if you are using agile. CMMI and agile actually go great together.

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. AWebFactory early home 320 breakpoint mockupThey 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.

Process

Now we can say “we use scrum”: in successive articles, and upon this foundation, we will implement the backlog.

Bookmark/Search this post with

May 13 2012
May 13

This is the first of a series of articles which will log the revamping of the AWebFactory company website and its migration to Pantheon, the "Cloud Platform for Drupal", which will not only be host to live deployment, but which will also serve as a development platform.

Signing up

So I signed up for an account on Pantheon, a free developer account to begin with. I went to https://www.getpantheon.com/ and clicked on Create Free Account. Filled out the details, received a confirmation account (curiously, even with GMail, which is pretty discerning about those things, it arrived in the Spam folder, so do check that when you create your account), and after validating my site when I was logged in (https://dashboard.getpantheon.com/login ) there was a sign on my dashboard offering a link to Create a site now.

Uploading my ssh public key

Before doing anything, I uploaded my public key (clicking on Add key under Your Keys), required whether you use the git push and pull or On-Server Development and sftp editing method for managing your code.

I then created a Panopoly site, since I wanted to leverage the power of Panels, Panelizer and a host of other convenient apps (see Report back on a set of key DrupalCon Denver 2012 presentations for background, especially the sections on the What's new in the Panels Universe and Open Academy presentations).

Creating and commiting the barebones starting point based on a Drupal distribution

To create this site, I repeated the steps documented in Making your life simpler: Just do it on Pantheon! Once I had finished and had a basic Panopoly based site with the Stark theme, I refreshed the site dashboard and since On Server Development was enabled (automatically upon choosing the Panopoly distribution as the site building start state) all I had to do was type in a commit message for the 236 file changes which had resulted. I typed in “Initial commit after installing Panopoly distribution with the Stark theme created” and clicked Commit. In order to make a local continuing backup of my work, I clicked on Make backup. After being notified of the completion of the backup, I clicked on the Configuration tab and download the database, the files and the code, unpacked it all and created a git repo on one of my own servers which gave me a nice warm secure feeling. So after each important commit I decided I would do the same and mirror the commits on my own local server.

Setting up a suitable development environment using the Eclipse IDE

In order to set up a development environment that clicked with the On-Server Development, I set up Eclipse with Remote User Explorer as my IDE for the project. After readying my Eclipse IDE with remote explorer support, from the Site Dashboard for Development (Testing and Live not yet being used and in any case to be managed through deployment via the Pantheon dashboard) I triple-clicked on the textarea to the right of the Codebase title, and selected the sftp connection string, which looked something like the following:

sftp -oPort=2222 dev.{lots of numbers}@appserver.dev.{lots of numbers}.drush.in

Actually, clicking on the context sensitive help “?” to the right of the text area, the string is broken down into its component parts suitable for sticking into an sftp client (like Transport on the Mac, for example, or, Eclipse Remote Explorer):

username: dev.{lots of numbers}

host: appserver.dev.{lots of numbers}.drush.in

port: 2222

In Eclipse I clicked on the Define a connection to a remote system icon, left ssh selected and click Next, filled in the Host name field (which was replicated in the Connection name field and typed in “AWebFactory dev instance on Pantheon”, left Verify host name checked and clicked Finish. I right-clicked on the Sftp files node and open Properties; clicked on the Subsystem node, and filled in the Port number and User ID. I then opened up the Sftp files node on the Code tree, and then the My Home node. The file system tree then opened up as shown in the Pantheon Support Center documentation (if you receive a request to enter a password, it will be because you neglected to upload a public ssh key as mentioned above).

Now, if I add, delete or modify files via the Eclipse IDE, I will be prompted to commit those changes as described above. I have a great and simple develoopment environment!

Next I set up the user stories on Pivotal Tracker, which we will review as they are implemented in future editions of this log.

Bookmark/Search this post with

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web