Низкое качество stories

[zhuravl]

Местные гении процедурного программирования (работающие в конторе довольно давно) пишут stories не очень качественно. Частенько то, что надо сделать описано только в title. Иногда дают implementation details. Пытался им намекнуть - мол, давайте хотя бы к багам steps to reproduce, screenshots, little bit more context - но нет. Ответ такой, что мол "и так все понятно" или "всем понятно, тебе непонятно" (что собственно так и есть - я пока чаще всех прыгаю из одной части системы в другую) или вместо полного описания какой-нибудь коммент типа "делай так и так, иди сюда". В общем, время расходуется на то, пока поймешь что надо делать. И ладно бы время - хозяин барин, хочешь чтобы я в кроссворды поиграл за твои деньги, я не против. Но они же при этом еще спрашивают - а когда будет готово?)

Что с ними делать? Продолжать мягко говорить в надежде, что когда-нибудь это сработает? Сказать, что не буду делать пока не пойму что вы мне тут понаписали? Подходить к челам и каждый раз разбираться шо таки они имели в виду? Или стукнуть своему менеджеру (который тоже большой любитель таких историй)? Или сразу дать негативный фидбек всем по емайлу - мол, качество историй очень низкое, надо исправлять?

Написать историю - дело 5-10 минут. Не понимаю в чем у них проблема.

[Sergunka]

Местные гении процедурного программирования (работающие в конторе довольно давно) пишут stories не очень качественно. Частенько то, что надо сделать описано только в title. Иногда дают implementation details. Пытался им намекнуть - мол, давайте хотя бы к багам steps to reproduce, screenshots, little bit more context - но нет. Ответ такой, что мол "и так все понятно" или "всем понятно, тебе непонятно" (что собственно так и есть - я пока чаще всех прыгаю из одной части системы в другую) или вместо полного описания какой-нибудь коммент типа "делай так и так, иди сюда". В общем, время расходуется на то, пока поймешь что надо делать. И ладно бы время - хозяин барин, хочешь чтобы я в кроссворды поиграл за твои деньги, я не против. Но они же при этом еще спрашивают - а когда будет готово?)

Что с ними делать? Продолжать мягко говорить в надежде, что когда-нибудь это сработает? Сказать, что не буду делать пока не пойму что вы мне тут понаписали? Подходить к челам и каждый раз разбираться шо таки они имели в виду? Или стукнуть своему менеджеру (который тоже большой любитель таких историй)? Или сразу дать негативный фидбек всем по емайлу - мол, качество историй очень низкое, надо исправлять?

Написать историю - дело 5-10 минут. Не понимаю в чем у них проблема.

Я обычно ставлю блокер в  Jira, что такой то вопрос не документирован. Когда будет готова документация, то продолжу работу на заданием. Это хорошо срабатывает когда довольно много заданий и не сильно парит если одно или два сидят в блокере. Сам понятно документирую свои задания подробно.

[M. Ridcully]

Вы там программы программирует, или рассказы пишете?
"Stories", блин.

[sp123]

Ответ такой, что мол "и так все понятно" или "всем понятно, тебе непонятно"

Вы можете аргументировать тем, что да, сейчас понятно, а через какое-то время кому-то придется искать концы, и будет кирдык.

Это еще что. На прошлой работе начальству показалось мало оджайла, и внедрили некий LeanLab. Одна из свежих идей была избавиться от stories, от слова совсем. Project manager'а под это дело сократили. Тикеты писались от руки на бумажках, бумажки лепились на стену, вертикально разлинованную синей лентой. На утренних летучках начальник двигал бумажки по мере прогресса. Ну, это как бы классический атрибут оджайла, но фишка была в том, что по окончании недельного цикла все бумажки, добравшиеся до правого края, было положено скомкать, сложить в специальный бумажный стаканчик и бросить в мусорное ведро. Концы в воду. Как раз в это время нашему джава гаю дали задание переписать на жабу некий нетривиальный датабазный функционал. Гай взглянул на pl/sql код и ничего не понял. Аналитик, придумавший бизнес-логику, к тому времени уволился. Спасло то, что удалось найти подробную story, написанную тем самым аналитиком ровно год назад. Мораль: без документации жить нельзя.

