Thank you for the very comprehensive reply.  :-)     (Yes, it was
hello.. I guess I'd forgotten to load up on 'o's that day).    I
understand what you mean about wanting to keep control of the
filesystem,  but my feeling is that the people creating new
environments will the project managers.. and at the moment everyone
above the level of 'developer'  (in our place at least) is a PHB...
*sigh*    Show half of them a command line, and they'll run
screaming..   ;-)

If I may suggest though: when you create the uber admin pages for the
Enterprise edition, it would be nice if you could add the facility to
also offer to create an associated SVN repository (or link to an
existing one, of course) and also to install the pre/post commit
hooks.  When I'm creating new repositories and new environments, tis a
lot of typing, even with most of it in batch files.  ;-)


One note I can pass on to anyone out there:  It *is* quite a learning
overhang if you want to set Trac up under Apache with Windows Domain
authentication and WSGI, then connect it to an SVN repository also
using Apache.    But if you are thinking of doing it, it *is* possible
with perseverance, and if you use NameVirtualHosts to create an http://svn
and an http://trac on the same server, you're sorted!  The developers
can just fly.


I hope you're having a wonderful weekend.   Thanks again!

All the best,

Nick










On Aug 5, 9:08 am, Andrea Tomasini <[email protected]>
wrote:
> On 5 Aug, 2009, at 24:05 , nww002 wrote:
>
> > Hell again!
>
> I hope it is Hello :-)
>
> > Thanks to earlier help from people here, I've now successfully
> > completed our first sprint, and persuaded the management to go full
> > steam ahead with Agilo. It's early days, but I thought I'd share some
> > of the questions my team has asked, and problems they've run into:
>
> Great news I would say :-)
>
> > *  Team Members
>
> >  In small organisations, the same person may have different roles in
> > different teams.  For example, while I can be the sprint manager of
> > one sprint, I could be a programmer on another...  I don't
> > particularly mind if 'sprint managers' are always 'sprint managers',
> > as sprint security isn't a real issue for us.. But I think in larger
> > organisations this would be a problem (don't want people
> > 'accidentally' changing things in the wrong sprint ;-).  My main
> > concern is that I cannot assign the same person into multiple
> > 'teams'....
>
> That happens because the organization still thinks in a traditional  
> way, if you have 5 developers, the best way of making them productive  
> is as a team, and pretending that they are a resource pool that you  
> can allocate in percentage to different "projects" never worked out,  
> especially with "creative" and "problem solving" work ;-) You are  
> human beings not CPUs that you can schedule to execute some jobs in a  
> specific order :-D
> So the question is, why small organization do not understand this and  
> try to prioritize the whole work to do in one single backlog that  
> feeds the development? Interesting ah? Than you could make a sprint  
> after the next of 2 weeks and focus on particular projects, so that  
> the manager will do their job or prioritizing by value and the team  
> will do its job of making a great product ;-)
>
> Back to reality...
>
> >  So, I guess that's three questions:
> >  1.  Any plan to allow a person to be on multiple teams with a
> > different hour-rating for each team?
>
> This ia planned for the Enterprise version, cause it is a justified  
> need when you have a lot of people and some of them are really not  
> needed for a whole sprint. For example when you have high level of  
> specialization like DBA, special testing skills, Architect... you do  
> not have enough work to do in one Sprint, or better, your talent can  
> be maximized if you help more than one team, but not more than 2, that  
> would already destroy productivity in terms of focus and task  
> switching :-)
>
> >  2.  Any plan to separate TRAC / AGILO permissions such that you have
> > different rights depending on Sprint (or more easily, Team)?
>
> We would try to make that more easy that what it is now, but being  
> based on trac infrastructure, it is not easy to do it separate, it is  
> also not a goal. If we start to separate on the basic we could abandon  
> trac completely, we already have an high level Architecture API that  
> completely abstract from Trac. I will post some example in the future  
> on how easy it is to create Agilo extensions now :-)
>
> >  3. Any plans to separate out the sprint administration from the trac-
> > administration, so that a non trac_admin can create and administer
> > sprints?  Or is this already in place, and I've just not played with
> > it enough :)
>
> That's already there, as PRODUCT_OWNER, or SCRUM_MASTER you can go to  
> the Roadmap and you will see a button "Add Sprint" below every  
> milestone. You can also click on a Sprint and if you have the proper  
> rights you will see the Edit Sprint and other buttons which will allow  
> you to do all the sprint operations without being admin ;-)
>
> > You might say 'just get them to log in using multiple logins, e.g.
> > n...@team1 and n...@team2, but we're using SSPI authentication for our
> > SVN / wiki etc, so I don't want to have to make the team start to
> > remember multiple usernames / passwords on top of their NT ones.
>
> That is not working out, I agree :-)
>
> > *  New Projects / trac.ini editing
>
> >  Setting up Trac / Agilo projects is a bit of a bind when using the
> > command-line.  Is there any plan to provide an 'uber-admin' page,
> > which allows for the control of projects (i.e. creation / deletion /
> > editing of termplate pages etc?).
>
> That is also part of the enterprise, there will be master site that  
> can create projects in the cloud ;-) With 0.8 we introduced a command  
> called create_agilo_project.py that is pretty much what trac-admin is,  
> but simplify a lot of things with Agilo, and saves you some steps...  
> it gets installed if you use easy_install to install the binary egg  
> for example, and you find it in the script folder of the source  
> distribution :-)
>
> >  I'd like my users to be able to set up new trac environments/
> > sprints themselves.  Now, I know that this is probably a 'trac'
> > question.. but it'd probably increase Agilo's "appeal" if there's less
> > mucking about on the command line.  Especially since to use this in a
> > commercial environment, this means that anyone who's allowed to set up
> > a new trac environment must be given /very/ permissive rights on the
> > trac server, which most sysadmins might baulk at (e.g. RDP / local
> > admin!).
>
> The reason for this is that you have to keep control over resources of  
> the system, creating a new project means changing the filesystem, and  
> that is something that not in every company will be allowed. We have -  
> as said - already implemented something in this direction with the  
> Enterprise version of Agilo, that will take a little longer to see the  
> light, but we are very positive about it ;-)
>
> >   Also, the trac admin page doesn't really cover everything that
> > Agilo has (in the trac.ini file).  Things like SVN path etc seem to be
> > uneditable... (is this true?)
>
> You can use other plugins fromhttp://trac-hacks.orgwe also integrate  
> some of them in our Hosted Agilo service, which provides full SVN  
> administration, as well as automated backup...
>
> > So I guess this comes down to two questions again:-
>
> >  1. Any plans to provide a web-based admin to allow for the
> > creation / deletion of Trac / Agilo environments?
>
> Yes in the Enterprise... may be in the future also in the Open Source,  
> not sure though
>
> >  2. Any plans to extend the admin page to include some of the other
> > trac.ini entries, such as SVN path and header logo?
>
> For this there are plenty of third parties plugins, we plan to extend  
> the Admin interface to manage other things which have been left  
> uncovered, such as email notifications for example... other ideas?
>
>
>
>
>
> > * SVN Branches
>
> >  Very often our sprints are coupled with SVN branches.   Very
> > occasionally a sprint might actually cover multiple SVN repositories
> > (because we've segregated out our independent components).   The way
> > that Trac has a one environment to one SVN repository link is a little
> > restrictive.    With only a small amount of extra complexity for the
> > user, a much more flexible environment would be something like:-
>
> >  1.  The creator specifies a set of comma-separated Repositories when
> > creating an environment, (not just one).
> >  2.  when creating a sprint, selects 0, 1 or many of the
> > repositories, and enters a path within those as the pertinent 'root'
> > folders of the sprint (e.g. /Branch/Sprint1).
> >  3.  When the "Browse Source" button is clicked, instead of dumping
> > at a repo, a set of 'Available Repositories' appears (with their
> > current head versions, etc), (much like the 'Available Projects' page
> > at the front of Trac).
> >  4.  Another button be on the LHS "Browse Source(s) for
> > Sprint:" [  Sprint 1 ] [View].   This would then take you to a
> > filtered version of the page in 3, which showed the current revisions
> > from each of the pertinent repositories / top-level branches.  When
> > clicking on these, they take you to a specific location within the
> > repo.
>
> This is very interesting, but the focus of Agilo is on Scrum, and not  
> on the technical part of the Software Development, for this we trust  
> and chose trac, that is doing pretty well, so if you want you can have  
> a look in their roadmap and post your suggestions in there :-) I am  
> sure there are already some requests on the topic :-)
>
> >  I think this would make the agilo/trac/svn linkage rather
> > spiffing :)
>
> I agree, but as you might understand the effort to keep up a  
> successful Open Source project is not trivial, and one of the key is  
> to keep a clear focus and a defined scope. Only in this way we can  
> maximize the contribution of the community, and the effort of the ones  
> bringing the product forward into achieving a higher value as fast as  
> possible ;-)
>
> Best
> ANdreaT
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Agilo for Scrum" group. This group is moderated by agile42 GmbH 
http://www.agile42.com and is focused in supporting Agilo for Scrum users.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/agilo?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to