Чи може фрілансер використовувати спритний розвиток?

Я хочу вдосконалити спосіб розробки програмного забезпечення. Я хочу розвиватися швидше і чудовий код! Сьогодні я використовую метод водоспаду як фрілансер, пишучи веб-речі (сайти, системи тощо). Чи є спосіб використовувати гнучку розробку (XP, SCRUM тощо), що працює таким чином? Я не знаю нічого про спритний розвиток, з чого мені почати? Велике спасибі.

... Окрім парного програмування, звичайно. ;-)

Серйозно кажучи, я теж фрілансер, і максимально використовую спритні прийоми. Це працює для мене дуже добре. Я дуже використовую TDD,

Ніхто ніде не використовує 100% XP або Scrum, але всі користуються його частинами, намагаючись перейняти стільки, скільки працює для них. На мою думку, чим більше ти приймаєш, тим краще тобі.

Що мені найбільше не вистачає, це парне програмування. Те, як ви подолали це

1. Ходіть на безліч зустрічей груп користувачів.
2. Знайдіть пару людей, яких ви поважаєте як розробників.
3. Попросіть їх познайомитись за кавою чи щось написати код. Час віддавайте їм частину своєї заробітної плати, якщо вам здається, що це потрібно або просто натурою відповісти на роботу над їх кодом.
4. Відвідайте або створіть подібний хак-клуб: http://www.DallasHackClub.org .

Ось деякі ресурси, які я використовую:

• Екстремальне програмування - онлайн-швидке, але ретельне керівництво по XP.
• Чудовий огляд Scrum .
• Фантастична та коротка книга . Ідеально для вас!

Тому я б сказав, що є три основні "дивовижні моменти" щодо використання Agile як фрілансера:

1. Для великих клієнтів Робота / рахунок в ітераціях. Після закінчення ітерації замовник може продовжити роботу над проектом або закінчити проект (тобто: він досяг своєї мети). Я знаю (з досвіду) я не можу добре оцінити більше декількох тижнів, а оплата за ітерацію також підтримує надходження грошових потоків. Не весело бути в 6 місяці 3-місячного проекту та чекати щоб закінчити проект, щоб ви могли ...

2. Спритний означає, що зміни відбуваються. Я зробив тону проектів з фіксованими ставками (які, на вашу думку, можна зробити з водоспадом), які втратили мені гроші через запит клієнта в середині циклу. Зміни трапляються: замовник може деприоритизувати квиток, щоб швидше виконати іншу роботу, або, можливо, ви пророкували неправильно і не зробили так багато, як ви сподівалися.

3. Хороші інструменти співпраці з клієнтами. Моя стандартна оцінка (для чогось меншого, ніж вартість роботи ітерації) - це насправді серія кроків розвитку, керованої поведінкою, що випливає з очікувань клієнта. Я надсилаю це клієнту і кажу "Це правильно?". Це гарантує, що всі знаходяться на одній сторінці.

4. Найпростіша річ, яка могла б працювати. Це щось, що слід пам’ятати, коли ви працюєте: не бійтеся повертатися до клієнта і сказати: «Це було б набагато простіше (або потужніше, або будь-що інше), якби ми зробили це таким чином ... "

5. Scrum важливий. Мені подобається щодня надсилати своїм клієнтам електронний лист, коли я працюю над їх проектом. Це як моє враження до них: «над чим я працював сьогодні», «над чим / коли я буду працювати над їхнім проектом далі?», «Чи є щось на шляху?» Та «загалом, як просувається прогрес ? "

6. Тестова розробка також дуже корисна, навіть як один програміст. Мої "оцінки з розповідей BDD в них" допомагають мені підгодувати цей процес.

Чудовий спосіб почати свою Agile подорож - налаштувати робочий процес за допомогою системи KANBAN.

У нас просто 3 плавника:

1. Наші завдання чи репутація
2. Над тим, над чим ми працюємо, або В ПРОГРАМІ
3. Речі, які ми доробляємо або РОБОТИ.

Цей простий робочий процес Agile - це чудовий спосіб почати.

Щодо кодування, я б рекомендував використовувати тестово-розроблену розробку (TDD). Ми включили в нашу статтю багато чудових посилань, що описують TDD, але їх повторно скопіюйте тут:

Для отримання додаткової інформації перегляньте такі ресурси:

• AgileData.org - чудовий ресурс для тестової розробки.
• JamesShore.com - ще одна велика поломка TDD
• Net Tuts - цікаве вступ до TDD, який мені подобається!
• Артима - Інтерв'ю з Мартіном Фаулером
• Ігри зсередини - хороший тематичний приклад TDD
• DaniWeb - знайомство з TDD для розробників
• Марк Левісон - Стаття про TDD

