-
|
-
|
-
|
Agile Requirements - How do you eat yours? |
| by Neil Middleton 3:09 pm Monday, 16 March 2009. |
One of the things that I have been looking at a lot recently is the definition of what we, as a team, are building - a commonly missed task by many teams which can often lead to cowboy coding.
Now, there are many viewpoints on how this can be done, the age old preference being that of creating a 10,000 document that everyone must adhere to and be measured by. The trouble is, the document takes months to write, even longer to get approval on, and then an eon to code. By the end of this process, the document owner has retired, the development team have cycled their staff three times, and your dog has died. But, more importantly, because these days is moving so damn fast in business, your document is now worthless as half of the requirements are now invalid - either because the workflows in place have subtly changed or the market the product is aimed at has.
So, what do we do about this? Do we just ignore the requirement making it up as we go along, or do we do something a little more clever. Most people seem to leave it to making it up as you go along.
Well, at Monochrome, we’ve been doing Agile now for a fair while, and the key mantra there is
But what does this mean? Well, in essence, don’t bother doing anything until literally just before you need it, and even then, only do the absolute minimum to makes things work. If you do things to early, you’re opening up the risk of change, and if you do too much, you’re pretty much wasting your time (the minimum amount is just enough after all). This means no massive tombs of out of date guff, and also a lot less time spent writing.
For us, we find that documentation in the form of multiple screen wireframes that are annotated with functional detail tend to suffice, especially when accompanied by some background blurb to describe the things you can’t see. This is especially effective for two reasons - firstly it’s nice and visual, which means clients are more likely to read it, and it also gives you a nice document to directly compare your screens and functionality against - it’s almost testable.
Now, here’s a question back to you guys, all of which will be either reading, writing or somehow interacting with requirements on a daily basis - how do you eat yours? What do you find works, and what do you wish you could have?
|
|
Mocking your User Experience |
| by Neil Middleton 11:31 am Tuesday, 13 January 2009. |
At Monochrome, when we are building an application for our clients to use in their business we strive to meet a single criteria when it comes to user interface. This criteria is essentially that we are able to deploy an application to a user, and the user be able to use the application as efficiently as possible with minimal/no training. More importantly than this we strive to ensure that the user also wants to use the application - a major requirement for productivity and motivation in businesses today.
So, how do we achieve this? Well, in short, we spend a long time talking about the interface with the client before we ever cut any code of any kind. This process typically involves our product manager, user experience design experts and traditional designers, as well as usability experts and technology domain experts. From these interactive sessions we typically end up with a final set of UI “screens” which make it into the final application, and are built in such a way that extending to the functionality isn’t a heavy process that destroys the initial concept.
During this process we use techniques such as wireframing and paper prototyping as well as the plain old whiteboard. However, one tool we are finding increasingly useful for UI wireframing is Mockups from Balsamiq.
Mockups is a tool that let’s us create very simple, design-free, UI concepts in a matter of minutes with a simple drag drop interface. This is great when we want to be able to put out a load of different ideas for a UI, as quickly as possible, in a manner that does not entice opinion on design, only the layout and contents. This ability to iterate through concepts in a rapid manner suits us perfectly as an agile agency, it means we can spend more time outputting ideas, rather than waiting for customer feedback. Best of all, we’ve found a couple of clients like the process so much that they are happy to sit down next to us while we use the tool - imagine pair programming with your client!
Overall, Wireframing and UI prototypes are very important to us at Monochrome, and the tools we are using make this easier every day.
Comments (2)
|
SQL Server Procedure to Change Object Owner |
| by Niklas Richardson 12:35 pm Wednesday, 25 July 2007. |
Have you ever needed to change the owner of a table (or for any object) in SQL Server?
We just had the need to do that today and found this nifty script from Microsoft to do it. Basically it creates a stored procedure that when run creates a list of commands that you can then run against the database to change all the owners for all the relevant objects.
So by using Query Analyzer do the following steps:
(1) Run the create stored procedure script against the database in Query Analyzer
(2) Then run the command “exec chObjOwner ‘test’,'dbo’” against the same database to create the commands
(3) Then copy and paste the outputted commands into the execute window, and run them all!
(4) All objects will have been updated!
Hope this helps someone!
Comments (2)|
|
Running Apache and IIS 6 together on the same server |
| by Niklas Richardson 5:11 pm Tuesday, 20 June 2006. |
We have a Windows Small Business Server at work, which we wanted to install Subversion onto. We therefore wanted to run Apache on the same server. However, IIS is also installed on the same machine for Small Business Server purposes so I couldn’t just remove IIS.
I had added multiple IP addresses to the server so that IIS could have one and Apache could have another (so they could both run on port 80). However, I ran into the problem that IIS was taking control of all IP addresses on port 80 and so Apache wouldn’t start. It seems that IIS 6.0 has a “feature” called Socket Pooling that claims all ports for all loaded IP address (even if not configured in IIS) - nice! So IIS had control of the port 80 on the IP address I had assigned to Apache.
Do not fear - there is a workaround:
You’ll then find that Apache and IIS will then play nicely together and run on the correct ports on the correct IP addresses. Woo hoo!
Note: Thanks to agrikk on p2p.wrox.com.
Comments (27)|
|
Eclipse ‘Compare with Local History’ Saved My Life! |
| by Niklas Richardson 5:28 pm Monday, 5 December 2005. |
Well, perhaps ‘Saved My Life!’ is a bit extreme, but it certainly turned my day from ending on a total downer to ending on a high.
After spending the last few days working on a feature for the current project we’re working on, I was doing a merge in Perforce on a few files that I had changed due to the new feature.
After doing the merge and then doing a complete build to ensure I hadn’t broken anything, the build failed to my horror because a fair amount of code had vanished during the merge! Evil!
In any case, one of my fellow developers on the project suggested I gave the Eclipse feature ‘Compare with Local History’ a go. And my day turned around, as I could step through all the changes through out the day to the point where the merge happened. I saved my code! Woo hoo! I was not looking forward to having to re-write it all! It even works if you have closed Eclipse and then reopen it! What a FANTASTIC feature!
Eclipse becomes my most favourite IDE the more and more I use it. It rocks!
Comments (5)