Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I am using TFS 2012 to develop a application that will be available as a website and a mobile application, i.e. Windows Phone, Android, etc. While I've been building up a list of features for this application I've noticed that a lot of them will be available across all platforms and I'm not to sure how to manage them within a product backlog.
For example, there will be an option to sign in with a Facebook account and user will be able to do this on website and mobile applications.
So my though was I would create a product backlog item "Sign in with Facebook account" and assign it to an area called "Website". I would then create another backlog item, with the same title, but this time assign it to an area called "Windows Phone". Therefore my backlog would have two items, both with the same title, but different areas.
The idea is I could assign the "Sign in..." backlog item for the website to one sprint and then assign the "Sign in..." backlog item for Windows Phone to another sprint.
Seeing as I'm new using Agile/Scrum would this be considered a viable way of managing a product backlog?
I think each one should be a different story. Why? You'll probably have a different acceptance criteria on each one of those stories, and you'll (hopefully) use a different layout for web and mobile.
Some of the benefits of breaking stories into small chunks are:
Your testers will have stories to test from the 2nd day of the sprint, rather than get a batch on the last day of the sprint.
It increases the flow (I know that this is more kanban, but I think it's a good symptom)
It becomes more difficult to have a story that is in progress at the end of the sprint.
I've found this mind-map really useful to guide me to break stories into the smallest possible deliverable unit.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
If a corporation includes as "internal entities" all of the following teams:
1) Red Team
2) Penetration Testing Team
3) Blue Team
What will be the differences between them? I find some difficulties in understanding the differences between Red and Pen Test!
And which team would have the wider scope and the higher authority?
Red Team - act as the enemy. The entire environment is within scope and their goal is to penetrate, maintain persistence, pivot, exfil, to examine what a determined enemy can do. All tactics are available including social engineering. Eventually the red team will get to a point where they own the entire network, or their actions will be caught and they will be stopped by the security administrators of the network they are attacking. At that time they will report their findings to management in order to assist in the increasing the security of the network. They keep copious notes as this information is valuable later on to fix the weaknesses they exploited. Not many organizations do this, but they usually have an organic red team so the information gleaned from the red team is extremely sensitive. Red team actions are controlled by the manager of the red team.
Penetration test - can use the same tactics of a red team (may be limited by management and the scope of the test), and is executed in controlled fashion usually dictated by management and/or asset owners. Typically, the limiting scope of a pen test is time (execution time of the event) in which a report will be made to management. Often in a pen test, before a flaw is exploited, management and system/network engineers must OK the attack to ensure it doesn't affect day to day operations. The goal is the find weaknesses in systems/networks in order to increase the security posture. Pen tester actions are controlled by business management and/or the asset owners.
Blue team - defend the network from the red team or pen tester. The term "blue team" is also used for network/system auditor in which they are assisting the asset owners in securing and defending their own assets.
Red Teams attack
Blue Teams defend
I don't know what they exactly they mean by Penetration Testing Team, but I would guess that they are a subset of the red team that focuses on penetration testing. There is more to attacking than penetration testing.
To answer your last question, the Red and Blue teams would probably be about equal, with the Penetration testing team being below the red team. Of course, without knowing anything else about the organization in question, there's no way to really know.
Generally when a penetration Team is in mission, their only objectif is to find vulnerabilities in the system and they don't give a mind if they will be detected or not.
Red team is a more complicated Job, in their mission they don't need to be discovered, they will play the role of attacker. Like "if they got detected they loose". Each step need to be well calculated.
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 9 years ago.
Improve this question
I'm new to Sharepoint but I do have a background in .NET development. How is it different to develop in Sharepoint? What does a Sharepoint engineers program exactly?
There's a wide range of things a developer can do on SharePoint. A short list of most common (to me) items are:
Web Parts
Application Pages
Event Receivers
Workflow
Timer Jobs
If you're not familiar with the raw ASP.NET Web Parts, SharePoint Web Parts are kind of analogous to ASP.NET User Controls with some additional wrapping that lets them store and retrieve settings, be targeted for visibility for users, etc. These are generally the most common (that I've seen) project for SharePoint. You can put multiple Web Parts on a page and the user can drag them to different zones to customize the way the page looks.
Application Pages are a bit more complicated. They require you to include a number of SharePoint-specific page directives and Content Areas in order for them to be rendered correctly. The result of which is the ability to control (the whole?) page render in SharePoint. This is in contract to Web Parts which only take up a small amount of space shared with other web parts on a web part page.
Event Receivers (List or Item receivers) are a lightweight mechanism to attach either to specific list instances or to whole list types. (A list is an instance of a type. There are pre-defined ones and a generic list type and you can use content type ids to specify your own unique list types.) Most commonly these are used when a new List Item is created/edited/deleted in a list to provide some additional notification, categorization, kick off some external process, etc. They're really easy to define and set up and one of the most flexible ways to listen for changes.
SharePoint Workflows are less common than the previous two, from my experience, but are still used quite heavily by larger organizations. Workflows can be synchronous (ItemUpdating) which will execute on the server currently serving the user, or asynchronous (ItemUpdated) which can be handled by any server in the SharePoint Farm when the Timer Service picks up the job. Workflows are generally used for watching forms, creating tasks, organizing new items, etc.
Timer Jobs are content-less pieces of code that are run on a schedule by the SharePoint Time Server. They run under the OWSTIMER (versus the w3wp IIS worker process) and there are some limitations and "gotchas" with these. They're analogous to Windows Scheduled Jobs.
Edit: Added Workflow information.
Edit 2: Added Event Receivers. Sorry! It's been awhile since I've had to crack my knuckles over SharePoint. This trip down memory lane is...a trip.
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 does the "self organizing" in "self organizing Scrum team" mean?
See this article for a good explanation. This quote explains the heart of it:
Self-organization does not mean that workers instead of managers engineer an organization design. It does not mean letting people do whatever they want to do. It means that management commits to guiding the evolution of behaviors that emerge from the interaction of independent agents instead of specifying in advance what effective behavior is.
The team approaches a project, and, based on the project at hand, decides how best to allocate its resources to take advantage of each team member's various strengths.
What does the "self organizing" in "self organizing Scrum team" mean?
It means this: No one – not even the ScrumMaster - tells the Team how to turn Product Backlog into increments of shippable functionality. The Team figures this out on its own. Each Team member applies his or her expertise to all of the problems. The synergy that results improves the entire Team’s overall efficiency and effectiveness.
Reference: Scrum Guide
A self-organising team is one in which every member of the team is working towards some shared goal. Team members collaborate to reach the goal, valuing the team's output over their own individual productivity.
A self-organizing team tends to be:
trusting of each other's motives and motivation
helpful, respectful, communicative and transparent
collaborative with other teams
interested in delivery and feedback
goal-focused instead of productivity-focused.
The project manager's roles in a self-organising team tend to be:
making sure that the team has people with sufficient skills to succeed
helping them be aware of and understand information coming from elsewhere in the company
reporting the team's progress, successes, risks and obstacles to other audiences
getting stuff out of the team's way wherever possible (see Servant Leadership).
A self-organizing team is usually pretty good at getting things done, blasting through obstacles, communicating issues outside of their control and generally provides a great project experience for anyone using them. See also: Forming, Storming, Norming and Performing - you're looking for that last one.
It’s a flexible, responsive team that is allowed to make important decisions on its own in a preset framework. Usually, the management decides on the goals and overall deadlines for a project. Then it's up to the team to find the best ways to attain these goals, distribute tasks among the members, plan and evaluate their own work at the interim deadlines they set. Team leadership is not set in stone. Usually, the Scrum master changes regularly, so that each team member has a chance to try this role.
The main aim of such teams is to encourage the self-actualization of every worker. When team members can make a difference, they feel inner responsibility and motivation to perform. This way, self-organization promotes innovation and a good team morale, both of which look like solid benefits. By the way, we recently published a blog post explaining the benefits of the concept in more detail. You can check it out here, if you are interested.
A self-organizing team in Self
organize scrum team means each and
every team member is responsible for
their individual module, Scrum master
role is minimal/existed in the team.
Self organizing scrum team means low
ceremony and trying to work as a
collective whole so titles mean
little.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
There's a project which we're doing for the govt which necessisiates the use of a workflow system. I'm looking for advice on what software systems we can use (either commercial or open source / freeware) with appropriate customizations.
Steps:
0. We monitor a certain site for "notifications". Whenever a notification is posted, this is what happens for each notification.
1. A team of 2-3 people (our employees) have to examine the document, examine whether we need to act on it. One person examines it, the other reviews the first's decision/action.
2. If we need to act on it, one of them needs to prepare a sort of summary document for outside experts. Again, another person (not the writer) needs to review it.
3. This document needs to be sent to outside experts (emailed in most cases, but also via postal mail). A database of experts and their specialities needs to be maintained.
4. A system of keeping track of which document went to whom and when needs to be maintained.
5. Responses will be received from the outside-experts (electronically and postal). The system needs to keep track of from whom we did NOT receive responses, so that we can remind them.
6. Once all responses have been collated, the company employees need to prepare a report which needs to be approved by a supervisor before it can be sent out to the govt.
I understand that a number of tools would be required and/or extensive customizations. That's fine - looking for inputs on all these aspects.
Steve!
If you already define a fixed workflow process, you can develop the workflow with Windows Workflow Foundation, or hire a developer to do it for you.
If you prefer a customizable workflow product, K2 (http://www.k2.com/) is a good option.
Are you using SharePoint or not?
In that case have a look at BlackPoint and Nintex.
Both will give you lots of workflow options based on SharePoint. If I interpret your requirements correctly these packages should be able to implement them all without coding.
I would advocate Nintex Workflow since I have positive experience working with it. Installation and initial configuration is quite easy although features are impressive. It also built is a way that end users can build their own flows, it's fairly easy to do. Also you can build more complex flows, create custom actions and use the web services SDK to access the activities/perform actions from the outside of the SharePoint - I used it from InfoPath and Silverlight forms.
A good commercial option would be PNMsoft's Sequence.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
To those of you who started using scrum in your development teams: Did you maintain the traditional teams or form new ones? At our organization we are split into database, product development and frontend developers (simplified!).
I am interested in whether others actually reorganized their whole team structure due to scrum or if you formed dedicated project (?) teams combining e.g. one person of each "old" team.
I actually can't even imagine how scrum could work if you maintain your role silos. In scrum we build vertical slices through the product so that every feature delivered during a sprint requires all the skills you mentioned (plus QA which you did not). How would you create continuous collaboration and have people commit to the sprint if they weren't all on the same team? Seems like the most likely way to end in "Scrumfall" to me. I'm not an expert by any means but it seems to me that the sure way to fail at scrum is to think of it as a project management solution instead of an entire organizational change. Its cultural at the core.
To answer you question about "generalists". The easy answer is that by having certain people only able to work on certain things you create big fatty bottlenecks in getting to Done. With specialties you are always constrained at each step by having limited resources to work on something. In sprint 1 you may have a lot of db work to do where there is more than just that one dba can do. But then in sprint 5 where there is no change to the datamodel at all, your dba will be sitting around keeping bored. It becomes almost impossible in sprint planning to commit in a reasonable time if you have to divy up and assign at the task level by role instead of just grabbing the next set of priority features that fits your team's velocity. The generalist model will inevitably bring business value in the long run. You may just not see it right away until you achieve cross-pollination.
I would warn that if you are already in silo-ed groups by role, then you have to be very careful in am agile reorganization. Many people are not ready and don't want to be ready to lose their special titles and just become team members. I would think you should almost always expect some amount of turnover.
It is preferred that in scrum/agile development that most individuals on the team are 'generalist' meaning that anyone can reasonably step into any role so that anyone can pull off items in the backlog as the come and nobody is waiting around for others.
now this may not be the case in your situation today but doing things such as peer programming and standup meetings to see where people are having impedements and to improve cross pollination of knowledge will help in obtaining this goal.
At my company we create a temporary cross function team for each project. Our existing teams are still there, but it is really important that we have cross functional teams for scrum.
We generally try to mix up a little bit to get some cross-team knowledge, but we for the most part work on our specialties. But as the project progresses we can more easily help out on different teams
When I worked for my previous employer, the company reorg'ed the whole dev organization and product management. They put engineers, qa, and analysts in each team. The split was mostly vertical/functional with some exceptions. Those exceptions were a mistake - the architecture vertical did not fit, because it was really horizontal. I thought that cross-functional teams worked well. In your case, the db and front-end departments need to merge with the rest if possible, and new verticals specific to your product may be created
We split our team into New Product Development and Existing Product Maintenance, with the ability for any developer to hop from one to the other between sprints.
I think we have maintained the traditional team, at least for now. There are a couple of other teams within the applications branch of the Information Systems department where I work though these were put in just before we got into Scrum.
There is a big project most of us are on that is using Scrum and the team seems to be evolving along nicely. We have some new tools and processes that seem to have helped us a lot and given us a sense of "awesomeness" that hopefully we will pass on to the other teams.
For changes to a database, any of us developers can make the change in the development environment and then pass along the script to a DBA to be done when it is ready for production. For changes to the network, there are infrastructure folks that handle that and initially setting up a server in terms of O/S, network, memory, hard drives, etc.