Embed Size (px)
Citation preview
The Agile Technical WriterThe Agile Technical Writer
Aviram Eisenberg, CEO, Ignite
Real Life Agility 1
X years ago I was in a honeymoon in h il dThailand…
Like many business men before me ILike many business men before me I decided to buy Armani-like tailor-made suitW f d th idWe found a worthy provider Negotiated price and scope g p pAnd then the vendor asked me to come on a daily basis to measure the suitdaily basis to measure the suit
Real Life Agility 2
My wife, however, preferred to tickle tigers in Kanchanabury
Real Life Agility 3
We prefer to do all measuring on the first d d h l d i k hday and come on the last day to pick up the suit, I told the vendorNo, no, no, said the vendor. I need to measure you on a daily basis because firstmeasure you on a daily basis because first of all this is a manual work, hence we may h d h dhave man-made errors that we need to identify and correct
Real Life Agility 4
And secondly you may eat too well and change your waste line during this week!during this week!
Final Results
Through an iterative process of daily deliveries, feedback and corrections – mission accomplished!corrections mission accomplished!
Ignite - Who We Are
A Software Development Management companyExpertise in Project ManagementExpertise in Project ManagementExpertise in SW Development methodologies & tools
Agile/Scrum/XP/KanbanLean Software DevelopmentTOCCustomized flavor
E ti i Gl b l D li d lExpertise in Global Delivery modelsDistributed developmentOffshore development (Eastern Europe)Offshore development (Eastern Europe)
Expertise in Project DeliveryTurn-key, dedicated teams, ODC, BOT
The Agile Umbrella
TDD
XPAgile ModelingXP
Scrum
g
LScrum LeanAUP
DSDM FDDCrystalCrystal
Agile Highlights
Claims that SW development is a spiral process hence waterfall model is usuallyprocess hence waterfall model is usually not effectiveDevelop in short iterations (sprints) that each contain the detailed spec analysis, estimations, design, develop and testingWorking (testable or shippable) software Wo g (testab e o s ppab e) so twa eshould be delivered at each iteration (increment)(increment)Due dates are fixed, scope can be changedS lf t i d tSelf contained teams
Agile Highlights
Self organized teamsh i i li iEmphasis on process simplicity
Emphasis on working software rather than p gdocumentationEmphasis on quality and test automationEmphasis on quality and test automation
Waterfall
A hit t
Req Analysis
Design Task 1
Architecture
Task 2 Testing
Task 3 IntegrationDesign Documentation
TestingTask 4
Management
Agile
Planning I0 Task 1
Task 2Release
TestingReleasePlanning
IntegrationDocumentation
Planning I0 Task 4I1: Integration
Planning
Integration
Testing
Task 3 Documentation
Testing
D t tiDocumentation
Product Owner
Scrum in a Nutshell
Agile Benefits
Increase QualityPerform testing in short iterations as part of thePerform testing in short iterations as part of the development cycleEach iteration must pass acceptance criteria (DoD)Utilize continuous integration platform – each developer is notified when the code breaks (compilation or test failure) as soon as he commits it to ( p )repository
Quick Response to change/marketProduct manager works closely with the R&D team to define requirements and priorities for each iterationThe team is able to change plans at the beginning ofThe team is able to change plans at the beginning of each iteration as software is always stableAs a result management may quickly shift R&D to
f t / j t ithi th it ti ti i dnew features/project within the iteration time window (two weeks usually)
Agile Benefits
Waste ReductionPerform ad hoc design instead of long preliminaryPerform ad-hoc design instead of long preliminary design as requirements may change until implementationD l tl h t’ d d di t i itiDevelop exactly what’s needed according to priorities – at any given time the team is working on the most valuable featuresLean processes and interfaces between stakeholders –overhead reduction
Increase Progress visibilityIncrease Progress visibilityAt any given time management knows the progress quality main obstacles and concreteprogress, quality, main obstacles and concrete due dates
Agile Benefits
Waste ReductionPerform ad hoc design instead of long preliminaryPerform ad-hoc design instead of long preliminary design as requirements may change until implementationD l tl h t’ d d di t i itiDevelop exactly what’s needed according to priorities – at any given time the team is working on the most valuable featuresLean processes and interfaces between stakeholders –overhead reduction
Increase Progress visibilityIncrease Progress visibilityAt any given time management knows the progress quality main obstacles and concreteprogress, quality, main obstacles and concrete due dates
The Technical Writer Challenge
From the Agile Manifesto:
We ValueWe Value…
W ki fWorking software over comprehensive documentationcomprehensive documentation
The Technical Writer Challenge
Incremental Development = Incremental Documentation: big paradigm changeDocumentation: big paradigm change Incremental development vs. the need to see the “big picture”see the big pictureSome tasks can only be done after development endsdevelopment endsFrequent releases = Tech writer overload?E b i Ch R i iEmbracing Change = Rewriting documentation?
Devalued Documentation
Devalued documentation?Refers mostly to official developmentRefers mostly to official development documentsWriting all documents at the beginningWriting all documents at the beginning encourage wasteA good document is a live documentg
Agile encourages less formal documentation – mostly Wikiy
Become the wiki expert/managerSet your guidelines and templatesy g pEncourage team members to use itUse RSS feeds
Incremental Documentation
Good documentation, like good software, is not written once and then left to decaynot written once and then left to decayWriting the perfect document is an iterative process:process:
Write the page, get it reviewed, and publish it as quickly as possible. There are people out there who need it now!If you find a programming quirk while documenting the software, let the developer knowdocumenting the software, let the developer knowRespond to comments from customers, developers, support staff and anyone else. Update the document immediatelyimmediatelyMonitor changes made by other people
Change Your Habits
Participate in Release and sprint planningUse daily standup to raise obstaclesUse daily standup to raise obstacles Review the Product Backlog and Sprint B klBacklog
Take advantage of your free access to product owner ask for customer feedbackowner – ask for customer feedbackTake advantage of your free access to the development teamdevelopment teamInsist on good quality user storiesInsist on clear definition of doneInsist on clear definition of donePlay with working software after every dropRegister to wikiRegister to wiki
The Big Picture
Not everything is incrementalEngineering best practices did not fade withEngineering best practices did not fade with AgileR l l iRelease planning
High level requirements analysisHi h l l d iHigh-level design High-level estimationA d hi h l l d t ti id liAnd…high-level documentation guidelines
End of Development Tasks
Some tasks can only start when development endsdevelopment endsWell, now development ends every two weeksweeks…Tech writer can work in a phased mode
I0 Dev
I1 Dev
I2Dev
I3 Dev
I4 Dev
I5 Dev
I6 Dev
Final Release
I0 Tech Writing
I1 Tech Writing
I2 Tech Writing
I3 Tech Writing
I4 Tech Writing
I5 Tech Writing
Complete System –Wide D t tiDocumentation
Tech Writer Overload
Frequent releases tend to create overloadDistinguish internal and external releasesDistinguish internal and external releases
Internal releases – less official documentationE t l l k f t f db kExternal releases – ask for customer feedback and correct as you go
Long effort of reasonable pace workLong effort of reasonable pace work instead of concentrated bursts of work
Changes and Document Rewrites
Agile embraces changeChange implies documentation rewriteChange implies documentation rewriteWell, yes, if you wrote it all at once…Document only what was already developedDocument what was confirmed as doneDocument only what you see workingy y gDid me mention that a live document is
better than decaying document???y g
Not Everything is Bad..
The Tech Writer is part of the Agile TeamUser stories are much more descriptive thenUser stories are much more descriptive then feature requirements W t t ki ftWe get to see working software soonerThe customer is heavily involved in the
l f ti l d b iprocess – clearer functional and business requirementsA li d i b h d iA live document is better than a decaying document
