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 9 years ago.
Improve this question
Have any of you ever tried to run from sharepoint? I've worked with sharepoint enough to know that it is not something that interests me. My interests are more along the lines of APIs / backend / distributed development. Have any of you found ways, as consultants, to move away from sharepoint and keep learning other things of interest? I'm currently in a position where sharepoint is in huge demand and I can't quite find a way to simply step aside from it. any suggestions ?
If I infer correctly that you work for a consulting firm then find out what other kinds of things your firm works on. Learn those technologies better that the people who currently work on them for your firm, involve yourself in those projects, even if just in a hallway conversation manner, and come up with better (faster, cheaper) solutions for the problems your firm is solving.
Your options are really seem to be 3-fold
convince your boss your talents
would be better used elsewhere
convince your co-workers they want
you on those other teams
convince your company's clients that
they want you, specifically.
Learn Java, or Ruby.
The Microsoft sales model of "attach" whereby they sell a solution comprised of multiple technologies and then sell the next solution on the basis of "well you have already invested in SharePoint so you already have the skills in place and the infrastructure for this new bit of technology we have" is here to stay... it's very successful.
SharePoint is cloud computing for business who have MS shops... you avoid it by not doing C#. If you're doing C# then given enough time, your apps will need to run in the corporate cloud and you should be looking after your career by embracing it.
Just my 2p. Sorry if it's not quite the answer you wanted.
I know exactly what you mean. I think you don't mind the idea behind a product like SharePoint, but really hate the way its been implemented and how problematic it is. I know its a nightmare to work with.
As a C# developer, I cringe when I hear the SharePoint word, SharePoint is Lord Voldemort. But unfortunately it comes with the job of being a senior C# / Microsoft developer.
I say unfortunately because its likely if you're working in a corporate structure sooner or later you will end up having SharePoint in your solution. Not because its good, but because as others have said - MS use SharePoint as a Trojan horse to get and keep business.
There might be some hope with the new version of SharePoint coming out (2010). Maybe this will finally include a better programming / implementation model.
Otherwise either work for smaller companies (usually less pay, but not always), or try to play down your skills as a MOSS developer if possible. Never actively market them unless your salary depends on it. Remove the skill from your skill matrix, and turn down jobs that completely focus on MOSS. Some MOSS integration here and there you can live with. An entire solution focused on MOSS will drive you insane.
If all else fails, learn other non Microsoft languages, and within a year or 2, SharePoint will be but a faded memory.
I know lots of developers who are thinking about quitting IT because of SharePoint. I would say don't let it be the end of your career.
And finally bitch and moan, and inform managers on a weekly / daily basis, as to why you are battling in SharePoint. Let them know, and constantly remind them how bad a technology it is.
When life deals you lemons. Make Lemonade.
Seriously, if you are seeing SharePoint in such high demand, maybe working with the beast is the best idea. SharePoint is really just middle-ware. SharePoint can simply be a distribution point for your solutions (i.e., a user interface such as a web application can be hosted on SharePoint through a Web Content part). If you look at it, SharePoint may even prove useful as a document respository or small scale data store, in the form of lists.
Maybe you should turn down SharePoint contracts and accept contracts that interest you.
Depending on the market you are in you can simply tell your boss at the consulting company you work for that your not interested in doing Sharepoint projects anymore and that you'll be forced to look elsewhere if they continue putting you on Sharepoint projects. That would work around West Michigan where the developer demand is high and the supply is sub-par.
I'm, on the other hand, just starting to use SharePoint to enreach my currently boring C#-only projects. I'm starting to use it as a front-end to the distributed and complicated systems: simple configuration and customization, reporting, management, system control - looks like all this is available in this package it it's easy to make is usable by non-techies and by beginners.
I personally don't want to work with SharePoint anymore. I've worked on developing a solution for it and even went full charge with a web integration of it. I hated it.
First you have to master the awful programming model then handle all the deployments and it's not even the beginning. If you are developing a product for SharePoint, you have to debug the software itself which is a feat on it's own.
My solution to this is to be very upfront about it. I don't mind doing knowledge transfer and helping out people but I don't want to be developing/deploying SharePoint applications.
My boss get it, my friends get it.
Our latest joke come from someone who said a few months ago that it was "easy and fast to deploy application with SharePoint". The joke? "Did he just put easy/fast in the same sentence as SharePoint?"
So unless you salary would be lower because of it... downplay your skills on it and be upfront to your boss. :)
Have you ever looked at Alfresco (http://alfresco.com)?
It serves many of the same purposes as SharePoint, but does it from an Open Source J2EE application. It will leverage your existing collaboration / content management experience and expose you to a whole bunch of open source technologies.
Full disclosure: I work for Alfresco.
I've already given this suggestion to another guy...Running from SharePoint won't be difficult because technologies are similar to each other according to their structure. SharePoint is not the worst technology to be used, although it is limited in some way... Fortunately, software sphere is too wide to be afraid of not finding anything you can be interested in.
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
I am a Asp.Net developer, currently working on Webforms in 3.5. I do C# now, used to do VB.Net. I am also a middle tier developer (business layer and data layer) working on refactoring the current code base to use the Service-Repository pattern.
My boss asked me if I would like to start doing Sharepoint development (company is currently upgrading to 2010, so I would assume I would be doing 2010).
I have read on here that it takes a long time to get up to speed with Sharepoint development, and I don't want to be thrown into the fire while still learning and not knowing what I am doing.
Also, any good places to start learning? I told my boss I would look into it for about a week and get back to them.
Some good links:
Get Started on developing on
SharePoint 2010
SharePoint 2010 Advanced Developer
Training
SharePoint Hands on lab
SharePoint Developer Center
SharePoint Foundation Development in
Depth
Good luck to you
I'd recommend finding out what they anticipate the company's needs are and whether they anticipate that this will become your primary role. Ask about what projects they have in mind. (Of course they're going to say a small percentage, and no, you'll be expected to continue with your regular duties...)
It may be helpful to schedule a 'state of the union' meeting a couple months out to realistically assess how much of your life Sharepoint has taken over, and whether someone else should be brought in to help (or take over).
It certainly can't hurt to get another set of skills under your belt. Having the background that you do will certainly help you be competitive. If you don't like the work, there's nothing saying that you have to include it in future resumes...
Don't be scared to learn SharePoint. It may seem like a difficult task at first, but if you take it one step at a time you should be ok. In fact, SharePoint is just a (really big) asp.net web application, so all your existing skills come in handy.
Also the fact that MS finally put some good quality project templates for SharePoint development in Visual Studio 2010 makes the learning curve less steep.
There are also some good books available to get you started. If the company wants you to learn SharePoint, I suppose they would be happy to pay the bill for those. :-)
Yes, SharePoint development has a steam learning curve, but from what you already do, you're half way there.
The best place to start is here:
http://channel9.msdn.com/learn/courses/SharePoint2010Developer/
I agree with the answers above. Only thing I would add is, if you had to learn SharePoint, starting with the 2010 version such an advantage over 2007. Especially when you add in Visual Studio 2010...
Regarding where to start, can't hurt learning from the horse's mouth (i.e Microsoft's MSDN sites). Also, be sure to request that your company get you adequate hands-on developer training.
It might be helpful to know that SharePoint.SE is dedicated to only SharePoint questions. If you have a non-programming related SharePoint question, or even a programming one, that is a good site to use.
All,
At my current company, we are looking to replace all ASP.NET Applications and OLTP databases with Sharepoint 2007. Our applications and databases deal with 10,000+ rows, and we have 5,000 + clients actively using the system. Our Implementation of sharepoint would replace all n-tier applications.
Does anyone have an experience in implementing this? My current viewpoint is that Sharepoint is not built for or adequate enough to handle this type of application. Can it really replace application with hundreds of pages, and hundreds of tables? Support Data warehousing operations? Support high performance OLTP operations? Provide a robust development environment?
Any and all input is greatly appreciated. Thanks S.O. Community.
SharePoint can absolutely handle this this level of data and users. But I'd have serious concerns though about whether the people in the organization can adequately manage, develop, and use such an implementation. There are hundreds of wrong ways to do things in SharePoint, and very few "right" ways.
At the level of usage you're talking about, you're going to have to do some serious customization and development. You'll have to be careful that people don't get fooled into thinking it will work for them out-of-the-box.
SharePoint is a platform, like any other, it has strengths and weaknesses and can be made, through various levels of effort, to do anything you really want to with it.
Can SharePoint handle the load you ask about? Without a doubt. Can it support your data back end? Sure, either via the "SharePointy" mechanisms of the BDC/BCS, or though your own custom code.
The better question is what is to be gained from essentially re-developing all of your applications on a new platform, if anything?
Don't be swayed jump on the SharePoint ship because Microsoft is selling it as the new shiny. A thorough knowledge of ASP.Net is required for development in SharePoint, but having that alone doesn't allow for a rapid start-up in development.
https://stackoverflow.com/questions/256407/what-are-your-biggest-complaints-about-sharepoint
How good/bad is sharepoint programming?
Basically not a good idea to shift to sharepoint. Difficult to use. Steep learning curve. You would probably need sharepoint consultants.
update: Developing a website for 3 mln. users: SharePoint OR pure ASP.NET?
Sharepoint CMS vs UmbracoCMS
might be more relevant to you.
Also you may want to look at Running away from SharePoint (just kidding)
Thanks all for your answers!
After reading all of the feed back, it seems to fall in line with my research. Having said, here is what I gather from your responses:
SharePoint out of the box is a CMS.
SharePoint Lists do not replace relational tables.
Extending SharePoint to fill other uses is limited to custom development within the SharePoint framework.
From my research:
- Utilizing a relational database in a SharePoint application is done through custom code. Adhereing to point 3 above.
- Developing and building applications in SharePoint, with features that fall outside of the CMS domain , nullifies many sharePoint features and requires heavy custom development.
Again, thank you all for your feed back, this ihas invaluble to my research.
Here's some info on Sharepoint capacity planning: http://www.microsoft.com/resources/documentation/wss/2/all/adminguide/en-us/stsb07.mspx?mfr=true
It suggests that more than 2000 items per list would not work.
For posterity , and anyone else who stumbles here.
Further points:
- Most Developers do not have enough SharePoint Development Knowledge to properly implement a solution with SharePoint.
- ASP.NET Knowledge is required to develop SharePoint applications.
- SharePoint Maintains a step learning curve.
Are we saying that developing on a platform built on top of ASP.NET is harder to learn then ASP.NET it self?
Ouch man, I don't know if you want to head down this path; SharePoint has a pretty notorious learning curve, isn't something easy to bend and flex too much.
I have a client who has been using WebOffice (from WebEx) for a variety of tasks within their small organization. The problem is that they only really need a small subset of the features WebOffice provides (Contact list, Database, and Document Storage).
They've asked me to develop a website focused on these three features with the rationalization that this should be more cost-effective, since they currently aren't using many of the features of WebOffice they pay for.
What are some open-source alternatives that I could implement for them? Sharepoint sounds like it would be too bloated and Google Apps may not be as collaborative as they would like.
We looked at sharepoint and went like "meh". Anything interesting you want to do with it requires prohibitive licensing, and if you expose any piece of it to the internet then the cost just blows any budget away.
We are piloting a deployment of Alfresco, with KnowledgeTree also being a very decent option, IMO. As for the main site, something like OpenAtrium looks like a pretty decent and flexible fit without much configuration needed. OpenAtrium is based on Drupal.
SharePoint sounds like a good match? Did whoever told you it was bloated also mention why?
You might only need WSS which is free (if you have Windows Server).
My company hosts LumiPortal (www.lumiportal.com) which is similar to WebOffice but with drive letters for storage. If you have inhouse technical expertise, then on the open source side we see Joomla and Drupal, which could be thought of as classic content management systems. If you have in-house technical expertise, you might look at Drupal and their document management component first.
Call WebOffice customer service and tell them. They will probably adjust your payment options to suit your needs.
There's a good roundup of online collaboration/office suites here although it is a bit dated now.
http://www.readwriteweb.com/archives/web_office_2007_year_in_review.php
Webex WebOffice hasn't been updated in 5 years and has been sunset by Webex with no migration path (confirmed in their forums) so I would get off it ASAP.
With the addition of Wave to Google Apps it would seem to be a much more cost effective and modern replacement.
Is there a way of offering the flexibility of Excel/Access development that end users love while instilling centralised IT management so data and logic is secure, backed up, version controlled etc. The common options are to re-write in C#/ASP.Net/Java/Python/Your Choice, but that takes away control from the users. Is there a better way, and what do you do at your site?
There is a universal issue of users creating fantastically useful Excel/Access mini-apps that the IT department would like to bring under control. Users love the flexibility that Excel affords, especially on the fly changes, graphing and data import/export. In Access we have brilliant QBE. The downside is that after a short while there are legions of out of control spreadsheets/mdbs which are mission critical, with lots poorly understood business logic, and brittle code, they're a pain to support especially as staff move on.
This puts the IT dept in an awkward spot, they'd like to support these apps, but don't know enough about them. This is made more difficult as they are typically insecure with zero documentation.
Having been of both sides of the fence I would go after the root cause of the problem. Why do uses make their own little apps? Because it is too hard/expensive/time consuming/never turns out right when they go through the “proper” channels.
The other thing is they tend to know the business very well so whilst their coding might not be very good their knowledge of what needs doing is very good.
So what can we do to combat this problem? I personally think their should be a small team of people within IT whose job (or one of their jobs) is to develop these small applications. They should work very closely with the end users and not be locked in the ivory tower of IT.
In my current role I’m on the non-IT side of the fence, I have a few quite major applications that needed to be developed so I asked for an install of visual studio and some space on an SQL server. I had my request denied. So I just asked for SQL server space, again request denied (each request taking about a week to go through) So in the end I’m “stuck” in access.
Now these are very nice access apps with version control, comments in the (shock!) and all the other nice things but at the end of the day I was trying to do things the “right” way and ended up being forced down the access route. So when my apps try to get scaled up and I’m quoting a long time for a rewrite who is to blame?
Have you considered looking at SharePoint for department-level applications? Many professional developers will balk at the idea of using Sharepoint for "application development," but it truthfully can be a great way for "power users" to start putting their data and tools in a managed framework.
With SharePoint, you can manage the overall structure of the site and then set up users with elevated permissions within their respective departments. There are some great 3rd-party tools to help with keeping an eye on what's going on in your SharePoint site.
SharePoint is not a silver bullet by any means, but it is great for many multi-user applicatinos that need to keep up with a list of data.
(The following is not really related to my above answer, but your question really hit home and I thought I'd share my similar experiences and insights.)
Our company will be going through a similar process in the near future. I'm on the "end user" side of things and can sympathize with a lot of what Kevin Ross said. Sometimes Access and Excel are simply the best tools available for me to get the job done.
Here's an example: I was asked several years ago to come up with a system for creating Purchase Orders to a vendor in China for product for which there is a 3 month lead time. Our ERP software had a few features for procurement, but nothing that even came close to the complexity of the situation we were facing. Years later, after going through several iterations of the application in Excel (VLOOKUP was a lifesaver), Access ("So that is why people using relational databases. Awesome!), and back in Excel ("let's not make this so complicated"), I still find that these Micorosft Office apps are the best tools to get the job done.
What's the cost to not use these tools to get the job done?
Contract work to our ERP vendor to add a special feature for this ordering process: are you kidding me? We'd likely pay tens of thousands of dollars for an unflexible monolithic application with horrendous user experience...and we would still end up back in Excel.
Buy third party software designed for this exact process: I've seen an on-site demo of software that does exactly what I want for our procurement process. It starts at $100,000. There are probably other tools that we can get for a few thousand dollars, but at that price point, I've already emulated most of their features in my own application.
Try to finish the job "by hand." : Ha! I'm a programmer at heart, which means I'm lazy. If it takes a solid week of sitting at a desk to work up a purchase order (it actually did take this long), you can bet I'm going to work up a solution so that it only takes me a few hours (and now it does). Perhaps the guy after me will go back to doing most of it by hand, but I'll use the tools in my toolbox to save myself time and stress.
It's so hard to find the perfect application to allow for maximum creativity on the user end but still allow IT to "manage" it. Once you think you've found a solution for one thing, you realize it doesn't do something else. Can I write I printable report in this solution like I used to do in Access? Can I write complicated Excel formulas that tie multiple data sources together from different sheets ("You want me to learn what? No, I've never heard of a "SQuirreL query" before. VLOOKUP is just fine thankyouvermuch)? Can I e-mail the results to the people in my department? Can it automatically pull data from our back-end database like I do in Excel and Access? Can I write my own code, VBA or otherwise, to make my job easier? The list goes on.
In the end, the best advice I can give to any IT manager in your situation is to respect the other workers at your company. Let them know their work is important (even if it's only useful to them and the guy at the next desk over). Let them know you are not trying to make their job harder. Don't assume they are morons for creating mission-critical applications in office productivity software; they are just trying to get the job done with the tools at hand and are usually quite capable and intelligent people. Invite them to explore different solutions with you instead of just removing the tools they currently have in their toolbox and then replacing them with ones they don't know how to use.
At the end of the day, if you have users who are smart enough to shoot themselves in the foot by creating complicated apps in Excel and Access, they are probably smart enough to learn to use the appropriate tools to accomplish the same tasks. Invest the time and energy to involve them in the process and you will have a solution that works for everyone at the end.
You could try a hybrid approach: Allow your users to use Excel/Access to home-brew their own, specialized tools, but take the mission-critical stuff and put it under IT control. There are a few strategies that could help you with this:
Make sure that your IT department is firm on VBA. Not the "yeah-everybody-can-write-a-few-lines-of-basic" type of knowledge, but in-depth training, just like you would if it were a less simple programming language. Although "real programmers" will tell you otherwise, it is possible to write large, stable applications in VBA.
If you currently have the data in Access databases, move away from that and migrate it to an SQL Server. This allows you to do centralized backup and management, while still giving your power users the flexibility to "link" these SQL Server tables to their Access frontend.
Commonly used business logic should be under control of your IT department. This can be done either with VBA, by creating an Access library that is linked by your users, or in any of the .net languages, using COM interop. The latter sounds more complicated than it is, and it will increase the satisfaction of your IT department, since developing in .net is just much more rewarding than VBA (version control possible, etc.).
I would second one of Kevin Ross's main points:
I personally think their should be a
small team of people within IT whose
job (or one of their jobs) is to
develop these small applications. They
should work very closely with the end
users and not be locked in the ivory
tower of IT.
I think any IT department that has a lot of users using Access/Excel should have at least one properly trained and experienced specialist in developing apps on those platforms. That person would be the go-between to make sure that:
IT's priorities and policies get properly implemented in the home-grown apps.
the end users get expert help in converting their home-grown efforts into something more stable and well-designed.
I would second Tony's point that whoever works with the end users in revising these apps to meet IT standards should work side-by-side with the users. The Access/Excel specialist should be an advocate for the end users, but also for the IT policies that have to be followed.
I also think that an IT department could have a specialist or two on staff, but should also have a full-time professional Access and/or Excel developer as a consultant, since the on-staff people could probably handle day-to-day issues and management of the apps, while the professional consultant could be called in for planning and architecture and for the implementation of more complex feature sets.
But all of that would depend on the size of the organization and the number of apps involved. I don't know that it would be desirable to have someone on salary who is nothing but an Access/Excel specialist, precisely because of the problem you get with all salaried employees compared to consultants -- the employees don't see as wide a variety of situations as an active consultant with the same specialization is likely to see and thus the consultant is going to have broader experience.
Of course, I recognize that many companies do not like to outsource anything, or not something that important. I think that's unwise, but then again, I'm the person that gets hired by the people who decide to do it!
If it's mission critical, and it's in Access or Excel, is built poorly, and no one understands it, it is probably time to rebuild it properly.
When the 'users' are in control it usual means one particular person is in control of the architecture, design, coding and documentation... except they normally omit the documentation step. Source control and bug reporting, the touchstone of software development, is usually absent. Few instances of code reuse, due to the nature of Office apps (code modules usually embedded into documents) and VBA (little OOP, most VBA coders don't use Implements, etc). All this means that the resulting applications are not subject to get proper scrutiny and quality can suffer, meaning there are likely to be maintenace issues, escpecially when that one user leaves. I know because I used to be that person ;)
So in order to satisfy the IT department, the proper process needs to be applied. That one 'power' user can continue to own the design and coding but will get peer review, perhaps the serivces of a technical author and a dedicated tester, be required to use source control, perhaps consider integrating with enterprise systems, etc.
There is no getting around the use of Excel/Access. It's what's available, and still very powerful and flexible. The best thing to do is offer some guidelines as to how files should look and be set up. If everyone is using similar standards then the files will live longer and more productive lives, beyond the creator's tenure at the company.
You've got some excellent answers regarding dealing with the folks and the business side of things. So my response will be more technical.
If you are going to redesign the app have the developers work in the same offices as the users. Given the users updates every day or two. If the users have any minor suggestions give those to the users within a day or two. Ultra Frequent Application Deployment
Give the power users an Access MDB/ACCDB linked to the tables with a bunch of starter queries. Let them create the queries they need to export the data to Excel for their own purposes and distribution to clients.
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 5 years ago.
Improve this question
Right now, our teams are using a combination of a bulletin board and an excel spreadsheet to keep track of tasks and to draw a burndown chart. Backlogs are keep on index cards in envelopes.
This works well when the stakeholders are in the same location. However, we will soon have Scrum teams in two geographically distant locations and I am looking for best practices on how we can leverage Sharepoint to help us communicate around Scrum artifacts (backlog, burndown chart, velocity, etc.).
How did you leverage Sharepoint for that purpose, what are the best practices and the potential pitfalls?
We actually use Sharepoint for our Agile development and have found it works pretty well for project management/collaboration.
There are 2 things we do which I found particularly useful, metrics tracking and automated testing. We use the document library and infopath to add all of our stories for the project to the site. The infopath form should contain all the information you need for a story: points, estimated time, developer, tester, story tasks, test cases.
For metrics, we create web parts for: burn down charts, velocity, points per iteration, etc.
This is especially nice for Managers or customers to see that progress being made on the project and will help them make decisions regarding features vs. release time.
For testing we have a simple SEND-RECV-ASSERT language which runs the tests nightly by scraping the XML for automated tests. The we have a little Green/Red webpart on the main page which tells you the stat of the tests.
This can be done pretty simply with some XML parsing since the backend of the document library is XML. (We currently use some simple ActiveX and javascript)
The metrics are pretty easy to set up (just some xml parsing and html charting). The automated testing takes some time to set up a test runner, but once its in place, and easy enough, you can even have customers/managers write acceptance tests! Agile! :)
If you have SharePoint in house already,along with a user base that is comfortable using it I think it would be fairly easy to get started with using it for SCRUM. I would start with the following:
A site collection to hold 1 scrum site per project
A scrum site should contain:
Document library for the electronic files (add columns for categorization as appropriate)
List of team members
Discussion board
The site can be built from a Wiki site template if its necessary.
Once you get the scrum site "feeling right" save it as a template so its easy to spin up a new one.
This solution may not be designed for SCRUM to the nth degree, but it should be enough to get you started. It seems a lot easier than having the entire team learn a new tool when it sounds like you are undergoing some other pretty radical changes.
my $0.02
jt
You really should consider something like Trello, VersionOne, Rally, or even Basecamp for this. They all have hosted solutions and offer free community versions that you can try out to get started. My experience with SharePoint is that it takes a lot of resources to maintain. If you were using Team System and had a lot of the stuff pre-built for you, that might be different -- although I have Team System and still choose to use a Wiki for my project management tasks. If you already have an investment in SharePoint as an intranet and all of the support staff, then it might be a viable solution in that case, too.
SharePoint is not the tool I would think of first for agile development. YMMV.
You need to try and keep the tool from getting in the way of working. In an ideal world the team will all be sat in a single room with big white boards, however often this is not the case and teams are distributed, or theres a push for some form of backup for the post-its.
I'm a big SharePoint fan and where you have this in house already, your already doing collaboration and team work on the platform. Adding another tool, with unique login's can work but the team need to really want to use them.
I've tried getting SharePoint out of the box to do what I wanted but it fell short. I've tried using Version One (on a number of occasions over many years, with many teams) but I find the tool is too much, there are too many otpions and things that need to be done that it gets in the way - it is a long way from the Whiteboard.
So I decided to develop what I needed for my projects. I needed a simple tool, and using the 37signals (creators of basecamp) approach I needed something with less features than the competition.
21Scrum is a simple scrum tool built on SharePoint that uses the platform, add the things that you need (white board, burndown charts) and leave you to get on with the project.
Perhaps this may be the best option for people who already have and use SharePoint - at least thats the goal.
We've setup a SharePoint workspace with lists for Release/Sprint planning, Product Backlog and Sprint Backlog.
Central element is this Task Board for SharePoint - we can drag & drop stories and tasks - even if we are not at the same location.
http://www.youtube.com/watch?v=XW89M0C3N7Q
A burndown report visualises the progress automatically.
Works great!
AFAIK, Sharepoint is ASP.net with free goodies. It is not designed for agile project management.. so you'd have to roll your own site.
IMHO instead of trying to bend the job to the tool you have.. switching to a better tool for the job would be a better option. Check this thread out to see if there is something more lightweight that fits your bill.
Also personally I'm a big fan of not digitizing the development activities.. So I'd use a spreadsheet for the backlog and post its and Big Visible charts. Use a digicam to persist diagram/design discussion snapshots (google whiteboard photo for tools) or for reports. I find that most of the "project management" tools are just excuses for generating instant status updates.. it gets in the way of software development (which is the main goal) and inhibits social interaction way too often.
(disclaimer: absolutely 0 experience with sharepoint.. except what I've read in the last 2 days so may be totally off track)