background preloader

Manifesto for Software Craftsmanship

Related:  Agile

Punishment driven development I'm a big fan of agile development. One of the key concepts that I like the most is story point estimation. The best suggestion I ever heard was to estimate the size of your stories in terms of gummy bears (at which point you can come up with possibly one of the best units of progress measurement, gummy bears / iteration), thereby making sure that nobody gets the impression that you're actually quoting any sort of real unit of time. The exact opposite of this is trying to estimate stories in an agile project in terms of hours. All too often, even though these realistically are no more than "ideal hours", they are taken literally by everybody and if a developer doesn't manage to "burn down" 80 hours of development per week, they risk being told to either work harder or estimate better (it's often left ambiguous which solution is preferable), leading to what can possibly best be described as punishment driven development.

Agile Craftsmanship Model-View-Controller Model-View-Controller-koncept. Den heldragna linjen representerar en direkt förbindelse, den streckade linjen indikerar förbindelse via en observatör. Model-View-Controller (MVC) är ett designmönster som används inom systemutveckling. I komplexa datorapplikationer kan det vara lämpligt att separera data (Model) och presentation (View) så att inte datahanteringen får konsekvenser på grund av förändringar i presentationslagret, samt att data kan omorganiseras utan behöva ändra i presentationslagret. MVC löser detta problem genom att separera data och affärslogiken från presentationen och användarinteraktionen, genom att introducera en mellanliggande komponent: Controllern. Beskrivning av designmönstret[redigera | redigera wikitext] MVC är ett av de äldsta designmönstrena som beskrivits. Det är vanligt att dela upp en applikation i separata lager: presentation (användargränssnitt), domän och data. MVC omfattar mer av applikationens arkitektur än vad som är normalt för ett designmönster.

Suggested Topics for Definition of Done Discussion Ken Schwaber and the rest of us advocate paying attention to what “done” means for a Product Backlog Item (PBIs, or “stories”). For a lot of programmers (like me), “done” often means “It works on my workstation!” The Scrum Master is charged with advocating a “done” that includes everything else needed to build a potentially-shippable product increment. To avoid nasty surprises at the Sprint Review Meeting, I’d suggest initially attaching a definition of done to each PBI during the estimation process. If you’re using cards, write the definition of done on the cards. Scrum, a generalized framework rather than a defined process, doesn’t prescribe a particular definition of done. However, reading this may save you a couple iterations because the same kinds of things come up a lot. –mj Michael James Software Process Mentor Danube Technologies, Inc. For a general description of Scrum, see the Scrum Reference Card.

Agile Ruined My Life I read the reply to my comment on a popular hacker board with sadness: (disclaimer: Agile consultants ruined the software group I work in.)Making good software is hard, and anyone claiming to have a magical process that guarantees good software is selling snake oil. I can appreciate your wanting to make a buck, but would also seriously appreciate it if you could find some other industry besides software development to go screw up Reminded me of an email I received back in May: [We] started working on [agile technique X] when [author]‘s [famous book] was just a draft. I’ve had many such conversations over the years.There are some seriously pissed off people about Agile out there. The easy answer — and the answer most agile-lovers would give — is that these folks are simply non-hackers. I don’t accept that. And the thing is, it’s not just the people who are being trained. So it’s time to get honest. Here are the problems I see and hear about: What’s Iterative Development? What’s Scrum? Nada.

Software Craftsmanship So what is software craftsmanship? A better metaphor: In a very simplistic way, we can say that software craftsmanship is a better metaphor for software development than software engineering, as I wrote in a previous post. Software craftsmanship sees software as a craft and compares software developers to the medieval blacksmiths. Wikipedia Definition: is an approach to software development that emphasizes the coding skills of the software developers themselves. I personally don't like too much the Wikipedia's definition. A more personal definition: Software craftsmanship is a long journey to mastery. A software craftsman cares and is proud of his or her work and is extremely professional and pragmatic when it comes to its implementation. The Software Craftsmanship Movement In the manifesto, the essence of the software craftsmanship is capture in its subtitle: Raising the bar. The values of the Software Craftsmanship Movement Not only working software, but also well-crafted software

Course: Programmering B Scrum 3.0 and Organization 4.0 - impressions from a great evening with Boris Gloger at ImmobilienScout24 | On the agile path Today I had the opportunity to join a great and inspiring presentation by Boris Gloger talking about Scrum 3.0 and organization 4.0 (thanks to Immobilienscout24 for hosting a great event). With this post I provide a short summary of my notes and insights and links to further posts I already wrote about some topics presented today. Based on an initial blog post by Boris (DE) - we started today with a recap of the Scrum journey from Scrum 1.0, Scrum 2.0 and developed to today's Scrum status. Scrum 1.0 foundation by e.g. Agile Software Development with Scrum (Ken Schwaber)basic meeting artifacts, 3 roles (ScrumMaster as management role, Product Owner and team)retrospective was not yet part of itBacklog idea, but not yet that establishedfocus on deliverysprint idea - a common way to think about what we would like to deliver together, but breaks in between sprintslong Excel-lists with tasks and detailed task estimations What did we learn? Scrum 2.0 Scrum 3.0 Product Owner Dailies NoMeetings Conclusion

Agile Intifada This blog post was inspired by a link my friend sent me titled “Agile Ruined My Life” as well as a conversation with my friends/co-workers and just wanting to clear up a few things about my previous “Agile Dilemma” post. Some of this is taken verbatim from an email exchange between myself and a few friends I greatly respect. I agree/like agile in theory and practice. I wrote the Agile Dilemma post mostly while I was letting off steam about computer science itself becoming extinct in lieu of a bunch of consultants pushing agile and TDD 90% of the time without teaching people how to actually design and write good software. Now, there are those that go even as far as saying that non-TDD written code is “stone age” or that programmers not practicing agile, TDD, pair-programming and all the other process crap are not “good” programmers or shouldn’t be programming. Writing tests is not innovative, it’s been around for decades. Agile is also not innovative. So let’s get back to basics.