http://accurev.com/blog/2008/05/08/why-use-accurev-for-document-management/ SCM and Agile Software Development Blog Wed, 09 May 2012 07:08:34 +0000 hourly 1 http://wordpress.org/?v=3.3 http://accurev.com/blog/2008/05/08/why-use-accurev-for-document-management/comment-page-1/#comment-18650 Dorthy Lingefelt Thu, 22 Sep 2011 11:22:28 +0000 http://accurev.wordpress.com/?p=182#comment-18650 It is often difficult to make the move between manual and electronic. My firm has just begun getting all of our thousands of papers converted for a digital document management system to be integrated. It is tough being without the files, arggghhh! With a little luck it'll be worth the cost ultimately. It is often difficult to make the move between manual and electronic. My firm has just begun getting all of our thousands of papers converted for a digital document management system to be integrated. It is tough being without the files, arggghhh! With a little luck it’ll be worth the cost ultimately.

]]> http://accurev.com/blog/2008/05/08/why-use-accurev-for-document-management/comment-page-1/#comment-455 Chris Boran Sat, 10 May 2008 12:27:49 +0000 http://accurev.wordpress.com/?p=182#comment-455 We have done this at Symantec. To combat the 'we don't want non-programmers accessing the source code' we simply created a pass-through stream which explicitly included the documentation directories and excluded everything else. It worked great. We stored everything from QA test plans, Design Docs, Functional Specs, to burn down charts, bug statistics, and requirements. Since we ran long-cycle releases (9-15 month cycles) it was a real benefit to us to be able to look back and compare how estimates changed and tracked and look for trends when planning the next release. We learned a lot about how individual team members estimated (and over time, developed methods to try to compensate for individuals estimating flaws), and were better able to predict/plan the next cycle. We have done this at Symantec. To combat the ‘we don’t want non-programmers accessing the source code’ we simply created a pass-through stream which explicitly included the documentation directories and excluded everything else. It worked great. We stored everything from QA test plans, Design Docs, Functional Specs, to burn down charts, bug statistics, and requirements. Since we ran long-cycle releases (9-15 month cycles) it was a real benefit to us to be able to look back and compare how estimates changed and tracked and look for trends when planning the next release. We learned a lot about how individual team members estimated (and over time, developed methods to try to compensate for individuals estimating flaws), and were better able to predict/plan the next cycle.

]]>