[adda_]

. Мораль: без документации жить нельзя.

Открыли америку. Правда к сожалению процентов 99% менеджеров этого не знают.

[nyekimov]

У нас практикуется "self-documenting code". Типа названия методов/процедур/переменных должны все объяснять. Ну и плюс комменты канечна.

И чем это поможет кроме как разобраться в коде разработчику? Но все равно без общей картины, а это может быть стори, бывает сложно понять в чем вообще была задача.

[nyekimov]

Я обычно в таких случаях в комментариях спрашиваю в чем мол именно задача и пока не ответит, Тикет в блоке, чтобы именно было доказательство, что я делаю так как просит тот, кто поставил задачу.
Другой вариант делать как хочется и потом если что вернут на доработку. Некоторые ребята пользуются таким методом, особенно если новички и боятся задавать вопросы.

у меня кстати было даже в рамках одной компании, что один прожект менеджер пишет все подробно, уважая своё и чужое время. А другой считал, что его должны понимать с полуслова. Ну я просто свалил с его проектов.

[Сабина]

С этими stories конфликт интересов на самом деле.
Писать их безусловно дожны product owners, посоветотавшись с архитектором. Прихем это не stories, a epics скорее где они расписывают что и как им надо с точки зрения end user functionality. Пусть там пишут million use cases, UI mocks etc. Но им категорически противопоказано писать конкретные implementation stories. Потому что они почти всегда очень слабо представляют как это сделать технически и начинают создавать stories через зад и по ним потом программеру часто нереально отследить progress, написать unit tests etc.

Самый отличный процесс который мне довелось испробовать работал примерно так:

- product owner analyzes user feedback, market and comes up with new features
- product owner discusses it with architect and writes epic with use cases, works with UI folks to build UI mockups etc
- architect comes up with the set of specific stories ( with detailed technical requirements) to implement new epic. He communicates with product owner and developers in the process to make sure to build realistic roadmap with those stories. architect arranges those stories in backlog ( in the right priority) to ensure roadmap compliance
- developers go over the backlog in planning and implement stories ( i.e. new feature) from sprint to sprint.

Ну и конечно всега будет что то неучтено, будут меняться приоритеты, что то будет убираться - добавлсяться. Но при таком подходе pain the ass is minimized

[Мальчик-Одуванчик]

То есть более-менее продуманное решение сводится к банальному ватерфоллу.

[oshibka_residenta]

Пытался им намекнуть - мол, давайте хотя бы к багам steps to reproduce, screenshots, little bit more context - но нет. Ответ такой, что мол "и так все понятно" или "всем понятно, тебе непонятно"
....
Или сразу дать негативный фидбек всем по емайлу - мол, качество историй очень низкое, надо исправлять?

Негативный email - big no-no Сразу станете не team player и вообще редиска.

Нужен positive reinforcement. Написали хорошо: похвалите, написали плохо - пишите, что их описание не дает reproduce bug, ну и reject r

[Мальчик-Одуванчик]

Пытался им намекнуть - мол, давайте хотя бы к багам steps to reproduce, screenshots, little bit more context - но нет. Ответ такой, что мол "и так все понятно" или "всем понятно, тебе непонятно"
....
Или сразу дать негативный фидбек всем по емайлу - мол, качество историй очень низкое, надо исправлять?

Негативный email - big no-no Сразу станете не team player и вообще редиска.

Нужен positive reinforcement. Написали хорошо: похвалите, написали плохо - пишите, что их описание не дает reproduce bug, ну и reject r

Китайские церемонии в действии..

