Twitter Design Pattern

På Twitter har man 140 tecken på sig att säga något, sedan tar det stopp. Texten ska helst vara läsbar, så frktngr får man vara sparsam med.

[raderna ovan innehåller 140 tecken]

Det jag speciellt gillar är att man som twittrare måste ta bort all onödig information för att kunna leverera korta meddelanden utan brus. Finns det här designmönstret på flera ställen?

ONE: #business
Ibland pratar man om att berätta hissversionen av ett förslag eller en affärsidé:

Vi levererar det stora företagets IT-kompetens med det lilla företagets själ och den enskilde konsultens engagemang.
[116 tecken]

Här i Sverige pratar vi ju inte med varandra i hissen, men vad sägs om twitterversionen?

TWO: #requirements
I den agila världen används redan Twitter Design Pattern, där man gärna skriver krav i form av User Stories. Många Scrum-team och beställare gillar kortfattade och tydliga beskrivningar av det som ska göras:

Som en redaktör vill jag kunna lägga till och ta bort nyheter på internetbanken, så att bankens kunder kan ta del av aktuell information.
[137 tecken]

TWEET: #programming?
Jag har inte sett några tydliga tecken på Twitter Design Pattern i utveckling av mjukvara ännu. Men tänk om vi bara fick skriva 140 tecken när vi programmerar fram en metod? Enligt designmönstret behöver jag (trots begränsningarna) skriva koden både läsbar och meningsfull, helst utan krångliga frKrtNgr. Vilken utmaning!

Jag tror att resultatet skulle kunna bli lika enkelt och tydligt som på Twitter:
man behöver ju sällan läsa tidigare tweets för att hänga med. Meddelanden är isolerade och externa beroenden tar man med som länkar, taggar och re:tweets (Dependency Injection, Interface och arv?).

Vilka fler områden finns det som skulle kunna följa Twitter Design Pattern, har du några exempel?

http://twitter.com/davidvujic

My Job went to India...

Språk är en cool grej, tycker jag. Just nu ägnar jag mycket tid och energi åt att bland annat försöka förstå det här:



Ja, det är jättesvårt! Men också inspirerande och en ordentlig utmaning. Mindre inspirerande är att det i mjukvarubranschen inte precis uppmuntras till språklig mångfald. Inte när det handlar om programmeringsspråk. Häromdagen kunde man läsa en artikel om IT-folk som tycker att det är tufft att begränsa sig (se länk längre ned). En utvecklare, ett programmeringsspråk, en plattform?

Varför? Konkurrensmässigt blir man ju väldigt sårbar, både som person och som konsultföretag. Varför välja svenskar som levererar IT-lösningar när man kan välja väldigt många lika duktiga (men billigare) proffs utomlands? Expert betyder väl inte att man bara kan en sak?

Svenska IT-företag behöver folk som är flerspråkiga, det är en bra grej!



(artikel)

Scrum på fem

- Scrum-metodiken skapades av Ken Schwa... Stopp!
- I det Agila Manifestet står det skriv... Stopp!
- I Scrum har man Sprintar, Backlogs och Burndown cha... Stopp!

Visst har man hört det där några gånger för mycket. Det är väl lagarbete och människor det handlar om? Scrum är ju inte särskilt mycket att hålla reda på, egentligen. Det är enkelt, konkret och borde gå att beskriva på fem.


Så:


1. Planeringsmöte med produktägaren.




2. Laget har ett eget planeringsmöte.




3. Perioden är igång (kallas för Sprint).
Laget arbetar med uppgifterna och har korta dagliga möten.




4. Perioden är slut och laget har en demo för alla som är intresserade.
En demo ger en ganska trevlig känsla av ett avslut och att det är dags att gå vidare till nästa del.




5. Till sist: laget har ett kort återkopplingsmöte.
Missa inte den här punkten! Det är här det händer grejer i laget.




Det var allt, det är det här som Scrum handlar om. Ganska enkelt, eller hur?

Människor är mjukvara, kontor är...

Jag läste nyligen ut Peopleware, som handlar om hur man kan lyckas och misslyckas med att skapa och driva framgångsrika företag. Författarna skriver om arbetsplatser och projekt som behöver anpassas till människor - inte tvärtom. Visst borde det vara självklart? Ett exempel: varför drar man fortfarande igång de där storskaliga IT-projekten som ingen människa kan överblicka?

I boken beskrivs också hur strikt kontorsdesign (kapitlet The Furniture Police) ofta sker på bekostnad av människors produktivitet. Väl dolda kostnader i företagsvärlden. På svenska tror jag vi kallar dem för HR! ;)

En del grejer har ju blivit bättre sedan bokens beskrivningar av det sena åttio- och nittiotalets COBOL-programmerande kunskapsföretag, men mycket känns igen från både större och mindre organisationer även idag. Kommer sådana företag att överleva krisen?

Med en team-förespråkande utvecklares ögon läser jag, i kapitel efter kapitel, förslag på hur man kan ta bort hinder för personalen för att bli ett framgångsrikare företag. Idéerna påminner mycket om det som finns i Scrum och jag tror att det var någonstans här som lättrörliga arbetssätt (agile) för mjukvaruindustrin började ta form.

Peopleware är nästan lika bra som Tom DeMarcos senare skrivna bok Spelrum på jobbet (Slack!). Läs båda!

Scrum - ett försvarstal

I metod-debatten hör vi ju ofta talas om det Komplicerade Projektet X: med jättemånga människor utspridda världen över, i flera tidzoner dessutom. Som inte kan samlas "för en massa Scrum-möten hela tiden". Det brukar också sägas att "agila" metoder inte skalar upp.

Vi behöver skala ner projekten istället för att skala upp metoderna.

För visst är det ganska enkelt att finna fem fel i den här typen av storskaliga projekt? Varför inte prova att anpassa projekten till människan istället! Jag tror att cirka sex-sju heltidsarbetande personer är betydligt hälsosammare för ett mjukvaruprojekt och ett bra recept för framgång.

Ett möte på femton minuter om dagen, där team-medlemmarna berättar om dagliga framsteg kan inte vara ett problem då. De flesta människor sitter väl en vanlig arbetsdag på toaletten längre än det?