Hi David,
Some suggestions inlined to yours:
> 1. this thing seems to them as auxiliary automation thing that isn`t cost effective
I like to pitch BDD as an analysis technique which results in tests as a nice side-effect. Even without automation, the conversations can be very effective.
> 2. we have long session (10 appointments of 3-4 hours each of 3 amigo) of discovery but later the PM said that they lacked a lot of details that we talked about it.
I like these conversations to happen as close to the work being done as possible, so right when the dev(s) pick up the story to work on it. If the stories are sliced finely enough, it's only a 5-10 min conversation, and the details stay fresh in everyone's heads. So, lots and lots of small conversations, rather than huge long sessions. (If a dev is waiting there's always refactoring and tidying up and documentation and email to do.)
> 3. later in the dev period which was based on scrum, only then the real and detailed specs were written.
Not a problem if you leave it until they're actually about to code.
> 4. after a bunch of scenarios, we add an UI appendix written with a lot of conditions, sometimes it looks like that appendix were the comfortable and fluent place to the pm to express them self
Right, so BDD isn't the only way to do analysis. It's OK to include detail in other ways, too. The "Test Pyramid" suggests that we should have way more unit tests than end-to-end scenarios, so if you're doing something like validation, for instance, it's OK to have all the tests for that at a unit level. The value of validation is in guiding the user to fill in a form correctly, so just have one example of that at a high level. It takes a bit of practice to work out what to do at a code level and what to do at a system level; generally if it's "the same kind of thing again" lower level unit tests are the way forwards.
You can also bring the UI to the conversation and just write down conditions around it too. I wouldn't expect to see "username field limited to 36 characters" in a BDD scenario, but it's part of the requirements so find a different way to capture that.
> 5. in some sprints (approx. 50 percent) the PM stop writing the gherkin and it became the job of the youngest team mate - the automation developer.
I do actually like it when developers write the Gherkin down. They type fast, and it gives feedback on whether they understood the requirements correctly. I like it better though when it's a record of a conversation between the 3 amigos. These days I advise any PMs, BAs etc. to come to the conversation just with the titles of the scenarios, plus any other information needed to have the conversation (that can all go in a JIRA ticket or equivalent if needed) and then add the record afterwards.
Also nobody talks in terms of Given / When / Then, so as long as the dev reckons they have enough information to do the write-up, you're probably good to go. I usually feed my scenarios back to my Product Owner (by email if necessary) to check that we got everything. It doesn't take long.
> 6. because that most of the develop team sit at other location, it seemed that a lot of the discovery we did during the sprints was on the emails and phone calls. Only after that the automation dev write the specs. (usually accomplished that only in the n+1 sprint)
I've done 3 Amigos via phone call; capture the conversation, write it up later. It's also not completely unusual to discover more scenarios while coding. I suggest limiting conversation and coding to about 7 scenarios at a time; if you need more than that, split the story.
> 7. We talked on the previous on vague scenario and mixture of problem and solution domains so I wouldn`t repeat on that matter.
Cool. Scenarios should usually be problem-domain rather than solution-domain.
> 8. Major Lack from my sight of view is that the PM crew didn`t get direct feedback from the CI system. They had a feedback on the release version of all sprint, but they didn`t see the connection of the BDD process regarded what they got.
Dashboards are your friends. Get it up at the stand-up while you wait for people to arrive. If the build pipelines aren't running green, make that a priority.
> 9. The new programmer said that she`s not gaining much from the specs, only some developer guides who document the software architecture was useful for her.
She might have gained something from learning about the specs in conversation. Having said that, it isn't the only thing that's helpful, so having conversations about architecture etc.. are also a good idea.
Also note that if it's really really boring work that's well-understood, you probably don't need to have the conversations; and if it's highly uncertain work that nobody knows what it looks like, do it early and spike / prototype it until it's understood, then do BDD.
Last thing: