Posts Tagged ‘workflow’

I have now got a relatively decent workflow for configuring both a vagrant instance and a server using chef.

I’m using a vagrant instance configured (initially) to use chef-solo. Because I will eventually be using chef with the opscode platform, I’ve acquired a couple of hacks that help me use data-bags when using vagrant.

I posted earlier some reservations about BDD – largely based (as I now understand) on the declared motivations of some BDD practitioners (ringleaders even) that BDD tools enable customers to write tests (and also it felt like another software practice that swept up ‘requirements elicitation’ as a simple step to do before coding (and even if you do this iteratively, you are still doing ‘spiral’ development, but certainly not doing agile development).

Reading a thread on the mysociety list, which discusses a posting showing a mashup technique “with no coding required” and a subsequent critique of the specific mapping presentation to which this technique was put, led me to think about how screen scraping adds or removes value from it source data. My first response was that the two parts of the online discussion – technique and usage – were separate evaluations that shouldn’t be conflated.

As part of the process for trying to get Clever Plugs onto the BBC commissioning roster for on-air graphics, we had to reflect on how we would help the BBC reduce costs. So I wrote the following about why I thought our approach – iterative, tendency agile (see e2x’s article on sustainable software for an interesting differentiation here).

We work with the latest technologies and with only the highest standard of multi-disciplinary developers and designers. These are both ways of cutting costs, but can also present risks (latest technologies carry unknowns, highest standard of developers delivery quality, but are expensive). For this reason we find that risk is the highest factor affecting cost, and we dedicate our working practices to controlling and reducing risk within the project, aiming to have a smooth curve in the decline in risk over the course of project’s timeline.

To do this, we use best practices & methodologies from the agile methods of software methodology (see Martin Fowler on the New Methodology and The Agile Manifesto). Overall this means focusing on interactions amongst the team, working software, and collaboration with our customer to achieve the needs of the project over its lifetime.

This leads to practical impact on what we don’t do, what we do do, and then how this reduces cost…

I am a fan of index cards and always have been. However index cards always end up being only a tentative experiment for me – from the days as I child where I would try to “categorize everything” into cards (I had several index card boxes with partial categorizations) – somehow this frustrated my parents greatly (Now as a parent I can begin to understand this).

I tried the ‘Hipster PDA‘ index-cards-as-organizer thing – at different times in my life (yes, even before they blogged about it), but only ever for a while. It’s fun while it lasts (till my backing cardboard gets too bent and all my rubber bands snap ).

And then there’s story cards. We had a great experience with running sodaplay development with these for a while – until some of us needed to work remotely. Since then we’ve had some good experience of transferring the principles to Trac, but the mystique (and discipline!) of story cards (that derives in many ways from the physical features (let’s say, affordances, even) of index cards) is missing.

This is a rather exciting* looking offering from thoughtworks (which seems to be crossing the consultancy-product gap in interesting ways) which seems to combine the virtuality of a trac-like system with some of the power of index cards. Plus oodles of optional process-y stuff (that trac largely eschews).

*’exciting’: perhaps only understood in context, and maybe only if you are a process-anorak (oh dear, that must make me one).

In some ways, I like the look of Mingle (I have to admit I haven’t tried it out, but only looked through the tour). However as a micro-business, with tiny (1-5 person) teams, all it does for me is increase my frustration with trac – don’t get me wrong, I do love trac, but it is aiming at a slightly different audience – opensource and product-management, I’d say, rather than project iteration management.

But Mingle’s not aiming for my segment of the market either, as at least evidenced from the price point. It is just too steep a hike away from even the most luxurious of hosted trac offerings. And in any case that price is license-only (unhosted).

The per-user pricing also hits if you are project-focused (which red56 is) – because the team needs to include one or more customers, each of which need to be a team member (interestingly the customer isn’t really a part of most of the tour – are index cards meant to be only part of the development ‘back room’?)

This probably adds up to a request for a different product – hosted, aimed at smaller companies, and probably with some of the issue tracking features of trac as well (after all a bug/enhancement ticket/issue is part of the pipeline towards becoming a story – though some (notably 37signals) disagree). Perhaps someone will write this application, launch a hosted service, sign me up and start billing me for it – or just tell me about it (send me one of those index cards with pictures on the back).

One odd thing that strikes me about Mingle – a ‘project collaboration and management tool for Agile software development’. Isn’t agile meant to be about “Individuals and interactions over processes and tools”? How do we measure that against promotion in Mingle of features that “make it easy to ensure adherence to project compliance”?