måndag, juni 18, 2007

Revenge of the nerds (Getting Real)

När jag läste den här boken för ett år sedan så valde jag att inte kommentera den men eftersom den blivit en guide för så många nya utvecklare så vill jag ändå skriva några rader.

"Getting Real" en bok av 37Signals vinklar ett utvecklarperspektiv och ser det inte alls från en beställares. Den andas "Revenge of the nerds" och hyllar Agile Software Development, vilket är en metodik som är en reaktion mot UML-diagram, funktionsspecar, RUP, möten med chefer och kunder. Det går ut på att aldrig skriva ett dokument som beskriver hur en leverans ska se ut, utan istället hålla frågan öppen och se vart åt det barkar. Passar säkert jättebra när man utvecklar första versionen av en produkt där det än så länge inte finns en beställare. Men om det finns en beställare, en budget och beroenden från andra grupper så är Agile helt förkastligt. Det finns inga garantier att man ska få det man önskar utan är bara en utvecklares önskan att få sitta ostörd och jobba utan krav.

Boken har många absoluta påstående och är ibland skrivna som religiösa sanningar:
  • "If you can't fit everything in within the time and budget allotted then don't expand the time and budget. Instead, pull back the scope. There's always time to add stuff later — later is eternal, now is fleeting."
  • "Don't follow the leader"
  • "You don't need to nail that perfect shade of green in week two. You don't need to move that "submit" button three pixels to the right in week three. Just get the stuff on the page for now. Then use it. Make sure it works. Later on you can adjust and perfect it."
  • "Don't be a yes-man", "Make each feature work hard to be implemented.", "Every new feature request that comes to us — or from us — meets a no. We listen but don't act. The initial response is 'not now.'"
  • "Don't expect to get it right the first time. Let the app grow and speak to you. Let it morph and evolve. With web-based software there's no need to ship perfection."
  • "There are too many meetings. Push back on meetings that do not make sense or are unproductive."
  • "So don't hire. Really. Don't hire people. Look for another way."
  • "When it comes time to hire, don't think you need a guru or a tech-celebrity. Often, they're just primadonnas anyway. A happy yet average employee is better than a disgruntled expert."
  • "Don't be afraid to say no to feature requests that are hard to do. Unless they're absolutely essential, save time/effort/confusion by leaving them out."
  • "Don't just pick tools and practices based on industry standards or performance metrics. Look at the intangibles: Is there passion, pride, and craftmanship here?"
  • "Don't worry about design, if you listen to your code a good design will appear...Listen to the technical people."
  • "Don't write a functional specifications document"
  • "Don't Do Dead Documents"
  • "Avoiding functional specs is a good start but don't stop there; Prevent excess paperwork everywhere."
  • "Build, don't write. If you need to explain something, try mocking it up and prototyping it rather than writing a longwinded document."
  • "Don't waste your time typing up that long visionary tome; no one's going to read it."
Det finns även rätt självklara saker som man kan skriva under på:
  • "Don't use acronyms or words that most people don't understand. Don't use internal lingo. Don't sound like an engineer talking to another engineer. Keep it short and sweet. Say what you need to and no more."
  • "You don't need to be a swiss-army knife. You can just be a screwdriver. You don't need to build a diving watch that's safe at 5,000 meters if your customers are land-lovers who just want to know what the time is."
  • "Be as open, honest, and transparent as possible. Don't keep secrets or hide behind spin. An informed customer is your best customer."
  • "Also, don't create a culture of fear surrounding bugs. Bugs happen. Don't constantly seek someone to blame."

6 kommentarer:

Patrik Löwendahl sa...

Agile är ingen ursäkt för att inte ha några krav.

Alla agile processer definerar kravsteg. Vad man däremot säger är att en BUF specifikation aldrig blir nära sanningen när man väl kommer till leverans. Man vet av erfarenhet att det finns en impedans miss match mellan det kunden uttrycker i text och vad det i praktiken blir.

