Позвольте могущественному , SecretGeeek учит Вас , как быть автономным программистом . Наслаждайтесь:)

   intellisense 
        ||
        \/
       code >>> compile >>>>> run >>>> success >>>> profit ;-)
        /\         ||          ||         
        ^^         \/          \/
        ^^      errors       errors 
        ^^          \\       //
        ^^           \\     //
        ^^             google
        ^^              ||
        \\              \/
         \<<<<<<<  copy N paste

TODO управляемая разработка

А серьезный предложение от SecretGeek.

Настроенный Ваша среда разработки или редактор для автоматического списка всех строк с тегами TODO - Visual Studio делает это по умолчанию.

Класс Записи Шага 1

• или основы метода (т.е., 'Общедоступный Класс...' или 'Общедоступный Sub...' без кода внутри.)
• Включают грубую логику
• , Добавляет псевдо код preprended с "TODO":
• Только пишут очень тривиальный код - что-либо еще просто добавляет шаг 1 Повторения шага 2

  • TODO

  , пока целое приложение не набросано вчерне
• , Вы теперь получили большой список задач 'TODO'
• , Проверка на полноту (ширина)
• Видит то, что может быть удалено.
• Видят то, что может быть упрощено (например, два подобных комментария todo: они могут быть сделаны идентичными?

TODO's Замены Шага 3

• с вызовами к несуществующим классам, методы и т.д. (Для разработки через тестирование, создают исчерпывающие тесты для каждого из этих методов/классов)

, Шаг 4

• Фиксирует Одну Ошибку компиляции за один раз:
  • оболочки записи классов, методы и т.д.,
  • Добавление TODO: псевдо код к каждому из них, когда Вы идете.
  • (Также Добавляют 'ВЗЛОМ': комментарии и объяснения в соответствующих случаях, если испытывающий нехватку времени)
  • В соответствующих случаях, TODO's замены с тривиальным кодом, требуемым

Шаг 4 Повторения Шага 5

• , пока нет никаких оставленных ошибок компиляции.
• , Если существует оставленный TODO's, то Вернитесь к шагу 3.

(существует также большое предшествующее планирование, бумажная разработка прототипа, встречи клиентов, обсуждение, промедление, проектирование баз данных, питье кофе, генерация кода для sprocs и вызовов грязи-sproc, импорт допускающего повторное использование DAL, использование блока ПАГА, идет ПАГ!, назад и вперед дебатирует до выхода документа, аргументов, последние ночи, разочарование, болтающее с друзьями, отсеивающими по электронной почте, царапающей в Visio, распечатывая вещи и оставляя их в "куче", добывая главные продукты, ловя шины, делая фрагменты спины и шеи и т.д., но это было все не учтено для простоты...)

(MarkJ снова) Немного как процесс программирования псевдокода от Код, Завершенный . И все мы соглашаемся , все прочитали Код, должен Завершиться, правильно?

Я рекомендовал бы Совершенно прозрачный метод

Эти Семь Свойств

• , Частая доставка/интеграция с помощью упакованных временем повторений
• Отражает и улучшает, критикует и фиксирует
• Осмотическое (пассивное) приобретение знаний и коммуникация через офисную организацию и открытые каналы
• Личная безопасность, безопасная честно говоря, уверенность для ухаживания за критикой
• Остается сфокусированные, ясные задачи, приоритеты на работе, ограничивает рабочую нагрузку
• Доступ к опытным пользователям, быстро, качественная обратная связь
• обычный гибкий материал: автоматизированное тестирование, CM, непрерывная интеграция

Большинство гибких методологий соответствует Вашему профилю.

самое популярное в настоящее время ТОЛПА . Это разработано для производительности в малочисленных командах, и это - вентиляторы, утверждают, что время разработки в 5-10 раз лучше, чем традиционные методологии водопада.

я рекомендую Головой вперед Разработка программного обеспечения книга, если Вы хотите начать на некотором чтении

Не прямой ответ на ваш вопрос, но у Стива МакКоннелла есть статья под названием Меньше значит больше , написанная более десяти лет назад, о том, почему небольшие команды более продуктивны.

Непрерывная интеграция - это первое, что я всегда пытаюсь создать в командах, над которыми я работаю, поскольку я считаю, что это основа хороших практик разработки, то есть частая интеграция, автоматическая сборка / выпуск, самотестирование сборка, легко получить последнюю версию.

Подробнее об этом здесь: http://martinfowler.com/articles/continuousIntegration.html

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

Если вы работаете над небольшими проектами, то любой Agile метод должен делать. GTD - это не метод, это метод подражателя. Это как если бы я запатентовал свой мозговой процесс.