Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have been looking for a collaborative tool for developing functional specifications. I am looking for the ability to:
Have multiple users contribute to the specification.
Provide some form of traceability, which could be done manually if needed.
Provide users with the ability to add comments and notes.
Upload and display Visio documents
Upload and display mockup screens using Balsamiq Mockup.
My initial impression is that using a wiki could be a good tool for this task. Does anyone have experience with using a wiki for creating functional specifications? What would be the pros and cons to using a tool like this as opposed to a requirements management tool?
Your input is greatly appreciated!
It's possible to do what you describe, to develop requirements in a collaborative way, in spite of using a wiki. Nothing about the wiki paradigm assists in this process.
I managed a wiki on the Zend Framework project to track proposals for components. They're still using it. Proposals are different from functional specifications, but the usage is similar enough to your question that I think this is relevant.
A wiki doesn't take care of itself. Unless you have someone responsible for managing it and making sure there is some structure and consistency, it quickly becomes a mess. The real-world analogy would be to hand each of your team a blank sheet of paper and tell them to write up their part of the requirements. Problems with this are:
Every contributor has to make up their own document structure, and write about different things in a different order. So it's impossible to compare one page to another.
There's no "index page" to organize all the disparate contributions. No one wants a page to "fall through the cracks," but in a wiki that's the default destiny of any page as soon as it's written.
There's no feedback loop to make sure the writing actually gets done.
The way to make it work is to apply some process to the project, and use the wiki in accordance with that process.
Give people the ability to create a new page in the wiki, but only through an interface that automatically links the new page into the right index.
Define a lifecycle for documents, so they are sure to be drafted, reviewed, and approved at the appropriate stages.
Provide a template for a new page. Provide the section headings that you need in each of these pages, and make part of the review process a confirmation that head section has been filled out adequately.
"What would be the pros and cons to using a tool like this as opposed to a requirements management tool?"
While it seems like a great idea, what you run into are people who can't and won't write.
People who can't write -- well -- can't write. They can't communicate with an email or a wiki or any medium outside voice.
Some people are "disorganized". Actually, writing is too linear and they don't think linearly.
Some people don't get the "write to your audience" and write stuff that's incomprehensible.
Sometimes you can't even figure out what they're talking about, much less what they're writing about. They talk in jargon or code. They don't know much but insist on being heard.
Some people won't write.
Some people refuse to make commitments. Even in a wiki where it can be retracted. They feel they must pre-discuss everything.
Some people are in the habit of doing everything by giving direction to someone else. They either don't write for themselves, or, they make people stand around in their office and listen to them talk and type.
Some people are generally toxic on any kind of project. They spring new requirements at the last minute. Their first response is "that will never work". They don't brainstorm well. When they say it work work, and you beg them for an improvement, they don't have one. They just know it won't work.
My experience is that only programmers can use a Wiki successfully. And only senior-level programmers.
N00bz don't have enough experience to sort out requirements from design from rumors and management fluff.
N00bz don't always have the language skills to write clearly. They may eventually, but one look at their Javadoc comments indicates that they're struggling with the "clarity" part of writing.
It's very appealing. I'm hoping for people to get better at using wiki's because I think it could have a lot of advantages over more traditional approaches where one person interviews everyone and writes things down. But it requires a level of confidence and skill in communication that few people seem to have.
Consider researching Fog Bugz. They tout themselves as the best of the
best for project management. Considering Joel's history I'd give them the
benefit of the doubt. They use a wiki in the way you've just described.
I would suggest signing up for the free trial, if you're serious.
Depending on the size of your project, buying it might be a very good
option.
At very least you could look at how they've structured it, or read the
forums for ideas on how to build your own stripped down version
Specialist tools help keep things on track and introduce a fixed work-flow. This is kind of the point, keeping things focused and functional. Using generic tools like a Wiki might be great for a bunch of programmers but introducing one for 'mixed-mode' work might be bad:
Things can creep and get off-track quickly
Communication can be lost in the medium
Look at things like Basecamp. They can be thought of as an applied wiki, or collaborative tool. A generic tool for specific purpose needs refining. I don't know if MediaWiki or others have enough customization to keep things clean and focused.
Maybe gather the requirements for your requirements management tool (recursive I know) and what aspects (communication aspects) you can take from the wiki culture and an open-communication mindset. If neither requirements management tools or wikis fit the bill, look at building one. Might be the next big thing. It feels like saying Could I use a wiki instead of Bugzilla?
A fixed work-flow webapp for requirements management with an open-communication emphasis that allows people from many roles to see and understand might be good!
We have used TWiki and now FosWiki in that context. There are many things one gets for free (version control, access control, Web-base access, searches, remote management, security patches, ...). In a few minutes, one can define:
a table defining requirements attributes,
which creates interactive forms with field selection and validation (where you can also document discussions and rationales, embed images, attach documents, link to other requirements...),
and then queries on these "requirements" and show them as tables that can be sorted, filtered, printed, reported against, etc. (e.g., http://jucmnav.softwareengineering.ca/ucm/bin/view/ProjetSEG/JUCMNavRequirementsVer2).
Obviously, one can easily use hyperlinks and Wiki links along the way. FosWiki also has features that can be used to enforce specific workflows, if needed. It is also easy to support forms for use cases and other paradigms (we have done this in the past, and that works generally well).
Wikis such as FosWiki are extensible and one could develop further modules for addressing weaknesses related to traceability management and impact analysis, table-based modifications of requirements, overall packaging, etc.
As a middle ground between a free-form wiki and a requirements management tool, consider using a structured wiki like Foswiki. I haven't done any formal requirements management (with a wiki or otherwise), but I have used TWiki (the predecessor to Foswiki) for other tasks, and it permits you to define a workflow, form fields, and so on as you need them, while keeping the flexibility of a wiki when you don't need a formal structure.
I agree with all (most) of the people above - use of a wiki may sound ok, but wiki's are meant to be present information and be updated as needed, not to be used as an interactive project management tool. I would strongly suggest SmartSheet (I'm a strong advocate of the product) - it provides a spreadsheet like interface where you can store multiple files per row/task, send out automated updates to users and maintain specification revisions...
The other approach could be the use of Google email, docs and calendar - a free friendly way of team interaction....I would shy away from issue/bug tracking tools for project management - they tend to have differ on focus: PM tools on the entire project/resource/timeline and Issue tracking tools for specific entered issues....
This may be a bit old now, but I am currently using Atlassian's "Confluence" and it's been great. I currently work as a UX engineer playing the role of "Product Owner" within an Agile process. I can document requirements for discrete interfaces, allow for multiple users' feedback and comments, and intertwine each interface with other interfaces within a larger context (e.g. user story). Everything is very dynamic and template driven. It's suiting my current needs very well.
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
What is a best way to organize many software development projects, interaction with clients, project documentation, sources, emails, knowledge, time tracking, issue and features tracking, support for releases and versions etc. for a small company?
For me (and I believe for many others) it is obvious that it must be some sort of web-based solutions. It would be great if it could provide an interface for iPhone (if not, it is also OK).
Important thing: it must be hosted on our servers, so PHP + MySQL is the best platform so far.
I have found the following system to consider:
http://www.activecollab.com/ (but I didn't found issue tracking as well as support for releases and versions, so it is not the best match for software development company)
http://www.mantisbt.org/ (Great tool, but no project planing...)
http://www.twproject.com/ (didn't try yet, but it has very strange interface)
But none of them is a 100% solution for me.
It also should (but not must) support SCRUM
We have about 25 people in our team and about 50 from client side. At once we run about 3-7 projects (some in dev. phase, some in support).
So, my questions: does anybody knows any good web-based system that gives everything software development company needs? I believe this information will be useful for many of us.
I would recommend FogBugz
They have a very interesting (admittedly not everyone's cup of tea) scheduling system and is apparently supporting scrum.
Their support for release management is something i'm particularly fond of, but i should also say that i have very little experience of other similar systems.
Another feature that I like is the ability to link different e-mail accounts as well as pure HTML forms to different projects.
Oh, and it is not a MySQL/PHP solution.
Some of the features are:
Issue tracking
Project planning
Scheduling
Customer support
Wiki
References:
Scrum and Fogbugz / Fogbugz questions / FogBugz Knowledge Exchange
I think it really depends on your company size. I used activecollab for a while but it never really convinced me and then they made it commercial anyway. There is an open source fork of it called ProjectPier.
Even if it is not MySQL + PHP but Ruby On Rails Redmine convinced me the most from all tools I tried (and installing the ruby module into apache is a question of 5 minutes). It is simpel and yet has anything I need (including Eclipse Mylyn, SCM integration, E-Mail Notification and time tracking). With a little RoR knowledge it is easily customizable, too.
The most popular Open Source sollution is probably Trac. It is written in Python, so it is not a PHP either.
But maybe it makes sense to consider a non PHP sollution. I didn't find any PHP open source tool that had the functionality and simplicity of Redmine or Trac. If you don't mind a hosted sollution Basecamp is probably the first address to turn to (never tried it though).
Trac with Agilo plugin might be a good option.
Here is link for Trac pluigns, some category are:
Code Documentation
User feedback and discussions
For another pespective - having used many of the above solutions, and liking them very much for bug tracking, wiki documentation and tracking information - I tend to move towards keeping much of my project "meta-data" (summary information pulling together wiki, bugs, schedules, communication) in spreadsheets now.
For those now climbing onto the top rope of the ring preparing for a takedown, here's why... I come from a programming background, and one of the best books I read early in my career was The Pragmatic Programmer. One of the tenets they preach is finding a fundamental editor that you like, and get good with it (for various Very Good Reasons). After trying (frustratingly) to port and adapt my PM/Dev Management approach multiple times to multiple systems, I've extrapolated that Pragmatic tooling philosophy to the product/project management world I now inhabit. To stretch the metaphor, my editor is now Excel.
I can't guarantee that for any company I work with, they have "Software Project Management xyz" or "Bug Tracking System abc" with the proper plugins - but I can be darn well sure they have Excel or some variant available. I know if I get ninja-like with that tool, I can continue to use it - and focus on the project, not the tools.
This spreadsheet approach comes with some caveats:
Excel done poorly can suck. We've all seen that. Watch for bloat and stupidity.
Keep the bugs in the bug tracking system, the wiki stuff in the wiki. The spreadsheet is meant to pull this stuff together, not replace it.
Keep it readable. Don't stuff everything in just because you can. Summary sheets are good.
Try to standardize your templates and macros meaningfully for tasks and information, to maximize reuse over time and projects. Just like good programming.
Back it up - use a document management system if you can. This approach isn't in the cloud or hosted centrally by default, so be aware of that.
Have you tried Assembla? They've recently released a new product called Portfolio which is great if you have to manage multiple projects + you get free clients! :)
You might like to consider http://targetprocess.com/ We use that in my current job and it works pretty well, from a developer point of view. I'm unsure as to whether it supports your installation requirements, however.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Hey all. I would like to get some insight on a question that I have been trying to find some information about. If you are the solo developer that is building a project from ground up, how do you manage the project? In the past, I have worked on a few personal projects that have grown into fairly large projects. In almost all of those projects, I have tried to wear the hats of all the roles that would normally be in place during a normal software development project (i.e. Product Owner, developer, architect, tester, etc.). It seems that when I leave the project for some time and come back, it is extremely hard to get back into the rhythm of what I was doing. So with that, I have some questions:
If I know the requirements (at this
current time), do I record them
anyways? If so, how do I go about
doing this, and how do I manage these
requirements? Product backlog,
features list, etc?
If this is the case, are full blown product backlogs or use cases a little overkill?
How does one efficiently appropriate
his/her time to each respective role?
What would be a normal flow of events
that one would follow? Start coding
immediately, write down user
stories/use cases, then go into
OOA/D?
What diagramming/modeling would be sufficient for this level? Domain model, class diagram, etc?
Basically, I was curious how everyone out there in the SO community would go about developing a project from inception to deployment when you are the lone, solo developer. What steps, documentation, and other project related activities are needed to help bring this project from an impractical, hobby project to something more professional? Any help, references, or suggestions would be greatly appreciated. Thanks in advance.
The most difficult part, I have found, about developing solo is that it's just tough to keep yourself driving forward. Even if you're doing this to make a living (AKA, running your own software business), unless you have pressing needs (AKA, you're going to starve if you don't make money) it can be difficult to sit down and just code.
From your perspective, I would recommend following good software practices where it makes sense to. For example, if I were a solo software developer, I would have no reason to create a collaborative development environment. All I really need is an SVN server, my IDE, and a place to record documentation (might setup a wiki or a website or something). I would personally create a realistic schedule to follow and would work on sticking to that.
As for level of effort of documentation, that really depends on you and the product you are developing. For example, I would definitely recommend recording your requirements. Unless your product is trivial, there is no way you'll remember them all and why you wanted certain ones over others. Managing a full backlog, however, can be a job in and of itself. In the solo programmer case this may not make sense.
Basically, the point I'm trying to get across (and should be followed with every project - not just in this case) is have just enough management that makes sense. The rest should be focused on the work and the development of the product.
Something else you may want to look into is reading this - Agile Programming Works for the Solo Developer. There are other, similar, articles out there. Might give you some good thoughts.
If I know the requirements (at this
current time), do I record them
anyways? If so, how do I go about
doing this, and how do I manage these
requirements? Product backlog,
features list, etc?
I have two lists of features:
A high-level view which states the scope of the finished product
A list of the features which I'm implementing in this iteration
Because I don't need to communicate it to other people (yet) I tend to write down the things that I don't know about the project (if I already know it there's no need to write it down): it's when it gets too complicated, or when there are details which I haven't defined but need to define, that I start to define them in writing.
I did however try to investigate/make a business-case for the project before starting coding.
How does one efficiently appropriate
his/her time to each respective role?
I did non-programmer, product-owner thinking at times when I had to be away from the computer anyway.
Apart from that, my cycle is:
Implement more functionality
Integration-test it
[repeat as above]
Every 3 to 6 months I compare the new-functionality-accomplished against my estimated schedule, and then recalibrate: i.e., make a new list of the highest-priority features to implement in the next few months.
What would be a normal flow of events
that one would follow? Start coding
immediately, write down user
stories/use cases, then go into OOA/D?
I started with working part-time or in my spare time, to make sure that I had:
Understood the required functionality
Made significant architectural decisions
Written any throw-away prototypes as necessary to learn new technology
After that I was ready to start developing full-time.
What diagramming/modeling would be sufficient for this level? Domain model, class diagram, etc?
I'm not using diagrams at all (except for sketches of the UI). By structuring the code, and refactoring, I'm able to know/remember/rediscover/decide which software components implement what functionality.
It seems that when I leave the project
for some time and come back, it is
extremely hard to get back into the
rhythm of what I was doing.
You need to comment your code more. If you leave the code, come back in two weeks, and can't remember how the code works, you need more comments.
If I know the requirements (at this
current time), do I record them
anyways?
Yes, for the same reasons stated above.
how do I manage these requirements?
A feature list is OK, provided you have enough detail in each feature to jog your memory.
How does one efficiently appropriate
his/her time to each respective role?
Break down each feature into smaller and smaller tasks, until you feel like you can do each task in a half day or less.
What would be a normal flow of events
that one would follow?
That depends on your development style. In general I would follow a clear but simple architecture, avail yourself of software patterns where practical, and provide adequate unit tests for your code as you go.
What diagramming/modeling would be
sufficient for this level?
Sufficient diagramming/modeling to make the project clear in your head.
What steps, documentation, and other
project related activities are needed
to help bring this project from an
impractical, hobby project to
something more professional?
Other than what I have already mentioned, make sure you have a good source control system and daily backups in place.
Good luck!
If you believe there is a chance that you're going to work on the project for some amount of time, leave it, and then come back to it at a later date...your best bet is to treat the documentation for the project the same as if you were working with a large team.
That means documenting requirements (even if they're from yourself), writing use cases (if functionality is going to be complex, otherwise some other form of documentation could suffice), and some level of UML diagraming (or other domain specific diagram) which could include activity diagrams/class diagrams/etc.
That way, when you leave the project for some amount of time, you can come back to a well documented idea and pick up where you left off.
As a side note, I try to do the majority of those things no matter what...that way if I ever find somebody interested in working on the project with me, I can get them up to speed quickly and get them on board with my ideas.
This is how I work, YMMV:
Keep a spreadsheet for high level of everything - list of your projects, and some top-level items/todos/reminders
Create a "project" folder for each product/project you have or work on, and create a strucuture to contain documentation and code for the project.
Keep a top-level "catch-all" document for each project, in the root of this folder. Keep you ideas, research, notes etc in this doc.
Then if you want to get organized, keep an MS project file (or similar) and plot out timelines for the various steps in each project. This is good for tracking progress on each project and make sure you arent forgetting anything. Basically keeps you honest with yourself.
And if you need to track progress on project work you are doing for clients, I understand Basecamp is a good solution for this. I am currently evaluating it for my own company. See www.basecamphq.com
Even as a solo developer, you should document at least the overall features of your project, and then the requirements for the particular feature you are working to complete, and then maybe produce a short pseudo-code for the functionality you're currently working on.
That way, if you do end up breaking away from that project, you can get back to it and see where you're up to easily enough. It's also pointless getting too far ahead of yourself with details for this same reason.
It's also a neat motivational tool for a solo developer - getting through and ticking things off is a way to show progress - something that you can start to feel you're not making when you're chewing through a couple of thousand lines of code and it seems like you're still miles away from actually having 'module x' completed.
Lastly - with regards to code comments - I at least try and fill out what actions/behaviour a new function should have in an outline, and then write the code in between the comments. Also, it is useful having plain English explanations of why you're branching in an if/else to support the logic in the condition...
I belive that better results in solo development one can achive with appropriate tools support and tasks that compensate lack of ohers people and help to organize working time. Any tool that generate metada with minimal create time cost describing your software is helpful.
VCS and tools for tracking user actity/code changes history - very important is to add good commit messages
mind-mapping tools for storing project related data (e.g. XMind), blacboard is useful too :)
time tracking tools (e.g. Toggl.com)
write a lot of acceptance test and use acceptance testing frameworks
Of course these clues also fits in non solo development :)
As a lone developer, I've found that your time is very expensive. This means that you have to balance sustainability and momentum - even though you are just one guy, you have to do things so that the you six months from now can go back and look at old stuff without wasting time, without spending so much time maintaining the systems that it compromises your flow.
Your question suggests that you are thinking in terms of fairly heavyweight tools and processes, but the 80/20 rule applies - for example, you can nail documentation well enough by TDD, using the doc tools of your platform to generate API docs, plus a Wiki for specs, lists, etc.
In that vein, I would suggest that you choose your platform carefully. The question about modelling suggests that you are using a platform that produce a lot of code and artifacts, but you may be able to get most of the functionality for much less management overhead elsewhere. Today I'm working on a .NET Web app that I wrote "the right way", but now realize that I could have delivered the same functionality much more efficiently in this case by using PHP with a PHP MVC framework to keep a clean structure.
Specific tools that I'd recommend:
A distributed version control system (much less overhead than centralized)
The most lightweight platform that you can use that has good tooling
A Wiki to easily capture and maintain small and large bits of content
Whatever testing framework that you can use, right from the start of the project
A lightweight TODO list system that you can access from anywhere
I used to work on a very small team (one dba and one C# developer). Even then I found it very useful to have written requirements, formal tests, source control and bug tracking (we used bug tracking for our features as well as bugs). It helped us to not forget anything and a year later when you were doing maintenance, you had something to research though to help you undersatnd what you did. Plus when the two of us left (as most people eventually move on) there was documentation there for the next person.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm facing developing a new web app in the future and I'm wondering how to decide what framework to use. I've settled on Python as my language of choice. But there are still may frameworks to choose from! More generally how do you choose between different similar technologies that are still in the works as the latest round of web frameworks are? I'm curious what your process is for deciding on technologies you've never used.
Recognize that no choice is perfect -- or even very good.
No matter what you choose, someone will have a suggestion that -- they claim -- is better.
No matter what you choose, some part of your tech. stack will fail to live up to your expectations.
The most important thing is "shared nothing" so that the components can be replaced.
After that, the next most important thing is automatically-generated features to reduce or prevent programming.
Look at Django. Lots of automatic admin features make life very pleasant.
There are a number of things you can do:
Download the frameworks and build something similar with them for comparison.
Look for comparisons by other people, but attempt to understand the bias of the reviewer.
Observe the community at work, see what people are building and the issues they run into when using the technology. Forums, blogs, mailing list etc are good places to check out.
Go to conferences and meet like minded developers interested.
You can also take the approach of using stable versions rather than alpha bits. After a while you might move closer the bleeding edge. People associated with the project in question are generally more biased than those approaching from other platforms, be careful who you trust.
Consider the impact of using a bleeding edge framework versus an established one. Sometimes it's important to your customers that you are on one perceived as stable. At other times this doesn't matter. How comfortable are you with fixing the framework itself? Great developers will learn the internals, or at least know enough to keep things moving whilst a bug is sent to the framework mailing list etc.
Consider some general best practices in building abstractions and reusable code on the python platform. You may be able to save yourself some work in moving to another platform. However, don't be a reuse junkie as this can limit the effectiveness of your use of the framework. The 37Signals guys are right when they talk about extracting frameworks from working code rather than building frameworks from scratch.
I know this is an old posting, but I am in a similar situation (again) and I think there are other people who may want to look for different opinions, and hear of (somewhat) successful experiences.
Since baudtack mentioned Python, I will try to answer this along the lines of my experiences using Python. Here is what has been working for me:
determine the scope of your project - outlining what your application is supposed to be able to do without introducing any programming or design notes will clarify your goals greatly
determine how you would like to work with your code, stack and data:
a. what sort of programming paradigm do you want to work with? i.e. object-oriented, functional, etc. do you want to play to your programming style or do you want to follow somebody else's programming style?
b. use semantic web or not? do you want greater control over URIs and their design? (I found web.py great for this by the way - It is my choice to create REST APIs in Python)
c. do you want to be trapped by framework requirements, or do you want a better separation of the application from the web component, i.e. use a framework to utilize your application as a set of modules, for example. My problem with Django was that I ended up not programming Python, but having to learn more Django than I needed to. If that works for you, then that is the way to go.
d. data stores... some sort of SQL vs. non RDBMS (xml databases like eXist-db with full xquery support) vs. OODBMS vs. a combination of the above? how complicated do you need this to be? how much control/separation do you need to have over how data gets stored and recalled in your application?
e. testing: unit tests... thank goodness for python! if your web app has the potential to grow (as they often do), having a sane and coherent testing platform to begin with will help out a lot in the future - I wish I had learned about this earlier on. oh well... better late than never.
f. how much control over the server do you need? hosting considerations? how much control over an Apache instance do you need to have? OS specific needs? I found that using shared hosting providers like Webfaction has been great. I eventually found I needed greater needs for flexibility and bandwidth. In other words, what can you get for your budget? If you have USD50 to spend each month, it may be better to consider a virtual hosting solution like Linode....
Finally, I echo S.Lott's sentiments that no choice for a solution is perfect, and are subject to obsolescence.
Experience trumps hearsay. I've found that prototyping is a huge help. Make a prototype that uses the features you expect to be the most important for various frameworks. This helps route out any features that may not work "as advertised."
In general though, kudos for being willing to look at new technologies.
I have a set of criteria in different categories:
Activity & Documentation
Is there an active user base?
Is there an active development base?
Is the support responsive and information accessible?
Are there user and development guides and reference material?
These are essential, there needs to be traceability of all of these to build confidence in the solution.
Ease of use
Are basic features easy and complex features possible? I typically give a new framework a test drive and try to roll out a set of use cases to see how intuitive the framework is to use.
Is installation intuitive and simple for a local/dev installation and production deployment?
How is it backed up and upgraded?
What is the effort and UX for implementing a "Hello World" type blog post, static page, menu item, and plugin?
How are versions dealt with for the core & plugins?
Example (on the topic of Automated Testing/Continuous Integration solutions)
Several years ago I evaluated several Automated Testing solution. At the time Jenkins and TeamCity were front runners and in the end I chose TeamCity because of the UX, active user & development base and quality of accessible documentation.
Example (CMS for a blog)
This criteria is also why I prefer to use Wordpress over other options. While wordpress has its shortcomings, the user and development base is strong and active which leads to a software architecture with more potential to evolve over time and maintain its relevance and a development community that provides quality plugins and themes to choose from.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
At the place I am working we are moving to a more agile approach to project management.
For tool support for project management I used MS Project and Target Process in the past. But I think they both have serious weaknesses:
MS Project is not very intuitive and therefore hard to use especially for novice users. It doesn't really fit the agile approach
Target Process seems only half done. E.g. users can set their own privileges to admin. Size of user stories is measured in hours instead of a unitless size which I think is really a bad idea. The UI feels bloated and overly complicated not really supporting usage by keyboard only.
We are also using Jira for Issue Tracking and I guess one could modify it and add some custom fields/reports to make it an agile project management tool.
So my question is: What software tools do you use for agile project management and what do you like or dislike about it?
Addition: I am aware that physical tools like a whiteboard or post-its are in a sense the perfect tool but if you want to get an overview about what is going on in the complete company it is kind of cumbersome to run from office to office to look at the whiteboards or to force people to copy it in a different kind of document. A similiar argument applies if you are working in a setting where the customer is not on site.
I'll try to list some features I'd consider interesting:
easy accessible by management, customer, team potentially from different sites. This almost requires a web app.
option to configure the app to fit the flavor of agile preferred by the team or company
it should allow multiple people to access it in parallel. E.g. a developer marking a task/story as done, shouldn't block the customer from adding a new task. This pretty much rules out Excel.
Nice usability for keyboard only usage, at least for things like updating a lot of stories or adding a lot of stories
Ability to integrate with Jira (entries there should become tasks or something in the system, changes should get synchronized or at least be impossible if they don't get synchronized) and SVN (commit comments with a story id should appear in the tool)
Ability to integrate with other systems using a Java API.
Mostly we use whiteboards and post-its. If we have to use software we usually use Trac or a simple wiki.
It's our experience that using a project management tool actually makes your project less agile. The tool tends to become the focus point of the whole development process and its data more important than the actual software.
I can really recommend using a physical tool instead of a software one. It keep everybody focused in the same location and is much more public and accessible then even the simplest software equivalent.
There is value in using a tool to provide visibility into your agile project when it is not pragmatic to come to the team room. I would not recommend using a tool other than the big visible charts in the team room in place of the big visible charts. When a person has to go to a tool to pull the information as opposed to see the information continuously visible in the team room, it looses its effectiveness.
Of the tools we have used my comments are as follows
Mingle - Programmable and the most customizable, largest learning curve but you won't be boxed into a corner and the learning curve is quickly picked up by a developer
Rally - Does what you need it to out of the box. Enforces agile practices and has a small learning curve. Reports are good.
Version One - Swiss army knife of agile tools. Easy, full of features, great query tool to extract project data, need to ensure hosted service provides the performance you need
XPlanner - free, basic but non-evolving, easy for the team to use, less capable in the reporting department
Excel - works great, most people start with it and the file can be posted to a WIKI that can be downloaded and viewed by anyone
Consider the licensing. A number of the tools can post results in HTLM which can be read from a WIKI as a dashboard report. If you need to control access to the data then providing a license to the tools or providing a login to the WIKI should meet your needs.
Redmine, it is easy to use and contains enough features.
What specific problems are you facing with your current project management software that you want to address.. What specific flavor of agile are you moving to ?
The first bullet is kind of shaky... in that novice users should not really be doing project management. Other arguments read like 'MS Project should not behave like MS Project'
If you want a simplified tool for a product backlog which seems to be what you're looking for.. use a spreadsheet and see if it works out. If not, move to complex ones.
There's a similar thread in SO ... dupe or does this thread deviate significantly ?
https://stackoverflow.com/questions/426458/recommendations-for-project-management-software-for-scrum
I actually use Atlassian's JIRA for all my Agile project management. And with their recent acquisition of GreenHopper, they fully integrated SCRUM into the project management as well. This is only available in the Beta version right now though.
My team is using Rally. I also used VersionOne a few years ago, but I think Rally is better. I am not an expert in all features, but I think it does most of the things you need.
Don't even try MS project ...
Axosoft's OnTime
CounterSoft Gemini (at least take their 5 user license for free)
There's a new tool - Bright Green Projects. It allows you to capture and prioritize requirements, build estimates, manage iterations, track issues.. etc. Nice interface and really easy to use: http://www.brightgreenprojects.com
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
What prompts my question is this post from Jeff Atwood, and this post from Dare Obasanjo. It seems to me that there might be at least a few areas where third-party functionality is a better idea than custom code.
For example, should logging always be third-party? How about encryption? Or search?
I'm looking forward to everyone's feedback on this.
Edit: This question assumes that logging, encryption, and/or search isn't your core business.
Encryption should be third party most of the times, ...unless you're in the business of selling encryption systems.
Which is pretty much Mr. Atwood his point as I understood it, your core busines shouldn't be third party, so there's probably nothing that should always be third party...
My rule of thumb is to use (or at least consider) third-party for anything that's outside the core purpose of your business.
Encryption's always been the prototypical example of this. But it extends to other areas as well.
Writing logging code for troubleshooting during development is entirely different than writing logging code used for monitoring production systems.
It's all about choosing which areas of development actually add value to your project. Using third-party stuff removes the risk that that component is incomplete/buggy/etc. but comes with the risk that it may not be as flexible as what you need.
Another example would be developing an entire web forum for a website, when you can buy a solution for much cheaper.
"What functionality should always be third-party?"
None. there is always an exception or special case to overrule the egregious use of "always" when discussing an essentially engineering decision.
Further, the decision to go third party should almost never be made on basis of a given "functionality." There is no such thing as such a perfect library that you never need go anywhere else for that type of functionality.
Going third party is a decision that should be made based on
Cost of going third party vs cost of doing it in house
Development time required placed against deadlines (ie, it might be cheaper inhouse, but your development timeline might not allow it regardless)
Ease of integration, debugging, maintenance, upgrade paths - it may be that you can develop something that will "do the job, but barely" inhouse vs not much more money for something that will take care of you for years to come
Ease/cost of testing and proving - security packages are notoriously difficult to test well
However. There are some things where it's really tough to believe that going in house is better. For instance, you can write a competitor to OpenGL and DirectX, and in certain applications (scientific computing, etc) there are good reasons for considering such a path. But in general you wouldn't dream of it. Even though it's "free" it's still a third party dependency, and you could end up on the skids because of a bug which only affects how you use these graphics languages.
In other words, some incredibly complex or hard to prove/test things exist which should almost always go to a third party. Security is another one. Don't write your own hashing algorithm unless you are 1) certifiably crazy and 2) have at least 3 excellent business reasons to do so.
But "What functionality should always be third-party?" None. There's always an exception.
-Adam
I fully agree that encryption should only be done by experts whenever possible. It should also be open source and have undergone a good deal of peer review.
It depends. Is there a 3rd party library available that suits your needs and most importantly, the language and/or API you work with. Then go for it.
If you have reasons to do your own version, make sure it's not just "not invented here". Also, if you haven't had an in depth look at the market's top five leading products for whatever you need, you haven't done your job thoroughly enough. There are good chances you will find what you are looking for, and even if you can't use it, you still learn something even from the library descriptions. At the minimum you will learn which features you would need and which you don't. If you also get the source code to one of the libraries, this should be your preferred choice over a competing library with no source code but possibly more features.
The area where I have consistently used third party controls was charting. It is a fairly common problem to have to chart some batch of data and the third party controls are mature and trustworthy.
I guess the answer depends upon the usage. If you are developing for profit, you would be likely to buy in components if the cost of using the component vs the cost of developing it results in more profit. This is particularly the case with large components when you do not have the in-house expertise to produce them.
A couple of good examples that I have used are the Infragistics controls and Dundas charts. Although we could have created these in-house, the costs in terms of time and lost opportunity would be huge compared to buying a couple of licenses.
Of course, sometimes we do this type of thing without even considering it as a component purchase. Streching the imagination a little, you could include the .NET framework, SQL Server, the Windows API, etc.
If you can buy it cheaper than you can build it, and the bought functionality meets your business requirements, then buy it.
There is not a definitive answer to this question because just like anything else in software development it depends on the situation. I would say that if the following 3 items are true than you shouldn't think about doing it yourself...
If it's not core to your business or expertise.
If someone else has written it for you and it is being used in widespread communities.
If it meets your needs and requirements or it can be extended to meet your requirements fairly easily.
This question is the inverse of the question: what software should you create?
Which is obviously silly.
For both there is no one answer, it depends on the needs of your business. Do you need to build a better search engine for the entire internet? Almost certainly not. But if you are Google in the late 90s, you do. 3rd vs. 1st party is just a matter of which office you work in, every 3rd party is a 1st party to themselves.
If all you need is good enough: use something off the shelf.
Either you'll create something lower quality or you'll waste money and effort on something that doesn't matter that much, or both.
If it's the foundation of your business: build it yourself.
If you can build something better, and you can build a business out of that better thing, then do!
Don't forget that the time is a big issue for writing all things by your hand, it is not that you cannot do that but the problem comes from your customers or company they always want to find the fastest way to build their system. But if you have a non-profit project you can try building things by yourself. For e.g you can use JQuery or Dojo as your ajax toolkit if you are writing web applications and you want to set some ajax functionality, it will take time to build those things by your hand :)
But you also must be careful when using a third-party libraries, you must trust them because they can contain malicious code, or they are very poorly written and can cause you headache.
Your own encryption function? dont even think about it but I think you probably meant some kind of wrapper for existing functions.
3rd party component advantages:
Alot of functionality
Fully tested (hopefully!)
Doesnt take time to develop so can be cheaper (but..)
Disadvantages
Is it really flexible enough for that next akward customer requirement
Distribution can be expensive
Ties you into 3rd party company which can be a pain when they make a new release to fix bugs
You dont learn to do the task yourself
Whether you use a third party component is going to depend on your application and the requirements. Something like graphing is going to take ages to get right so would be a good third party component to use.
Anything that is outside your core business is a good candidate for third party solutions. You want to spend your development time creating that core functionality that is unique(ish) and can not be purchased and used in a cost effective manor.
For example, lets look at web gridview control. Can you develop and extend a gridview yourself? Sure you can, but to develop, code, and test you grid view is going to take X amount of time and resources, which you can translate in to dollars. Now you have factor in reoccurring costs for support, maintenance, and bug fixes.
Now lets use the arbitrary amount I remember reading in some mag about the average US developer making $40 per hour including their benefits. There are whole web control suites available for around another approximated $800 per developer license. If your developer spends more than say 25 hours total on this one control, you could have purchased a whole suite and spent 5 hours integrating and testing.
Now hopefully I didn't get too confusing there, but the general gist is if you can buy it off the self it will probably save time and money, and instead focus on things you can't get off the self which are usually your money makers.
I'd say for writing boiler plate code, or redundant code which is copy and paste almost every time should be done through a library. For me, validation code almost always has me making stupid mistakes, because it's boring. Spring.NET is amazing for this. I'm so glad my boss encouraged me to try it.
seems you have all the answers you need, but i would just like to throw my opinion in here along with everyone else's. clients pay you to make applications that work specifically for them, and that's usually why they go to you; something they need isn't found in any other product on the market. thus, your focus should be on developing that specific part they need.
undoubtedly your application will need to do other things as well. maybe it will need to connect to a database, or encrypt certain lines. this is where third-party libraries come into play. you don't want to waste time writing a new driver for a database, or a new encryption scheme that might have holes you don't have time to test. you want to use the ones that already exist, and have been extensively tested and optimized.
remember, the faster you finish, the less they will have to pay. this makes them happy and want to come back to you. this also means you make more because even though they pay less, you can work on more projects, which means more money.
in conclusion, you should rely on third-party libraries in miscellaneous modules.