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.
Related
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
I am attempting to adopt agile concepts and I have done a fair amount of research, but I have not come across the answer to one question. I know that while the developers are initially coding the tasks of an iteration, the testers can be preparing their test plans and test cases, but when testing begins, if there are no bugs being identified for further coding and re-testing, what should the developers be working on at that point? In my current waterfall SDLC, the developers would begin working on the next release's content, but with agile it seems that work can only be done on the current iteration/sprint until it is fully completed.
#user3329073 - so, out of curiosity, are you currently planning sprints and releases - or are you still using waterfall? Or a hybrid approach?
In any case, it would appear that during a planning cycle, your developers complete all the tasks they are meant to work on and hand those off to your QA team to test. Depending on the volume of defects or changes, they might either be fixing those defects or coding the changes - OR - are waiting for new work to be assigned to them. This seems somewhat odd - but it is perhaps due to my not understanding your situation fully.
Normally, I would expect that (especially in an Agile environment), the developers could be doing one or more of the following -
They could be writing test automation scripts, so that each new feature is covered by your test automation suite. (Are you currently doing test automation?)
They could pick up the next task/ user story/ requirement within the same sprint - and start working on that.
They could pick up some engineering task - such as code re-factoring for performance or other usual reasons, as well as other important (but usually not urgent) tasks - such as even documentation.
It all depends on the overall context in which your team operates. What are the organization goals for code quality, stability, performance, documentation? What is the test automation strategy? What are the tools available to enable developers and testers do their work fully?
In our engineering organization, for example, where we follow more of a Kanban approach for being Agile, we have almost no testers. We do Test Driven Development where developers must write test cases before they even start coding. Once the finish coding, they must automate the test cases they wrote, and test the code to ensure that it works. Once done, we do code reviews by our lead architect - and other engineering leads as needed. In the mean time, the developer goes on to the next user story or defect available to work on. Shown below is our Dev lane in our overall product development board.
Additionally, we have a separate lane for tracking important Engineering tasks and work that needs to be done - and if the developer has time on their hands, they will pull work from that lane - and work on it till completed.
We do have a 1-2 manual QA folks, who - along with Product Management - do an overall review of a specific set of features that are identified for being shipped in the next release.
So, like I said, it depends on what your overall approach is to managing your teams and to product deployment and delivery. The advantage of Kanban in helping you become Agile is that it helps you start where you are and improve your processes from there.
Here is some additional reading about our practices that might help -
All in the Day of a Kanban developer - http://bit.ly/1h7kBcH
Benefits of Kanban - 300% Reduction in Cycle Time - http://bit.ly/1bmuYLy
Hope this helps!
It does sound that during your transition to agile you haven't yet achieved full integration of your team members. Think about getting daily builds out to a test environment (or continuous deployments if you can) so that the testers can be reviewing work as it is progressing.
Additionally, as #Mahesh Singh mentioned, developers can be helping with the testing as well and will likely be communicating with the test team to guide them through the testing as new builds are going out for review.
No matter how you set it up, there is always a point in the sprint when no more stories are left in the sprint to start on, and the team needs to close out the iteration. This is where you want to have your 'cross-functional' team members so that they can help with whatever might be left:
Preparing demo scripts
Building installation packages
Documentation
Training preparation
Automated testing
Reviewing upcoming stories for the next iteration
Helping refine estimates
Playing some ping-pong!!
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
Everyone is talking about Agile and how good this is. There are several advantages and disadvantages of Agile. I have studied them theoretically. Since there are experts here who have worked in many projects I want to know real two-two scenarios where Agile is unsuitable and suitable. Thanks
If it is possible to do agile well, then i believe that is always a good thing. If it is not possible to do it well, then i believe that it can be harmful. Not because there's anything intrinsically hazardous about agile, but because it would mean using a dysfunctional process.
So, agile is unsuitable when the conditions for doing it well do not exist.
Some things that could scupper the adoption of agile:
Team members do not understand the process, and do not have either the time or the inclination to learn it
Team members do not have the experience or maturity to assume more control over their own process
Management requires detailed long-term plans as a deliverable
The customer is unwilling to provide feedback on incremental releases before the final ship
There is a high churn of members in the team
The technology in use does not permit a build and test cycle of a useful length (i've done agile with a three-hour build and test cycle; this was very painful but just about doable), or does not permit it at all
The problem domain does not admit incremental development of a solution (i'm not sure if this is ever true; the nearest i've come to this is when dealing with cryptography, where the thing either works completely or doesn't work at all)
To some extent, these can be remedied. An uninformed or inexperienced team can be shepherded by a cadre of informed or experienced members. Team leadership can write a long-term plan, then let the team ignore it and hope that delivering working code will pacify management. Business analysts or QA can act as a proxy customer for providing feedback on incremental releases. Branching strategies and build servers can be used to decouple build-and-test from commit and merge. These remedies are certainly not guaranteed to succeed, though, and if the problem remains insuperable, agile will not be succesful.
Agile may be unsuitable when:
it threatens to expose overgrown management (some positions suddenly become clearly superflous)
people actually don't want to have fun and do creative things, preffering 9-17 mode of mundane work (maintenance of legacy crappy software that just cannot wait to be disposed of)
politics rather than professionalism run the company
Human Resources run the company (Agile is about humans, HR treats them as things)
the customer expects that you will figure out what he needs for him (Agile will make you asking him questions that he doesn't want to answer)
Agile is expected to be a magic wand that will solve problems without anyone changing their habits (another buzzword, a fad)
development is spread across multiple locations far away from each other, in different time zones (communication suffers)
you have a pointy-haired boss ;)
or in general:
it is misunderstood
organization is devoured with serious patologies
no one actually wants it
I worked with many different teams trying to move to agile. Some succeeding, other which did not succeed. Based on my experience, I can say that:
Moving to agile is suitable when the software creators want to improve quality of their product(s) (whatever its mean in their context) so badly that they are even ready to work as a team to achieve it.
Moving to agile is not suitable when everybody is happy with the current quality level and/or do not want to work as a team.
Sort answer:
agile is suitable, when IT company is making its own product. e.g. visual studio is made in agile way couple of years. And you can see much better "idea to delivery time".
Agile is not suitable for Internet Banking. Another example is client based in US and dev team or its part in azia. The time delay makes things complicated.
Long answer:
First, if you want to run an agile project, your management should understand it and processes in your company should embrace it. If you try to workaround them, you will fail. See how management and internal processes are important here: https://www.youtube.com/watch?v=4u5N00ApR_k It's more important that the management and team leads understand agile processes than the programmers. Usually, opposite is true.
Second, your client's management and processes should embrace agile processes. A bank or financial institution will never sign an agile contract. Their processes requires deep planning and approval at multiple levels. See how clients misunderstanding of agile can cause a fail: https://www.youtube.com/watch?v=lAf3q13uUpE
I completely agree with Tom Anderson, that the circumstances are more important that the type of project itself. For example, if you have signed fixed contract (either because of your management, or a client), you probably have detailed requirements. If you have detailed requirements, you wont run scrum but "SCRUM BUT". It's against agile philosophy.
It may happen that the project is not suitable for neither agile, nor waterfall.
Sometimes it's better to use agile internally having Product Owner role assigned to somebody from your company, who understand the domain best.
Suitability and Unsuitability of Agile methods?
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 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 11 years ago.
Improve this question
Our IT manager is pushing for ITIL, I'm only loosely familiar with it and wanted to know if ITIL fits into an Agile work-cycle well?
From my initial impression I would assume no, mainly because what our manager is proposing is to put timelines against everything, stating SLA's to the business that "high priority tasks must be completed in x hours" etc... which we get penalised as developers if we do not meet these SLA's.
If anything I'd prefer a negotiation strategy where timelines are based on agile methods of velocity and story points to negotiate an expected timeframe to end users.
We have our agile development practices in place, test driven development, continuous integration, there's areas for improvement but we're working on it.
What are others experiences with ITIL and Agile methods working together?
In my company ITIL framework is used for service delivery (production and incident support). For this SLAs are appropriate as if you are say losing customers/money per hour then it is expected that business should have some indication of when things will be fixed. It is not directly related to development methodology. Only if you decide that an emergency hotfix is required and approved then some development may be done. But hotfixes are usually very small and targeted to fix a defect and shouldn't cause any issues with agile methodology. New requirements are never done as hotfix change and are taken in normal dev/test/release process.
That doesn't look good at all, if that's the case, it really doesn't fit agile at all.
I'm suspicious if ITIL really calls for that, specially since "high priority tasks must be completed in x hours" goes beyond not fitting agile, it doesn't fit software development i.e. all tasks aren't born equal.
update:
So would you say that normal development processes can be exempt from ITIL methodologies and have ITIL purely concentrate on the infrastructure/incident support areas?
I don't think this is mutually exclusive. While it might be the case that ITIL isn't applicable in how you manage the team, it doesn't mean there aren't valid areas of it that affect what you develop.
Development needs to include considerations in the design/product that are required by infraestructure / support, and such may relate to practices suggested in ITIL.
Maybe a more appropriate question would be: are management aspects/practices of ITIL applicable to management of software development? which I don't know, but suspect is addressed specially in ITIL. At least I know that ITIL 3 introduced changes that relate to Enterprise Architecture practices, that are definitely compatible with agile (in fact are enablers) --- but at least those are far from anything related to fixed estimations / task tracking / dev response times.
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.