|
Thanx for the response. I haven't much luck here - but I could try again.
Know way too many languages... master of none!
|
|
|
|
|
Everytime I INVEST time and energy into a Microsoft Product, they discontinue it just as I'm mastering it.
I'm mastering Windows API. (I try to do so every day since 1996). And that's not outdated.
Nuclear launch detected
|
|
|
|
|
xacc.ideIronScheme - 1.0 beta 3 - out now! ((lambda (x) `((lambda (x) ,x) ',x)) '`((lambda (x) ,x) ',x))
|
|
|
|
|
I don't understand why have you received several 1 votes for saying that you don't have a plan to use it?! What are they trying to tell? Like.. You *must* use it? So, let me repeat: "I am never planning to use SharePoint".
You cannot just convey your opinion without these idiots graying your post? Some people are just completely screwed up.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
Rajesh R Subramanian wrote: You cannot just convey your opinion without these idiots graying your post?
I haven't voted, but IMHO he did not express any opinions in his post - he merely made his vote public.
|
|
|
|
|
Nemanja Trifunovic wrote: I haven't voted, but IMHO he did not express any opinions in his post - he merely made his vote public.
And how does that justify the ACs acting like children?
|
|
|
|
|
I like the concept of it and seeing it is a 'product' it is not bad at all however:
- in order to use it well, you need customizations and a very good setup. (it's still missing features.)
- you need to have designated people maintaining it.
- it's not always that fast.
|
|
|
|
|
I agree with your comment about Sharepoint.
Know way to many languages... master of none!
|
|
|
|
|
V. wrote: Stop smoking so you can: Enjoy longer the money you save.
How do you enjoy money that you save. If you enjoy your money then you need to be spending it. Unless you save your money in a hole in your mattress then you might enjoy it in another way .
Vita est usquequaque virtus victus ut plenus. Ego non sum semper iustus tamen Ego sum nunquam nefas!
|
|
|
|
|
We built a significant SharePoint (WSS 2.0) Portal Server for a customer project about 4 years ago. The customer never bought, so we started using it internally.
While all of the criticisms of SharePoint I've read seem to have elements of accuracy, in our organization, several hundred engineers have come to rely on it for daily functions.
With very little customization we're using it effectively to support Scrum for software development, ITIL Incident and Problem management and general collaboration.
In our Scrum use we've created three custom templates (one for the Product Team Site, one for the Sprint, and one for Customer meetings).
Does it do everything we want? No. But applying a Lean Six Sigma Pareto analysis to common collaboration problems, we solved a good 80% of our needs in about 2 hours of template work just using the GUI.
We have done some work on custom web parts and I have found that to be functional object model, but then my idea of "bad programming environment" is Clipper, on a Z-184, in a tent in a Shamal in Saudi Arabia.
All in all, we find it useful, and will continue to extend and expand our use.
|
|
|
|
|
I'd be very interested in finding out how you use sharepoint for scrum.
Is it a certain template? Where can you find it? Did you do custom dev on it in order to get it to work?
Do you need a certain version of sharepoint?
Any information on this would be great.
Many thanks.
|
|
|
|
|
We used SharePoint 2003 because that was the install available.
We made three custom templates using the SharePoint GUI, no custom programming.
We created Product Site template based on a Team Site. This contains Product persistent artificats, the Product Backlog, the Failure Mode Effects Analysis (FMEA, its an LSS tool) and some other things that are Product centric.
We created a Sprint Template based on a Meeting Workspace. This is where we put the Sprint Backlog and the artificat the Team uses for Scrum working inside a Sprint. We have lists for Since Last, Before Next, Obstacles and Burn Down that get updated at each Scrum (we have distributed Scrum teams, so this is really, really helpful). Other lists include Sprint Tasks (things that need to happen to deliver the Sprint Features), Sprint Events (planning meetings for key dates), Sprint Documents (non code things, all code goes in TFS), and Lessons Learned (we're pretty serious about continuous learning, so each Sprint has a Lessons Learned activity that is deliberate and recorded).
We created a "Gap Week" site which we use between Sprints as Product Training \ Sprint Planning support. We aren't able to devote a team to a product for more than one or two Sprints, so we've adapted the Gap Week to transition new Team members based on the expected skill sets we need, availability and the relative priority of any Product compared to all our other Products. The Gap Week allows us to train the new Team Members, review the Product Backlog, and catch up on required training or do specific technical training for the upcoming sprint. (The Gap Week started out at 5 work days, but we're looking at cutting it down to 3 in order to go faster. We think we can do this because we've done a lot of Product Domain training and now most people are familiar with most of the Products in our space.)
We created a custom webpart (programming task here) that rolls up lists from sites for consolidated views. The one we have is pretty basic and we'll probably going to Sprint our custom webparts Product later this year to make some updates.
|
|
|
|
|
Many thanks for the reply.
It might be very helpful for us too
|
|
|
|
|
I love the bit about the Tent Here Here - Clipper This LOL! (I would not like that environment either) Yeah, I will say, whether I like the current "paradigm" or not - Microsoft does have a functional object model.
My biggest peeve I keep writing about however is this: If they kept one model (its abstracted right? So underlying "guts" shouldn't matter) and didn't keep reengineering the entire model each generation - it'd be much more attractive. Case and point: MSCRM 2, 3 then 4... Unnecessary "retiring" of functional objects whose inards could have been changed without changing the working model. So... Customers who invested time and money in version 3 had to rewrite a ton of stuff to make it work the same way in version four (less simple gui customizations).
--Jason
Know way too many languages... master of none!
|
|
|
|