Currently I am the only programmer in the company. My goals are two-folded. One, I need a way to show my non-technical superiors that I am working and making progress. A way to provide a timeline with goals to work toward so they can see where I am at and how far I have to go. The problem I have run into is they can't see the progress I am making... all they will see when the first usable version comes out, until then they have no way of verifying that I am actually working. Secondly, an intern or two could be brought in to work on the project, and I would need a way to divide tasks and a way to track their progress.
Would trac help me keep a timeline/roadmap of target goals for a release? JIRA is more impressive, and looks to have most of the features of trac but they need to be installed as plugins. Would there be anything significant for going with JIRA instead of trac or visa versa? What kind of ways are there to get the most out of a roadmap and a timeline? What is the best way to store project documentation, howto's, flow charts, UML diagrams, developer notes. Should these be stored in text files and version controlled with the project or should these be stored separately? Should these be all digital, or a printed copy made of them as well? How do you determine how long it is going to take you to finish part of the project. To me programming is an art, it takes as long as it takes, but that answer is not acceptable to those in charge, how do I handle these kind of situations? Sometimes I don't know how long it might take me until I sit down and start working on the issue. -Thadeus On Sat, Jan 9, 2010 at 4:13 PM, howesc <how...@umich.edu> wrote: > Thadeus, > > I'm a huge fan of trac for most of this stuff. it's a wiki, bug/task > tracker, and svn all in one (though i'm starting to use mercurial and > i might want to find trac for mercurial). the last "big" project i > was working on (team of 6 living in 6 different states) we used trac > with some plugins that linked all of our checkins to the ticket they > were addressing. and we can follow the branches of mainline to > releases and such forth. if you want more details let me know, i'd be > happy to talk about the things i have used, pretty much all in small > companies (3-100 people). > > good luck! > > christian -Thadeus On Sat, Jan 9, 2010 at 6:05 PM, rev <reneversch...@gmail.com> wrote: >>The thought of managing a semi-large application seems a bit... daunting to >>me. > Yep, it is ;) > >> I was hoping some older >> programmers, and those with experience managing projects that were >> either large, or had multiple developers work on, could share some >> insights with me. > I'm a senior developer and now manage exactly the apps you need in an > enterprise environment (few hundred developers in a global company). > >> The kind of stuff they don't teach you in school. > There is no single solution. > It depends on the company culture, size and velocity of project, and > your personal preferences. > > First of all use a version control app. > Contrary to what some people belief, version control is not only > something for large bureaucratic development teams. > Even if you're the only developer you'll benefit hugely from a version > control app. > Pick any of the well known apps out there that you feel comfortable > with (e.g. Subversion, Mercurial, Perforce, Git). > >> With a large project, how do you handle the tracking of bugs ? I > As long as you're on your own a piece of paper can be sufficient. > But even then, start using a bugtracker. > Make it a habit of just entering each and every bug, task, and > improvement request. > An electronic archive of all your issues beats a piece of paper any > time. > When there are more developers, or you get issues from your customers/ > users, a bugtracker is vital. > You have one central point of information, developers can get issues > assigned or they pick issues themselves (depends on the way you work), > issues can get transferred between developers, and you can get > feedback from the reporter (customer/user). > If there are chats/phonecalls/emails related to an issue, make it a > habit to record the relevant part in the bugtracker (or force people > to communicate about issues only through the bugtracker). > For the record, we use JIRA. > > Hope this is of any help. > Try things out, read some articles/reviews and use common sense. > > rev > > -- > You received this message because you are subscribed to the Google Groups > "web2py-users" group. > To post to this group, send email to web...@googlegroups.com. > To unsubscribe from this group, send email to > web2py+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/web2py?hl=en. > > > >
-- You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
