As powerful and useful as Git is, it’s not all fun and games. It can be down right intimidating and hard to use.
But with some customization on your part, and some changes to your team’s Git workflow, Git can become a far more tammer beast to conquer.
As a software consulting firm, Grio strives to provide high quality, high value software to its clients. We embrace an agile software development methodology based on Scrum. This iterative approach provides our clients with flexibility to adapt and change their product over the course of development as discoveries are made while using the software.
This flexibility can prove challenging when providing up front estimates regarding project costs. The problem arises that providing an estimate that is too high may lose you the contract; Estimating too low can result in several outcomes:
As a recent convert to Test Driven Development (or TDD as his friends call him), I was surprised to hear that there were in fact 2 kinds of developer driven testing. The standard one that everyone knows of is unit testing: writing little testXXX methods that test a single publicly exposed method. But the lesser known – but just as important – are acceptance tests: tests which verify that a group of classes working together properly fulfill some functionality.
So this first post will take a closer look at the first type of testing, unit tests, and will go into the value it provides to you as a developer.
In Part 1 and Part 2, we saw the forces of extreme right and extreme left savage two organizations in the name of scrum. One company goose stepped about in Luftwaffe jumpsuits. Another built a gulag for stakeholders who would question its developers-only central planning meetings.
In both cases, malevolent propagandists diverted the team’s purpose, and product progress all but ceased. The right was called wrong. The in progress was called done. The 1 was called 0. User stories were enigmatic and undecipherable.
Whether or not they follow other precepts of Agile development, many software companies have implemented some form of a ‘scrum’ – a short daily stand-up in which team members report on their current progress. A well run scrum can be an extremely valuable communication asset for team members. A poorly run scrum can be an annoying and time consuming hassle that turns teams off of scrum. And even though teams are supposed to be “self-organizing”, in my experience a good scrummaster is always important for a good scrum outcome. Below I’ve outlined a few common problems for scrums, and things the scrummaster can do to keep things on track.
Having toiled for years under the yoke of a brutal waterfallocracy, one bitter developer learns of management’s decision to adopt scrum and sees…a revolution.
Born is the Marxist, leader and friend to the common bit farmer.
The revolutionary swoons at scrum’s commitment to the “self-organizing team”. He visualizes an enervated bourgeois middle management, an empowered development base that directs company affairs, and an opportunity to play video games at work.
Scrum is a bit like 20th century politics. You have your burn-down crazed fascists, your ground-up “power to the coding plebe” reds, greedy ladder climbers hiding under the guise of scrumocracy, and on very rare occasions… responsible elected representation.
Fascism
Let’s deal with the fascists first. Your average scrum doctrinaire falls back on phrases like “command and control” to describe the tired, archaic waterfallists. They should poke their own chests with that finger. I’m going to stick my neck out here and suggest that a large percentage of businesses practicing scrum err on the side of a Gestapo-like control. Why? Well let me answer you with a question: What do you think got your Product Owner or Director of Engineering their job in the first place?