Комментарии 11
Как гласит принцип Парето: на выполнение 20% работы уходит 80% времени.
И если что-то не доделано, то наверняка был повод.
А какой у вас был повод выпускать недописанную статью? Это просто план статьи.
В каждом пункте следовало бы привести расширенную аргументацию. Например, при описании функционала следовало привести перечень необходимых документов, пример их составления и т.д.
При описании кода и комментариев следовало указать, например, степень деталировки.
Если вы это сами не можете или не хотите описывать, то надо было дать ссылку на источники, где все это можно прочитать. А так получилась статья ни о чем.
Документация — это очень дорого. Потом написать доку один раз ещё можно, но держать её в актуальном состоянии — это адский труд. Если у вас нет специального человека для этого, то скорее всего скоро ваши доки устареют и будут враньём. Лучше отсутствие документации, чем устаревшая документация.
Намного лучше и дешевле, чтобы обращался и спрашивал, чем делал какие-то предположения по устаревшей документации. Да даже и не по устаревшей, всегда лучше спросить, чем сделать неправильное предположение.
Не обращаясь за помощью к другим.
Намного лучше и дешевле, чтобы обращался и спрашивал, чем делал какие-то предположения по устаревшей документации. Да даже и не по устаревшей, всегда лучше спросить, чем сделать неправильное предположение.
Это если проект маленький, над ним работает 1-5 человек и кадры не меняются. А когда набирается более 10 человек — все сложнее и сложнее передавать информацию в нужных объемах в нужное время.
UPD: Да, документация — дело дорогое. Но если проект крупный — это этого стоит и дешевле чем вложение ресурсов в решение псевдопроблем из-за ее отсутствия.
UPD: Да, документация — дело дорогое. Но если проект крупный — это этого стоит и дешевле чем вложение ресурсов в решение псевдопроблем из-за ее отсутствия.
Доки писать и сопровождать будет ещё сложнее. А ещё при определённом количестве документации её никто не читает.
Работал на очень больших проектах, как там обычно там всё знает Product Owner или BA и все бегают с вопросами к нему. Обычно, на проекте есть несколько диаграм, на которых всем всё объясняют. Есть history в git с ссылками на задачи и есть описание того, что нужно было сделать в тикете. Хорошо, когда обсуждение тикета ведётся в комментах к тикету. Так что когда начинаешь исследовать проблему, то идёшь в хистори git, потом в тексты тикетов, потом к человеку.
Работал на очень больших проектах, как там обычно там всё знает Product Owner или BA и все бегают с вопросами к нему. Обычно, на проекте есть несколько диаграм, на которых всем всё объясняют. Есть history в git с ссылками на задачи и есть описание того, что нужно было сделать в тикете. Хорошо, когда обсуждение тикета ведётся в комментах к тикету. Так что когда начинаешь исследовать проблему, то идёшь в хистори git, потом в тексты тикетов, потом к человеку.
Хм, на мой взгляд одна из задач QA: владеть информацией о продукте и предоставлять ее. А у владельца и аналитика иных задач с лихвой хватает. И если они будут заниматься ответами на вопросы, то будут меньше времени уделять своим задачам.
Был у меня такой опыт тоже. QA всё знает и все бегают к нему. Метод очень хорош и быстро работает. Но писать доки… я не видел ещё проекта с нормальными доками. Обычно, если продукт нормально развивается, то доки устаревают каждую итерацию.
С комментариями в коде те же уши.
На моём текущем проекте вся докуменация — это несколько гайдлайнов по разработке и где-то десяток диаграмм по бизнес логике.
С комментариями в коде те же уши.
На моём текущем проекте вся докуменация — это несколько гайдлайнов по разработке и где-то десяток диаграмм по бизнес логике.
НЛО прилетело и опубликовало эту надпись здесь
Да, и документация она разная бывает. Всё, что вы описали (тикеты, комменты, история репы) это тоже доки проекта.
Да, верно. Толко тикеты и комменты к коммитам привязаны к конкретному моменту времени. Потому никто не будет считать их актуальными на данный момент. Там сразу понятно, что так было когда-то.
Я про документацию в классическом понимании: wiki-страницы в confluence.
> всегда лучше спросить
Далеко не всегда. Работал в конторе, где (при отсутствии документации) было дешевле по ресурсам разобраться по коду, чем спросить (получить неверный ответ от того, кто, вроде, это разрабатывал, что-то делать на неверных вводных и потом всё равно возвращаться к коду), при наличии документации спрашивать было ещё более глупо (потому как был высок риск столь же неверного ответа).
Далеко не всегда. Работал в конторе, где (при отсутствии документации) было дешевле по ресурсам разобраться по коду, чем спросить (получить неверный ответ от того, кто, вроде, это разрабатывал, что-то делать на неверных вводных и потом всё равно возвращаться к коду), при наличии документации спрашивать было ещё более глупо (потому как был высок риск столь же неверного ответа).
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Взгляд тестировщика на сопровождаемость ПО