[adda_]

У нас практикуется "self-documenting code". Типа названия методов/процедур/переменных должны все объяснять. Ну и плюс комменты канечна.

Это помогает понять логику которая имплементирована причем для относительно небольшого объяма кода. Для того чтобы увидеть картину в целом этого может быть мало. Тут действительно нужна документация где описан бизнес процесс с точки зрения пользователя и взаимодействия системы с внешним миром.
Я столкнулся с этой проблемой придя туда где работаю ноне. Оказалось что имеется какая то документация написанная лет десять назад и не обновлявшаяся все это время. Причем для той части проекта где я оказался, не было практичски ничего. В итоге пришлось делать реверс инженеринг и восстанавливать все, поскольку часть постановщиков задач уже давно уволилась. А те кто остался не сильно хотели делиться информацией. Первый год был супер кошмарным.

[oshibka_residenta]

Оказалось что имеется какая то документация написанная лет десять назад и не обновлявшаяся все это время. Причем для той части проекта где я оказался, не было практичски ничего. В итоге пришлось делать реверс инженеринг и восстанавливать все, поскольку часть постановщиков задач уже давно уволилась. А те кто остался не сильно хотели делиться информацией. Первый год был супер кошмарным.

Удивительно такое читать. Вроде бы в другом топике вы писали, что главное -знать Дельфи, а тут вот как оно оказалось.

[caltrain]

Я обычно ставлю блокер в  Jira, что такой то вопрос не документирован. Когда будет готова документация, то продолжу работу на заданием. Это хорошо срабатывает когда довольно много заданий и не сильно парит если одно или два сидят в блокере. Сам понятно документирую свои задания подробно.

Это хоть и грамотная, но всё равно оборонительная позиция. Получается, что это не вы решаете, хорошо ли вы справляетесь. Как в том мультике "Бегай, Суслик, бегай. Бег мне па-ле-зен /cладко зевая/".

[caltrain]

Местные гении процедурного программирования (работающие в конторе довольно давно) пишут stories не очень качественно. Частенько то, что надо сделать описано только в title. Иногда дают implementation details.

Да, да. Разработчики они были такие же... И в менеджеры их выдвинули не за результаты работы. Просто иногда позже пришедшие не знают деталей вознесения. А знающие... ну, вот их как раз и сдали
К сожалению с ними особо ничего не сделаешь. Главное, их вовремя вычислить и не связываться. Ну, и вести нежную переписку в jire с блокерами и контр-поручениями.

[Prosche]

Местные гении процедурного программирования (работающие в конторе довольно давно) пишут stories не очень качественно. Частенько то, что надо сделать описано только в title. Иногда дают implementation details. Пытался им намекнуть - мол, давайте хотя бы к багам steps to reproduce, screenshots, little bit more context - но нет. Ответ такой, что мол "и так все понятно" или "всем понятно, тебе непонятно" (что собственно так и есть - я пока чаще всех прыгаю из одной части системы в другую) или вместо полного описания какой-нибудь коммент типа "делай так и так, иди сюда". В общем, время расходуется на то, пока поймешь что надо делать. И ладно бы время - хозяин барин, хочешь чтобы я в кроссворды поиграл за твои деньги, я не против. Но они же при этом еще спрашивают - а когда будет готово?)

Что с ними делать? Продолжать мягко говорить в надежде, что когда-нибудь это сработает? Сказать, что не буду делать пока не пойму что вы мне тут понаписали? Подходить к челам и каждый раз разбираться шо таки они имели в виду? Или стукнуть своему менеджеру (который тоже большой любитель таких историй)? Или сразу дать негативный фидбек всем по емайлу - мол, качество историй очень низкое, надо исправлять?

Написать историю - дело 5-10 минут. Не понимаю в чем у них проблема.

