I am using Team Foundation Server to track my projects and tasks (I'm using the MSF for CMMI process template), so in Visual Studio 2013 I can start a task, but I have not found a way to track the time spent on the task; the fields Remaining work and Completed work stay empty.
I found the tool tfsworkingon that does this function, and other tools for TFS, but I was searching for a way to do this natively within Visual Studio. Does anyone know if VS2013 has this behavior natively and how I can use this?
https://tfsworkingon.codeplex.com/documentation
Don't think there is anything out of the box in Tfs that allows you to automatically tracked time.
I worked in a project where we used the Pomodoro technique to track time spent. The entire team used Pomorodo sequences of 20 minutes and we added a custom field for capture the number of Pomodoro sequences for each task - both actual and estimated.
The tool we used to track time was Pomodairo, which was outside our development environment. I see that there is a Visual Studio extension available as well but I haven't used it personally.
If you are searching for a tool to track your efforts in Visual Studio/TFS, maybe you want to take a look at http://www.tfs-timetracker.com. We have developed this tool for tracking directly on TFS workitems, fully integrated into Team Foundation Server. Based on the idea to help developers learn about their speed and where their time is really going, we focus on tracking. So you have for instance a client that is acting like a stopwatch, you can start/stop while you work (amongst other ways to track). Maybe this helps.
Sort answer: No TFS and Visual Studio don't offer a native way to keep track of your time for you.
Long answer:
Remaining work and Completed work are both to be filled by the team members working on the item. Remaining work is an estimate of the currently remaining time (and it can go up if you've found more work to be done), completed work is the amount of time spent so far.
Since Visual Studio doesn't know what you do all the time, you could be reading email, checking facebook, having a chat at the coffee machine, etc it won't track the Completed work for you. Since Visual Studio can't predict the future it can't re-estimate the Remaining work either.
The general guidance is to not use TFS for time tracking. It can be used to track some aspects of time, but these features doesn't handle good coding practices like pair programming without creating way to many duplicate tasks. It also re-enforces the idea of individual ownership over collective ownership and assumes that we can predict teh future accurately when we assign the Remaining Work value.
If you need to track your time spent, the advice is to track it at a higher level (Requirement or Change Request for CMMI or even better, at the Feature level).
3rd party plugins for TFS offer time tracking features including start/stop timer options.
Related
I wonder if this question really fall in the topic of this site and feel free to tell me if it doesn't. But anyway, here's the situation : I'm currently in college and when I'm at school, I program on my lap top, and when I'm at home, I'd like to programm on my desktop. I was wondering, what is the best way to carry my projects over from one PC to another? I currently use Visual Studio 2015.
I tought of one solution, set my VS Workspace in my Google Drive so everytime I save a project, it's carried over.
But do you guys have a better solution? Thanks for your responses! :)
I also don't know whether this question belongs to SO. Anyway, I will try to answer your question.
In situation where you program in groups, a source code management system (version control) is absolutely necessary to synchronize code and avoid conflicts. A very popular one is Git which is used in many various projects in different programming languages. For other version control systems, look at the bottom of the wiki article.
It would be too much to explain Git (or version control in general) in this answer, but the general work flow is always the same: There is a server somewhere, an when you start coding you 'check out' your project, which means you copy the most recent updates to your local machine. When you are done, you commit the changes to the server. If you want to work on another computer, you just check your project out again. When finished, commit again.
That is a really useful feature, there are many IDEs that can provide it but I can't find any extension which can provide Local History.
By Local History I mean something that tracks any changes and edits that I make on the source code so I can be able to recover it in future.
There is a separate extension that provides local history functionality:
http://visualstudiogallery.msdn.microsoft.com/226c2108-9da9-407d-b90d-9783040d27b8
I think the local history feature complements version control.
What you are describing is a source code control system. Visual Studio does not provide this by default as its primary job is that of an editor. It does support a number of source code control plugins, many for free, which will do this for you.
For example there is a free Git plugin that is now officially provided by Microsoft.
http://visualstudiogallery.msdn.microsoft.com/abafc7d6-dcaa-40f4-8a5e-d6724bdb980c
This can be used with a number of free Git providers
CodePlex
GitHub
Visual Studio Hosting
There is an option to have best of both worlds:
autogit - Visual Studio extension
Here are some counter reasons why local history is different then source code repository:
Some simple reasons:
simple insurance against accidental changes or deletions.
makes it easier to support smarter undo, backtracking, or exploratory programming.
resume a task or track a task by seeing changes at a fine-grain level as they happened.
light-weight, stays invisible until you need it.
Some deeper reasons:
Better Task Resumption: research suggests that resuming an interrupted task or reviewing a change made by another is made easier when changes can be reviewed in an time-ordered manner (in comparision to a flat commit).
Auto-blog: automark is a sister project that can examine a git repository and then automatically generate a markdown file, in a format suitable for publishing a blog post.
Personal Analytics: Watts Humphrey has advocated the idea of tracking personal activity for self-improvement, using methods such as the Personal Software Process. Using services, such as codealike or codeivate, you can track things like time spent editing, etc. Tracking the actual changes can take this analysis to another level.
Api Analytics: Frequent mistakes are made when programming or using particular apis. This can be analyzed: "You spent 3 hours figuring out how to correctly use pygit2.create_commit(), create github issue?"
There's also the Auto History Extension: https://visualstudiogallery.msdn.microsoft.com/dfcb2438-180c-4f8a-983b-62d89e141fe3
It's like the one Juha Palomäki linked to, except has more downloads, reviews, and a slightly higher average-review. (haven't tried either myself yet, though plan to in a day or two)
I have a development team specialized in ASP.NET. So the solutions we provide are web based, running on IIS and using MS SQL server. Everything within the intranet of the company. The team has this expertise, and they are excellent in C#, and .Net in general.
The company is deploying SharePoint MOSS 2007. This deployment is part of a project that I am not involved in, and for which I have very little information. However I know that they have established the "thinkers" layer (those who will say what to do), the integrations layer (the who will configure, deploy and manage the production), and that they need to establish the so called development layer (those who will do things the other two can't).
I am asked to evaluate the possibility to increase my team's expertise by adding SharePoint development. This is the easy part, I just have to find the required training and send my people.
However these days the word development could mean a lot of things and sometimes I discover that configuration is used in place of development.
I don't have any objections to evolve the team by developing new expertise, but I want to be sure to keep things stimulating for my developers.
Secondly I don't want to say that we have SharePoint development expertise, and actually what we do is just modifying css or xml files. Also, I don't think that using wizards to produce a solution is the best path to push a C# developer to follow.
The questions I am asking myself first is : what is the background of a SharePoint developer? how could .Net developers feel if asked to become SharePoint developers?
Any thoughts will be greatly appreciated.
I started in Sharepoint development over a year ago when I inherited a WSS 3.0 solution at my company.
Personally I think it was a great step for me getting to know Sharepoint development a little, there are a lot of problems (e.g. security, load – balance, ghosting) that was good to see how was solved by the WSS team and helps me solve problems in other solutions I‘m working on. But I don‘t work on WSS solutions full time, so others have to anwer how it is working with WSS every day.
WSS and Sharepoint are an extension on the ASP.NET platform, so any experience in ASP.NET and .NET in general should be a good foundation for a developer that is starting creating Sharepoint solutions. I read the Inside Microsoft Windows Sharepoint Services 3.0 book in order to get the basic concepts and wss solution architecuture before I started working on WSS projects.
I quickly found out that you have to have a Virtual Machine environment for Sharepoint development, this is because it‘s a pain working on a client and attaching to a remote process on the server to get in debug mode. Therefore I recommend creating a MOSS virtual machine that has Visual Studio installed that has access to your source control system. Develop solutions on that machine and when finished then check into source control.
I also recommend looking at development tools, such as stsdev and wspbuilder to help you building your solution, these will ease you development process quite a bit. There are also quite a lot of tools available on the web, e.g. codeplex to help you out.
Sometimes it can be a pain developing these solutions, changes can require recycling the IIS pool or a brute-force IISReset, error messages can sometimes by a little cryptic and so on. But you quickly catch on and know where to look. Sharepoint also helps you out a lot, I‘ve had millions of questions from clients that can be solved with standard out-of the box web parts, so that I don‘t have to code anhything to keep my clients happy :)
Sharepoint also expects solutions to be coded in certain way, e.g. 12 hive filestructure so it helps you standardizing your solutions.
There is a serious lack of documentation, so that you have to rely on Reflector and such tools a lot, just to know what is happening within the framework, hopefully this gets better with 2010.
The initial learning curve is high, and a lot of new concepts an technologies to learn ,e.g. Workflows within sharepoint, featuers, ghosting and code access security
There is a lot of Xml configuration that sharepoint uses that developers have to learn, this includes the site definition, list templates and more. There are sometimes days when I‘m stuck in Xml edit mode and can‘t figure out why things don‘t work as they should do
These are just few of my thought, I‘ve been working mainly in WSS development and it would be great if someone could comment regarding web part configuration in Sharepoint, e.g. configuring the search. Which is something I haven‘t been doing a lot of.
From what I have heard around, the SharePoint is a popular technology from the customer point of view, but an object of hatred among developers.
Nice to see you noted Dev and Admin being used "incorrectly".
Although Developing for SharePoint could be purely that, development, like creating webparts etc., I strongly encourage you and your team to get to grips with SharePoint deployment, installation and configuration as well. I am fully SharePoint Certified (WSS Config/Dev and MOSS Config/Dev) and having knowledge of both ends has been invaluable for me.
Knowing what is configured where will help in debugging and troubleshooting along the way. I suggest taking an MCTS WSS 3.0 COnfiguration training / and or a MOSS Config training for at least 1 or 2 of your team. The rest of the team will pick up the essentials as they go along, having those 2 certified colleagues as go to guys concerning config and admin.
IMHO, being a sharepoint consultant entails knowing how to create a piece of functionality as a dev and then being able to deploy, configure and maintain that piece of functionality as an admin (or at least an informed end/power user).
Albert, take a look at this other thread titled Is a sharepoint developer technically “equipped” to do custom app dev and vise-versa. There's quite a bit of info in there about what's involved in making the leap from pure .NET to SharePoint.
My co-worker is studying SharePoint at the moment. Making fun of him all the time. Frequently he gabbles something like "wtf is that??!!". And then i feel a bit sad, because i know - there's a probability that i'll have to learn that stuff too (i guess it's not so easy to get projects nowadays).
I see it more as configuration and customization than software development (something like hunting down fing checkbox for 3 days in a row). You pick up some clay through those crazy sharepoint designers and then endlessly customize it.
For everything i know already - there's a new name (i.e. - spGridView) and unexpected behavior underneath.
Html that gets rendered is bizzare (tables and bunch of serialized viewstate everywhere).
But those configuration xml`s... o_0
Now that's a hurdle i can't get over. Even hardcore SQL stuff starts to seem like a childish game.
Maybe i'm wrong, but as i have heard - Microsoft developed 'spatial columns' (let's you expand count of columns for tables over thousandsomething) for sql mainly because of Sharepoint. That terrifies me.
Of course - my opinion is HIGHLY subjective and a bit offensive. But i hope that helps to better reveal what i think & feel about Sharepoint.
Hopefully developers you are working with sees this different.
In short:
No. I wouldn't like to become a sharepoint developer.
Edit:
I could handle that initial complexity. But the main reason i don't want to - i don't think that development in Sharepoint is the right way to go. I mean - lately people discuss that webforms provides too much abstraction. Then what to say about Sharepoint?
To be a successful SharePoint developer you must have a high threshold for pain and the patience of a Buddha.
thank you all for the answers, they are all really helpful.
from what I read here, I see two things to consider.
First is the context of utilization which I think is an important factor. In some places SharePoint "development" could go very far, and could involve developing really exciting things, in order to satisfy new customers' needs. it could involve writing code and so on. And in some other places it could be just administration and configuration, in order to maintain already established solutions.
Secondly is the personal motivation. It really depends on the person. Some .Net developers with good experience, will prefer not to go in a direction, where they will not code the "SharePoint way", and will like to write code in C# or some other languages. However there will be others that will choose this path and will be happy to have such careers. They will be motivated and thus propose really nice solutions.
For example, from my personal perspective and if I had stayed in development and programming, I would not choose SharePoint development using high level wizards and menus,as a progress path for my career. Even though I am not doing it these days, I still enjoy coding, compiling, debugging etc, but this is just me.
Our project is currently developed in C#2 , VS2005.
We were thinking of migrating to VS2008 and C#3.
Do you think it might be a better idea to move directly to VS2010 instead?
We do not plan to release the new version till the end of next year.
Is there any advantage in moving from vs05 to vs08 and then moving to vs10?
thanks!
Well this post implies you can, but certain features of certain projects might get broken:
When you upgrade certain solutions from VS2005 to VS2010, the solution explorer layout can become broken. Some files move up the filter hierarchy. In our large solution, a hundred or so files ended up in the root of solution explorer.
It only seems to affect solutions where the solution explorer filter nesting is more than one deep, the files are not compiled (like headers), and they're excluded from the build in some configs.
Though an answer indicates it was fixed:
We have verified that the header file now gets placed under subfolder rather than directly the header filter. The fix should be available in the next public release of VS2010 (Beta2).
To answer your other point. One advantage of going via VS 2008 is that you can make that migration now (assuming you don't want to risk beta software) and start using the features of C# 3 straight away.
Visual Studio 2010 Beta 2 comes with a "Go-Live" license, so if you are ok dealing with beta software, then why not? I have tried it at work myself, while the other developers continue on 2008, but I have to be careful with the project files, to not check in changes, etc.... I don't use it all the time, yet, because it's a memory hog, but other than that performance is a lot better.
There are also a lot of features that are worth the upgrade. The text editor is in WPF now and scales nicely with a ctrl-click and I find I use it a lot. There are a lot of new addins being built to integrate with the UI because the new framework for the code editor exposes a new addin model that is much easier to develop against.
Being able to split windows across multiple montiors in a more flexible way is great.
If you go for the "Ultimate" versions, there are a ton of new architecture and modeling tools and tools for exploring code. I love the ability to generate a sequence diagram from some method and use that while I am reading some unfamiliar code. Works great.
The list goes on really, I have barely scratched the surface, so yeah move on if you want to learn how to use the new stuff, and no one is stopping you, go for it.
I work for a very small company (~5 employees, 2.5 coders). We have gotten away with no code or document management for several years, but it's starting to catch up with us as we grow a bit.
Any suggestions for a management system. Free is better, but cheap is acceptable. We just don't want to spend more time on installation/configuration than it is going to save us.
We use mostly VC++ 6, but we're branching into VC# 2008. Also, we need to keep track of mechanical drawings and circuit diagrams for several pieces of hardware, as well as user manuals for both hardware and software (but I don't really expect to find one tool that will do all of this, just hoping).
Subversion (SVN) is an excellent option for you. It's free, integrates nicely into Windows with TortoiseSVN, and is well-tolerated by users.
We are using it for source code, as well as for document management.
http://trac.edgewall.org/ - might be a bit hard to install but otherwise is very good if coupled with svn repository
Mantis is good for issue tracking. Subversion for source control. Both are free.
For documents, I do not know. Sounds like you would do fine with a network share.
You may want to look at Trac.
I work for a similar sized company, and when I got here I was in the same place as you. I implemented SVN/Subversion http://subversion.tigris.org/ quite easily. If you use the svn protocol and use svnserve (can be setup as a windows service that auto starts on your server) it should take you 1.5-3 hours to setup depending on how much you want to read http://svnbook.red-bean.com/, see collabnet http://www.collab.net/downloads/subversion/ for the Windows package download
Using Windows, you can use Tortoise SVN which integrates into the windows shell. There is also a new release of Ankh SVN (2.0) http://ankhsvn.open.collab.net/ that integrates into Visual Studio. Ankh is very nice (has pending changes window, kind of similar to Subclipse like functionality) but it is a new release and is somewhat buggy (we have experienced some memory probs and slowness). We currently use both Tortoise for initial checkouts or imports and Ankh for everything else and are pretty happy.
If you have any Mac users, there are a lot of options out there. We have a mac user here who uses Versions http://www.versionsapp.com/, though it sounds like they will charge for it once they get out of beta.
I would recommend SVN because it is widely used out there and I feel that is important with open source projects you are going to use daily for production purposes. Just to spell it out, everything (other than Versions) mentioned is free.
Perforce!
It's extremely fast compared to most other source control systems. It works great remotely. (SSH tunnels, in my case)
The VS plugins are quite decent... I haven't tried the Eclipse one that much yet.
If you can get by with two users with 5 workspaces each, then you can use it for free. (I do, currently)
If that won't work, then it does cost a bit... something like $800/user I believe. Sometime next year I'm probably paying that. (5 workspaces is tough when you work on several machines with VMs)
Still, I heard the slower-than-glacial ClearCase/ClearQuest system one client one mine is using was something like $10k per developer, so expensive where source control is concerned is a relative concept.
Don't skimp on the source control, man! Slow source control is a serious pain in the a$$.
Avoid SourceSafe-like systems that only version files... use systems that track tasks or change sets. It's very useful to see what all belongs together as a task. Tags are not an acceptable substitute.
Also, the journalling nature of Perforce makes backups and recovery a lot easier.
Use Git for source control, Basecamp/Pivotal Tracker/Unfuddled for coding workflow, and Sharepoint/Google Docs for document management.
If you get a MSDN developer license, you can run TFS workgroup edition. That has source control and document management rolled all up in one package that's pretty easy to use and manage. That, in addition to an internal wiki, is what my company does.
Use Subversion. It's free and is the preferred source control system for the vast majority of open source projects.
SVN uses shallow copies, so when you have large files in a repository and you branch, a full file copy isn't done... just a pointer to the original. As for text files (code) only diffs are stored.
Use TortoiseSVN for windows explorer integration.
TFS is a pig, and you'd need to open visual studio to interact with source explorer. Stupid for a CAD engineer to have to need a license to TFS for that.
For document management, just use Windows Sharepoint Services that comes with Windows Server 2003 (or 2008).
I also work for a small company and we mainly develop in .NET languages. We have decided to use Visual SourceSafe for source control, despite its questionable reputation, since it integrates nicely with Visual Studio. VSS works very well for us, and we have not experienced any serious problems with it. Also, we host a SharePoint server, which we use to store documents like coding standards, storyboards, and even our SCRUM log.
We use HostingPlayground. For $6 per month we get multiple Subversion repositories and an instance of Trac. Can't beat it. And since its a service its available immediately.
It seems the solution for your 'management' requirements will require at least a tool or set of tools in the following categories: (sorry about the links, not enough reputation to put proper ones in the reply)
Source Code Management
Trouble/Bug Ticketing
Document Management
Definitely take a look at stackoverflow.com/questions/15024/tools-to-help-a-small-shop-score-higher-on-the-joel-test Tools to help a small shop score higher on the joel test referenced by stackoverflow.com/questions/84303/code-document-management-for-a-very-small-company/84363#84363 Kristopher
Each have various free/open source solutions, and likewise there are commercial solutions.
Source Code Management (SCM)
A significant trend(?) of source code management is evolving from centralised code management with something like TFS(?), cvs or subversion.tigris.org svn), to decentralised 'distributed' source code management with tools such as www.selenic.com/mercurial/wiki/ or git-scm.com/. Some of the tools either integrate into continutation
The above mentioned source code management tools all have nice ms windows integration tools, and some even have closer Visual Studio integration (e.g. TFS, ankhsvn.open.collab.net/ ANKH svn mentioned by Mario).
A simplistic generalistion would recommend git/mercurial when your coding involves a good portion of time away/off disconnected from your centralised source code repository (such as doing a lot of coding from home when your repository is not accessible through the Internet.)
Wikipedia has a en.wikipedia.org/wiki/Source_code_management nice overview of the various issues related to source code management, and the benefits of various options.
If you haven't used scm before, just pick one or two of the tools that fits your groups requirements and test it. Of course, if you know someone near who has experience with a particular scm solution it may help with the team's learning curve to have that shared experience around.
My pick for your scenario: Subversion with ankhsvn.open.collab.net Ankh SVN for Visual Studio integration.
Trouble/Bug Ticketing
None of the tools available solve everything for everybody, each have their advantages and most require some compromise from a development teams existing modus operandi. Again, wikipedia is your friend with a en.wikipedia.org/wiki/Bug_tracker general summary and en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems comparison of major tools.
Installation
The php based tools are the easiest (in my experience) to get up and running, and the perl tools more involved(?) Of course there's python one that's real easy to install, but then requires a better mind than mine to configure.
My pick for your scenario: trac.edgewall.org/ Trac
Trac is an enhanced wiki and issue tracking system for software development projects. Trac uses a minimalistic approach to web-based software project management. Our mission is to help developers write great software while staying out of the way. Trac should impose as little as possible on a team's established development process and policies.
It provides an interface to Subversion (or other version control systems), an integrated Wiki and convenient reporting facilities.
Trac allows wiki markup in issue descriptions and commit messages, creating links and seamless references between bugs, tasks, changesets, files and wiki pages. A timeline shows all current and past project events in order, making the acquisition of an overview of the project and tracking progress very easy. The roadmap shows the road ahead, listing the upcoming milestones.
Drawings/Document Management
If you use Subversion with Trac then much of your document management may be solved with these tools. Otherwise another stackoverflow discussion topic: stackoverflow.com/questions/587481/developer-documentation-sharepoint-document-management-vs-screwturn-wiki Developer documentation sharepoint document management vs. screwturn wiki, for Windows centric environment, is a good read.