Какой интересный проект. Вот бы ещё кто создал приложение для поиска друзей =) А то знаете, обилие мнений "все ищут секс или спонсоров, но стесняются сказать" вообще не мотивирует знакомиться в приложениях. И когда отношения хотелось найти -- тоже не мотивировало. Получаешь в личку несколько десятков таких убеждённых и сносишь анкету.
Я не писала о ролях, я писала о профессиях, вакансии на которые можно найти на HH. Вы правы, что здесь специализации смешаны с должностями, однако это отражение реального мира с реальными вакансиями. В моей схеме Program Manager соответствует Руководителю группы разработки. Так вот, по Москве сейчас ищут 588 Руководителей группы разработки / тимлидов и всего 14 Program Manager. Вы извините, что короблю ваше чувство прекрасного, но я считаю, что с людьми надо говорить на языке, который используется жизни, а не в туториалах.
Полагаю, человек намекает на роль в Scrum, как выше другой о PO писал. Между тем в списке специальностей хабра фигурируют всяческие разработчики и два программиста.
Я поняла. Я говорю о том, что спустя N лет дельту изменений можно посмотреть и в гит, и в конфлюенс. Причина изменений и там, и там будет указана только в том случае, если её не забыли указать при коммите/сохранении. То есть есть при выборе между этими системами историчность сама по себе бонуса не даёт. И мы хотели иметь плюшку от дельты непосредственно в момент разработки и непосредственно в IDE, чтобы разработчику даже не приходилось её сворачивать и смотреть документацию где-то ещё. И вот это не стрельнуло.
Это понятно, но та же история есть в конфлюенсе. А качественную трассировку версионирование само по себе не обеспечивает, к сожалению. Трассировку обеспечивает только чистоплотность человека, который вносит изменения. Гипотеза была в том, что, работая над задачей, разработчик будет смотреть дельту изменений по ней. Но нет, разработчики предпочли смотреть только итоговую доку.
Спасибо, поняла. Да, при согласовании мы смотрим исходник в гитее и в предпросмотр там же. Там же пишет замечания по коду. Собственно, идея была в том, чтобы согласовывать дельту изменений, а не итоговый вид документа...
Спасибо. Я не сомневаюсь в возможностях Hugo касательно Markdown. Наверное, и для Asciidoc его можно годно кастомизировать, чтобы не извращался над таблицами. Наверное. Но у нас не было времени и свободных рук, чтобы это выяснять. Поэтому и пишу — в полной мере из коробки не поддерживает. Конкретно: в превью документа видим красиво отформатированную таблицу в соответствии с туториалом Аскидока, в хьюго таблица уезжает за границу экрана без возможности горизонтальной прокрутки и выравнивает столбцы, как захочет. Но это всего лишь эстетика. Может быть, ею и занялись бы когда-нибудь, если бы нам удалось выстроить процесс согласования. Провалились мы на нём.
Иногда PO есть, а скрама нет. Невероятно, но факт. Про должности и профессии, пожалуй, справедливо. Что ж, переименую в Продукт-менеджера, раз так коробит.
Скажем так, за десять лет я ни разу не видела PO и PM на одном проекте. Верхний человек проекта назывался по-разному, но его функции были примерно те же с поправкой на тип проекта. И это всегда был один человек. Любопытно, что где-то выделяют двух.
Справедливости ради, системное администрирование я упомянула... Да, не отдельно. Ну как бы если хочешь разрабатывать ПО, то логично идти его разрабатывать или хотя бы внедрять. Думаю, о сисадминах и их путях развития лучше всех напишут сисадмины)
Что как бы намекает на что? Сами-то как давно слышали слово "программист" применимо не к 1С? С#, Java, Go, даже Python преимущественно "разработчики", а не "программисты". Тут все специальности про разработку ПО, вообще-то.
По моей оценке затраты на документирование больше на 40%, но на согласование — в 3-5 раз...
Но верю, что можно внедрить адекватно и без боли.
В восторге от этого инструмента. Спасибо огромное.
А что, свежая идея — вырастить новые суставы взамен поражённых! Отличное лекарство!
Какой интересный проект.
Вот бы ещё кто создал приложение для поиска друзей =)
А то знаете, обилие мнений "все ищут секс или спонсоров, но стесняются сказать" вообще не мотивирует знакомиться в приложениях. И когда отношения хотелось найти -- тоже не мотивировало. Получаешь в личку несколько десятков таких убеждённых и сносишь анкету.
Спасибо.
О, да, была бы бомба
Я не писала о ролях, я писала о профессиях, вакансии на которые можно найти на HH. Вы правы, что здесь специализации смешаны с должностями, однако это отражение реального мира с реальными вакансиями.
В моей схеме Program Manager соответствует Руководителю группы разработки. Так вот, по Москве сейчас ищут 588 Руководителей группы разработки / тимлидов и всего 14 Program Manager. Вы извините, что короблю ваше чувство прекрасного, но я считаю, что с людьми надо говорить на языке, который используется жизни, а не в туториалах.
Полагаю, человек намекает на роль в Scrum, как выше другой о PO писал. Между тем в списке специальностей хабра фигурируют всяческие разработчики и два программиста.
Я поняла. Я говорю о том, что спустя N лет дельту изменений можно посмотреть и в гит, и в конфлюенс. Причина изменений и там, и там будет указана только в том случае, если её не забыли указать при коммите/сохранении.
То есть есть при выборе между этими системами историчность сама по себе бонуса не даёт.
И мы хотели иметь плюшку от дельты непосредственно в момент разработки и непосредственно в IDE, чтобы разработчику даже не приходилось её сворачивать и смотреть документацию где-то ещё. И вот это не стрельнуло.
Выглядит здорово, но мы не пробовали. Ограничение: опенсорс либо отечественное ПО...
Это понятно, но та же история есть в конфлюенсе. А качественную трассировку версионирование само по себе не обеспечивает, к сожалению. Трассировку обеспечивает только чистоплотность человека, который вносит изменения.
Гипотеза была в том, что, работая над задачей, разработчик будет смотреть дельту изменений по ней. Но нет, разработчики предпочли смотреть только итоговую доку.
Спасибо, поняла.
Да, при согласовании мы смотрим исходник в гитее и в предпросмотр там же. Там же пишет замечания по коду.
Собственно, идея была в том, чтобы согласовывать дельту изменений, а не итоговый вид документа...
Спасибо. Я не сомневаюсь в возможностях Hugo касательно Markdown. Наверное, и для Asciidoc его можно годно кастомизировать, чтобы не извращался над таблицами. Наверное. Но у нас не было времени и свободных рук, чтобы это выяснять. Поэтому и пишу — в полной мере из коробки не поддерживает.
Конкретно: в превью документа видим красиво отформатированную таблицу в соответствии с туториалом Аскидока, в хьюго таблица уезжает за границу экрана без возможности горизонтальной прокрутки и выравнивает столбцы, как захочет.
Но это всего лишь эстетика. Может быть, ею и занялись бы когда-нибудь, если бы нам удалось выстроить процесс согласования. Провалились мы на нём.
Разметку пишем ручками, да, но это не теги.
Вот так исходник выглядит:
Иногда PO есть, а скрама нет. Невероятно, но факт. Про должности и профессии, пожалуй, справедливо. Что ж, переименую в Продукт-менеджера, раз так коробит.
Я поняла) Мне ваше наблюдение показалось интересным.
Скажем так, за десять лет я ни разу не видела PO и PM на одном проекте. Верхний человек проекта назывался по-разному, но его функции были примерно те же с поправкой на тип проекта. И это всегда был один человек.
Любопытно, что где-то выделяют двух.
Справедливости ради, системное администрирование я упомянула... Да, не отдельно. Ну как бы если хочешь разрабатывать ПО, то логично идти его разрабатывать или хотя бы внедрять.
Думаю, о сисадминах и их путях развития лучше всех напишут сисадмины)
Что как бы намекает на что? Сами-то как давно слышали слово "программист" применимо не к 1С? С#, Java, Go, даже Python преимущественно "разработчики", а не "программисты". Тут все специальности про разработку ПО, вообще-то.
Ревью при пулреквестах. У нас ревьюят лиды разработки, а не те разработчики, которые будут пилить задачу.