(but don’t try to solve all of them)
IT development projects can suffer from problems that are addressed within the wrong domain. I’ve encountered many projects where a development team implemented requirements that in the end did not add any business value, purely because they tried to automate a business process that was far from stable. Sounds familiar?
December is met Sinterklaas en Kerstmis voor velen de maand van cadeautjes. En daar hoort natuurlijk een verlanglijstje bij. Veel kinderen stoppen hun lijstje al half november in hun schoen, zodra de Sint in het land is. En vaak zetten ze daarop ook wat ze het belangrijkste vinden.
Veel organisaties zijn bezig met het opzetten van Agile werken door Scrum in te zetten. Een van de eerste stappen is dan het maken van een Scrum board. De wereld wordt steeds meer digitaal en dus is de eerste reactie: “welke tool kunnen we gebruiken voor een Scrum board?” De reacties zijn op z’n zachtst gezegd nogal lauw als ik aangeef met een “ouderwets” white board te willen starten.
Niet zo heel lang geleden ben ik begonnen aan het bouwen van een mobiele app in xamarin. Je wilt toch dat je app op meerdere platformen kan draaien en niet dat je al je code opnieuw moet gaan schrijven in verschillende talen voor verschillende platformen. Nu was ik daar al een aardig eindje mee op weg en toen kwam ik het Microsoft bot framework tegen. Na me verdiept te hebben in het framework wist ik het, het wordt geen app meer maar een bot!
Veel Agile transities worden gestart omdat door de Agile methode in te zetten het werk sneller, beter en goedkoper kan worden gedaan. En deze belofte is volledig waar, maar om hier te komen moet de basis van de transitie wel goed zijn. De basis bestaat uit een aantal belangrijke elementen en keuzes die ik graag met jullie wil delen. In deze blog schrijf ik over de eerste keuze die gemaakt moet worden voor een transitie, namelijk: wat is de goede aanpak voor ons?
Een kleine twee jaar terug kreeg ik bij één van mijn klanten de opmerking: wij willen graag Scrum! Op zich geen gek punt. De organisatie had al kennisgemaakt met Kanban en dat succesvol geïmplementeerd bij het beherende deel van de organisatie. Ze had het Agile gedachtengoed omarmd en wilde graag verder groeien met de ontwikkelteams. Maar toen kwam er een zin welke bij mij alle alarmbellen deed afgaan: “Maar… dan niet dat hele strenge Scrum. Wel een beetje iets dat past bij onze organisatie. Niet iets Scrumdamentalistisch.”
De afgelopen weken heb ik stil gestaan bij het belang van onderhoudbaarheid van maatwerk applicaties, hoe een Agile ontwikkelaanpak hieraan bijdraagt, hoe de mate van onderhoudbaarheid kan worden gemeten en hoe deze opgebouwde technical debt met refactoring kan worden aangepakt. Vorige week stond ik stil bij de rol van testen en geautomatiseerd testen in het bijzonder en het automatiseren van de infrastructuur. In dit afsluitende stuk aandacht voor overdraagbaarheid.
De afgelopen weken heb ik stil gestaan bij het belang van onderhoudbaarheid van maatwerk applicaties, hoe een Agile ontwikkelaanpak hieraan bijdraagt, hoe de mate van onderhoudbaarheid kan worden gemeten en hoe deze opgebouwde technical debt met refactoring kan worden aangepakt. Vorige week stond ik stil bij de rol van testen en geautomatiseerd testen in het bijzonder. In dit deel aandacht voor de onderliggende infrastructuur.
De afgelopen weken heb ik stilgestaan bij het belang van onderhoudbaarheid van maatwerk applicaties, hoe een Agile ontwikkelaanpak hieraan bijdraagt, hoe de mate van onderhoudbaarheid kan worden gemeten en hoe deze opgebouwde technical debt met refactoring kan worden aangepakt. Deze week sta ik stil bij de rol van testen en geautomatiseerd testen in het bijzonder.
De afgelopen weken heb ik stilgestaan bij het belang van onderhoudbaarheid van maatwerk applicaties, hoe een Agile ontwikkelaanpak hieraan bijdraagt en hoe de mate van onderhoudbaarheid kan worden <a class=”clr–prim” href=”https://vxcompany.com/2016/08/12/onderhoudbaarheid-tip-2-maak-analyseerbaarheid-en-complexiteit-zichtbaar/. In dit deel ga ik in op refactoring, het verminderen van de opgebouwde technical debt.
Dit is deel drie over het belang van onderhoudbaarheid van applicaties. In het eerste deel hebben we stilgestaan bij het belang van onderhoudbaarheid van applicaties. Hoe onderhoudbaarheid wordt omschreven en hoe technical debt de onderhoudhaarheid negatief beïnvloedt. Vorig week is het belang van een Agile ontwikkelaanpak de revue gepasseerd. In dit deel sta ik stil bij het kunnen inschatten van de hoeveelheid technical debt.
Vorige week hebben we stilgestaan bij het belang van onderhoudbaarheid van applicaties. Hoe onderhoudbaarheid wordt omschreven en hoe technical debt de onderhoudhaarheid negatief beïnvloedt.
