I am an .NET developer and would like to learn Umbraco.
I see best way to learn Umbraco is to attend their Master Class (Level 1 and Level 2)
I am interested in umbraco Level 2 certification. Do I need to attend Umbraco Level 1 before that?
Best Regards
Hardeep
You don't need to do a level 1 to do a level 2. I did never do a level 1, only a level 2. But I had experience with a few umbraco websites. Further more, if you want to become a certified company, you need 4 exams. If you only do a level 2, that will count only for one exam.
I would suggest you do both, even though you don't need it.
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
We have one Dev Team (Approx 20 Team members) currently working on 5 products with 5 product owners (one for each product). We are struggling with story prioritization between different products and lots of meetings for the same.
Below are the two options we are looking at:
1. Merging product backlogs to a single product backlog
So that team can pull stories from one product backlog to sprint backlog. (And does not have to bother about priorities anymore). But a single product backlog maybe too huge and unmanageable.
2. Separating the team into 5 teams for each product
But this is not currently possible as we have resources specialized it a particular skillet and needs to be shared across the products.
Any suggestions?
I would suggest a third option.
Form teams around the products that generate the most work. Then have the remaining developers work on teams that cover the remaining products.
Something like:
Team 1 - Product 1
Team 2 - Product 2
Team 3 - Product 3, 4, 5
Hopefully this will reduce the struggle with story prioritisation (although not completely eliminate it).
The most important thing is to identify what you want to gain by the new organisational structure and how you intend to measure success.
Get some suitable metrics in place, try the new structure and see if the metrics get better or worse. Then inspect and adapt your approach.
I have a couple of things to point out, the tasks priorities are not responsibility of the development team at all, this is something that is managed by the PO for many reasons, but lets not discuss about that.
As you don't have a single PO this is transformed in a fight of interests. If there is no common goal between them every PO will want their US to be done ASAP because is the highest priority for them (and this is totally understandable).
So, if you want to keep one single team for all this products you will need a PO that works as single point of contact for the Dev team, a single backlog for them and then you can try to make sprint goals focused on single products so the dev team does not have to change their "environment" in the middle of the sprint (but this is a bonus point, not mandatory).
The main thing is if it is possible to have this single PO to manage this single backlog, at the end its the same as if your current 5 POs becomes stakeholders, they will ask for what they want, and this single PO will put those thing in order. Based on what ? could be company need, if there are blocking issues or it could go as easy as money ... who is the one that is paying the most and thats the one you will attend first.
In resume, remove the responsibility of picking the task to be developed off the team, it could be by this single PO approach, by a forum between the PO where they manage the single product backlog all together. And those are my 2 propositions.
There are too many factors in place, the company, the POs shared vision and needs, the reason why there is 1 single team that is managing all this.. etc.
We are currently working with one single team for multiple products as well and we have just one PO and a single product backlog and things goes smoothly.
Hope this helps! Any doubt just tell me!
This is a common problem and one that can be solved by discipline and team work.
5 Products seams like a lot for 20 people, and hopefully some of that work is similar and you can include it together. I would encourage the group into a smaller number of teams of 6+-3 and have them choose how best to meet the work.
If you have a self organising set of teams they will be able to figure out how to cross train enough that you will not have the need of so many specialists. Have a look at the Scrum Guide (http://www.scrumguides.org/) and follow the guiding principals in there.
I'll make some assumptions first:
The products are loosely related - e.g. if your company produces HR software, the products may be Timesheet, Training, Performance Management etc...
There is a certain amount of shared code between the products e.g. login, logging, deployment etc...
It is possible to have smaller teams that would have the skills necessary to ship product features.
The Product Owners are able to understand the business value of a product feature and negotiate between themselves on priority.
In this case I would...
Divide into 3 teams of 6/7 - this is enough people with the skills to get significant features done.
Have the 3 teams "own" 1 or 2 of the products - this is so that the team can really understand and contribute to the longer term vision of the products, and ensure that technical backlog items are prioritised appropriately against the product value.
Have a backlog for each team - that the product owner(s) and team own.
Have an explicit method that the product owners use to prioritise features - e.g. business value, WSJF, Kano etc... Agreeing this and writing it down may help stop arguments over the approach
Have the 3 teams co-ordinate changes to the shared code - maybe an Inner Source type approach.
Have a coach help the team and stakeholders through the change.
Too many fronts open maybe? Take a step back to revisit your companies goals, consider lowering expectations and re-organise the teams accordingly. If you postpone a product and do 4 products instead of 5 is not the end of the world. This will give you a good boost in the other products. Be smart and pick your battles. You don't need to fight every battle to win a war.
I want to manage a 3-tier Application Develpoment (Data/Business/Presentation) with scrum in jira but do not know if I use 3 Projects (one for each Layer) or one project and arrange the layers with the epic tag function.
I have found a lot about big scrum projects but not with this structure and the most articles refered to big teams that we do not have.
The problem with tools is that they will attempt to drive your adoption of scrum. I advise stepping away from the tool and considering how you see the approach when simply using scrum. Then see whether the tool will model that.
For the situation you describe, I would think about one product and one product backlog, with multiple product backlog items. The product backlog items would describe vertical slices of functionality that cross all three tiers of your business model
It is unusual when using the Scrum framework to break out the tiers of the application in to separate projects. With Scrum we typically work on user stories that represent vertical slices through an application that deliver some business value.
Separating out the tiers means that:
You create external dependencies, which makes it difficult for teams to resolve their own problems. The Scrum Guide includes the following: "Cross-functional teams have all the competencies needed to accomplish the work without depending on others not part of the team."
Measuring the rate of progress of 'done' software becomes more difficult. The Scrum Guide says: "Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available."
You create a synchronisation and resourcing problem in that the teams have to work at a balanced velocity so that they build the three tiers at a consistent rate. For example, the business tier development mustn't get too far ahead of the presentation tier.
Testing may be less effective as you have integration testing that spans several teams. This makes coordination more difficult and it may increase the time between when the code is written and when bugs are revealed.
I am designing a program that needs multiple level of approval.
when an employee apply for leave 1 notification should go to his relevent Boss & if Boss approved it..
it should sent back a successfull message
Thanks & Wating for your valuable solution
Even if I totally agree with the comment leaved by #gert-arnold, what you're talking about is a "Human Workflow System", and generally a system like that is based on a Persistent State Machine: there are various ways to accomplish that technology speaking, and many frameworks and tools to do that, but this sure is not the kind of arguments to treat in StackOverflow
We would like to use TFS2010
In my company, there is a single team working on multiple products at the same time. There is a visual studio solution for each product.
We can have the following scenarios:
Customer requirement 1 involves adding several features in product A and must be deliver in May
Customer requirement 2 involves adding several features in product A & B and must be deliver in Aug
Customer requirement 3 involves adding several features in product A & C and must be deliver in Aug
Customer requirement 4 involves adding several features in product B and must be deliver in Oct
Customer requirement 5 involves adding several features in product A & B and must be deliver in Oct
Developer Team is small (10 people) and can work on product a , b or c even though some developer know the product A better than the product B and so on.
In reality, we have almost 10 products. Sometimes we have hot fixes and I have to track all activities.
What do you recommend ? one or many team project ? if one team project, which structure do you recommend? Agile or CMMI templlate ?
The decision which project template to choose depends on you development process because the template represents it.
The CMMI template has a lot more fields for the workitem types (bug, task) than the agile one and is more formal. Take the time and think about your actual or future development process and take a look here to get an overview.
The scenarios you are decribing are reached via a branching strategy, take a look at the ALM Ranger branching guide
I would make one team project collection (because branching over team project collections is not possible).
I would create one team project and organize the products with the areas, iterations and team queries.
Reasons for my decicions
each team project gets its the version control and sharepoint site
you are a small team which work on all projects
the administrative overhead for each team project
Here you can find some good pictures and walkthroughs for working with one team project for different products.
For example team A and team B are working on different applications that need to implement a similar feature. The feature in question relies on a database and the database is under the control of team B. Even though the user interfaces of the two applications are based on different technologies, the functionality is supposed to be roughly the same. Both teams have their own requirements and design documents. The functionality can be changed based on feedback from either team but then both teams have to update their requirement and design documents.
The teams are geographically distributed and members of each team itself are also geographically distributed. Both teams work with the same client entity but different people. Each team has their own business analyst (requirements specialist).
I am trying to make the technical communication between the teams more formal than email so that we can avoid misunderstandings.
How do you make sure that if team B changes the database and or the feature functionality, the other team gets properly notified about it? Do you use some formal text based documents such as interface contracts? Can you share any templates for those? Or do you use some other mechanism?
A couple of things from my own experience (which sounds very similar to yours)
You should try and have a single design document for the database part of the solution which as djna suggests should be posted on a wiki or similar, with a defined public contract for interaction with the data. This is a good step in the right direction, as it will give everybody a kind of 'shared vision' which helps people converge towards doing the right thing. The contracts should try to ensure that the data access is done in a standardised way.
However, from experience, the code does not always follow the spec exactly, so i would also assign a single owner from one of the teams, whose responsibility is the integration of both systems to the database.
i would then implement a continuous nightly build process with tests, and this build should include the database. This will hopefully flag any issues earlier in the process.
From the project i worked on, you may still have occasional disagreements and breakdowns, eventually we merged both teams. This was the best solution of all for us!!
Hope this helps a little
What about having a Team site (both as one team) or a Wiki so that both teams are aware of the change.
Regular stand-up meetings. Via a conference call. Stand-up == brief, highly focused, information centered. Delegate discussion to individual discussion outside meeting, reporting back at next.
There does need to be an overall authority though, to mediate where agreement cannot be reached and to ensure overall solution integrity.
I agree with Wiki or other collaborative site for publishing the current reality.