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.
What is the best support for Scrum in Redmine?
Best practices?
Plugin support?
All plugins I've tried are either not that active anymore and/or not up to the task of managing a major project using Scrum.
I've googled to no avail...
Thought I'd make mention of the Redmine Backlogs plugin again. It's been getting some TLC lately. product backlog view, taskboard view, real-time updates, reports, task colors unique to the user's preference, etc.
http://www.redminebacklogs.net
I don't really know Redmine but it looks like the Scrum Alliance Development Team has several Scrum plugins for it. Others potentially useful plugins are the Scrum dashboard plugin, the Todo Lists plugin, the Backlogs plugin but I can't say if they conflict or overlap with the Scrum Alliance plugins. This requires IMO some further investigations and testing.
My advices:
If the team is collocated, don't use a web based tool, use sticky notes on a wall and a spreadsheet.
If there are good reasons to use a web based tool, don't use Redmine if it's not satisfying.
You don't need a scrum tool to use redmine in a scrum way, however, it can at least help with acceptance. Redmine Backlogs isn't too bad. I have evaluated it and the product backlogs screen is a little raw, but useful. The task board is good. I recommend you take a look at it.
Redmine Backlogs
Redmine_scrummer is a plugin developed by BadrIT to facilitate scrum processes, it easy to use and follows the all practices you apply while in a scrum process i.e. scrum board, burning charts, etc..
Scrum PM is a decent, current Scrum plugin for Redmine. It's fairly basic, and the UI leaves something to be desired, but it works.
It has a Backlog where you can create stories, and a Dashboard where you can drag and drop tasks for stories through status to done.
Redmine Issues are Tasks, and Versions are Sprints. There is no strong correlation between tasks and stories, and there are a few (non-blocking) bugs, but it's the best scrum plugin for Redmine I've seen.
try Redmine Scrumbler
https://github.com/256MbTeam/Redmine-Scrumbler
Scrum best practice is to avoid using too many tools.
Agile methods put individuals and interactions first. Tools aren't important. Read this page to see what the real background of scrum is: http://agilemanifesto.org/
Read this to see more about Scrum. http://www.controlchaos.com/old-site/Scrumo.htm
Note that tools aren't really necessary.
Scrum is a series of sprints (managed with a simple backlog and burndown chart).
Scrum is a daily stand-up meeting (managed with no tools at all).
Related
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 9 years ago.
What kind of software development (projects) can kanban be used for and what are the requirements to implement it? I was reading a lot about kanban and how great it is. But now i have to write a paper about it that focuses of the requirements for kanban, and especially for what kind of projects kanban doesen't fit. I couldn't figure it out yet.
KarlM gave a good overview.
I think Kanban can be used in any project, because it takes your existing process and visualizes it, introduces WIP (multitasking) limits, and uses pull to maximize flow and minimize lead time. My team recently migrated to Scrum and it's been a very smooth transition so far.
Kanban is especially good for situations in which a standard iteration doesn't make sense.
For example, you might not have frequent releases. Maybe you want to decouple one or more of your planning, demo, retrospective, or release schedules.
Good examples:
Maintenance project. Even though you might want to have 2-week (or whatever) meetings to discuss priority, retrospectives, etc., you're probably not going to demo or release every 2 weeks, and it's not likely you'll be able to commit to everything in the next 2 weeks anyway. Situations like this are so dynamic that the priorities shift every day, as new feedback comes from customers. Scrum or other iterative processes don't make sense in this case.
There is a real need for stories that are longer than your iteration length. Kanban, like Scrum, thrives with small stories (better flow, slack, etc.), BUT, unlike Scrum, it DOES at least allow large stories if really necessary.
Extremely fast-paced development. Continuous deployment. Iterations no longer make sense, because maybe you're responding to change lighting-quick, and maybe releasing multiple times a day!
See code.flickr.com:
Flickr was last deployed 4 hours ago, including 8 changes by 2 people.
In the last week there were 85 deploys of 588 changes by 19 people.
Do you think Flickr is doing 2-week iterations, or even 1-day iterations? I doubt it. Looks like they're in super-speed dynamic flow mode... Maybe Kanban, but definitely looks like they're in the Lean umbrella. (Kanban falls under the umbrella of Lean thinking, and continuous deployment was made popular by last year's book by Eric Ries, "The Lean Startup".)
It might not fit in the following environments:
Organizational culture can't get away from up-front planning, overwork/commitment, push instead of pull, fixing all of schedule, scope, and cost, etc. Kanban will start to provoke continuous improvement in an organization, and many are simply opposed to anything but the traditional overengineering, overdocumented, siloed, non-Lean, non-Agile approach that they know and love, which is waterfall. Some government contracts might also fall under this category, although I believe at least DoD is trying to advance Agile in its projects now. But some companies, if you tell them they need to do LESS (i.e., limit work in progress, have a clearer vision, get less stuff done faster, but therefore more stuff done overall), will have a heart attack. Many (most?) companies are addicted to overwork, and think SLACK (which is a fundamental Lean principle) is a 4-letter word. Unfortunately, queuing theory and theory of constraints is hard to get through some people's heads. :) So Kanban might not fit in those kinds of places. ;)
The requirements are, that everyone on the project agrees to use the principles and practices:
Principles
1. Start with what you do now
2. Agree to pursue incremental, evolutionary change
3. Initially, respect current processes, roles, responsibilities and job titles
4. Encourage acts of leaderships at all levels
Practices
1. Visualise what you do / knowledge discovery
2. Limit work in progress
3. Measure and manage flow
4. Make policies explicit
5. Develop feedback mechanisms
6. Improve collaboratively using models and the scientific method
If they don't agree to do that, they can't use kanban. Pretty clear.
Kanban is a tool for visualizing and improving existing processes. If there's a scenario in which it won't work, that scenario would probably have one or both of two properties.
1) There is no existing process or the existing process is such a disaster that it is not working at all and/or is constantly changing in a chaotic manner.
2) There is no will or opportunity to improve.
Lacking the second is not a deal-breaker. Kanban could still help with communication and coordination, and increasing clarity might lead to an increased desire to improve or help establish trust necessary to empower improvement experiments. That would be an example of a low-maturity Kanban implementation leading to a higher level of team maturity.
Kanban is a simple process tool. Applied well, it is good for any project, not just software - any.
In my opinion Kanban can be implement in any kind of organization and in any industry.
But...
the team must be ready for a change
the change must has an evolutionary character
the organization must be focused on cooperation instead of performing routine work.
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.
I've just joined a new company and at the moment we're using Microsoft SourceSafe as our repository. The settings aren't ideal and it's proving to be a big pain in the neck.
I've recently used Mercurial and thought it was amazing, so I'm advocating switching to that, but it looks like the company already has a Team Foundation Server licence and wants to use that instead.
Can anyone give me a list of points where one is better than the other? I've not used TFS and so I don't know what it's good/bad at.
You cannot directly compare TFS and a DVCS.
If your company leans toward TFS, that may be because of the other features TFS comes with (data collection, reporting, and project tracking, all well integrated with Microsoft products)
On the pure Version-Control side, the Team Foundation Server 2010, with its Team Foundation Version Control (TFVC) 2010, introduces branches as first-class citizen.
See Team Foundation Server and branching characteristics, compared to others.
I still find their branching models more complex than a Mercurial or Git one.
See TFS2010 Branching into a subfolder of another branch vs. Guide to Branching Model in Mercurial (and this SO question which also details merges and branches with DVCS)
That being said, it remains a CVCS (Centralized VCS), meaning you get different working processes than with a DVCS: see Describe your workflow of using version control (VCS or DVCS).
The true killer feature of a DVCS remains its merge capability (simpler and faster than any CVCS).
But introducing a DVCS in a corporate environment remains hard.
I recommend Joel on Software http://hginit.com for a list of very good reasons to switch to distributed version control.
I have found a few gotchas with TFS that make it a little different than other CVCS.
TFS is very difficult to use outside of Visual Studio. Even diffing versions is done inside VS. Personally I only like to use VS for writing code.
We have had lots of issues with dll's and other binary files not updating to the latest version.
TFS makes all your files under version control read-only. This makes modifying files outside of VS very painful. In fact, this is still causing issues with out Silverlight projects in our Continuous Integration build in TFS.
The command line tool for TFS is not easy to use from the command line. (Personally, I like to use the command line)
Background:
My company switched from SVN and TFS and I use Mercurial/Git for my side projects. I also followed this blog about using Mercurial with TFS and it has made my work with TFS much more enjoyable.
TFS is an Application Lifecylce Management Tool not ONLY a source code repository / versioning system.
It's strength's are:
-It's natural integration into Visual Studio (+100)
-It's Full App Lifecycle support from Work Item through Q/A acceptance.
-It's integration with MS Project / Sharepoint, and all the other
hoo-ha's you get
-And now TFS 2012 has added support for "Local Workspaces" which allows
for off-line working, but also allows "Server Workspaces" which is
similiar to TFS 2010.
-Diff on every Check-in / Commit
The Source control side of it is also very strong, however, personally, as long as I can see the entire history, not lose code, and not have my code "stepped on". I could give a darn.
I've been using TFS since 2008 and the latest round of improvement further demonstrates Microsofts commitments to evolving their products and keeping up with industry changes. Personally I love it, but i stay in the Microsoft environment (which i also love).. outside of that, it may not work with everyone's needs.
Now, a few days into working with Mercurial professionally (BitBucket / Mercurial / tortoiseHG / VisualHG ) , i have to say the tools seem a bit dated. The integration with Visual Studio is like luke warm coffee (ho-hum), and the explorer integration takes me back to "the good ol days" when i was lucky to NOT be working on Visual Source Safe.
Another thing to take note of is the ease in migrating from Visual Source Safe into TFS, it's fairly painless.. i recently moved my last companies entire history in VSS into TFS and it just took a couple command line utils and overnight to get all the change history moved over. I was shocked (as where my colleagues) at how easy the migration was, it even kept all the history since the beginning (by request of the powers that be)
I'm definitely biased having worked with MS tools for a long time, but there's not much to source control as long as it works..
If your organization wants to truly manage all aspects of application development, and they haven't got integrated tools or processes yet, TFS will afford them the ability to grow and manage from the get go.
Start with Source Control, end up with specs originated in MS Project, tied to work items tied to Unit Test tied to acceptance tests tied to automated builds and deployments
And Lastly: Burn Down / Velocity Charts
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).
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.
What are the differences between a wiki and a CMS? Is there any?
CMS:
A CMS focuses on content which is then published through standardized templates -- think of an online newspaper as driven by a huge CMS system.
It's about standardized publishing information.
CMS'es usually have a limited group of editors.
Useful for relatively static content, maintained by non-tech people.
Much emphasis on style/presentation: very slick templates so it looks professional.
Wiki:
On the other hand, a wiki focuses on pages where each page represents a topic.
It's much more about collaboratively improving each topic (adding hyperlinks to other topics and websites counts as improving the topic).
Wikis are generally much more open to "the public" (or everybody in the company, vs. just the "internal communication" department).
Wikis are meant to be living, dynamic things, maintained by everybody.
Much emphasis on content: less slick templates but easier to find and update information.
The difference is in the letter "M". A content management system manages content. A CMS often has built-in workflow and other features to make it easier to manage a collection of assets. For example, to move articles from staging to production, to facilitate proofreading, etc.
A wiki is more like a public bulletin board. Anyone can add any content at any time and in any way they choose.
Think of it perhaps as the difference between an IDE and a text editor. Both can be used for many similar tasks but one is a bit more structured than the other.
Of course, the lines can blurr in that some Wikis have tools for managing the content and some CMS's are nothing more than "type here and press the submit button".
Typically a Wiki is community editable, visitors to the site can edit it, take Wikipedia for example. A CMS is more designed typially, for a set of site administrators to manage and display content.
A Wiki is a type of CMS, CMS come in many flavors, but all manage some content somehow. In a wiki's case the content is user-editable and creatable information or articles.
In some cases, a wiki is built on a CMS. A wiki is an application, that people use. A CMS is just a kind of database. CMS's often have front-end administrator applications. However, the point of a CMS is to manage content for some purpose-built front-end application.
CMS is to Wiki as Database is to Financial Application.
In the conceptual world a Wiki is for collectible content, anybody can create, delete, modify any content. Is oriented on knowledge.
A CMS manages content, is oriented on format, form, maintenability.
Some wikis are constructed with an CMS
A CMS is a Content Management System. The idea behind the development of CMS evolved when the need for a Management System amplified. A CMS works as a cornerstone for web development by the help of which a developer can build powerful and feature-rich websites in minimum amount of time and effort. A good and powerful CMS not rectifies the frustrating need of writing repetitive and mundane codes, but also eliminates arduous and heavy tasks involved in building a website or web application.
Wikipedia on the other hand is an information directory. Sites such as Wikipedia can be built on a CMS, for instance The New York Times and TechCrunch is built on WordPress. In regard to information acquisition, Wikipedia is the best place that a user can go for - even better than Google. The number of articles Wikipedia contains is stupendous and highly reliable. The daily number of users depending on Wikipedia for information, itself serves as a testimonial for the service Wiki offers to us users.
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.
The company I work for is wanting to add blog functionality to our website and they were looking to spend an awful amount of money to have some crap being built on top of a CMS they purchased (sitecore). I pointed them to Telligent's Community Server and we had a sales like meeting today to get the Marketing folks on board.
My question is if anyone has had issues working with Community Server, skinning it and extending it?
I wanted to explain a bit why I am thinking Community Server, the company is wanting multiple blogs with multiple authors. I want to be out of the admin part of this as much as possible and didn't think there were too many engines that having multiple blogs didn't mean db work. I also like the other functionality that Community Server provides and think the company will find it useful, particularly the media section as right now we have some really shotty way of dealing with whitepapers and stuff.
edit: We are actually using the Sitecore blog module for a single blog on our intranet (which is actually what the CMS is serving). Some reasoning for why I don't like it for our public site are they are on different servers, it doesn't support multiple authors, there is no built in syndication, it is a little flimsy feeling to me from looking at the source and I personally think the other features of Community Server make its price tag worth it.
another edit: Need to stick to .net software that run on sql server in my company's case, but I don't mind seeing recommendations for others. ExpressionEngine looks promising, will try it out on my personal box.
I've done quite a few projects using Community Server. If you're okay with the out-of-the-box functionality, or you don't mind sticking to the version you start with, I think you'll be very happy.
The times I've run into headaches using CS is when the client wants functionality CS does not provide, but also insists on keeping the ability to upgrade to the latest version whenever Telligent releases an update. You can mostly support that by making all of your changes either in a separate project or by only modifying aspx/ascx files (no codebehinds). Some kind of merge is going to be required though no matter how well you plan it out.
Community Server itself has been very solid for me, but if all you need is a blogging engine then it may be overkill. Skinning it, for example, is quite a bit of work (despite their quite powerful Chameleon theme engine).
I'd probably look closer at one of the dedicated blog engines out there, like BlogEngine.NET, dasBlog or SubText, if that's all you need. Go with Community Server if you think you'll want more "community-focused" features like forums etc.
You can also take a look at Telligent Graffiti CMS.
http://graffiticms.com/
It supports multiple blogs and authors.
Update: It's now open source and available at http://graffiticms.codeplex.com/
Community Server 2008.5 lets you add several members that can post articles. Also with
Community Server 2008.5 you now have wiki's along with forums and the blogs. This probably has one of the better web based admin control panel's I seen in a while. This let's you easily change several things including the site's theme (or skin). To me it is one of the most scalable applications I have seen in a while. We are using it for our site http://knowledgemgmtsolutions.com.
Skinning is pretty straightforward, and the sidebar widgets aren't very difficult to create (if you don't mind building controls in code). The widgets also allow options for the users to customize them in the control panel very easily. I doubt you'll find a strong community of widget builders for Community Server however. Nothing compared to the dev community for blogs like wordpress.
I recommend starting templates from scratch and adding in CS controls as needed, to get the markup you prefer for styling and to use only what you need.
Setting up different roles for users to post to different blogs is also very easy and requires no coding. You can have blog groups, and allow only certain users to post to certain blogs.
Sitecore's Forum module is powered by Community Server and integrated with Sitecore CMS.
Expression Engine with the Multi-Site Manager works great for that kind of situation.
Have you had a look at the Shared Source blog module for Sitecore?