Оскільки ваша особа, вам краще підходити до спритних методологій як до чогось, що є, щоб допомогти вам зрозуміти, що найкраще працює для вас . Вони там, щоб допомогти вам досягти того, що плато "немає ложки", але як саме це відбудеться, залежить тільки від вас, і те, що ви придумаєте, врешті-решт, сильно збігатиметься з деякими методологіями на різних рівнях. це буде щось абсолютно твоє.

Оскільки ви намагаєтеся знайти свій власний шлях, щоб покращити загальну ефективність, ось деякі вказівки, які можуть допомогти вам принаймні не робити тих самих помилок, які я робив:

Відмовтесь від усіх програмних рішень, орієнтованих виключно на гнучкі методології, наскільки це можливо.

Справа в тому, що вони більше підходять для полегшення колективної співпраці. Встояти перед спокусою. Ви не корите себе таким чином, а потім сподіваєтесь, що його прийняття вийде найкращим чином. Це не так, це просто засмучує вас. Спочатку ви знайдете свій спосіб робити, а потім шукаєте відповідне програмне рішення. Я закінчив використовувати дошки (почав з однієї, але зараз у мене є дві у своїй кімнаті) для відстеження / розвитку історій та техніки Помодоро | Список " Сьогодні робити", щоб відстежувати мої завдання з розвитку, і це friggin 2011. Дотримуйтесь основ, поки ми не отримаємо деякі інтерфейси, такі як "Залізна людина 2" або літаючі машини не з'являться.

Рефлексія, рефлексія, рефлексія

Це я зрозумів як найбільш важливу частину будь-якої методології для окремої людини. Йдеться про розробку цього робочого процесу, який дає вам цілісне уявлення про ваш проект, щоб ви могли відслідковувати, що потрібно робити, і коли легко керувати, і де погані рішення рідко приймаються та виділяються, щоб їх можна було швидко змінити перш ніж вони завдадуть будь-якої шкоди ... але ви не можете просто забрати її з полиці. Почніть звідкись, де завгодно. Ви дотримуєтесь цього, поки він працює. Вкладайте кошти у відстеження хорошого, поганого та іншого. Вдосконаліть свої припущення, а потім відрегулюйте, як ви робите все відповідно. Це єдиний спосіб, який ви збираєтеся покращити.

Роздумуйте про терміни, зосередьтеся на тому, як швидко ви все зробите

Я, мабуть, був як наступний хлопець, коли почав, переслідуючи побачення. Діаграми вигорання? Раніше я думав про них як про спосіб візуалізації моєї програми розвитку у встановлені терміни. Це продуктивність, а не модель оцінки. Час є для того, щоб виміряти свою ефективність, розмірковуючи над виконаною вами роботою протягом певного часового періоду, а не лише якоюсь тупою величиною для відображення відстані до перешкоджання термінів. Реальність полягає в тому, що це робиться, коли це робиться, і ваша методологія повинна це враховувати.

Відповідно відхиліться

Зрештою, хто каже, що ви повинні використовувати історії користувачів чи щось, що ми знаємо з цього питання? Не думай так. Якщо вам більше комфортно думати в особливостях, то будь-яким чином киньте виклик світовій спільноті розвитку і робіть це по-своєму, адже завершення роботи - це все, що має значення в кінці дня. Якщо в кінцевому підсумку ви відчуваєте, що робите щось не так, вітаю - ви щойно зробили висновок, що настав час перейти до чогось іншого. Йдеться про те, що, а не як.

Я відповів би "як ти хочеш покращити спосіб розробки програмного забезпечення?". Що стосується вашої бізнес-моделі, які найбільші проблеми зіткнулися з використанням методології водоспаду?

Чи є ваша мета швидшим розвитком, більш надійним кодом, більшою мірою використання, зустріччю / адаптацією до змін, що змінюються тощо? Існують різні методології для подолання різних проблем.

Звичайно, використання методології дизайну, відмінної від Waterfall, може бути дуже корисним для ефективного управління життєвим циклом проектів залежно від ваших потреб бізнесу. Для спритного розвитку існує величезна кількість ресурсів в Інтернеті. Я б роздивився AUP (Agile Unified Process), який включає TDD (Test Driven Development). Це може бути надзвичайно корисно під час створення / управління великими масштабованими системами.

Не існує методології «один розмір, який відповідає всім», і це є основною причиною величезної кількості різних підходів. Я б почав думати про те, де ви відчуваєте, що вузькі місця є у вашому процесі розвитку, а потім спробую прийняти нову методологію для подолання цього.

Наприклад, чи часто ви не дотримуєтесь строків? Чи вводять нові функції велику кількість помилок? Чи спричиняють нові вимоги серйозні перепланування? Чи потребує бізнес представлення регулярних робочих систем? Перевірте: Agile , Iterative та Agile Intro .