Все зависит от методологии которая у вас применяется. Если у вас старый добрый ватерфол, то тут такое вполне уместно, есть FRS, описание архитектуры, прочие документы. Девелоперы делают стори по документу и особо там распинаться нечего, ибо фактически стори для себя пишется или для коллеги читающего тот же документ, дабы тут же заимплементить это дело.
Если же у вас аджайл, к примеру скрам, то тут все иначе, на беклог груминге PO должен приоритезировать ваши сториз, а он вообще не обязан быть техническим специалистом, а дальше во время спринта уже создавайте себе сабтаски какие хотите, хоть с одним тайтлом и "subj." в дескипшене. Но стори должна быть исчерпывающей и понятной. Так же QA вам спасибо скажет за то, что будет понятно что и как тестировать. ИМХО так.

[adda_]

Оказалось что имеется какая то документация написанная лет десять назад и не обновлявшаяся все это время. Причем для той части проекта где я оказался, не было практичски ничего. В итоге пришлось делать реверс инженеринг и восстанавливать все, поскольку часть постановщиков задач уже давно уволилась. А те кто остался не сильно хотели делиться информацией. Первый год был супер кошмарным.

Удивительно такое читать. Вроде бы в другом топике вы писали, что главное -знать Дельфи, а тут вот как оно оказалось.

Наверно ход ваших мыслей слишком сложен для понимания человеком покалеченным Делфями.
Мне скажем сложно представить чтобы человек не знающий языка ХХХ досконально, смог бы сделать реверс инженеринг большой системы за разумное количество времени.
На будущее, я буду вам благодарен, если обращаясь ко мне, вы будете говорить простыми словами, так чтобы даже я мог уловить смысл того, что вы пишите.

[АццкоМото]

У нас практикуется "self-documenting code". Типа названия методов/процедур/переменных должны все объяснять. Ну и плюс комменты канечна.

Self-documenting code совершенно не решает проблему. Возьмем утрированный пример.

Code: Select all

Button button = new Button("Cancel"); // Create a Cancel button
button.setColor(Color.BLUE); // make it blue

И вот что толку с такого "самодокументированного кода", если кнопку решили перекрасить в красный уже полгода назад? Документация должна быть не просто для того, чтобы ее прочитать, а и для того, чтобы был набор артифактов с жизненным циклом, который отслеживается и ничего нигде не теряется, все отслеживается от "вася попросил кнопку перекрасить", через "петя проанализировал и зааппрувил", "сирожа поправил тесты", "сашко закоммитил код в такой-то дев бранч", "пердишь протестировал" и до "ден сяопин выпустил релиз такой-то"

[adda_]

У нас практикуется "self-documenting code". Типа названия методов/процедур/переменных должны все объяснять. Ну и плюс комменты канечна.

Self-documenting code совершенно не решает проблему. Возьмем утрированный пример.

Code: Select all

Button button = new Button("Cancel"); // Create a Cancel button
button.setColor(Color.BLUE); // make it blue

И вот что толку с такого "самодокументированного кода", если кнопку решили перекрасить в красный уже полгода назад? Документация должна быть не просто для того, чтобы ее прочитать, а и для того, чтобы был набор артифактов с жизненным циклом, который отслеживается и ничего нигде не теряется, все отслеживается от "вася попросил кнопку перекрасить", через "петя проанализировал и зааппрувил", "сирожа поправил тесты", "сашко закоммитил код в такой-то дев бранч", "пердишь протестировал" и до "ден сяопин выпустил релиз такой-то"

Это классический пример того что люди не понимают что такое самодокументирующийся код (хотя я бы использовал термин clean code). Я не говорю уж о том, что лет 25 назад в хороших вузах учили что комментарии не должны дублировать то что написано в коде, а добавлять новую информацию. За использование имени "button" я бы увольнял без выходного пособия без разговоров. Читайте книжки молодые люди. Хотя конечно вам не до того, вы изучаете новые фреймворки.

[АццкоМото]

