В теме 1 ответ, и 2 участника, последнее обновление сделано пользователем 
Герман Шестеров 14 г, 2 мес. назад.
Показано 2 ответа - от 1 до 2 (всего 2)
-
Сообщения
-
Я вот считаю, что аналитик имеет прямое отношение к SDLC (процессам разработки ПО). Более того, я лично считаю, что именно аналитики должны заниматься выработкой подходящего / адаптацией существующих, внедрением и поддержанием (всё это по согласованию с ПМом, конечно) SDLC на проекте. Ну это личное мнение, но дело не в этом.
А вопросы такие: по каким SDLC вы работали / работаете? Какие вам понравились, какие нет? и почему?
Юрий, я так понял, вы имеете в виду методологии разработки ПО, то бишь водопадная, scrum и т.п.? Я ни в коем случае не доколебываюсь к терминам, просто хотел уточнить
, потому что в плане именно видов SDLC я ничего не знаю и может сейчас пойду рассуждать в неверном направлении 
.
Да, я абсолютно согласен, что аналитик имеет прямое отношение к SDLC и в целом — аналитик, как в принципе и любой другой участник разработки, должен знать и понимать процесс разработки, его виды и их особенности.
Я работал на проектах, организованных по таким методологиям:
1) Waterfall ("водопадка", tollgate). Процесс, на мой взгляд, устаревший и неактуальный в наши суровые времена выживания и конкуренции. Удобен и интуитивно понятен своей простотой, но весьма неэффективен. Пытались по нему работать (по инициативе самого заказчика), но вскоре отказались (опять же по инициативе заказчика). Кастомер поигрался и понял, что получая организованность и прозрачность, он жертвует скоростью и гибкостью.
2) Спиральная модель. В принципе — этой мой выбор процесса разработки. Нечто среднее, как мне кажется, между водопадом и agile. Средняя степень гибкости + значительная степень организованности и контролируемости. Мы работали с заказчиком по такой системе долгое время, пока не наступила необходимость "делать быстрее".
3) Agile Development. Мне лично не нравится, потому что у нас agile понимают немного по-своему, а именно: делай быстро и качественно, но при этом достаточно ресурсов на проект не дадим, так как на дворе сложная экономическая ситуация… Если говорить для меня как аналитика, то это вообще катастрофа — я люблю ответственно подходить к работе, и если уж разрабатывать требования к системе, то делать это качественно. А здесь приходится долго думать над средним между временем и достаточностью. В итоге требованиями получаются неполными и некачественными. Остается только слезами обливаться и тосковать по "характеристикам превосходных требований" Вигерса
Есть, конечно, и другие методологии процесса разработки, но во-первых на мой взгляд границы между ними немного размыты, а во-вторых мало кто официально объявляет, что вот этот проект "будем делать так", поэтому приходится самому анализировать ситуацию и пытаться понять, а под какой же процесс подходит то, как мы сейчас работаем. Ну ведь на то мы и аналитики, ведь так?
Показано 2 ответа - от 1 до 2 (всего 2)
Вы должны авторизироваться для ответа в этой теме.
