Kanban

I found this excellent article while researching Kanban, Lean, Agile, etc.

Lean development came into focus for me after a comment by Adam Monago about how they were using Lean internally at ThoughtWorks Studios. What I particularly latched on to was the concept of a work pipeline that was continuously being balanced rather than a product backlog + iterations + release plan + estimation pain, etc. (these are my inferences, not Adam's statements)

Given that back ground, the one of the appealing statements that Karl Scotland made in his article was:

The consequences of using a kanban system are that the Product Backlog can be eliminated, because the immediate queue is the only work of interest, timeboxed iterations (i.e. Sprints) can be eliminated, because work is pulled as necessary, and estimation can be eliminated, because work is not planned into iterations.

Does Scrum Work?

Good read.

Does Scrum Work?

How to Improve as a Software Development Team?

Joel Spolsky has some interesting ideas, but one I want to focus on in this note is his "12 Steps to Better Code"

• Do you use source control?
  
• Can you make a build in one step?
  
• Do you make daily builds?
  
• Do you have a bug database?
  
• Do you fix bugs before writing new code?
  
• Do you have an up-to-date schedule?
  
• Do you have a spec?
  
• Do programmers have quiet working conditions?
  
• Do you use the best tools money can buy?
  
• Do you have testers?
  
• Do new candidates write code during their interview?
  
• Do you do hallway usability testing?

I plan on focusing on these points over the next few weeks here at TransCore, in the 3Sixty FM Client team.

Functional Specifications

 

I'm researching Functional Specs.

 

As usual, Wikipedia has a good overview with lots of good links:

http://en.wikipedia.org/wiki/Functional_specification

 

Excerpts:

"A functional specification does not define the inner workings of the proposed system; it does not include the specification how the system function will be implemented. Instead, it focuses on what various outside agents (people using the program, computer peripherals, or other computers, for example) might "observe" when interacting with the system."

 

And:

"In practice, most successful specifications are written to understand and fine-tune applications that were already well-developed"

My main source of good information is Joel Spolsky (again).

Painless Functional Specifications:

• Part 1: Why Bother
  
• Part 2: What's a Spec?
• Part 3: But... How?
• Part 4: Tips

My take-away?

Functional specs should be easy to read, evolutionary documents that help you think through the design and workflow of your intended application.

Development should not start while there are open issues.

On the other hand, the document should not be considerd 'done' until the project is feature complete.

Side By Side Assemblies

Side-by-side Assemblies



Side-by-side assemblies allow multiple versions of the same DLL to be loaded and available to the same application at the same time.



The SxS Manager is responsible for using the manifests of the application and the Side-by-side (SxS) assemblies.



Overview link: http://msdn.microsoft.com/en-us/library/aa376307.aspx









Isolated Applications



SxS is a part of an overall strategy to implement Isolated Applications.



Isolated Applications are important because they enable stable and reliable installations that are unaffected by installation or removal of other applications.



Isolated and SxS applications can also be reconfigured after deployment without re-installing.



Overview of Isolated Applications: http://msdn.microsoft.com/en-us/library/aa375190(VS.85).aspx











Manifests are the XML files that ship with SxS, Isolated, and other assemblies. They describe the assembly, and contain information for binding and activation.



Manifests: http://msdn.microsoft.com/en-us/library/aa375365(VS.85).aspx











To create a manifest you can include it in an actual DLL or .EXE, or you can include a standalone PE file that contains the assembly manifest information.



http://msdn.microsoft.com/en-us/library/1w45z383.aspx





How the runtime locates assemblies: http://msdn.microsoft.com/en-us/library/yx7xezcf.aspx

And related best practices for assembly loading: http://msdn.microsoft.com/en-us/library/dd153782.aspx

Installing multiple versions of the same ClickOnce application

While researching Side-by-side (SxS) assemblies and ClickOnce I found this article by Brian Noyes that addresses the problem with attempting to install two versions of a ClickOnce application.



http://briannoyes.net/CommentView,guid,fe63caf8-a84e-4cb4-a784-703835ac327e.aspx





Essentially he says that the Application Identity is the actual discriminator that allows two versions of the same ClickOnce application to be installed on the same machine. Visual Studio set's the application id when publishing, but you can use the mageui.exe, or some other manifest manager tool, to change the application id.

Mingle

Our team is starting out with Mingle on a new project.

 

So far it’s been fairly good. 

 

 

We’ve been using version 2.0.1 on Linux.  We started with the MySQL database, but found that there were some issues with that, so we switched to the PostgreSQL database.

 

 

The really nice things about Mingle are:

-          Really, really easy to add, edit, manipulate ‘cards’

-          Everything is essentially a ‘card’: User Stories, Tasks, Sprints, Releases, Defects, etc.

-          Mingle is a RoR (Ruby on Rails) web app, and is very AJAX-y; this works really nicely with Chrome, which has a FAST JavaScript engine

-          Wiki collaboration is built right into the heart of the app; wiki pages, wiki style notes on cards, etc.

-          Completely customizable ‘transitions’; i.e. changes to properties like Status can trigger automatic changes to other properties

-          Very customizable properties.  There are a few built-in properties, but you can add all sorts of new ones.

 

 

 

Essentially, Mingle is about building your own workflow around Agile principles, rather than conforming to some agile process tool.

 

 

 

On the downside; keeping in mind that we’ve not yet installed the latest release, 2.1, we did find some usability issues:

 

Although you can drag and drop cards between ‘swim lanes’ representing values on a property (i.e. “In Process” to “Ready For Testing” in the Status property), when you do so in the grid view the transitions don’t work.  ThoughtWorks has told us that this is fixed in 2.1, so we’re looking forward to verifying that.

 

Aggregate properties (which are properties that represent aggregate values from sub cards), don’t always keep up with reality, leaving you guessing as to “ how much time really is in sprint 2?” for example.  To be fair, the aggregate properties show an asterisk next to them when they could be out of date.

 

 

 

In short, Mingle seems to be a very powerful, and well executed solution to the very diverse implementations of Agile.

 

We look forward to installing and using version 2.1