• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Does Agile mean less documents and meetings?

 
Ranch Hand
Posts: 434
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Create Document--->Review--->Revise--->Review--->Revise.....

Actualy I've implemented the function. But I need to obey the Process called "SOP100". Will this situation be changed in Agile Process?

Thanks.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The combined values in the Agile Manifesto point to a preference to other forms of communication. A face to face meeting is a more effective way to answer questions and resolve issues than an exchange of documents. Frequent feedback and course adjustments are a more effective way to get high value software than rigid contractual agreements. And so on.

Agile and XP never say "no documentation". If somebody wants a document and is willing to pay for it, make it. But if you can find a better way to communicate, do that instead. Stop to think about the cost and value of the doc before making it.

One phrase I like from the agile crowd is "barely sufficient." If you do produce a doc, focus on what it is meant to do (____ reads this to learn ____ so they can ____), make it do that, and no more. I see lots of docs with a cover page with a logo, a table of contents page, a revisions page, sometimes 5 or 6 pages of stuff before anything of any value. The sheer number of wasted electrons and pixels overwhelms me.
 
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes Agile means less documents. It means more testing and also more communication among team members, so meetings are not reduced. Meetings are daily standup are kept short because participants will stand and not sit.
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Adopting an agile approach may mean fewer documents, but really that depends on what documents you have now, and what documents you need!

As pointed out above. Agility is about making sure that the things which give the most business value get done first, and things which give no business value don't get done at all.

A document is just an artefact, like a java source file, or a configuration file, or a build script, or whatever. If it needs to be written, then write it. Just like the other artefacts, though: keep it under version control, test it to ensure it does its job, and be prepared to refactor it or eliminate it as soon as it is no longer useful.
 
Qunfeng Wang
Ranch Hand
Posts: 434
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Stan James:

......

I see lots of docs with a cover page with a logo, a table of contents page, a revisions page, sometimes 5 or 6 pages of stuff before anything of any value. The sheer number of wasted electrons and pixels overwhelms me.


That's absolutely what I am asked to do now! Everyone in the team should prepare such a document which is about 20 pages. It's quite interesting that everyone copys & pastes the documents created before to make up the 20 pages.

I've written a document about 2 pages to describe the how my module works. And I've written an email to tell everyone the steps I need to do to implemnt this module. Then I implement and test it. Do you think it's enough? I just think the "SOP100" process pushes me into a wrong way. But as an employee, I need to obey the policy.
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
See if you can replace any of your docs with tests. Unit tests and acceptance tests can make great documentation of requirements and usage demonstrations. If somebody insists on a document, print the tests. Of course the document will soon be out of date and you can't run the document to see if it's true, but you have to keep the folks who write the paychecks happy some days.
 
author
Posts: 608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You might find my article on Agile Documentation to be of value.

Agilists write documentation, it's just that we try to be as smart about it as possible. When we do write documentation we tend to be concise. We also tend to have "executable documentation" such as tests instead of static documentation such as Word documents. Big difference.

- Scott
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Stan James:
If somebody insists on a document, print the tests.


I did this in grad school. We were supposed to hand in a list of test cases that we used. So I handed in the names of all my JUnit tests.
 
Qunfeng Wang
Ranch Hand
Posts: 434
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Scott, I've read your article. It's great! Thank you very much.

I want to be an agile developer!
 
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Louis,

I searched the web for SOP100 with no success. Do you have a link for this ominous documentation standard

Regards,
Darya
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Darya Akbari:
I searched the web for SOP100 with no success.



Smiley aside - I read it as a euphemism for a general, non-descript, process-heavy way of conducting business:

SOP - Standard Operating Procedure
100 (level) - Fundamental
 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Peer Reynders:
SOP - Standard Operating Procedure
100 (level) - Fundamental



Interesting, I never heard of that procedure. Who stands behind SOP? Is there a spec?

Searching for it leads to different explanations. The term SOP seems to be overloaded .

Aside of whether SOP is somehow mapping to Agile or not, I don't get what SOP is exactly .

Regards,
Darya
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Darya Akbari:
Who stands behind SOP? Is there a spec?



That was my point - it doesn't have to stand for anything. It could be entirely made up or something that is only used internally in a team, department, or institution.

Quite often the term Standing Operating Procedure (SOP) is simply used to refer to "the way things are done around here" as it is known by the people who do the work - sometimes it may even refer to an internal memo or document - and it is often used in a denigrating manner.

Standing operating procedure
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sometimes also known as S.O.B.
 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Peer Reynders:
Standing operating procedure



I read that link before but couldn't get lot out of it.

Originally posted by Stan James:
Sometimes also known as S.O.B.



Do you mean it stands for Standard Operational Bullshit .

After all, I can somehow understand Louis to get around this ominous SOP100 process.

Regards,
Darya
 
Qunfeng Wang
Ranch Hand
Posts: 434
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In fact, I know little about SOP(Standard Operating Procedure)100 too. There are SOP1,2,25.., and SOP100 is for Product Creation and Delivery Process.

It seems like the traditional waterfall process. In every step, some standard documents need to be created and appoved. The test cases and drawings on the whiteboard are impossible to be treated as documents.
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Louis Wang:
drawings on the whiteboard are impossible to be treated as documents.



A digital camera and if you want to enhance the drawing use Whiteboard Photo- that usually does the trick.
Start talking about the opportunity cost of making nice clean drawings on expensive drawing software AFTER the meeting when the meeting clearly demonstrated that the artifact on the whiteboard was clearly good enough to communicate the intent - then somebody may start to get the message.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Louis Wang:
The test cases and drawings on the whiteboard are impossible to be treated as documents.



Why?
 
Qunfeng Wang
Ranch Hand
Posts: 434
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:


Why?


Because we have standard document template. The sections are fixed:Scope, Overview,......

And we don't write unit test code now.
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Louis Wang:

Because we have standard document template. The sections are fixed:Scope, Overview,......



Once you start using unit tests you can always add a comment header to each test that includes relevant JavaDoc information. Use that info to generate input files that are referenced in the documentation through documentation automation.

Of course this is not ideal because you are repeating information that can go out of sync - i.e. comments are always in the danger of going stale, though less so than other forms of documentation.
 
So there I was, trapped in the jungle. And at the last minute, I was saved by this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic