I want to assign a resource -Excavator- to a task -Task#1 : duration = 4 month- : 2 units in first 2 months and 5 units in second 2 months.

I am the Agile Coach for a team which comprises of 4 completely different platforms (iOS, Android, Javascript, Windows) each with 1 or 2 engineers. There are 2 automated/manual testers in total and 1 PO.

All 4 platforms work from precisely the same backlog of user stories (we have separate identical user stories for each platform.

Currently we have a single kanban board in Jira pulling data from 4 different projects. We have a swimlane for each platform but share WIP limits, standups, retro's and demos.

Current problems:

• Different platforms switch off during stand-ups since they only care about their platform
• Different platforms don't work with other platform team members since they only care about their own platform
• There is no team cohesion across platforms just silos
• Team members don't help team members on other platforms
• There is no technical leadership across all the platforms

The question is, should these platforms bit split into 3 different teams or what technique could I use to fix this?

This depends on who you are trying to secure it against. The most common scenario is you want to prevent identity theft or/and keep information a secret from your room-mate or relative.

An identity thief will not be spending hours of his time cracking files of one individual considering slim chances of success and questionable outcome. That's way too much effort for them. Unless you are a multimillionaire which I doubt considering you are here

As long as you relatives are not security researchers they shouldn't be an issue.

However if you are a person of interest for FBI / NSA / CIA etc then I'd recommend solutions that provide plausible deniability in conjunction with a good lawyer

Ansible v2.5 introduced a new "running" state for the service module, the doc is not saying anything about it.

started/stopped are idempotent actions that will not run commands unless necessary. restarted will always bounce the service. reloaded will always reload. At least one of state and enabled are required. Note that reloaded will start the service if it is not already started, even if your chosen init system wouldn't normally.

I presume it checks if the service is running and starts it if not, but this is exactly what the started state does.

What differs the running state from the started state ?

It looks like there exists a plugin to do exactly what you want: Display console output plugin.

However, I haven't tried this plugin myself, and it looks like this plugin is not well-maintained, so I cannot vouch for the quality of this plugin.

As far as I know internal SSL is also required. CC data needs to be encrypted in transit, and that includes both public and private networks. Depending what your apps connect to it it also means connections from applications to the DB/messaging systems/you name it... and also if you use an CDN/SSL accelerator like Akamai, the SSL accelerator shouldn't see the plain CC details, unless they are PCI Certified themselves on the services you use AND you need to have evidence they are certified (aka a signed document, which usually costs a pile of money, saying they are certified).

Reference: Talks with a QSAs.

A retrospective is a chance for the team to review and reflect on their way of working - the things that went well, the things that didn't go well, and potential improvements. The Principles Behind the Agile Manifesto says that teams reflect on "how to become more effective" and then "tune and adjust its behavior accordingly" "at regular intervals". In Scrum, this is embodied in the Sprint Retrospective and is held by the Scrum Team (the Development Team, the Scrum Master, and the Product Owner).

It is preferable that the team participates without too much outside influence. The team should have a good deal of trust and respect, and keeping the event to the team encourages openness and more free discussion. However, there may be instances where it's beneficial to bring in people from outside the team. However, this should generally be done with the team's consent beforehand.

The four main components are people, process, tools, and relationships. These aren't restricted to things that are internal to the team - if the team had big successes or had to overcome problems with working with people outside the team, that should come up at a retrospective. However, not every problem is solvable by the team - some are broader, strategic or organizational problems. The team can identify these as problems, work on mitigation strategies, but should generally escalate these to be solved at a higher level.

I'm guessing this question will seem incredibly trivial for some readers, but as someone who is a developer but with little experience of deploying apps in anything other than a manual, hit and hope sort of a way, I hope you will understand that it's quite daunting to see the number of different approaches and tools there are, so I could do with a bit of advice to get me started in the right direction.

I am a developer, now only in my spare time, which is limited. Up to now I have worked with Java, building webapps, and have been reasonably happy with deploying a war file to a Tomcat environment which keeps things nicely encapsulated.

I am now working in Python and Django, but as I get closer to the point where I need to deploy, I want to set up a solid devops workflow to automate as much as I can and ensure I can deploy reliably, but given that my use case is relatively simple, I want to avoid learning a big fat toolset which is over-engineered for my needs and which requires a big investment of time I would rather use coding my app.

So I am looking for a middle ground which allows me reliably to deploy and manage my app(s) without investing a huge amount of time setting up and learning a big devops ecosystem.

Some more details...

Context

1. I develop on a Mac, using PyCharm to build Django 2, Python 3.
2. I use git (but not on github) to manage software versioning.
3. I am comfortable with other languages and scripting languages and have written a few (probably fairly amateurish) bash scripts, although I don't enjoy bash. I've also dabbled with Perl, which I realised isn't really a language for dabbling (i.e. you need to spend time learning it properly)
4. I intend to deploy on a VPS environment, probably DigitalOcean.
5. My app isn't mission critical but it is important that I know if the site goes down, and need to have a way of reliably recovering if it does, whether this be restarting the app, restarting the server, or moving to another server (or other).

Specific Requirements

1. Ability to set up a new environment to receive the app.

   Up to now while I am learning, this has been manual, and every time I have done it I have started from scratch with a new Droplet. I would like this to be much simpler (automated) so that if I have to set up a new environment in an emergency I can do so reliably.

2. Ability to deploy the app to a staging environment which is as identical to the live as possible, ideally as an automated process triggered by a git push using a continuous integration approach (which I have never done before).

3. Ability to "press the button" when I am happy with the app in the staging environment to push to a live environment ideally automatically.

4. Way to monitor the site (just a poll to a page will do)

5. Way to switch live site to another server if I need to recover from an app or server failure on the live site. I think maybe a Blue-Green approach would work for me?

What have I tried or considered?

• Manual set up of live environment with Django app, then manually copy new codebase to it when there is a change. This feels prone to human error and I fear making a mistake in a deploy causing an un-recoverable failure.

• Docker. I admit when I found out about Docker it seemed like a dream come true but after a bit of experimenting and research I am daunted by how much I need to learn and know to get this up and running and to manage it. It may be that this is worth it because once it's working it is very low risk but at the moment it feels like a larger investment of my time than I am hoping for.

• Bash scripts. Use them to set up the original environment and for specific tasks like updating the app. My worry about this is that the scripts will be code which needs testing and I fear it would take a lot of time to build a reliable toolset this way.

• I've looked at Digital Ocean's options for floating IP addresses and the ability to have two servers for a "blue green" approach which seems quite sensible. If I go this route I still need to be able to automate the deployment.

So... I am looking for advice on a devops approach which finds the right balance between minimising risk (e.g. the risk of breaking the live app with an update, or the risk of being unable to recover from a failure) and minimising the time investment I need to make to set up the environments and workflow.

I can try to provide some information here. It is almost impossible to say if Scrum, Kanban, or DevOps is applicable to your exact situation, but I can see benefits of any of these.

Kanban

The goal of Kanban is to simply improve process. There is no process that is not potentially benefited by Kanban. The key steps here are to visualize your workflows that you mention in your question and then using a taskboard or some other mechanism, watch as work items flow through those steps. Note that you want the value-delivery item (analysis of a business question, for example) to flow through the steps, not individual tasks. This, plus the other rules Kanban puts into place, like limiting work in progress, will show you where your bottlenecks and inefficiencies are in your process. Then, try small experimental improvements to change your process for the better.

Scrum

Scrum is great at iterating on a problem. Let's say you're trying to improve market impact with your data analysis. Scrum is going to ask you to plan a small targeted analysis inside of a sprint that changes and advances your view of the problem. Then you'll decide what the right next analysis is to take it further in the next sprint. There is a lot of potential here, but some of the common practices that have arisen in scrum are focused on product creation and you might need to leave those pieces behind.

DevOps

The problem that DevOps solves is that software teams were calling things "Done" but those things had to go through a long process before they were deployed and "Accessible" by the person using it. If you have this problem, that work is "done" but not accessible by the people who use it for some time, this might help you. Now, the tools that most people are using probably won't if you aren't building and deploying software, but the ideas and techniques around the processes in DevOps are probably applicable.

I'm going to answer this assuming you mean Certified Meeting Planner. If that's not the case, my apologies.

TL;DR- Absolutely! In my opinion event planning is a highly specialized kind of project management.

My wife was an event planner for a long time. She went through the process to become a CMP and between that and watching her plan and run large events, I know she'd be an awesome project manager and that the hours she put into doing events would apply as projects.

Just remember, PMI doesn't care if you have a CMP. It is just that the same kind of work you did that qualified for a CMP application is also going to be usable in the PMP application.