(Posting the question here as this is the 'community' that Microsoft redirects to with a 'Need advice? Ask community' button. Hope it won't get closed as 'primarily opinion based' or 'too broad')
Hello,
I want to start using AzureDevops in my department for organizing code & work. We're a small team who creates a large number of applications & plugins.
Some of these applications have a very short lifecycle, i.e. we deliver them, and they work for years without changes. Other apps are larger and are updated/fixed across several months or years.
These applications are completely separate from each other in all aspects.
As far as I understand Azure DevOps structure, my department should become an 'Organization' (we can/need to be separate from the rest of the corporation).
I am a bit puzzled about the 'Project' part. Documentation says
In general, we recommend that you use a single project to support your organization or enterprise.
So, let's say we do have one project called Our Apps - where do we then put all the individual application-projects?
As far as I understand, each product (application) that we deliver should have it's own repository (or a set of applications, if they are logically connected).
This is in order to allow a developer to simply clone the repo on their machine and contribute to that product only - without downloading other projects etc.
I need to be able to:
easily navigate/see all the tens/(hundreds?) of applications that we create,
view their separate kanban boards (for those project that do have it, not all of them will)
to see their repositories (Git or TFS), commits etc
see & manage their pipelines
At the moment it seems to me that the only place where I can see a 'list' of what products do we have is the drop down below:
And the only way to see what is going on in the big-enough-to-get-own-board products is by creating a new separate 'SomeApp Team' in the Project (even though same people are in it), so that I can have a board for the SomeApp - and view the boards from here:
Is that the intended way to organize the structure?
Any alternative approaches?
Is there any way to have a 'cross-reposistory' or 'cross-team' overview?
What about creating documentation for each 'product'?
The "one project to rule them all" was coined by Martin Hinshelwood and his blog post from way-back-when explains the reasons and limitations.
With the introduction of Tagging and filtering on the backlog there is an alternative approach within the one-project setup.
Create team for the real teams you have in your organisation.
Create an area path for each major project/product in the org.
Assign the area paths of the projects to the teams who are working on them. This can change over time.
Optionally tag work items with the major project/product for additional filtering.
This way each team sees a complete view of all the work they can pull from. And they can quickly filter the work by tags to remove items from view when discussing specific projects/products.
Also, when teams change their focus from one product/project to another, you can simply change the assigned areas for that team to update their view.
The Plan View extension provides an additional cross-team view across over all the work. And the Dependency Tracker extension can visualize dependencies over time.
You can also use the Epic/Feature/PBI|UserStory tree structure to create additional grouping in your work items. You can customize the process template to introduce a Product level, though for the planning features to work, that would also mean that you'd also have to create full traceability from Product down to PBI|UserStory.
The main recommendation is to try a few of these approaches in a light-weight manner to see how they work and find your own ideal setup.
Another option for cross project visualization is to enable the Analytics Extension and connect it to PowerBI.
As you'll soon figure out, naming guidelines for your Tags, Repositories, Pipelines is going to be very important. Being able to quickly filter to the right level requires this.
I have Magento 2 store and looking jet.com for sales point of view.
Is this possible ?
Please suggest me any possible solution.
Thank you.
You have a couple options:
You can directly integrate with CedCommerce's commercial extension.
You can use a third-party omnichannel integrator that will sync catalog data, inventory and orders to any of a number of marketplaces. While there are a number of these platforms, there aren't many right now that have ready-made integrations with both Jet and Magento. Two that I have found are SellerCloud and ChannelSale. One thing to note is that these typically become the center of your e-commerce operation, with Magento pushed to the fringe, as just another marketplace alongside Jet. That may be good or bad depending on your business model and existing architecture.
Note that I have no first-hand experience with using these integrations or omnichannel platforms like this, so I cannot personally vouch for their quality.
I'm considering moving my open-source project Flyway from Google Code to GitHub.
One of the features I really like in Google Code's Issue Tracker is the ability to vote and sort issues by the number of votes. This has allowed me to get a good feel of where current pain points lie and what the community feels needs attention or further work.
How can I achieve something similar on GitHub? Is there a way to maintain a democratic approach to Issue Tracking?
There is no built-in ability to do so. Technically speaking, you can only manage issues by
assignee
tags (called labels at github)
milestones
While you can define label systems for lots of differentation criteria like
bug/feature request/...
prio high/low/...
status verified/unverified
it is simply not possible to have something that accumulates votes. So typically you will see "+1" postings as in good old mailing lists. I've seen people using external voting systems (like Google moderator) for issues on github, but that doesn't make a good user experience either.
If you're willing to use a third-party system that integrates with GitHub, you can try GitPoll.
I want to setup a website where a team of developers (distributed all over the world) can get together and develop Software.
So far (after a ton of reading) im coming close to the conclusion that the tools I will need are: a Version control system (git , mercurial), a bugtracker and and project manager? This post here also help come to this conclusion.
Now my questions are:
- Am I correct and what other tools will I need?
- Will is be possible to integrate these tools with my website?
by this I mean the look ( my website logo) and feel (not having to bounce around from one link to another)?
- I would also prefer hosting my own git/mercurial repo as i dont want to have to go open source is is this advised?
-Free/open source applications would be best
Also another question, I had a look at redmine, does this cover all the things that i would need? as i see it has a lot of features..
You want to reinvent the wheel... do you know it?!
You forgot at least:
Future planning (and bugtracker will become issuetracker)
Team communication (realtime and|or non-realtime)
Some type of internal documentation (wiki?)
Code reviews
Unit-tests, build and deploy tools
Maybe private repository on code-hosting sites will be more natural (and fast) way? Or you can try GitHub Enterprise or Assembla Private Installation
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
We use Trac as our bug tracking / development / wiki system and I was wondering if anyone has experience and uses some of the Trac Agile/Scrum plugins or functionalities? Anything you'd recommend?
Or would it be better to duplicate Trac tickets as dead-tree user story index cards and a hand-drawn burndown chart?
Note that I found a similar question here. Though it's specifically about Scrum. They recommend Agilo. Has anyone tried Agilo yet?
With a collocated team, I'd always duplicate user stories on index cards. A wall of cards is much more collaborative and simple to use than any software tool. And what's most important, it's in your face.
The same is true for a burn chart. In my experience, a software chart gets online looked at by a small number of people, and typically is a pull medium. A big, handdrawn poster (that changes regularly) gets noticed by everyone, and serves as an incubator for ad hoc discussions.
It's also quite valueable to be able to point at them during your daily scrum meeting.
This is how we use Trac for our scrum like sprints:
We use the milestones in Trac to identify sprints.
There is a default Backlog milestone where we gather all new tickets.
Before each sprint we move tickets from the backlog the current release.
On the milestone page, we can add retrospectives and other info about the sprint using wiki syntax.
So just the default Trac functionality without any plugins for now to keep it lightweight. As we get better we may add features like burndown charts or maybe switch to another tool, but we want to get the proces in place first.
Answering late, but this more of sharing my experience with Trac+Agilo so far.
To quickly answer your question, perhaps Agilo is the best option available for Agile development with Trac.
Now comes to install and usining install was just very easy. We used their latest release 0.7.3.3. It installs flawless on Trac 0.11 and Python 2.5. Don't forget to install libjpeg and python imaging library. It would be useful to note that we used virtualenv which took a made things easier.
Further usage is very simple. For wiki I kind of prefer Trac's old clean look over Agilo's customization. Other than that all things just works.
On thier mailing list I have noticed that they are planning to offer multi-project support in future. In all I recommend Agilo plugin for Trac.
Yep, I installed Agilo on our Trac installation.
Seems very cool, includes nice burndown charts.
Unfortunately I left the company where I installed it before I could get any serious usage out of it.
Installation was a pain (Ubuntu Ibex) - I documented precise steps on the Agilo Google Group.
The problem (as always) is integration into the business end of things that PMs and CEOs like to see (e.g. estimated vs actual hours). There are (as has been mentioned) other products out there that cover this off (FogBugz covers this off I believe), but I (and the team) love Trac so we worked around this.
Oh, one more thing; it looks like it introduces quite a lot of overhead (i.e. you have to spend more time in trac to get the most out of it), but like I say I didn't have an opportunity to really use it in anger.
We used Trac before with a burndown plugin then went to Redmine. We've found Redmine to be miserable for repository viewing and the issue interface. We're actually looking to move back to Trac again.
Bitten is a Trac plugin for continuous integration that can be harnessed to do automatic builds on check-in, which provides a critical part of the Agile process (rapid feedback). I haven't used any other plugins for Trac personally, so I can't comment on them. However, the native Trac functionality of milestones could be leveraged fairly easily, I suspect, to be used as iteration markers (where each milestone represents the end of an iteration). Since milestones can be used to mark a 'due date' for features already, you shouldn't need much in the way of modification to use them as such.
From there, using tickets as user stories, and tying them to milestones (I'm sure this can be done manually at worst) would give you a basic method of tracking velocity and keeping the team aware of progress (and changes that need to be made as well).
We use the Trac wiki for:
List of requirements for each feature
List of technical specs (if any) for the features
List of Releases and their features
Deployed environments, with links to all instances
There's a macro for making web requests, so we can list which version, etc. each env have
(there's a GraphViz plugin which is quite helpful for simple drawings)
There's also a ticket in the ticketing system for each "feature", for keeping a gross backlog and the current/next sprint planned.
Then we write a bunch of cards during sprint planning for each feature.
There's also a more operational side to things. We keep one person each sprint on Ops, so we have one person who's dedicated to be interrupted by people outside the team. The rest of the team can focus on delivering features.
Each bug/ops task gets a ticket, but as soon as we start working on it, it gets a card and starts moving across the board. That way it gets visibility and we don't forget to involve the testers, etc.
Scrum is pretty tactile, so I don't think it would work great to put too much stuff outside of the physical working environment. But in the end your team needs to find a balance that works.
For something completely different, the best way to do Agile Development with Trac may be to simply migrate everything to Redmine. It supports Trac's core features with some extras including multiple projects, Gantt charts, forums, DCVS, etc. though it looks like it's not completely there yet. Some good things in the pipeline.
Daniel Srb (in the comments) has a redmind agile plugin he's been working on that looks promising. You may be able to contact and see if he's planning to release it (was a long time ago).
We've had success using two products in concert in the past, Trac for tickets, xplanner for planning.
Agilo for Scrum rocks, the latest versions are using client side generated charts, so there is no dependency anymore, much easier to install :-) agile42 just release a Pro version that enriches the Agilo experience with a nice and intuitive Planning Board, very cool screencast :-)
We recently started using Scrumban.
Basically a Kanban board, with the daily stand-up meetings covering the classic Agile Scrum questions - what did you work on the previous day? what do you plan to work on today? do you have any blockers?
We do this around a physical Kanban board, it is great for visualizing the work flow and for team synergy, but we also wanted a digital form of our Kanban board to be able to double check trac usage vs. the physical board.
In search for something that would work, I found this clever post on re-creating a digital version of the Kanban board in trac.
It is very straight forward and simple, I was able to easily manipulate this approach for our work flow, and you could probably tailor it to your Agile Scrum iterative approach (or if your able to ditch the time boxed approach, give Scrumban a try).