Most companies today have embraced the Agile Methodology due to its flexibility and its focus on divining effort into small atomic tasks.
One benefit of dividing the effort this way is that users, developers, and clients have continuous visibility in to the development process.
In an Agile work flow, business analysts will gather the requirements for projects called "User Stories." These user stories go into what is called a Story Backlog. These stories are then assigned to developers by either the project manager, or a scrum leader.
Once a story has been assigned to a developer, the developer will review the story requirements and create a list of tasks (TFS: work items) that will represent the estimated effort for the story.
Both the user stories and the tasks can be displayed on Kanban & Scrum Dashboards. We can track the Estimated Effort, the Actual Effort, and the Velocity. We can also track Capacity versus Utilization.
These user stories that are encapsulated with tasks provided by the developer are assigned to sprints by the project manager, or scrum master.
These sprints are usually 2 weeks of functional development with 1 week of delivery, review, and feedback for a total of 3 weeks per sprint (iteration).
At the end of the feedback process, we go through an approval process. The stories that are approved will be assigned a release id and begin the release process. Stories that are not approved are recorded and changes will be incorporated into future iterations. For smaller issues, we will adjust and track keeping with the flexible nature of the Agile Methodology. Vary rarely will a feedback change require changes that will ripple throughout the entire Epic. An Epic is a larger grouping of User Stories that represent a larger, or bigger picture of the overall development goal.
Once these feedback adjustments and changes have been managed by collectively modified in the current and, or future iterations, the Next 3 week iteration begins. This 3 week iterative cycle is repeated for the required duration determined by the Business Analysts and Development Team during the Story Estimation Meetings.
One excellent way to estimate effort with a development team is by using a free "Planning Poker" Agile User Story Estimating plication. These estimation applications use a Fibonacci sequence. The reason for using the Fibonacci sequence is to reflect the inherent uncertainty in estimating larger items of effort.
When discussing development team collaboration, the topic in the Microsoft product line is Team Foundation Server. I want to point out that team collaboration
in this sense can include executive leadership, middle managers, business analysts, project managers, developers from other teams, as well as your team.
At the heart of Team Foundation Server is Visual Studio. In fact, TFS is an installable extension to Visual Studios. It is also true that TFS is also an expendable application like Visual Studio. The user interface inside Visual Studio is called Team Explorer.
Besides Team Explorer, there is also a web interface. TFS as an application also interfaces well with SharePoint, Office, and Project. TFS also support lab (training lab) management features.
In terms of collaboration between the development team and the operations team such as a database administrator (dba), we enter the discussion of DevOps.
DevOps is short for development and operations. In terms of developers, it can mean many developers and many teams of developers. In terms of operations,
it may mean one dba, or it may mean a dba team and an approval process with a team of its own.
At the core of DevOps is source control. Source control is where we manage and administrate the enterprise source code that we develop. We can branch and merge code, track versions, protect intellectual property by securing access to the enterprise code stored in source control. This represents the development side of DevOps.
Changes that developers make that are checked into source control will trigger what is called continuous integration. Continuous integration is the continual
process of building the Microsoft Solution and releasing the build according to a release management schedule maintained by operations. This represents the
operations side of DevOps.
Operations will manage things like the release life cycle that may look like a migration from a development environment, to a test environment, to a final user acceptance (UAT) environment . Once user acceptance has been approved, operations will initiate the release and deployment of the code following their set change control policies. Ideal continuous integration will build the code on a set schedule such as nightly. In some environments, like development, automated builds may fail, however at higher level release environments, such as UAT, build should rarely fail during scheduled continuous integration.