Во многих организациях есть внутренние проекты, которыми занимается программисты ИТ-отдела. Такие проекты часто скатываются в говно (как программное обеспечение), ибо релизить не надо, все пользователи под боком, на проблемы апгрейда-миграции пофиг — весьма распространённое мнение, между прочим. Намерения у программистов может и благие, но результат почти всегда плачевен: обязательно настанет время, когда прибить новый костыль к программе окажется некуда.

Совсем печально становится, когда такой проект достаётся «в наследство» от предыдущих поколений программистов. Многие программисты считают, что такой проект — это карьерный тупик, поэтому найти квалифицированного разработчика на легаси (=legacy) проект часто очень сложно — они воспринимают такую работу как нечто вроде ИТ-ассенизатора. В чём-то они правы, однако не всё так плохо, поскольку такая работа предоставляет редкий шанс проявить себя в роли «решателя проблем» — весьма полезный навык, пригодится в будущем, если решите пойти по менеджерской лестнице.

Перевод статьи Майкла Чёрча Don’t waste your time in crappy startup jobs.

То, о чём я хочу рассказать, справедливо для июля 2012 г. 15 лет назад необязательно было так же, и не факт, что будет справедливо через год. Но в данный момент это абсолютно верно для большинства людей в достаточной степени, так что я считаю обязанным высказаться. Нынешний мир ИК-стартапов (ИК=инвестиционный капитал / venture capital) — я его нежно называю ИК-стан — является, мягко говоря, тотально напрасной тратой времени для большинства вовлечённых людей.

Продолжу тему айтишных книг, начатую вот в этом посте. Прошло уже три года, некоторые книжки переосмыслились, накопился новый опыт, прочитались новые книжки.

На этот раз я решил не ограничиваться простым перечислением списка, а описать свои впечатления и размышления от каждой книги. Если название и авторы книги указаны по-русски, то книга читалась в переводе; если по-английски, то читалась в по-английски в оригинале.

Пост будет периодически обновляться. Последнее обновление: 22 ноября 2012 г.

Перевод на русский язык статьи Why Software Projects are Terrible and How Not To Fix Them.

Если вы хороший разработчик и работаете в дурной фирме, вам часто приходят в голову идеи об улучшении рабочего процесса.

Очередная статья из цикла, посвящённого системам управления проектом (процессом). На этот раз немного структурированного формализма: общий план, сравнения, цели, перспективы. По сути, этот текст — самый первый документ, который пишется перед началом любого проекта. Целью проекта является продукт.

Эту статью можно рассматривать как первый шаг в долгом пути построения системы управления софтварным проектом. Под «софтварным проектом» я имею в виду создание программного продукта. А под «системой управления» — интегрированный набор инструментальных средств, обеспечивающих (и автоматизирующих) различные этапы создания продукта. В статье же пойдёт речь о самых базовых вещах, например, целевой аудитории подобной системы.

У каждого программного проекта есть жизненный цикл. Для разных этапов такого цикла есть средства управления — багтрекеры, системы документирования, тестирования. Однако хочется найти полноценную систему для управления всеми этапами жизненного цикла проекта.

Если совсем упрощать, этапы жизненного цикла такие:

• сбор требований
• проектирование
• реализация
  • рецензирование кода
  • контроль исполнения задач
• тестирование
• внедрение
• поддержка/сопровождение

Для некоторых этапов есть различные инструментальные средства, например, для автоматизации тестирования есть TestLink, для контроля исполнения задач — разнообразные трекеры, например, Bugzilla, JIRA, Trac; для документирования есть разнообразные WIKI-системы. Есть попытки построить интегрированные решения из нескольких компнентов, например, линейка продуктов компании Atlassian — Confluence, JIRA и другие. Однако полноценного продукта, охватывающего ВСЕ этапы, мне не встречалось вообще.

Далее пойдут мои размышления на тему ожидаемой функциональности от подобного продукта.