Category: documentation
... please remember people, no matter who you are, and whatever you do to live, thrive and survive, there are still some things that make us all the same: you, me, him, them - everybody, everybody! - this is a fragment of Blues Brothers' "Everybody Need Somebody" song. Nothing to do with software development but when you change the next line of this song from "Everybody needs somebody" to "Everybody needs Unit Tests" it becomes closer to software development.
I intentionally used lyrics of this song to keep everyone's attention (just a little bit) to this post. If you are familiar with TDD and unit test your code you can disregard it - I'd like to address this post to all software engineers/developers/programmers/etc. that DO NOT unit test their code.
In this post I will try (again) to convince all software developers that still don't unit test their code that it's right thing to do and it's damn simple.
Bookmark/Search this post with:
Most software project managers have very little power in an organization. They are on the hook for delivery, but have very little control over the actual resources required to get the job done. Project managers have to broker agreements, hold people accountable, and get people to do things that they are not otherwise incented to do.
Fixed Constraints and Up Front Design
Requirements documents are created early, and often with little input from the delivery team. Budgets are set and timelines negotiated, prior to the project team even being engaged.
In other words… project managers are in a pretty bad spot. They are trying to manage in a situation where the triple constraints are all set for them, they have little direct control over resources, and the resources they have are matrixed across several projects with competing priorities and differing agendas.
Bookmark/Search this post with:
Developers are the customers - from time to time. They are the customers for product definition/specification team that is preparing technical specification documents. It doesn't really matter whether you work in an agile or non-agile environment - I'm sure you have some technical documentation and the main goal of it is to answer developers' questions on technical issues (e.g. how to configure some components to work with others, how to map fields from GUI forms to XML message, etc.) It also helps test or QA team to prepare acceptance tests and to verify whether what developers implemented is what was specified (I know it stinks a bit the waterfall but stay tuned - I will say something about agile documentation soon).
I would suggest you reading an article on TAGRI (They Aren't Gonna Read It) by Scott W. Ambler - it's really great. And in my post I'm going to give you real-life example from what I experienced regarding documentation. I will share with you my opinions of what kind of documentation sucks and what documents are really cool and useful (btw. my dream documentation is the one with which I'm able to find accurate information of my interest quickly and be able to put this information into my head in less than 10 minutes - the picture you see is a total contradiction of my dream - it's a waterfall process).
Bookmark/Search this post with:
Agile software development methods tend to be lightweight. That is, while agile project can produce extensive user documentation, there is usually very small amount of internal documentation and bureaucracy. There is almost never any heavy architecture and design specification and even if there is, it is never produced upfront, but rather evolves iteratively.
Teams don't just skip the boring documentation. There are reasons for using a lightweight process:
- Agile teams focus on adding value for the end customer.
While customers might find a user guide useful, in most of cases they don't care about the internal design documents. Therefore if it is possible to work without the heavy upfront documentation, it actually saves some customer money.
Bookmark/Search this post with:
RSS feed
Subscribe on Kindle