Därför skapar man enklare kravdokumentation, jobbar med korta iterationer och kontinuerlig avstämning med beställarna. Isf, kravspec in - applikation ut.

Tyvärr är det många som använder Agile som ett alibi till att inte ha någon struktur alls, men de har inte förstått agile. Agile handlar inte om ingen struktur, inga krav och ingen dokumentation. Det handlar om "just enough" av krav, struktur och dokumentation.

Läs gärna Robert Martins book om Agile principles, eller Kent Becks XP bok, där finns gott om uppmaningar att skapa struktur osv.

Thoughtworks som tex Martin Fowler jobbar på, har lyckosamt använt Agile för att både skapa från början och ta över redan befintliga finanssystem i bankväsendet. Det är ett exempel på att om Agile används korrekt (och inte bara som ett alibi) så funkar Agile principer i miljöer med enormt höga krav som banker är.

Jonas Ekström sa...

Du fortsätter rapa upp texter och url:er som jag ska läsa ;) Jag försäkrar dig Patrik att jag har bara en annan åsikt än du och är inte dåligt påläst. Jag har varit med i över 50 utvecklingsprojekt under drygt 15 år som professionell utvecklare. Under de åren har jag varit med om tiden då programmeraren hade vit rock och var full av auktoritet, genom IT-bubblan då programmeraren tappade sin status och sin integritet till nu när utvecklaren försöker ta sig tillbaka på tronen som han tycker han förtjänar att sitta på.

Problemet är att Agile Development har ett pris som ingen organisation är beredd att betala, nämligen ovisshet. Agile utelämnar all kontroll uppifrån och beställare får leva med att sitta och hålla tummarna att teknikerna vet vad de gör. Imorgon kommer en ny version, hoppas den är bättre än den är idag. Men vi får se ...

Nämn en professionell organisation som använder sig av Agile Development som metodik för mjukvaruutveckling, och då pratar jag inte om mjukvaruproduktföretag.

Patrik Löwendahl sa...

Thoughtworks är det enda jag kan/får nämna utan att kolla först. Men det finns en hel mängd andra som jag stött på bara de senaste åren.

Jonas Ekström sa...

Agile Methodologies kan bero, men ta dig en titt på boken Getting Real och säga om du tror någon organisation skulle låta sina utvecklare få arbeta på det viset.

Joakim Sundén sa...

Jag är lite osäker på om din senaste kommentar betyder att du backar i det tämligen kategoriska avfärdandet av Agile du ger uttryck för i din bloggpost, t.ex. när du säger att metodiken är "förkastlig" om "det finns en beställare, en budget och beroenden från andra grupper". I så fall kanske du tydligare bör påpeka det, annars blir det lätt lite "guil by association"...

Jag har ingen omfattande erfarenhet av Agile, jag har inte läst boken du skriver om och jag är absolut ingen korsfarare för agila processer, men jag tycker de presenterar intressanta lösningar och perspektiv på problem jag ofta sett med andra mer traditionella processer.

Jag vet inte vilka företag du anser går bort för att de är mjukvaruproduktföretag (de kan nämligen också ha beställare, budgetar och beroenden från andra grupper), men exempel på profesionella organisationer som använder agila metoder är Chrysler, Ford, Qwest, IBM, Microsoft, HP, Federal Reserve Bank, Siemens och Sabre. Här i Sverige känner jag bland annat till Tain, PPM och Ericsson.

Jonas Ekström sa...

Man kan säga att jag backar från det kategoriska att dra alla agila metoder och alla agila projekt över en kam. Men jag anser fortfarande att det är en metodik som syftar till att lösa utvecklarnas förståelseproblem av domänen de jobbar i på ett felaktigt sätt. Rätt sätt är att 1) lära sig domänen 2) lära sig kommunicera bättre med beställaren 3) använda modell/verktyg/språk för realiseringen som bättre motsvarar verkligheten än vad OOD och liknande (läs DDD) gör.

Läs gärna boken för den tycker jag tar problematiken till det extrema och sätter utvecklaren i första rummet utan hänsyn till verksamheten och beställaren.