Это классический пример того что люди не понимают что такое самодокументирующийся код (хотя я бы использовал термин clean code). Я не говорю уж о том, что лет 25 назад в хороших вузах учили что комментарии не должны дублировать то что написано в коде, а добавлять новую информацию.

это классический пример, когда человек на седьмом десятке все еще не умеет читать, а апломб - как у 17-летнего. написано же русским языком: "утрированный пример". не доходит? перечитайте

За использование имени "button" я бы увольнял без выходного пособия без разговоров. Читайте книжки молодые люди. Хотя конечно вам не до того, вы изучаете новые фреймворки.

модератор: переход на личность. Предупреждение

а я бы за такие комменты, как ваш просто кастрировал бы. впрочем... в вашем случае это уже не актуально

[Alexander Troyansky]

Это классический пример того что люди не понимают что такое самодокументирующийся код (хотя я бы использовал термин clean code). Я не говорю уж о том, что лет 25 назад в хороших вузах учили что комментарии не должны дублировать то что написано в коде, а добавлять новую информацию.

это классический пример, когда человек на седьмом десятке все еще не умеет читать, а апломб - как у 17-летнего. написано же русским языком: "утрированный пример". не доходит? перечитайте

За использование имени "button" я бы увольнял без выходного пособия без разговоров. Читайте книжки молодые люди. Хотя конечно вам не до того, вы изучаете новые фреймворки.

а я бы за такие комменты, как ваш просто кастрировал бы. впрочем... в вашем случае это уже не актуально

кстати, а, что не так с "button"? Как должно быть? btnCancel? pipkaCancel?

[adda_]

Это классический пример того что люди не понимают что такое самодокументирующийся код (хотя я бы использовал термин clean code). Я не говорю уж о том, что лет 25 назад в хороших вузах учили что комментарии не должны дублировать то что написано в коде, а добавлять новую информацию.

это классический пример, когда человек на седьмом десятке все еще не умеет читать, а апломб - как у 17-летнего. написано же русским языком: "утрированный пример". не доходит? перечитайте

За использование имени "button" я бы увольнял без выходного пособия без разговоров. Читайте книжки молодые люди. Хотя конечно вам не до того, вы изучаете новые фреймворки.

а я бы за такие комменты, как ваш просто кастрировал бы. впрочем... в вашем случае это уже не актуально

модератор: оскорбления - предупреждение

Ну ты и урод бля.. А помню писал мне что то в личку. Такого говнюка как ты на этом форуме искать и искать..

[zhuravl]

Не уходите в оффтопик, за ответы по теме выше спасибо.

[Alexander Troyansky]

Это классический пример того что люди не понимают что такое самодокументирующийся код (хотя я бы использовал термин clean code). Я не говорю уж о том, что лет 25 назад в хороших вузах учили что комментарии не должны дублировать то что написано в коде, а добавлять новую информацию.

это классический пример, когда человек на седьмом десятке все еще не умеет читать, а апломб - как у 17-летнего. написано же русским языком: "утрированный пример". не доходит? перечитайте

За использование имени "button" я бы увольнял без выходного пособия без разговоров. Читайте книжки молодые люди. Хотя конечно вам не до того, вы изучаете новые фреймворки.

а я бы за такие комменты, как ваш просто кастрировал бы. впрочем... в вашем случае это уже не актуально

Ну ты и урод бля.. А помню писал мне что то в личку. Такого говнюка как ты на этом форуме искать и искать..

у кого-то понедельник круто начался

[Alexander Troyansky]

Не уходите в оффтопик, за ответы по теме выше спасибо.

Можно составить список шаблонных вопросов и вставлять их в каждую историю с просьбой дать ответ, так сказать помочь аффтарам:
- номер сборки;
- как часто воспроизводится;
- какие файлы подать;
- какие кнопки (последовательно) нажать;
- какой экепшн;
- что ожидается (и на основании чего);